9 min leitura • Guide 49 of 877
Definindo Deadlines de Projeto Realistas
Deadlines irrealistas preparam projetos para o fracasso desde o primeiro dia. Times se esgotam correndo para cumprir metas impossíveis, qualidade sofre e confiança se erode quando datas escorregam. GitScrum fornece as ferramentas baseadas em dados para criar cronogramas realistas baseados em capacidade real do time, performance histórica e avaliação honesta de riscos.
O Problema do Deadline
Por que deadlines falham e suas consequências:
| Causa Raiz | Resultado |
|---|---|
| Definir data top-down | Deadline existe antes de entender scope |
| Ignorar capacidade time | Mais trabalho que horas disponíveis |
| Sem dados históricos | Estimativas baseadas em esperança, não realidade |
| Dependências ocultas | Trabalho bloqueado por outros não considerado |
| Sem buffers | Um único atraso cascateia até data final |
| Scope assumido fixo | Novos requisitos não fatorados |
Estimativa Bottom-Up
Estimativa por Story Points
PROCESSO DE ESTIMATIVA:
┌─────────────────────────────────────────────────────────────┐
│ PASSO 1: QUEBRAR EPICS EM STORIES │
├─────────────────────────────────────────────────────────────┤
│ │
│ Epic: Sistema de Autenticação de Usuário │
│ ├── Story: UI formulário login (3 pts) │
│ ├── Story: Validação senha (2 pts) │
│ ├── Story: Geração token JWT (5 pts) │
│ ├── Story: Gestão de sessão (5 pts) │
│ ├── Story: Fluxo reset senha (5 pts) │
│ ├── Story: Integração OAuth (8 pts) │
│ ├── Story: Configuração MFA (8 pts) │
│ └── Story: Bloqueio de conta (3 pts) │
│ TOTAL: 39 pontos │
│ │
└─────────────────────────────────────────────────────────────┘
PASSO 2: SESSÃO DE ESTIMATIVA DO TIME:
┌─────────────────────────────────────────────────────────────┐
│ RESULTADOS PLANNING POKER │
├─────────────────────────────────────────────────────────────┤
│ │
│ Story: Integração OAuth │
│ │
│ Votos desenvolvedores: │
│ @Alex: 8 @Kim: 5 @Sam: 8 @Pat: 13 @Jordan: 8 │
│ │
│ Discussão: @Pat explica 13 por peculiaridades API LinkedIn │
│ Time concorda em adicionar tarefa pesquisa │
│ │
│ Estimativa revisada: 8 pontos + 2 pontos spike LinkedIn │
│ │
│ Final: 10 pontos total │
│ │
└─────────────────────────────────────────────────────────────┘
Previsão Baseada em Velocidade
CÁLCULO DE VELOCIDADE:
┌─────────────────────────────────────────────────────────────┐
│ VELOCIDADE TIME (Últimos 6 Sprints) │
├─────────────────────────────────────────────────────────────┤
│ │
│ Sprint │ Comprometido │ Completado │ Velocidade │
│ ──────────┼──────────────┼────────────┼────────── │
│ Sprint 19 │ 45 │ 38 │ 38 │
│ Sprint 20 │ 40 │ 42 │ 42 │
│ Sprint 21 │ 42 │ 40 │ 40 │
│ Sprint 22 │ 45 │ 44 │ 44 │
│ Sprint 23 │ 42 │ 41 │ 41 │
│ Sprint 24 │ 44 │ 43 │ 43 (em progresso) │
│ ──────────┴──────────────┴────────────┴────────── │
│ │
│ VELOCIDADE MÉDIA: 41 pontos/sprint │
│ FAIXA: 38-44 pontos/sprint │
│ │
│ RECOMENDAÇÃO: │
│ ├── Planejamento otimista: 44 pts/sprint │
│ ├── Planejamento realista: 41 pts/sprint ← USAR ESTA │
│ └── Planejamento conservador: 38 pts/sprint │
│ │
└─────────────────────────────────────────────────────────────┘
CÁLCULO TIMELINE PROJETO:
┌─────────────────────────────────────────────────────────────┐
│ PROJETO: Portal Cliente v2 │
├─────────────────────────────────────────────────────────────┤
│ │
│ TRABALHO TOTAL ESTIMADO: 245 story points │
│ VELOCIDADE TIME: 41 pontos/sprint (sprints 2 semanas) │
│ │
│ CÁLCULO: │
│ 245 pontos ÷ 41 pontos/sprint = 5.97 sprints │
│ │
│ CENÁRIOS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Otimista (44 pts): 245 ÷ 44 = 5.6 sprints = 11 sem ││
│ │ Realista (41 pts): 245 ÷ 41 = 6.0 sprints = 12 sem ││
│ │ Conservador (38 pts): 245 ÷ 38 = 6.4 sprints = 13 sem ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ RECOMENDAÇÃO: 12-13 semanas (6-6.5 sprints) │
│ BUFFER ADICIONADO: +2 semanas (15% contingência) │
│ DEADLINE PROPOSTO: 14-15 semanas do início │
│ │
└─────────────────────────────────────────────────────────────┘
Gestão de Buffers
Tipos de Buffers
ESTRATÉGIA DE BUFFERS:
┌─────────────────────────────────────────────────────────────┐
│ TIPOS DE BUFFER E ALOCAÇÃO │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. BUFFER INCERTEZA ESTIMATIVA (10-20%) │
│ Para: Complexidade desconhecida, nova tecnologia │
│ Regra: Maior para trabalho novo, menor para familiar │
│ │
│ Exemplo: 245 pts × 15% = ~37 pontos adicionais │
│ Tempo: +1.5 semanas │
│ │
│ 2. BUFFER MUDANÇA SCOPE (10-15%) │
│ Para: Mudanças inevitáveis, esclarecimentos │
│ Regra: Maior para clientes externos, menor internos │
│ │
│ Exemplo: 245 pts × 10% = ~25 pontos adicionais │
│ Tempo: +1 semana │
│ │
│ 3. BUFFER RISCO (5-15%) │
│ Para: Riscos conhecidos que podem materializar │
│ Regra: Baseado em avaliação registro riscos │
│ │
│ Exemplo: 2 riscos altos = 10% buffer │
│ Tempo: +1 semana │
│ │
│ 4. BUFFER INTEGRAÇÃO/DEPLOYMENT (1-2 semanas) │
│ Para: Testes finais, prep deployment, documentação │
│ Regra: Tempo fixo, não percentual │
│ │
│ Tempo: +1.5 semanas │
│ │
│ TIMELINE TOTAL PROJETO: │
│ ├── Trabalho core: 12 semanas │
│ ├── Buffer estimativa: +1.5 semanas │
│ ├── Buffer scope: +1 semana │
│ ├── Buffer risco: +1 semana │
│ └── Integração: +1.5 semanas │
│ ════════════════════════════ │
│ TOTAL: 17 semanas │
│ │
└─────────────────────────────────────────────────────────────┘
Níveis de Confiança
FRAMEWORK CONFIANÇA DEADLINE:
┌─────────────────────────────────────────────────────────────┐
│ COMUNICAÇÃO BASEADA EM CONFIANÇA │
├─────────────────────────────────────────────────────────────┤
│ │
│ Em vez de: "Estará pronto em 15 de abril" │
│ Dizer: "Temos 80% confiança de entregar até 15 de abril" │
│ │
│ NÍVEIS DE CONFIANÇA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 50% Confiança: 1 Abril (otimista, sem buffers) ││
│ │ 70% Confiança: 8 Abril (realista, buffer mínimo) ││
│ │ 80% Confiança: 15 Abril (compromisso recomendado) ││
│ │ 90% Confiança: 22 Abril (conservador, mais buffers) ││
│ │ 95% Confiança: 29 Abril (muito seguro, max buffers) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ COMUNICAÇÃO STAKEHOLDER: │
│ │
│ "Baseado na velocidade do nosso time e no scope definido, │
│ temos 80% confiança de entregar até 15 de abril. │
│ │
│ Isso assume: │
│ - Sem adições maiores de scope │
│ - Estabilidade do time (sem saídas) │
│ - Dependências entregues no prazo │
│ │
│ Se precisar de maior certeza, 22 de abril nos dá 90% │
│ confiança com buffer adicional para desconhecidos." │
│ │
└─────────────────────────────────────────────────────────────┘
Gestão de Dependências
Mapeamento de Dependências
VISUALIZAÇÃO DEPENDÊNCIAS:
┌─────────────────────────────────────────────────────────────┐
│ MAPA DEPENDÊNCIAS PROJETO │
├─────────────────────────────────────────────────────────────┤
│ │
│ Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 Sem 6 │
│ ────────────────────────────────────────────────────────── │
│ │
│ [Sistema Auth]───────┐ │
│ │ │
│ [Design BD]──────────┼────►[Desenvolvimento API]────────┐ │
│ │ │ │
│ [Componentes UI]─────┼────►[Dashboard UI] │ │
│ │ │ │ │
│ │ ▼ ▼ │
│ └────►[Integração]────────►[Testes] │
│ │
│ CAMINHO CRÍTICO: BD → API → Integração → Testes │
│ Duração: 5 semanas (mínimo com execução perfeita) │
│ │
│ DEPENDÊNCIAS ADICIONANDO RISCO: │
│ ├── Externa: Acesso sandbox API Pagamentos (Semana 2) │
│ ├── Interna: Infraestrutura DevOps pronta (Semana 1) │
│ └── Cliente: Aprovação conteúdo/copy (Semana 4) │
│ │
└─────────────────────────────────────────────────────────────┘
Alinhamento com Stakeholders
Negociação de Deadline
CENÁRIOS DE NEGOCIAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ CENÁRIO: STAKEHOLDER QUER DEADLINE ANTES │
├─────────────────────────────────────────────────────────────┤
│ │
│ Stakeholder: "Precisamos disso para 15 março, não 22 abril."│
│ │
│ FRAMEWORK DE RESPOSTA: │
│ │
│ 1. RECONHECER A NECESSIDADE │
│ "Entendo que 15 de março é importante para a │
│ conferência de vendas. Vamos ver o que é possível." │
│ │
│ 2. APRESENTAR TRADE-OFFS │
│ "Para atingir 15 março, precisaríamos ajustar scope. │
│ Aqui estão três opções:" │
│ │
│ Opção A: Reduzir scope │
│ ├── Remover: Módulo relatórios, OAuth │
│ ├── Manter: Auth core, Dashboard, Pagamentos │
│ └── Timeline: 10 semanas → 15 março alcançável │
│ │
│ Opção B: Aumentar time │
│ ├── Adicionar: 2 contractors por 8 semanas │
│ ├── Custo: +R$200.000 │
│ └── Timeline: Talvez 22 março (melhoria 1 semana) │
│ │
│ Opção C: Release por fases │
│ ├── 15 Março: MVP (Auth, Dashboard básico) │
│ ├── 22 Abril: Release completo │
│ └── Conferência: Demo MVP, prometer completo abril │
│ │
│ 3. DEIXAR STAKEHOLDER DECIDIR │
│ "Qual opção se encaixa melhor nas suas necessidades?" │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Anti-Padrões de Deadline
O QUE NÃO FAZER:
✗ DEADLINES DE PENSAMENTO DESEJOSO
"Vamos trabalhar mais" / "Vamos dar um jeito"
Realidade: Times não conseguem sustentar crunch
✗ DEADLINE PRIMEIRO, SCOPE DEPOIS
"Lançamento é 1º junho, façam acontecer"
Realidade: Scope ou qualidade sofrerão
✗ IGNORAR DADOS DE VELOCIDADE
"Este time deveria fazer 60 pontos, não 41"
Realidade: Dados históricos são melhor preditor
✗ SEM BUFFERS
"Cada dia está contabilizado perfeitamente"
Realidade: Algo sempre dá errado
✗ DEADLINES ESCONDIDOS
"Diga abril mas realmente precisamos março"
Realidade: Destruição de confiança ao descobrir