Como este tema funciona na sua empresa
Estimativas são informais, baseadas em experiência e intuição. Margem de erro é grande (±30% é aceitável). Técnicas simples como planning poker ou "comparar com projetos passados" são suficientes. Documentação de estimativa é mínima.
Estimativas estruturadas usando decomposição (Work Breakdown Structure) e dados históricos. Margemde erro esperada: ±20%. Análise de risco está presente mas simples. Repouso de histórico de projetos começa a acontecer. Documentação formal de estimativa.
Estimativas sofisticadas com análise de cenários, sensibilidade e benchmarking externo. Margem de erro: ±15%. Histórico de projetos é robusto — usado para calibração contínua. Subprojetos estimados separadamente. Análise de risco é formal e integrada ao orçamento.
Estimativa de esforço em projetos de TI é previsão (em horas, dias ou meses) do tempo e recursos necessários para executar um projeto, baseada em decomposição do trabalho, dados históricos e análise de riscos. Bem feita, melhora probabilidade de sucesso do projeto[1].
Por que estimativas ruins são causas de desvios de projetos
Estimativas ruins geram cascata de problemas: atraso em entrega, custo acima do orçado, equipe desmotivada, crédito perdido com negócio. Paradoxalmente, gestores frequentemente usam estimativas "comerciais" (otimistas) em lugar de "técnicas" (realistas).
Dilema comum: pressão comercial diz "comprometemos 3 meses", mas TI sabe que é 5 meses realisticamente. Resultado: projeto de 5 meses é forçado em 3, gera atraso, qualidade sofre.
Segundo pesquisa Standish Group sobre projetos de TI, estimativas incorretas estão entre as 3 principais causas de falha de projeto[1].
Técnicas de estimativa: escolhendo a apropriada para contexto
Não existe técnica única. Contexto do projeto determina qual técnica usar.
Técnicas de estimativa por tipo de projeto
Planning poker (quick, colaborativo), comparação com projetos passados, ou "palpite educado" de especialista. Documentação mínima. Margem de erro +30% é aceitável para empresas menores.
Bottom-up (descompor em tarefas, estimar cada uma), validação com especialistas, análise de risco simples (adicionar 20-30% de contingência). Dados históricos começam a ser coletados. Documentação de WBS (Work Breakdown Structure) e estimativas.
Multiple estimating (3-point PERT), análise de cenários, benchmarking externo. Banco de dados de histórico de projetos é usado para calibração. Análise de sensibilidade (qual variável impacta mais?). Documentação completa.
Principais técnicas:
- Planning Poker (Agile): equipe estima junto em workshop. Cada um dá palpite, discute diferenças, converge em número. Rápido, envolvente, reduz vieses. Ideal para projetos de tamanho pequeno/médio com requisitos claros.
- Bottom-up: decomposição detalhada (WBS), estima cada atividade, soma. Mais trabalho inicial, mas mais preciso. Ideal para projetos maiores e bem definidos.
- 3-point PERT: estimar otimista (melhor caso), pesimista (pior caso) e realista (caso meio). Fórmula: (otimista + 4×realista + pesimista) / 6. Produz distribuição que reflete incerteza. Ideal para projetos com incerteza alta.
- Benchmarking histórico: olhar para projetos passados similares e extrapolar. Requer base de dados de histórico. Ideal para PMEs com série histórica.
- Análise de cenários: estimar sob diferentes cenários (melhor, pior, provável) e calcular valor esperado. Ideal para transformações ou projetos com mudança de contexto esperada.
Estruturando estimativa com Work Breakdown Structure (WBS)
WBS é ferramenta que torna projeto "inteligível". Em lugar de "desenvolver sistema em X meses", você decompõe: requisitos, design, desenvolvimento, testes, deploy — cada um estimado separadamente.
Exemplo de WBS (simplificado):
- Projeto: Sistema de gestão de vendas (estimativa total: 6 meses)
- Fase 1: Requisitos e design (1 mês)
- Entrevista com usuários (1 semana)
- Design de arquitetura (2 semanas)
- Aprovação (3 dias)
- Fase 2: Desenvolvimento (3 meses)
- Modulo de vendas (6 semanas)
- Módulo de relatórios (4 semanas)
- Integração com ERP (2 semanas)
- Fase 3: Testes (1 mês)
- Fase 4: Treinamento e deploy (2 semanas)
Benefício: você consegue identificar qual fase é "longa demais" e onde há oportunidade de otimizar.
Fatores que influenciam estimativas (e precisam ser considerados)
Mesma atividade pode ter tempos muito diferentes conforme contexto. Team experience, clareza de requisitos, complexidade técnica — tudo impacta.
Fatores comuns:
- Experiência da equipe: time experiente faz em metade do tempo do time novato. Fator: 0.5x a 2x.
- Clareza de requisitos: requisitos vagos exigem mais tempo para esclarecer. Fator: 1x a 1.5x.
- Complexidade técnica: tecnologia nova que time não conhece toma mais tempo. Fator: 1x a 2x.
- Dependências externas: se precisa de input de terceiro, adicione tempo de espera.
- Disponibilidade: time 100% dedicado vs time em múltiplos projetos tem produtividade diferente. Fator: 1x a 2x.
- Integração com legado: integrar com sistema antigo toma mais tempo que greenfield. Fator: 1.5x a 3x.
Dica: ao estimar, documentar os fatores assumidos. "Estimativa assume que team tem experiência com React. Se não, adicione 50%."
Análise de risco na estimativa
Estimativa sem análise de risco é ingênua. Riscos acontecem; estimativa deve acomodar probabilidade deles.
Contingência por tipo de projeto
Contingência geral: +20-30% da estimativa. Adicionar ao total e comunicar como "prazo realista" não "melhor caso".
Análise de risco formal: listar riscos (requisitos mudam, tecnologia falha, recurso não disponível), estimar impacto e probabilidade, calcular contingência. Típico: 15-30% dependendo de risco identificado.
Análise de risco integrada a estimativa. Riscos altos são comunicados com clareza. Contingência é acordada formalmente. Típico: 15-25% para projetos já existentes; 30-50% para projetos com nova tecnologia.