Por que os projetos de desenvolvimento falham?

Você sabia que cerca de 70% dos projetos de TI têm algum tipo de falha? Neste artigo gostaria de resumir o que estamos aprendendo a respeito deste assunto com o estudo de XP**.

As principais causas de falha são:

• Falta de proximidade com o cliente,
• Trabalho empurrado goela abaixo do time,
• Codificação a toque de caixa produzindo código sujo,
• Tempo desperdiçado desenvolvendo o que o cliente não pediu (a famosa cereja do bolo)
• E o retrógrado hábito de testar o software apenas na véspera da sua data de entrega.

Vamos agora explorar um pouco cada tema:

1 — Cliente distante

É normal ter dúvidas durante o desenvolvimento. Neste momento procuramos o Analista ou o PO e é normal que eles não tenham a resposta. Nesse momento precisamos do cliente.

É também “normal” que ele não esteja disponível ou não esteja com vontade de se envolver, afinal ele já pagou uma boa grana e não quer ser responsável por um erro de trajeto. Chamamos isso de cliente distante. Projetos assim tem grande chance de dar errado

Solução:

Precisamos deixar bem claro desde o início que em cada projeto ele poderá ser chamado para tirar dúvidas ou validar uma funcionalidade e ele precisará estar disponível.

Pedir o aceite do cliente não é o mesmo que testar. Testar é responsabilidade da equipe de desenvolvimento, dos desenvolvedores e acredite se quiser, normalmente eles não gostam de fazer isso. O que queremos do cliente é um feedback.

E se o cliente odiar a funcionalidade? Ótimo! Melhor no início do projeto que no momento da entrega a gente descobrir que várias coisas não saíram conforme era esperado por ele.

2 — A cereja do Bolo

Por que muitas vezes queremos entregar mais que o cliente pediu? Por que falhamos em outras entregas? Devemos entregar somente o que o cliente pediu.

Se ele pediu um relatório com as colunas A,B,C, devemos nos limitar a elas e evitar de entregar um relatório com A,B,C, X e Y. O cliente tem expectativas importantes:

• 1 — Receber exatamente o que pediu
• 2 — Receber o mais rápido possível
• 3 — Receber com a mais alta qualidade e no menor custo

Fazer algo a mais não vai ajudá-lo com as falhas anteriores e nem com as futuras.

Solução:

Simplicidade, maximizar a quantidade de trabalho que não precisou ser feito. A meta do time é trabalhar com o cliente para enxugar a quantidade de features que precisa ser feita. Muitos métodos não são simples para medir valor ou ROI. Uma simples classificação no entanto pode ser suficiente.

Nessa linha, primeiro examinamos quem tem alto risco e alto valor para ver se teremos problemas aí. (Falhar rápido) O mundo perfeito é trabalhar no alto valor e baixo risco. Definitivamente, não queremos trabalhar no que tem baixo valor

3 — Teste só no final

Temos um problema de não entender o valor de testes, sua relação com a qualidade e o fato de só acontecerem no final e isoladamente. Com isso, pagamos o alto preço do retrabalho. Isso gera desconfiança e estressa a relação de trabalho.

Solução:

Não podemos ter aquele conceito “está pronto e só falta testar”. Em algumas organizações há o chamado Teste Sistêmico (tempo reservado para retestar o sistema, considerando inclusive o aspecto de integração e efeitos colaterais das alterações de outros times).

Minha visão é que este conceito vai contra a ideia do Pronto. Um time ágil deve garantir que a entrega está pronta para ir para produção em cada sprint ou iteração.

Caso contrário, se cria um débito invisível e não gerenciado. Desta forma o teste não pode ser encarado como uma etapa à parte. As funcionalidades devem ser testadas o mais brevemente possível. Um padrão que ajuda muito nisso é o Desenvolvimento Guiado a Testes, TDD.

4 — Trabalho empurrado

O gerente comunica que fechou um projeto e já tem data. Além disso, comunica que não há a menor chance de alterar esta data. O time começa a trabalhar, gerar tarefas e descobre que para cumprir a data, que inclusive consta no contrato, precisará de uma velocidade muito acima da praticada normalmente.

Ao notar isso, o nível de stress no time sobe, começando a gerar código sujo, mal estruturado e em cima de requisitos mal concebidos. Com o tempo curto, ninguém quis “perder tempo” com uma especificação de mais qualidade e foram todos para o código.

Solução:

Trabalho puxado! O time tem uma capacidade e não adianta querer pedir para correrem. Se o projeto não cabe, temos que pensar em outras soluções. Quando o Dev termina uma tarefa, ele vai até o board e puxa a próxima, lembrando-se de desenvolver com qualidade.

Importante seguir a prioridade estabelecida na fila, exceto nos casos de módulos/tecnologia que não conhece. Porém, são ótimas oportunidades para parear com alguém.

5 — Dívidas Técnicas

O time começa um novo projeto à toda, com produtividade alta e moral alta. Com o passar das semanas a produtividade cai um pouco, mas ainda estão trabalhando bem. Mais algumas semanas e vários bugs aparecem, a produtividade está baixa e a moral também. O que está acontecendo? Dívidas técnicas!

São códigos fontes escritos de qualquer forma, sem refatorar, sem testes automatizados e sem padrões. Com o tempo, esses códigos atrapalharão os desenvolvedores e alterações simples levarão grande quantidade de tempo.

Em alguns casos nos deparamos com uma funcionalidade em que é praticamente impossível evoluí-la e somos obrigados a refazê-la com grande desperdício de tempo e dinheiro. Muitos ainda não entendem que qualidade de software está intimamente relacionada à qualidade de código. Mas um dia a conta chega.

Solução:

Produzir requisitos com o formato de User stories ou equivalentes, codificação que seguem padrões de qualidade como TDD e clean code, programação em pares, refatoração constante (Lema do escoteiro — deixe sempre mais limpo do que encontrou), Integração contínua, boas práticas e ritmo sustentável.

Faz sentido pra você? Deixe seus comentários, pois como disse, estamos aprendendo e buscamos através das opiniões e do conhecimento dos profissionais ampliar a nossa forma de pensar e entregar soluções.

Créditos:

*Seventy Percenty not Success — https://www.hyland.com/en/complete-view/articles/standard/seventy-percent-not-successful,

**eXtreming Programming -Práticas para o dia a dia no desenvolvimento de software — Daniel Wildt, Dionatan Moura, Guilherme Lacerda, Rafael Helm