team-612x400.jpeg
team-612x400.jpeg

Projetos limitados por estimativas estão fadados ao fracasso – ou os benefícios de métodos (verdadeiramente) ágeis

As estimativas formam a base de muitos projetos de TI. Estimamos organizar um projeto, estimamos estabelecer um cronograma, estimamos determinar uma data de entrega, estimamos comprometer e contratar… e acima de tudo, usamos essas estimativas preliminares para julgar o sucesso ou o fracasso de um projeto. Um projeto é considerado bem-sucedido quando o prazo é cumprido, é considerado fracassado quando o prazo é excedido. No Web2day, Frédéric Leguedois, Agile Evangelist do Cloud Temple, oferece outra leitura. E se todos os projetos já estivessem fracassando quando uma estimativa é feita?

As justificativas preferidas pelos gerentes de projeto

Muitas vezes acontece que os projetos com prazo não são entregues no prazo. Nesse caso, os gerentes geralmente encontram desculpas.

“Meu planejamento foi bom, mas o cliente mudou de ideia”

Esta primeira justificação é difícil de justificar. O fato de o cliente mudar de ideia não é uma coisa ruim em si. Ele refletiu, seu projeto amadureceu, ele acredita que uma modificação pode ser útil para os usuários. É potencialmente bom, mas não é compatível com os horários.

“Meu planejamento foi bom, mas os desenvolvedores estão atrasados”

No segundo caso, dizer que os desenvolvedores estão atrasados ​​coloca em dúvida sua competência. Eles estão atrasados: entendem mal ou com defeito. No entanto, Frédéric Leguedois acredita que a culpa é de quem faz o planejamento, não de quem faz o trabalho. “Atraso é uma diferença de tempo entre o que é esperado e o que realmente aconteceu. É a diferença entre um sonho e a realidade. A realidade não pode estar errada, mas o planejamento não pode. É como as previsões do tempo: elas têm uma certa confiabilidade, enquanto o tempo é necessariamente exato” .

“Meu planejamento foi bom, mas houve imprevistos”

Os imprevistos têm a capacidade de justificar todos os problemas que os projetos podem enfrentar. Se o prazo não foi respeitado, muitas vezes é porque as varetas ficaram presas nas rodas dos membros que trabalham em um projeto. Podemos ver esses eventos como imprevistos, também podemos aceitá-los e considerar que é impossível prever e planejar tudo. “Planejamento é uma profissão: a de clarividentes, a de oráculos e, às vezes, a de gerentes de projeto” .

A receita milagrosa para a agilidade autoproclamada

Para acabar com esses atritos e projetos imperfeitos, “todo mundo está falando em agilidade”. Assim que usado, também banal. Embora os princípios de agilidade e o pensamento que envolve esses conceitos sejam bons, muitas vezes tendemos a colocar termos relacionados à agilidade em todos os lugares, para provar sua modernidade. “Pegamos o gerente de projeto, ele se torna o proprietário do produto, instalamos o Jira, colocamos a palavra Agile no folheto de vendas: e de repente, todos os problemas desaparecem, como que por mágica” .

Claro que a realidade é bem diferente. Sem formação em métodos ágeis, sem explicação do seu interesse pela gestão de projetos e, sobretudo, sem uma mudança de mentalidade na gestão eficaz dos projetos, estes últimos não podem ser melhor geridos. “Quando você muda a terminologia e não muda a realidade, as mesmas causas levam às mesmas consequências. As ligações causais são imutáveis. Você tem que repensar a forma de operar e não fazer mais planejamento só porque é tradição, porque sempre fizemos assim” .

post-it-612x405.jpg
post-it-612×405.jpg

O impacto das estimativas na produtividade do desenvolvedor

Segundo Frédéric Leguedois, as estimativas têm pelo menos duas consequências nefastas. Primeiro, quando feito, eles são o único indicador do sucesso de um projeto (quando, na realidade, um projeto pode ser entregue no prazo e falhar). A segunda consequência diz respeito às equipes de desenvolvedores. Digamos que a equipe tenha um prazo na quinta-feira à noite. No final da tarde, eles entendem que não conseguirão entregar as funcionalidades finalizadas no prazo. Eles então têm a escolha:

  • Adiar a produção para uma data posterior
  • Colocado em produção na data acordada, apesar dos bugs

