Estimativas: como se posicionar diante delas

📖 Tempo médio de leitura: 14 minutos

TL;DR

Estimativas não são prazos, são apostas com base no que sabemos até agora. Tratar estimativas como compromissos fixos gera micro gerenciamento, afeta a qualidade e desgasta o time. Engenheiros devem comunicar incertezas com clareza, PMs precisam gerenciar contexto, não cronograma e Stakeholders merecem previsibilidade, mas com margens realistas. O problema não é estimar, é fingir que a incerteza não existe.

Introdução

Você já se viu naquela situação clássica em uma reunião de planejamento, você estima que uma tarefa levará, digamos, dois dias para ser concluída (ou x pontos). Parece simples, no entanto, ao começar a trabalhar, surgem imprevistos… algo que não foi previsto e que agora vai exigir mais tempo do que o imaginado. O que era para ser uma tarefa de dois dias se transforma em algo que leva três dias ou mais.

Então, a partir do momento em que a tarefa atrasa, a cobrança aparece. Mesmo quando você reforça que “estimativas não são prazos” e que “elas servem apenas para planejamento“, fica claro que aqueles dois dias mencionados viraram, na prática, um prazo disfarçado que você agora é obrigado a cumprir.

Tratar estimativas de software como prazos fixos é um grande erro.

O que são Estimativas. E por que elas estão erradas.

Para entender o problema, precisamos primeiro clarear o que significa estimar no contexto de software. Estimativa é basicamente tentar prever o futuro. É chutar quanto esforço ou tempo algo deve levar para ficar pronto.

A natureza de toda previsão é a incerteza. Não existe estimativa precisa ou exata. Estimativa não é uma medida de precisão; é uma medida de probabilidade.

ℹ️Importante: estimativas, por si só, não são ruins. Elas são úteis em cenários onde o nível de incerteza é baixo e as variáveis estão sob controle.

Mas porque estimativas de Software são imprecisas?

Para ilustrar a diferença, podemos comparar software com cenários onde estimativas são mais confiáveis:

Viagens de Avião: A previsão de chegada de um voo é geralmente muito precisa. Isso ocorre porque a estimativa se baseia em dados históricos, rotas fixas, condições monitoradas em tempo real e sistemas de navegação complexos que consideram altitude, vento, tráfego aéreo e até a rotação da Terra. É um ambiente onde as variáveis são conhecidas ou fáceis de controlar.
Linhas de Produção Industrial: Nas fábricas, especialmente com o Kanban na Toyota na década de 40, era possível cravar prazos. Lidava-se com peças físicas, processos repetitivos e tarefas com começo, meio e fim bem definidos. O nível de incerteza no processo de montagem era baixo. Mesmo quando algo dava errado, geralmente dava errado do mesmo jeito, permitindo processos padronizados de solução.

Software, por outro lado, é completamente diferente

É intangível: não segue as leis do mundo físico. Você não consegue pesar ou medir um software.
É mutável: enquanto está sendo construído, está mudando, como um organismo vivo.
Envolve pessoas: considera conhecimentos técnicos, habilidades e experiências diferentes de cada desenvolvedor.
Não é uma linha de produção: onde se espera produzir uma quantidade fixa de “código” ou “endpoints” por hora.

Por estes motivos que as estimativas nunca deveriam ser tratadas como compromisso.

Os vilões da estimativa precisa

Existem motivos profundos e psicológicos que provam por que qualquer tentativa de transformar estimativas de software em compromissos é um erro:

O Viés do Otimismo ou Falácia do Planejamento: Segundo a psicologia e a neurociência, ao estimar tarefas, nosso cérebro ativa uma “simulação mental” perfeita… sem bugs, atrasos ou imprevistos. Isso acontece porque ele economiza energia ignorando incertezas. Estimamos com base em uma visão idealizada, antes mesmo de ver o código ou entender as armadilhas escondidas. Cobrar com base nisso é exigir precisão de um chute: a estimativa parece exata, mas nasce de uma realidade que ainda não foi explorada. O erro não está em errar, mas em fingir que não haveria erro.

