Desenvolvimento

Ξ 1 comentário

Por que gerar valor só no final?

publicado por Flávio Steffens

Por que gerar valor só no final?Uma das formas mais interessantes de ilustrar o ganho com uma metodologia ágil é trabalhar em cima do conceito de valor. Você quer mostrar aos seus colegas a principal diferença entre processos ágeis e processos tradicionais? A resposta para essa pergunta está neste post. Observe o gráfico abaixo. Você consegue associar a relação “esforço x tempo” ao conceito de geração de valor?

O gráfico representa o esforço realizado em um projeto em relação ao tempo. Vamos analisar o que acontece nos dois cenários.

No método tradicional, normalmente se inicia com toda a fase de requisitos. Senta-se com o cliente, discute contrato, depois requisitos de todo o projeto. Raramente são discutidos se os requisitos irão gerar, de fato, valor ao projeto. A idéia aqui é apenas mapear tudo o que o cliente quer. Após a geração de uma vasta documentação (documento de projeto, documento de start-up, declaração do escopo, cronograma, etc. todos – teoricamente – aprovados pelo cliente) o projeto é devidamente iniciado. Nas primeiras reuniões com a equipe são discutidos todos os casos de uso que serão implementados. A equipe acaba começando pelo mais fácil. O cliente só é consultado em pontos pré-definidos  (aprovação de layout, homologação, etc), ou seja, um dia ele verá o sistema… pronto. A equipe normalmente começa a se desesperar ao perceber que não dará conta das deadlines com tantas funcionalidades difíceis a serem implementadas.

O resultado disso? O que era mais difícil foi deixado para o fim. Só que o tempo é cruel e não pára. Logo, o esforço sobe de forma vertiginosa no final do projeto. Cronogramas atrasam, testes e bugs são esquecidos, horas extras explodem, o escopo acaba sendo mudado apenas para agradar o já furioso cliente. Inclusive aquela funcionalidade absurda que foi pedida lá no início do projeto, para que o sistema “toque uma música divertida toda vez que for aniversário de alguém”. Funcionalidade, aliás, que foi uma das mais complexas de serem feitas.

E como seria no método ágil? Temos uma total inversão de mentalidade! Após uma breve discussão de contrato com o cliente, toda a equipe senta com o cliente e as funcionalidades são discutidas. É o momento da criação das estórias. Após terem um material suficiente, o cliente é convidado a priorizar o que é mais importante para ele. Enquanto é discutido isso, uma pessoa da equipe se dá conta da funcionalidade “toque uma música divertida toda vez que for aniversário de alguém” e comenta com o cliente da real necessidade da função. O cliente diz que quer, de fato isso, mas aceita priorizar outras coisas na frente. A equipe inicia o desenvolvimento com base no que foi definido para cada ciclo. O cliente é convidado a participar ativamente do desenvolvimento. Dúvidas são tiradas diretamente com ele. Soluções alternativas são propostas em alguns casos e já no primeiro ciclo o cliente vê funcionalidades importantes do seu sistema entregues. Em alguns casos já pode sair inclusive utilizando! Ao final de um dos ciclos, mesmo antes do final do desenvolvimento de todas as funcionalidades, o cliente já se dá por satisfeito e diz que tem tudo o que precisa. Ele se dá conta que a funcionalidade “toque uma música” de fato era totalmente inútil e pede para a equipe esquecê-la.

O resultado disso? O cliente participa ativamente do desenvolvimento. Ele vê como o seu dinheiro está sendo aplicado, ele sabe de antemão de qualquer problema, ele confia na equipe, ele sabe que pode acrescentar novas funcionalidades quando quiser… para ele fica claro que será desenvolvido o que tem mais valor! E mais do que isso, ele vê valor logo no fim do primeiro ciclo. O prazo é cumprido e, em alguns casos, até mesmo antecipado.

Notem como os dois casos são ilustrados no gráfico. E observem como o método ágil proporciona ao cliente um acompanhamento e, mais do que isso, uma colaboração direta com seus parceiros. O conceito de valor não precisa sequer ser explicado. Se você o compreendeu a mensagem deste artigo, então poderá responder a pergunta que entitula este texto.

Toda vez que você tiver que enfrentar um cliente furioso devido aos atrasos de cronograma, negociações de contrato e demais atritos comuns, lembre-se: com um pouco de vontade isso pode ser mudado ;)

  •  
  •  
  •  
  •  
  •  
  •  
  •  

Compare preços de Uber, 99 e Taxi

Minimum Way

Autor

Flávio Steffens de Castro é empreendedor na Woompa (www.woompa.com.br), criador do crowdfunding Bicharia (www.bicharia.com.br) e gerente de projetos desde 2006. Trabalha com métodos ágeis de gerenciamento de projetos desde 2007, sendo CSM e autor do blog Agileway (www.agileway.com.br).

Flávio Steffens

Comentários

1 Comment

  • Perguntas que não querem calar:
    _ Por que o mais difícil foi deixado para o final? É problema de gerencia?
    _ Se a equipe percebe que não dará conta do Deadline das funções então a estimativa de esforço e prazo estava errada?
    _ E a documentação do novo sistema no método ágil não existe? e se der um problema ou tiver uma mudança eu corrijo no código e não atualizo versões de componentes na Gestão de Configuração? COMO GARANTO RASTREABILIDADE?
    _ Como eu asseguro a qualidade da Entrega? Não tenho padrões de construção? Não faço revisões? Não tenho Plano de testes?
    _E o cliente tem tempo para ficar do seu lado fazendo códigos e validando casos de uso? E as suas atividades ficam com quem?
    _E a Especificação de Requisitos, que possui Requisitos Funcionais e Não Funcionais, O que não é Requisito? Regras associadas a cada função? Que se desdobra em Especificação Técnica com casos de uso e serve para validar as regras, Monitorar o ESCOPO em desenvolvimento? Analisar impactos de mudança, não serve para nada?
    _E as lições aprendidas não foram utilizadas pela equipe para não cometerem erros que anteriormente já foram detectados?
    _ Se os cronogramas atrasam, testes não são realizados e bugs são esquecidos não é um problema de gerência, de planejamento da capacidade da equipe, de seleção do skill correto para o projeto, de aplicação correta de técnicas de medição de esforço e prazo, de negociação do prazo com o cliente? Também não é um problema de falta de compromisso com a excelência do serviço prestado aos clientes, garantindo a eliminação de todos os BUGs?
    _E tudo o que se sucedeu no método tradicional não acontecerá no método ágil?
    _E o plano de riscos do projeto não levou em consideração as complexidades das funções?
    _O cliente não foi alertado?

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade




Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.