- Estimar com precisão a duração de projetos de software é impossível, e a maior parte do trabalho é dominada por “desconhecidos” imprevisíveis
- Estimativas são usadas como ferramenta política da gestão, não da engenharia, servindo para definir prioridades de projeto e alocação de verba
- Na prática, a estimativa define o trabalho, e as equipes trabalham encontrando uma abordagem técnica viável dentro do prazo dado
- Para estimar de forma eficaz, engenheiros devem se concentrar em entender o contexto político, avaliar riscos desconhecidos e apresentar múltiplos cenários de execução
- Essa abordagem prioriza confiança e colaboração realista acima da precisão, e enfatiza a capacidade de engenharia de compreender a estrutura de tomada de decisão dentro da organização
A ficção da estimativa de software
- Na indústria, existe uma “ficção educada” de que equipes experientes conseguem prever cronogramas com precisão com esforço suficiente
- Na realidade, a maioria dos engenheiros reconhece que previsões precisas são impossíveis
- Algumas equipes usam dimensionamento por tamanhos de camiseta (t-shirt sizing), mas isso acaba sendo convertido em unidades de tempo e repassado à camada de gestão
- Às vezes são usados heurísticos irreais como “pegue a estimativa inicial, dobre e adicione 20%”
Por que estimar é impossível
- Trabalhos pequenos e claros são previsíveis, mas a maioria dos projetos ocorre em sistemas incertos e complexos
- Ex.: alterar o texto de um link simples pode ser previsto em 45 minutos, mas mudanças em sistemas de grande porte não
- A maior parte da programação é uma atividade exploratória de pesquisa, na qual não dá para saber antecipadamente qual trabalho será necessário apenas com planejamento prévio
- O antigo modelo de projeto arquitetural centralizado fracassou, e quem precisa tomar decisões são os desenvolvedores que lidam com o código real
- Como resultado, o trabalho conhecido representa apenas 10% do total, e os outros 90% não podem ser estimados por estarem no domínio do desconhecido
Estimativa é uma ferramenta da gestão, não da engenharia
- Estimativas não têm relação com aumentar a produtividade da equipe, e muitas equipes eficientes trabalham sem elas
- A gestão tenta ajustar a estimativa ao resultado desejado: cronogramas longos sofrem pressão para encurtar, e cronogramas curtos recebem pedidos para adicionar buffer
- Apenas projetos tecnicamente impossíveis conseguem, excepcionalmente, levar a julgamentos realistas
- Em áreas de baixo interesse dentro da organização, procedimentos formais podem continuar intactos
- Portanto, a estimativa funciona como um instrumento político pelo qual não engenheiros escolhem ou cancelam projetos
A estimativa define o trabalho
- Ao contrário da percepção comum, não é o trabalho que vem primeiro, e sim a estimativa, e a abordagem técnica é definida a partir dela
- Ex.: a forma de implementar um recurso de “conversar com PDFs” em 6 meses é completamente diferente da forma de fazê-lo em 1 dia
- A restrição de tempo determina a profundidade e a qualidade do design do código, e os engenheiros escolhem a solução possível dentro do prazo dado
Como a estimativa acontece na prática
- Primeiro, é preciso entender o contexto político para compreender a importância do projeto e o prazo esperado
- Depois, explorar abordagens possíveis com base no prazo já definido
- Quanto mais áreas desconhecidas (unknowns) houver, maior será a estimativa, e mais o escopo da abordagem precisará ser reduzido
- No fim, em vez de um prazo exato, o ideal é apresentar avaliação de risco e vários cenários de execução
- Ex.: resolver tudo diretamente, contornar parte do problema, pedir apoio de outra equipe etc.
- O papel do engenheiro não é “quanto tempo vai levar?”, mas “que método é viável dentro do prazo dado?”
Objeções e respostas
- Alguns engenheiros evitam estimar em condições incertas, mas isso apenas faz com que uma pessoa não técnica estime no lugar deles
- Uma postura de confronto constante com a gestão, sem cooperação, é improdutiva e enfraquece a confiança
- Equipes que não sentem pressão podem simplesmente estar em áreas fora do foco de interesse da organização
Conclusão
- Na prática, gestores já abordam a equipe com um prazo em mente, e a equipe procura uma solução técnica possível dentro dele
- A estimativa é uma ferramenta de negociação entre gestores, e apenas projetos impossíveis conseguem, excepcionalmente, comunicar a realidade
- Uma boa estimativa deve incluir não um número exato, mas a apresentação de riscos e opções
- A estimativa precisa de trabalho de software é impossível, e estimar bem depende da capacidade de reconhecer riscos desconhecidos e administrá-los
2 comentários
> Primeiro, entender o contexto político para compreender a importância do projeto e o cronograma esperado
> Depois, explorar abordagens possíveis com base no prazo já definido
Opa
Comentários do Hacker News
Compartilho minha tabela de critérios de estimativa de projeto, meio na brincadeira
Projetos internos (ex.: migração de fornecedor, sem impacto para o usuário): defino um prazo que dê para convencer o chefe
Projetos com impacto para o usuário (ex.: adicionar nova funcionalidade): seguem enquanto o ROI for positivo
Projetos que exigem colaboração com parceiros externos: o time comercial define a entrega, e a engenharia ajusta levemente a definição do MVP para caber no cronograma
Eu me perguntava por que ninguém estava falando de planning poker ou story points
Não é perfeito, mas é um método bem razoável. Todo trabalho precisa caber dentro de um sprint, e se for grande demais, tem que ser quebrado
O time inteiro precisa concordar com os pontos, e nesse processo surge o verdadeiro valor da discussão
Depois de alguns meses, a velocidade da equipe se estabiliza e passa a ser previsível com algo em torno de ±10% de precisão
Não é mágica, mas ajuda a entregar valor de forma consistente e a reavaliar a relação custo-benefício a cada sprint
Quem acabou de entrar pode levar mais que o dobro do tempo no mesmo ticket
Além disso, a organização cria regras como terminar review de PR em 24 horas, o que acaba destoando da realidade
Desenvolvedores e QA estimam comparando complexidade juntos, e o QA avalia a dificuldade dos testes e a possibilidade de automação
Graças a isso, a métrica de velocidade de desenvolvimento é estável e as estimativas por versão são bem precisas
Só fazem sentido quando o time inteiro tem um entendimento comum da unidade mínima e consegue convertê-la em tempo
No fim, nesse caso é melhor simplesmente usar tempo, então os pontos em si se tornam desnecessários
Eu faço estimativas com base em intervalos de confiança, perguntando em unidades de “2 horas, 2 dias, 2 semanas, 2 meses, 2 anos”
Se o intervalo estiver amplo demais, eu quebro mais; se isso não for possível, avalio se vale a pena gastar tempo levantando mais informações
Se não valer, o projeto é descartado
Se você definir claramente o resultado e dividir a ideia em etapas menores, dá para fazer estimativas realistas
Se não dá para quebrar em blocos de um dia ou uma semana, então o planejamento ainda está insuficiente
Nesses casos, acho difícil estimar, porque o processo consiste justamente em seguir tentando abordagens diferentes e aprendendo
Isso faz você pensar em termos de ação, e não só de duração estimada
Uma vez estimaram em um sprint uma simples migração de senhas em texto puro para hash, mas na prática levou 6 meses
Descobrimos porque um cliente mostrou em vídeo que usava a senha sem diferenciar maiúsculas e minúsculas
Além disso, a imagem de PHP foi removida e ainda tivemos falha de build
Estimar é sempre uma aventura divertida
Ele mostra estatísticas de estouro de orçamento com base em dados reais de projetos
Projetos de TI estouram em média 73%, sendo piores apenas que depósitos de resíduos nucleares, Olimpíadas e hidrelétricas
18% dos projetos de TI estouram mais de 50%, e a média de estouro desses casos é de 447%
No fim, isso mostra que, na maioria dos setores, as estimativas são estruturalmente otimistas
Acho curioso que tantos engenheiros e gestores não façam estimativas com base em métricas de projetos passados
Observando os dados de throughput do time, dá para calcular um prazo aproximado e intervalos de confiança (ex.: 90%, 70%, 50%)
Assim, dá para oferecer contexto probabilístico também para as partes interessadas externas
Mas muitos engenheiros veem isso como carga administrativa
Uma boa prática é usar estimativas por intervalo, modelando melhor caso, caso esperado e pior caso, como no método PERT
Quanto melhor o técnico, maior tende a ser a autoconfiança excessiva nas próprias estimativas de tempo
O modelo de cada um estimar e depois aplicar uma correção de 20% funcionava bastante bem
Quando a gestão impõe um cronograma, é preciso explicar o que cabe naquele prazo ou propor uma nova estimativa após definição clara do escopo
Referência: PMI PMP, Lessons Learned Repository do PMBOK
A previsão aprende com o erro, mas a prescrição acaba virando pressão por produtividade
Eu vejo a estimativa como um processo de negociação
Apresento três opções, como em versões de acabamento de carro: Economy, Mid-tier e Luxury
O negócio sempre quer a funcionalidade da opção 3 com o orçamento da opção 1, então no fim eu ajusto conforme a situação
Ter um plano #1 preparado permite mudar rapidamente em caso de crise e visualizar, durante a negociação, o custo dos atalhos
Isso já me ajudou várias vezes a evitar decisões irracionais de PMs ou executivos em pânico
Eu trabalho com sistemas distribuídos de grande escala nível FAANG, e aqui estimativas precisas são quase impossíveis
Existem unknown-unknowns demais, e até um protótipo já exige volumes enormes de dados e tempo
Por isso, mais do que estimar, o foco fica em gerenciar a incerteza
O método mais confiável é comparar com projetos semelhantes
Algo como: “isso é 20% mais complexo que o projeto X, então vai levar 20% mais tempo”
Mas para isso é preciso registrar continuamente os dados reais de duração dos projetos anteriores
No começo eu queria discordar da ideia de que “estimar é impossível”, mas acabei percebendo que o papel da organização é ainda mais importante
Mesmo que o time veja, pela capacidade comparada à estimativa, que algo é inviável, o cronograma não muda
No fim, tudo é ajustado com redução de escopo ou concessões de qualidade
Então talvez seja mais correto dizer que “estimativas são inúteis”
Sinto que o ponto central da estimativa é a ambiguidade
Coisas que parecem pequenas, como um ajuste fino de UI, muitas vezes são trabalhos em que se aprende fazendo
Por outro lado, mesmo uma grande mudança pode ser concluída rápido se estiver claramente definida
Na era dos LLMs, mais do que o tamanho da mudança, o grau de incerteza será o fator que determina o tempo necessário