A Lei de Hofstadter: “Sempre leva mais tempo do que você espera, mesmo quando você leva em conta a lei de Hofstadter“. Essa lei trata do caráter recursivo da incerteza. Mesmo sabendo que pode atrasar, tentando ser realista e adicionando uma “gordurinha”, ainda assim demorará mais. Isso acontece porque o que atrasa uma tarefa não é o que você sabe que pode dar errado, mas aquilo que você nem sabe que ainda não sabe. Um bug inesperado, um comportamento bizarro de uma API de terceiro, tempo perdido em reuniões inúteis, ou uma alteração de última hora do cliente fazem parte do desconhecido que arrebenta a estimativa e que não tem como prever. A lei de Hofstadter nos alerta que a incerteza é tão inerente que nem considerando-a você evita o atraso.

A Lei de Parkinson: “O trabalho se expande até preencher todo o tempo disponível para sua realização“. Ou seja, se uma tarefa que levaria 2 dias recebe 5, ela provavelmente será entregue em 5. Não por ser mais complexa, mas porque o tempo está ali. O cérebro economiza energia até sentir urgência. Tanto prazos apertados quanto folgados demais afetam o desempenho. Tratar estimativas como compromisso fixo só agrava esse efeito. A gestão eficaz não é sobre dar mais tempo, é sobre dar o tempo certo, com foco claro e senso de prioridade.

A Lei da Trivialidade (Bike Shedding): “Quanto mais simples e fácil de entender for um problema, mais tempo e energia as pessoas vão gastar discutindo sobre ele“. Em software, isso se traduz em gastar tempo excessivo debatendo um CRUD ou um endpoint simples (ex: qual padrão usar), enquanto problemas complexos (State Machine, Redespacho, Eventos etc) são estimados rapidamente com pouca discussão. Isso distorce as estimativas da sprint. Tarefas triviais são entregues rápido, criando falsa sensação de produtividade, mas as tarefas complexas empacam e geralmente afundam os resultados da sprint. O difícil é ignorado porque o cérebro tende a economizar energia.

Todas essas leis e o viés do otimismo apontam para o mesmo fato: tentar tratar a estimativa de software como compromisso fixo é um grande erro. O resultado é um time cansado de cobranças e um projeto sempre atrasado.

As consequências de tratar estimativas como prazos

Essa pseudo-gestão, que ignora a natureza incerta do software e as leis que o regem, traz consequências:

Cria uma falsa sensação de controle para a gestão;
Gera um clima de cobrança velada e responsabilização injusta;
Prejudica o time de desenvolvimento e a qualidade do código;
Alimenta o micro gerenciamento.

O pior cenário ocorre ao ignorar o Triângulo de Ferro (ou Tríplice Restrição). Este modelo clássico da gestão de projetos mostra que todo projeto é condicionado por Escopo, Prazo e Orçamento (ou Custo/Recursos).

A regra é clara: você só pode fixar duas dessas variáveis; a terceira terá que ceder.

Escolha duas e ceda a terceira:

Escopo + Prazo fixos = Orçamento/Custo tem que ceder (mais pessoas, hora extra, infra).
Orçamento + Escopo fixos = Prazo tem que ceder (mais tempo para o time).
Prazo + Orçamento fixos = Escopo tem que ser reduzido (precisa reduzir funcionalidades).

O que vemos muito na prática é a gestão tentando fixar as três variáveis (Escopo, Prazo, Orçamento). Quando isso acontece, a única coisa que sobra para ser sacrificada é a Qualidade, que fica no centro do triângulo.

O sacrifício da qualidade se manifesta de várias formas: testes ignorados, refatoração adiada, arquitetura frágil, código sem revisão, sistemas instáveis em produção. Quando bugs aparecem e o sistema quebra, gerando retrabalho (que leva o dobro do tempo), trabalhos aos fins de semana e horas extras e ai ninguém lembra do Triângulo de Ferro.

ℹ️É importante notar que o problema não é a gestão de projetos, que é necessária. O problema é a pseudo-gestão que trata estimativas como compromissos, criando um ciclo vicioso.

Como se posicionar

Mude sua percepção: Não é seu trabalho prever o futuro com precisão. Você não tem bola de cristal. Seu papel é criar soluções e resolver problemas. Isso, por natureza, exige margem de erro.
Reposicione sua comunicação: Deixe claro que a estimativa é uma aproximação, não um compromisso. Use uma linguagem que reforce a incerteza, como “com base no que sei até agora, acho que pode levar uns dois ou três dias” ou “se não tiver surpresa, acho que até sexta-feira dá para entregar“. Essa mudança sutil ajuda a plantar a semente da dúvida e reduzir a pressão futura.
Aprenda a recusar escopo com prazo fechado (Profissionalmente): Principalmente se você não participou da estimativa. Se uma demanda chega com prazo já definido, use o conceito do Triângulo de Ferro. Pergunte qual vértice (Escopo, Prazo ou Orçamento/Recursos/Qualidade) será reajustada. Se nada puder ceder, avise que a qualidade será impactada. Isso mostra que você entende o processo e evita ser encurralado.
Entenda seu valor: Ambientes que insistem em tratar estimativas como contratos e culpar o desenvolvedor refletem uma cultura ruim. Não tema questionar práticas prejudiciais.

