Pra quando fica pronto?

Essa é, de longe, a pergunta mais temida (e repetida) em qualquer time de engenharia.

Estimativas viram apostas, comunicação falha, pressão aumenta e quando a entrega atrasa, sobra frustração pra todo mundo.

Mas e se o problema não for a estimativa em si, e sim como lidamos com ela?

📌 Neste artigo, compartilho um passo a passo prático de como o time pode:

✅ Pedir tempo antes de estimar
✅ Fazer spike ou POC para ganhar segurança
✅ Quebrar tarefas de forma inteligente
✅ Organizar entregas em roadmap com fases claras
✅ Melhorar a conversa entre produto e engenharia

Spoiler: não é sobre mágica, é sobre processo.
E sim, dá pra fugir da pastelaria sem travar entregas.

O dilema dos prazos

Dar um prazo para uma tarefa técnica já virou meme em todo time de engenharia. Você provavelmente já viu (ou viveu) esse clássico: alguém de produto pergunta “pra quando?”, o time técnico hesita, solta uma estimativa, e então começa o jogo de expectativas, pressões e frustrações.

Mas e se eu te disser que existe uma forma mais saudável e eficaz de lidar com isso?

Antes de mais nada, precisamos alinhar algumas premissas básicas sobre estimativas. Elas são o ponto de partida pra evitar pastelaria e aproximar produto e engenharia sem conflitos desnecessários.

Alinhando as premissas: o que todo mundo precisa entender

Premissa 1 – Estimativa não é certeza:
Toda demanda é influenciada por muitas variáveis. Imprevistos acontecem, por isso trabalhamos com estimativas, não com promessas.

Premissa 2 – Não se promete o que não se sabe:
Não dá pra prometer uma data com segurança antes de entender bem o que será feito. O correto é falar em expectativas com nossos clientes e stakeholders, e ao longo do caminho passar a evolução e as entregas faseadas.

Premissa 3 – Prazos flexíveis não são desculpa pra relaxar:
Dado que a demanda é importante, o foco deve existir. O prazo pode ser flexível, mas a priorização deve ser firme, com isso o time não pode aceitar novas demandas pelo caminho o tempo todo, ajustes acontecem, mas o foco sempre deve permanecer no escopo definido inicialmente.

Premissa 4 – “Não sei o prazo” não é resposta:
Dizer “não tenho como estimar” pode (e deve) ser substituído por “preciso de X tempo para analisar e te dar uma estimativa”. É o prazo do prazo e ele será seu melhor aliado para te dar tempo para entender melhor o que precisará ser feito.

Primeira etapa: Entenda antes de estimar

Quando te pedem uma estimativa, sua resposta imediata não deve ser um número e sim um pedido de tempo. Esse tempo será usado para:

Fazer um spike técnico ou uma POC
Levantar riscos
Quebrar a demanda em tarefas menores

A ideia aqui é reduzir a complexidade e permitir estimativas mais realistas e fundamentadas.

Segunda etapa: Quebre antes de calcular

Tarefa boa é tarefa pequena. Se possível, quebre tudo em blocos que levem até uma semana. E para facilitar a comunicação, sugiro usar uma linguagem mais simples:

P (até 1 dia)
M (2 a 3 dias)
G (1 semana)
GG (mais de 1 semana – evite ou quebre mais)

Quanto menores as tarefas, melhor a sensação de progresso, menor a chance de desvios grandes, entregas serão faseadas possivelmente gerando valor contínuo, e mais fácil será revisar código e testar.

2.1 – Antes de levar essa estimativa para produto/solicitante, refine essas tarefas com um grupo maior de pessoas, algumas tarefas podem ser mais quebradas, ou adicionadas ou mesmo removidas se não tiverem necessidade.

Terceira etapa: visualize e alinhe

Agora que você tem uma boa noção das tarefas, é hora de organizar visualmente:

Monte um roadmap simples, com responsáveis e tempos estimados
Considere tempo para testes e uma gordurinha para imprevistos
Explique (em alto nível) como cada etapa contribui para o todo: performance, manutenção, escalabilidade, etc.

Esse é o momento em que a conversa com o solicitante começa a mudar de “é pra quando?” para “o que dá pra entregar primeiro?”.

Entregas faseadas: seu aliado no alinhamento

Com a demanda quebrada e visualizada, é possível discutir entregas parciais. Isso reduz a ansiedade, mostra progresso e entrega valor mais cedo ao cliente.

Também ajuda o solicitante a entender o impacto de cada pedaço do escopo — e eventualmente abrir mão de partes menos prioritárias para ganhar tempo.

O processo, na prática

Resumo das etapas:

Produto define a necessidade e pede um prazo
Engenharia pede um tempo para analisar antes de estimar
Após spike, acontece o refinamento e a quebra de tarefas
A estimativa é apresentada com entregas faseadas
Se necessário, escopo é ajustado — e bora codar!

Conclusão: confiança é construída no processo

Nem produto é obrigado a entender a complexidade de uma feature, nem engenharia pode virar uma fábrica que diz “sim” pra tudo. A chave está no processo e na comunicação transparente.

Com as etapas certas, todo mundo ganha:

Produto entende melhor as limitações técnicas
Engenharia ganha mais autonomia e respeito pelas estimativas
Cliente recebe valor de forma contínua e com qualidade

Dar prazo não é mágica, é método. E com método, vem confiança.

05/05/2025

Gabriel Dornelas