Segundo o diretor de tecnologia Jean Pierre Lessa e Santos Ferreira, existe uma tensão estrutural em todo processo de estimativa de software que raramente é discutida com honestidade: quem pede a estimativa quer certeza, e quem estima sabe que certeza não existe. O resultado dessa tensão é uma dança bem conhecida em que o desenvolvedor ou gerente de projeto oferece um número com mais confiança do que a situação justifica, o cliente ou stakeholder trata esse número como compromisso, e, quando a realidade diverge da estimativa, o problema é enquadrado como falha de entrega e não como a imprecisão inerente de qualquer processo de estimação de trabalho criativo e complexo.
Se você já se comprometeu com um prazo que sabia que era otimista demais, ou se já recebeu uma estimativa que se revelou completamente equivocada sem que ninguém conseguisse explicar onde o cálculo falhou, este artigo vai nomear os mecanismos que produzem esse padrão e oferecer alternativas que funcionam melhor na prática.
Leia até o final: aprender a estimar com honestidade é uma das habilidades que mais diferenciam profissionais de tecnologia que constroem confiança duradoura dos que explicam atrasos permanentemente.
Por que estimativas de software são estruturalmente imprecisas e quais são os mecanismos que tornam o problema sistemático?
Como destaca Jean Pierre Lessa e Santos Ferreira, o desenvolvimento de software é fundamentalmente diferente de outras formas de produção em um aspecto que torna a estimativa particularmente difícil: cada projeto envolve resolver problemas que nunca foram resolvidos exatamente dessa forma antes. Construir o mesmo sistema duas vezes seria mais rápido na segunda vez porque os problemas já foram encontrados e resolvidos. Mas, na prática, cada sistema é diferente o suficiente dos anteriores para que a experiência passada ofereça referências, mas não certezas. Essa novidade intrínseca é a origem principal da imprecisão das estimativas, e ela não desaparece com mais experiência ou com processos mais rigorosos.
O viés do planejamento, documentado extensivamente pela psicologia comportamental, é outro mecanismo que sistematicamente produz estimativas otimistas. Quando as pessoas estimam o tempo necessário para completar uma tarefa, tendem a focar no cenário em que tudo corre como planejado e subestimar a probabilidade e o impacto de imprevistos. Em projetos de software, em que imprevistos como integrações mais complexas do que o esperado, requisitos que se revelam ambíguos durante a implementação e dependências técnicas não identificadas no planejamento são a regra e não a exceção, esse viés produz estimativas que seriam precisas apenas se nada de inesperado acontecesse, o que raramente é o caso.
Como comunicar incerteza de estimativas de forma que preserve a confiança da relação com stakeholders e clientes?
A abordagem mais eficaz de comunicação de incerteza em estimativas é o uso de intervalos em vez de pontos únicos. Em vez de dizer que um projeto vai levar três meses, comunicar que, com base no que foi levantado até agora, o intervalo mais provável é entre dois meses e meio e quatro meses, dependendo de como certas incertezas se resolverem ao longo do desenvolvimento, transmite a mesma informação de forma significativamente mais honesta. Esse tipo de comunicação não diminui a confiança quando é bem explicada: a maioria dos clientes e stakeholders que entendem como o desenvolvimento funciona na prática prefere honestidade sobre incerteza a falsa precisão que vai ser contrariada pela realidade.
Assim como pontua Jean Pierre Lessa e Santos Ferreira, a explicação explícita das premissas que sustentam a estimativa é um complemento essencial à comunicação de intervalos. Uma estimativa é sempre condicional: ela é válida enquanto certas premissas sobre escopo, equipe, dependências e requisitos se mantêm verdadeiras. Tornar essas premissas explícitas permite que qualquer mudança em uma delas seja rapidamente conectada ao impacto na estimativa, transformando a conversa sobre atraso de uma discussão sobre quem falhou para uma análise de quais premissas se revelaram incorretas e o que precisa ser ajustado a partir daí. Essa abordagem, além de ser mais honesta, cria um framework compartilhado de entendimento que facilita a tomada de decisão quando as circunstâncias mudam.
A revisão regular das estimativas à medida que o projeto avança e mais informação se torna disponível é uma prática que as metodologias ágeis incorporam formalmente, mas que frequentemente não é comunicada com clareza suficiente para stakeholders que ainda operam com a mentalidade de que a estimativa inicial é o compromisso definitivo. Explicar desde o início que estimativas são revisadas periodicamente com base em aprendizados do desenvolvimento, e que revisões para cima ou para baixo são parte normal do processo e não indicadores de falha, estabelece expectativas mais realistas sobre a natureza do processo de planejamento e reduz o choque quando as primeiras revisões ocorrem.
Quais práticas de estimativa produzem previsões mais úteis do que o número pontual que todo cliente quer ouvir?
O planejamento baseado em throughput, que usa dados históricos reais sobre a velocidade de entrega do time para projetar datas prováveis de conclusão, é uma das abordagens mais sólidas disponíveis para times que já têm histórico de projetos anteriores. Em vez de estimar cada tarefa individualmente e somar as estimativas, essa abordagem usa a distribuição estatística do que o time efetivamente entregou em sprints anteriores para criar uma projeção probabilística do que pode ser entregue em um determinado horizonte de tempo.
O refinamento progressivo do escopo antes de se comprometer com estimativas de prazo é uma prática que reduz a principal fonte de imprecisão em estimativas iniciais: a ambiguidade de requisitos. Projetos em que o escopo foi completamente detalhado, com casos de uso, critérios de aceitação e dependências técnicas mapeadas, têm estimativas significativamente mais precisas do que projetos em que a estimativa foi feita com base em uma descrição de alto nível. Conforme elucida Jean Pierre Lessa e Santos Ferreira, investir tempo em discovery e refinamento antes de dar um número de prazo não é procrastinação: é a única forma de produzir uma estimativa que tem base factual suficiente para ser útil.
A separação explícita entre estimativas de esforço e compromissos de prazo é o último componente de uma abordagem de estimativa mais honesta. Esforço é uma previsão sobre quanto trabalho uma funcionalidade ou projeto vai requerer, e é uma previsão que pode ser feita com alguma confiança por profissionais experientes no domínio. Prazo é uma função do esforço, da disponibilidade da equipe, das prioridades concorrentes e dos imprevistos que vão ocorrer durante o projeto, e a tradução de estimativa de esforço em compromisso de prazo sempre envolve premissas sobre variáveis que não são completamente conhecidas.
Autor: Diego Rodríguez Velázquez