O papel do time de Produtos

Talvez esteja se perguntando: “Entendi que estimativas não são prazos. Mas o que eu faço com isso quando eu e meu time estiver sendo cobrado por prazo?”.

Primeira coisa a deixar claro, a pessoa de produto que transforma uma estimativa em compromisso rígido está sabotando a si mesmo.

Você não é gestor de cronograma, é gestor de contexto

Seu trabalho não é garantir que uma tarefa termine na quinta-feira às 17h. É garantir que todos entendam por que essa tarefa existe, qual o risco de não entregá-la e quais são os trade-offs se ela atrasar. O atraso, em si, não é o problema. O problema é demorar para sinalizar o atraso e não termos tempo para ajustar o curso quando ela acontecer. E adivinha? O papel de identificar atraso e sinalizar é… nosso!

Você não negocia prazo. Você negocia escopo, risco e impacto

Quando o stakeholder Cliente diz: “Isso precisa estar pronto até sexta”, a resposta não é “Ok, vamos correr”. A resposta é:

“Legal. Isso muda o jogo? O que deixamos de lado para caber até sexta? O que podemos cortar para entregar só o essencial com qualidade?”

Falar isso com naturalidade exige prática, mas é um divisor de águas entre um Júnior (executor) e um Sênior (estrategista).

Pare de fingir que o roadmap é um cronograma

Roadmap não é agenda. É um guia estratégico que muda conforme aprendemos. Times de produto maduros tratam o roadmap como hipótese, não como contrato.

ℹ️Lembre-se: seus stakeholders vão respeitar mais um roadmap mutável, com bons motivos, do que um cronograma fixo com desculpas fracas.

Seja o advogado do risco, não o mensageiro da pressão

Ao invés de só repassar a ansiedade dos stakeholders para o time, leve risco e incerteza para a mesa de decisão:

“Temos 70% de chance de entregar até o prazo, mas com risco médio no ambiente de staging“
“Aumentar a confiança exige cortar parte do escopo ou adiar a entrega em dois dias“
“Podemos prometer entrega, mas com dívida técnica embutida que vai custar caro no próximo ciclo“

Isso é gestão de produto de verdade. O resto é só acompanhamento de Jira.

Use estimativas como farol, não como amarra

Estimativas boas guiam decisões. Estimativas ruins viram algemas. Seu papel é lembrar o time e a empresa que estamos lidando com complexidade, não com peças de Lego.

Crie rituais que reforcem isso: converse sobre riscos logo na planning/daily, documente hipóteses no Confluence, e por favor não trate ponto de história como moeda de produtividade.

O Cliente: entenda a cabeça de quem “paga a conta”

Até aqui falamos sobre o erro de tratar estimativas como promessas, das armadilhas cognitivas envolvidas e de como POs/PMs e Engenheiros podem se proteger e se posicionar nesse ciclo vicioso. Mas tem um personagem que ainda não foi devidamente compreendido nessa história: o stakeholder Cliente.

Sim, aquele que faz a pergunta fatal:

“Quando vai ficar pronto?”

É fácil cair na tentação de tratá-lo como o antagonista da trama. Afinal, é ele quem cobra, aperta o prazo, quer visibilidade e manda um “só mais essa coisinha”.

Mas aqui vai uma verdade incômoda (e libertadora): Ele também está tentando sobreviver.

O Cliente é prisioneiro da cadeia de dependências

Ele te pressiona por prazo porque ele também está sendo pressionado. A operação precisa saber quando vai lançar. A diretoria quer fechar o orçamento do trimestre. Compliance precisa revisar os termos. As lojas estão esperando a funcionalidade prometida.

O Cliente não quer nos matar de burnout. Ele quer, ou melhor, precisa, saber se pode se comprometer com a próxima fase do projeto com alguma confiança. Ele é parte do sistema. E como todo sistema vivo, precisa de previsibilidade mínima para não colapsar.

