Por que estimativas de software falham — e como reduzir o erro

Estimativas falham quando tratam incerteza como compromisso. A pesquisa aponta um caminho mais confiável: combinar métodos, usar dados do próprio contexto e revisar previsões conforme o projeto avança.

Por que estimativas de projetos de software falham?

Uma estimativa de software falha quando é tratada como uma medição exata, embora tenha sido produzida com informações incompletas. Antes do desenvolvimento, ainda existem dúvidas sobre regras de negócio, integrações, comportamento dos usuários, qualidade dos sistemas existentes e decisões técnicas. Cada dúvida pode alterar o esforço necessário. Quanto mais cedo surge a exigência de uma data fechada, maior tende a ser a parcela de premissas embutida no prazo.

Também existe uma diferença importante entre esforço e duração. Esforço representa o trabalho necessário; duração representa o tempo transcorrido até a entrega. Acrescentar pessoas pode aumentar a capacidade em algumas atividades, mas não elimina dependências, tempo de comunicação, revisões ou tarefas que precisam ocorrer em sequência. Uma estimativa de esforço razoável pode, portanto, gerar uma previsão de calendário ruim quando disponibilidade da equipe, dependências externas e filas de decisão não são consideradas separadamente.

O terceiro problema é organizacional: a previsão frequentemente se transforma em meta comercial, orçamento aprovado ou promessa a investidores. Essa conversão não torna o número mais preciso. Ela apenas muda o custo de revisá-lo. Em um conjunto de projetos de uma mesma empresa de outsourcing, estimativas selecionadas entre duas ou mais alternativas tiveram desempenho razoável: 63% ficaram dentro de 25% do esforço realizado, com erro absoluto médio de 0,26 [1]. O resultado mostra que um processo estruturado pode funcionar, mas não autoriza esperar a mesma precisão em qualquer empresa ou projeto.

Um modelo isolado não resolve a incerteza

Não existe um método de estimativa que seja consistentemente superior em todos os conjuntos de dados. Uma avaliação de modelos de inteligência computacional encontrou desempenho instável dos modelos individuais entre diferentes bases; mesmo os modelos combinados não produziram um vencedor consistente em todas elas [2]. Para quem contrata software, a implicação é direta: uma planilha, fórmula ou algoritmo não deve ser tratado como fonte universal da verdade.

Modelos paramétricos dependem da relação entre tamanho, esforço e duração observada nos dados usados para construí-los. A investigação de modelos clássicos encontrou relações gerais compatíveis com algumas premissas, mas um dos modelos avaliados estimou mal os custos naquele conjunto de dados, enquanto a distribuição temporal observada também não seguiu o formato previsto por outro modelo [3]. O mesmo trabalho indicou que modelos adaptados ao ambiente específico podem ganhar precisão e ser atualizados com informações das primeiras fases do desenvolvimento [3].

Estimativas por especialistas e por analogia também têm limitações. A literatura resumida em uma pesquisa sobre novos métodos de estimativa aponta falta de dados históricos, indisponibilidade de especialistas e vieses de opinião como problemas dessas abordagens [4]. Isso não torna o julgamento humano inútil. Significa que a opinião deve revelar suas premissas e ser confrontada com outras referências, em vez de aparecer como um único número sem memória de como foi produzido.

O que reduz o erro na prática?

A melhor defesa contra o erro não é aumentar artificialmente a margem, mas tornar o processo de estimativa verificável e revisável. Um processo consistente registra o que está incluído, quais condições precisam permanecer verdadeiras e quais eventos exigem nova previsão. Assim, uma mudança relevante de escopo deixa de parecer um atraso inexplicável e passa a ser reconhecida como alteração da base usada para estimar.

Uma sequência aplicável a projetos novos ou evoluções relevantes é:

1. Definir entregáveis e critérios de aceite antes de estimar, separando requisitos confirmados de hipóteses ainda abertas.
2. Decompor o trabalho até que dependências, integrações e atividades de validação fiquem visíveis, sem fingir que cada tarefa pode ser prevista com precisão extrema.
3. Produzir estimativas independentes por mais de uma perspectiva, como julgamento técnico, comparação com entregas anteriores e um modelo baseado em dados internos.
4. Expressar a previsão como faixa ou cenários, registrando as premissas que diferenciam um resultado mais favorável de outro mais conservador.
5. Comparar estimado e realizado durante o desenvolvimento, revisar o prazo quando surgirem evidências e preservar o histórico para estimativas futuras.

Combinar perspectivas não significa calcular uma média automática. Se o histórico interno pressupõe uma integração conhecida, mas o projeto depende de um sistema sem documentação, a divergência contém informação: existe um risco que precisa ser investigado. A pesquisa com modelos de conjunto reforça o valor potencial de combinar abordagens, embora também mostre que nenhuma combinação foi consistentemente a melhor em todos os dados avaliados [2]. O benefício está na confrontação de erros diferentes, não em uma garantia matemática de acerto.

Prazo confiável exige atualização, não adivinhação

Uma estimativa deve ser atualizada quando novas evidências alteram as premissas originais. A descoberta de regras de negócio, a implementação de uma integração inicial e a validação de uma arquitetura fornecem informações que não existiam na proposta. O estudo sobre modelos de custo adaptados ao ambiente observou que incorporar o esforço conhecido das fases iniciais pode melhorar a precisão ao longo do ciclo de desenvolvimento [3]. Revisar não é apagar o compromisso anterior: o registro deve conservar a previsão original, as mudanças encontradas e o efeito esperado sobre esforço e duração.

Faixas são mais honestas que datas únicas, mas precisam orientar decisões. Uma faixa sem premissas pode virar apenas uma margem ampla de proteção. Cenários úteis explicam o que leva a cada resultado: disponibilidade de especialistas do cliente, estabilidade do escopo, acesso a ambientes, qualidade dos dados legados e quantidade de validações externas. Quando o negócio exige uma data fixa, a variável de ajuste pode precisar ser o escopo; quando o escopo é regulatório ou contratualmente rígido, capacidade e data precisam ser negociadas com base nos riscos identificados.

Na experiência profissional da Phurshell, acumulada em mais de 15 anos de mercado e mais de 100 aplicativos entregues para empresas brasileiras, as conversas mais produtivas começam pela decisão que o prazo precisa sustentar. Uma estimativa para avaliar a viabilidade de uma ideia não requer o mesmo nível de decomposição de um compromisso contratual. Essa observação é experiência da empresa, não uma estatística do mercado: o ponto prático é ajustar o custo da estimativa ao custo de errar.

Referências

1. Barbara Ann Kitchenham, Shari Lawrence Pfleeger, Beth McColl et al. (2002). An empirical study of maintenance and development estimation accuracy. doi:10.1016/s0164-1212(02)00021-3
2. Mahmoud O. Elish, Tarek Helmy, Muhammad Imtiaz Hussain (2013). Empirical Study of Homogeneous and Heterogeneous Ensemble Models for Software Development Effort Estimation. doi:10.1155/2013/312067
3. Barbara Ann Kitchenham, Nolan Taylor (1985). Software project development cost estimation. doi:10.1016/0164-1212(85)90026-3
4. Mansoor Ahmed, Naeem Iqbal, Faraz Hussain et al. (2022). Blockchain-Based Software Effort Estimation: An Empirical Study. doi:10.1109/access.2022.3216840