Distanásia em Projetos
Eu e minha esposa temos o hábito de conversar sobre o trabalho um do outro quando chegamos em casa. Certo dia conversa vai, conversa vem e eis que surge o termo: distanásia! Na hora parei, pois não conhecia o significado e obtive a seguinte definição: distanásia é uma prática de prolongar a vida de um paciente considerado pela medicina incurável ou sem chances de recuperação. Inevitável para mim não associar isso a projetos! Quantos projetos conhecemos que estão em fase terminal e mesmo assim continuamos a investir nele?
Pesquisando um pouco mais sobre o termo, o Wikipédia apresenta a seguinte definição:
Distanásia é a prática pela qual se prolonga, através de meios artificiais e desproporcionais, a vida de um enfermo incurável.
No mundo dos projetos o que mais vemos por aí são projetos inúteis que nem sequer sabemos por que e para quem estamos fazendo aquilo. Projetos obsoletos ou que já foram superados por uma tecnologia mais avançada, continuam em nossas carteiras. Projetos com desvios de cronograma em 70, 150, 250% que mesmo assim continuam sendo repactuados, com a intenção de que um dia ele seja concluído.
A pergunta é: para que prolongar projetos desta natureza? Se já não faz mais sentido entregar tal projeto, por que continuar investindo?
Nestes casos a mudança de mindset é fundamental e obrigatória, e passa pela célebre frase de Peter Drucker: “Não há nada tão inútil quanto fazer com grande eficiência algo que não deveria ser feito”, ou pela citação de Russel Ackoff “Quanto mais certo fazemos a coisa errada, mais errados nos tornamos”. Precisamos, antes de investir maiores esforços nos projetos, validar a nossa hipótese, ou seja, mudar o paradigma da eficiência para a eficácia e saber de fato se aquilo é o certo a se fazer.
O fato é que as pessoas são resistentes a mudança e o excesso de otimismo atrapalha um pouco. Trocamos o time, contratamos consultoria, pedimos mais recursos e fazemos de tudo para não deixar aquele projeto morrer, sendo que nada mais adianta. Ainda há o apego emocional a determinados projetos até mesmo pessoal quando ao invés do cliente, são os gerentes que julgam se aquele projeto deve ou não ser feito.
E como vamos fugir dessa armadilha? Vou trazer três boas práticas aqui que entendo como essenciais para não chegarmos a esse ponto:
Fail fast: se você tem que falhar, que falhe logo e aprenda com isso. No Brasil essa cultura ainda é pouco explorada, pois errar aqui é muito caro. Outra observação é que ninguém gosta de errar, mas é melhor perder pouco e aprender do que investir demais e perder muito lá na frente.
Ciclos de feedback: trabalhe constantemente com o seu cliente. Peça a ele feedbacks do avanço do seu trabalho, essa pratica diminui o risco. É muito melhor já ir fazendo o certo desde o começo. Imagine um projeto com apenas uma entrega final, o risco do erro é muito maior.
Validar hipóteses: Temos muitas ideias de novos projetos, novos requisitos. Uma extensa lista no backlog. Será que tudo que está ali precisa ser feito? No Software Zen a fórmula é a seguinte: ? min(t) !, onde o ponto de interrogação é a sua hipótese, o ponto de exclamação é a sua hipótese validada e entre um e outro está o tempo. Quanto antes validar, melhor.
Evite o desperdício, não prolongue a vida de um projeto fadado ao fracasso. Quantos milhões são gastos anualmente para corrigir falhas ou repactuar projetos? Você não vai acertar sempre, mas pode aumentar muito este percentual.
Sobre o autor
- Sólida experiência em Metodologias Ágeis e Engenharia de Software, com mais de 15 anos atuando como professor de Scrum e Kanban. No Governo do Estado do Espírito Santo, gerenciou uma variedade de projetos, tanto na área de TI, como em outros setores. Sou cientista de dados formado pela USP e atualmente estou profundamente envolvido na área de dados, desempenhando o papel de DPO (Data Protection Officer) no Governo.
Últimos Posts
- Outros Temas4 de setembro de 2024RMC – ROPA Model Canvas
- Outros Temas28 de agosto de 2024Adequação à LGPD e os desafios do Encarregado Interno
- IT1 de julho de 2024Event Storming nella pratica – Post 1
- Engenharia de Software18 de junho de 2024Event Storming na prática – Post 1
Deixe uma resposta
Want to join the discussion?Feel free to contribute!