Darwin e os produtos: adaptabilidade vence

Lembra de Darwin? “Não é o mais forte que sobrevive, nem o mais inteligente, mas o que melhor se adapta às mudanças.”

No mundo corporativo, isso vale para todos os lados (inclusive para nós, times de Produto e Engenharia). Ser adaptável também significa ter empatia e aprender a comunicar incertezas com clareza e profissionalismo, especialmente para quem precisa tomar decisões estratégicas com base nelas.

Empatia não é aceitar tudo

Ter empatia pelo Cliente não é aceitar qualquer prazo impossível. É entender que ele está buscando sinais de confiança para se mover. E nossa função não é dar certezas impossíveis, mas sim reduzir o risco da decisão dele com o máximo de transparência possível.

Por exemplo:

“Ainda não temos segurança total sobre o esforço, mas com base nos riscos identificados hoje, estimamos de 3 a 5 dias. Com um dia extra para validação, poderíamos lançar com segurança no dia X.”

Isso não resolve tudo, mas mostra maturidade. E é isso que constrói confiança.

Margem de erro ≠ margem infinita

O stakeholder não está pedindo perfeição. Ele está pedindo uma margem de erro aceitável para planejar o que vem depois. Entregar algo estimado em 5 dias, mas que leva 15, quebra a confiança. Por outro lado, comunicar 5 com margem de 2, e entregar em 6, fortalece o relacionamento.

Se você quiser que o negócio compre o tempo que a incerteza exige, você precisa vendê-la bem.

Incerteza mal comunicada vira dúvida.
Incerteza bem comunicada vira planejamento.

Conclusão

Para o time de Engenharia

Utilize o conhecimento sobre a incerteza inerente às estimativas, as leis que explicam por que elas falham como prazos e o conceito do Triângulo de Ferro para se proteger, comunicar melhor a realidade do desenvolvimento e argumentar contra práticas que sacrificam a qualidade e o bem-estar do time. Sua função é resolver problemas com excelência, não ter uma bola de cristal.

Para o time de Produtos

Times de Produtos maduros não cobram precisão de estimativas. Eles cobram clareza, aprendizado e impacto. No fim das contas, ninguém espera que você tenha todas as respostas. Mas todo mundo espera que você tenha coragem de fazer as perguntas certas, especialmente quando o prazo está curto e a pressão alta.

Para o stakeholder Cliente

Stakeholders não são monstros, POs/PMs não são mágicos e Engenheiros não são oráculos. Todos estão tentando entregar valor em um sistema que vive de prazos, prioridades e pressão.

A saída está na maturidade coletiva: stakeholders merecem previsibilidade, não promessas vazias.

ℹ️no fim do dia, não se trata de vencer a disputa entre quem pede e quem executa, mas de criar pontes mais fortes entre expectativa e realidade. E isso começa com empatia entre todos.

Referências Bibliográficas

Estimativas, incerteza e psicologia cognitiva

Daniel Kahneman – Thinking, Fast and Slow
Livro clássico sobre viés cognitivo. A falácia do planejamento é discutida em profundidade.Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux.
Hofstadter’s Law – cunhada por Douglas HofstadterHofstadter, D. (1979). Gödel, Escher, Bach: An Eternal Golden Braid. Basic Books.
The Planning Fallacy: Cognitive, Motivational, and Social OriginsBuehler, R., Griffin, D., & Ross, M. (1994). Journal of Personality and Social Psychology, 67(3), 366–381.

Gestão de produtos e estimativas em software

Steve McConnell – Software Estimation: Demystifying the Black Art
Leitura essencial sobre por que estimar é difícil e como fazer isso com mais consciência. McConnell, S. (2006). Software Estimation: Demystifying the Black Art. Microsoft Press.
Marty Cagan – Inspired: How to Create Tech Products Customers Love
Ainda que não seja focado em estimativas, é excelente para entender o papel de Produto em decisões difíceis. Cagan, M. (2017). Inspired. Wiley.
Mike Cohn – Agile Estimating and Planning
Uma das melhores fontes práticas para estimativas em contextos ágeis. Cohn, M. (2005). Agile Estimating and Planning. Prentice Hall.

Gestão de projetos e triângulo de ferro

PMBOK Guide (Project Management Body of Knowledge)
Fonte padrão sobre o Triângulo de Ferro (escopo, tempo, custo). Project Management Institute. (2021). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – 7th Edition.