Os desenvolvedores escolherão com base nas consequências de sua escolha. Se não entrar em operação a tempo os expor a culpa significativa do gerente de projeto, gerenciamento ou cliente, eles entrarão em operação – apesar dos riscos inerentes ao MEP. Caso contrário, se o product owner e os demais elos da cadeia entenderem que esse atraso é mais prudente, não hesitarão em falar sobre isso, adiar o início da produção se necessário e continuarão trabalhando até que as funcionalidades estejam concluídas. “Parar de estimar é entregar funcionalidades que funcionam. O prazo leva ao medo” . Alguns continuarão esta observação especificando que“o medo leva à raiva, a raiva leva ao ódio, o ódio… leva ao sofrimento” .

O planejamento também resulta na geração de dívida técnica. “Para quem não conhece o assunto, dívida técnica corresponde a um empréstimo feito ao banco. Você não tem recursos para comprar um carro, você faz um empréstimo, você paga seu carro e uma dívida em vários meses. A dívida técnica é exatamente o mesmo princípio: você não tem tempo para fazer um bom trabalho, você faz um trabalho ruim, os usuários não o veem, mas todas as alterações feitas posteriormente serão mais longas, mais arriscadas e, portanto, mais caras.

O fato de forçar os desenvolvedores a prazos mais ou menos aleatórios também tem o efeito de rebaixá-los ao papel de simples executores. A mensagem é: “você tem que fazer isso para esta data”. Um desenvolvedor precisa de tempo para tomar iniciativas, projetar, discutir com seus pares. Ao basear sua organização em prazos, você força os desenvolvedores a uma função restrita, seu valor agregado é limitado, sua motivação é de fato degradada.

team-612x400.jpeg
team-612×400.jpeg

O problema dos métodos de estimação

O principal problema com os métodos de estimativa é que eles nunca são confiáveis. Os gerentes de projeto estimam os prazos relendo as especificações várias vezes (o famoso método do dedo molhado).

Os clientes apresentam suas necessidades muito brevemente para que uma estimativa coerente seja feita. “Primeiro queremos saber o orçamento necessário, depois especificaremos nossas especificações. Experimente este método com o seu merceeiro, vá vê-lo e simplesmente pergunte-lhe quanto vai custar-lhe sem lhe dizer exatamente o que quer comprar. É apenas em TI que esse tipo de método persiste” .

Outros métodos como o COCOMO (COnstructive COst MODel) tentam prever o imprevisível com fórmulas mais ou menos científicas. Aqui, o número de linhas de código esperado permite saber o tempo necessário para o desenvolvimento do projeto. Mas o número de linhas de código não é conhecido antecipadamente e nem todas as linhas de código requerem o mesmo tempo de desenvolvimento. Frédéric Leguedois também acredita que os processos para facilitar as estimativas no método SCRUM (como o planning poker) também apresentam falhas. No início do sprint, você gastará tempo estimando o imprevisível; no final do sprint, você passará algum tempo tentando descobrir por que seu palpite inicial não se confirmou.“Planejar o pôquer é uma prática de adivinhação pseudo-ágil extremamente demorada e complexa e, portanto, cara, destinada a adivinhar informações que ninguém precisa. Traduz a desconfiança de quem a coloca em prática, pois um prazo está sempre atrelado à desconfiança” .

Que solução, além das estimativas?

A conferência de Frédéric Leguedois na Web2day, que quase assumiu os códigos do one man show, foi oferecida com o objetivo de fazer pensar as pessoas que participam dos projetos. Segundo ele, para permitir que os projetos sejam verdadeiros sucessos, é preciso começar parando com a gestão por medo. “Temos que parar de dizer que temos que fazer tal e tal coisa para tal data. Devemos deixar os desenvolvedores discutirem, trocarem, encontrarem soluções. As pessoas não precisam de um prazo para compartilhar, basta motivação. Você tem que criar uma emulação para que os desenvolvedores se orgulhem de seu trabalho e compartilhem com a equipe” .

Mas como vender um projeto para um prospect sem depender de estimativas, quando os clientes estão acostumados a comprar especificações associadas a um preço e um prazo?“Na realidade, os clientes escolhem os projetos em que confiam. Se queremos parar de fazer estimativas, temos que ir aos clientes, explicar o interesse de nossos métodos para gerar confiança. Aqueles que experimentaram projetos de preço fixo insatisfatórios o entenderão. A variável de ajuste deve ser sempre o escopo de um projeto e não sua qualidade, custo ou prazo. Nada é indivisível, tudo é um conjunto de características. Quando começamos com as funcionalidades prioritárias, quando confiamos nos desenvolvedores, quando deixamos de fazer promessas, quando nos adaptamos ao contexto, estamos realmente em agilidade e os projetos dão certo”.