8 min leitura • Guide 808 of 877
Planejamento de Capacidade para Crescimento
Crescimento requer planejamento. GitScrum ajuda equipes a entenderem sua capacidade e planejar escalabilidade conforme a organização cresce.
Entendendo Capacidade
Capacidade Atual
AVALIANDO CAPACIDADE DA EQUIPE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FATORES DE CAPACIDADE: │
│ │
│ TEMPO DISPONÍVEL: │
│ Dias de trabalho total - feriados - PTO - reuniões │
│ │
│ TEMPO EFETIVO: │
│ Tempo disponível × fator de foco (tipicamente 60-80%) │
│ Conta para: interrupções, admin, suporte │
│ │
│ HABILIDADES DA EQUIPE: │
│ Nem todo trabalho pode ser feito por todas as pessoas │
│ Gargalos em habilidades especializadas │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CÁLCULO DE CAPACIDADE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ CAPACIDADE DA EQUIPE - SPRINT 15 ││
│ │ ││
│ │ MEMBRO DIAS FATOR EFETIVO ││
│ │ ────── ──── ────── ──────── ││
│ │ @alex 10 80% 8 dias ││
│ │ @jordan 8 80% 6.4 dias (2 dias PTO) ││
│ │ @pat 10 70% 7 dias (dever de suporte) ││
│ │ @sam 10 80% 8 dias ││
│ │ @taylor 10 50% 5 dias (treinamento) ││
│ │ ───────────────────────────────────────────────────────││
│ │ TOTAL: 48 34.4 dias efetivos ││
│ │ ││
│ │ VAZÃO HISTÓRICA: ││
│ │ Sprint 14: 35 pontos de história ││
│ │ Sprint 13: 38 pontos de história ││
│ │ Sprint 12: 32 pontos de história ││
│ │ MÉDIA: ~35 pontos/sprint ││
│ │ ││
│ │ CAPACIDADE SPRINT 15: ~32 pontos ││
│ │ (Menor devido a PTO e treinamento) ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Planejando para Crescimento
Quando Crescer
SINAIS DE QUE PRECISA DE MAIS CAPACIDADE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SOBRECARGA CONSISTENTE: │
│ ─────────────────────── │
│ • Backlog crescendo mais rápido que entrega │
│ • Compromissos de sprint regularmente perdidos │
│ • Equipe trabalhando horas insustentáveis │
│ • Qualidade sofrendo devido a pressa │
│ │
│ GARGALOS: │
│ ───────── │
│ • Uma pessoa bloqueia múltiplas histórias │
│ • Habilidades especializadas em falta │
│ • Revisões/aprovações criando atrasos │
│ • Ponto único de falha │
│ │
│ NECESSIDADE ESTRATÉGICA: │
│ ──────────────────────── │
│ • Nova área de produto planejada │
│ • Escalabilidade para servir mais clientes │
│ • Investimento em plataforma técnica │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ⚠️ AVISO: LEI DE BROOKS │
│ ────────────────────── │
│ "Adicionar pessoas a um projeto atrasado o torna mais atrasado" │
│ │
│ POR QUÊ: │
│ • Novas pessoas precisam de integração │
│ • Pessoas existentes treinam em vez de entregar │
│ • Sobrecarga de comunicação aumenta │
│ │
│ PLANEJE COM ANTECEDÊNCIA, não em crise │
└─────────────────────────────────────────────────────────────┘
Divisão de Equipe
ESCALANDO EQUIPES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CRESCENDO UMA EQUIPE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ TAMANHO DA EQUIPE: 5 → 6 → 7 → 8 → 9 → DIVIDA! ││
│ │ ▲ ││
│ │ │ ││
│ │ Ótimo ││
│ │ ││
│ │ 5-9 pessoas: Ponto ideal ││
│ │ 10+: Sobrecarga de comunicação muito alta ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ QUANDO DIVIDIR: │
│ ─────────────── │
│ • Equipe alcançando 10 pessoas │
│ • Limite de domínio claro existe │
│ • Pode criar equipes autônomas │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ESTRATÉGIAS DE DIVISÃO: │
│ │
│ POR ÁREA DE PRODUTO: │
│ ┌──────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Equipe │ ──→ │ Frontend │ │ Backend │ │
│ │ Grande │ │ Team (6) │ │ Team (6) │ │
│ │ (12 pessoas)│ └────────────┘ └────────────┘ │
│ └──────────────┘ │
│ │
│ POR DOMÍNIO DE RECURSO: │
│ ┌──────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Equipe │ ──→ │ Pagamentos │ │ Auth │ │
│ │ Grande │ │ Team (6) │ │ Team (6) │ │
│ │ (12 pessoas)│ └────────────┘ └────────────┘ │
│ └──────────────┘ │
│ │
│ MANTENHA: Algumas pessoas experientes em cada nova equipe │
│ EVITE: Todos os seniors em uma equipe │
└─────────────────────────────────────────────────────────────┘
Impacto da Integração
Curva de Produtividade
PRODUTIVIDADE DE NOVO CONTRATADO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRODUTIVIDADE AO LONGO DO TEMPO: │
│ │
│ Produtividade │
│ │ │
│ 100%├─────────────────────────────────────────────────█ │
│ │ ██████ │
│ 80%├──────────────────────────────────────█████ │
│ │ ████████ │
│ 60%├────────────────────────███████ │
│ │ ██████ │
│ 40%├─────────────█████ │
│ │ ████ │
│ 20%├─────████ │
│ │ ████ │
│ 0%├█──────────────────────────────────────────────→ Tempo │
│ Mês 1 Mês 2 Mês 3 Mês 4 Mês 5 │
│ │
│ RAMP TÍPICO: │
│ Mês 1: Aprendendo, configuração, tarefas pequenas (20%) │
│ Mês 2: Contribuindo com suporte (40%) │
│ Mês 3: Trabalhando independentemente (60%) │
│ Mês 4: Quase contribuição total (80%) │
│ Mês 5+: Produtividade total (100%) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ IMPACTO NA EQUIPE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Ao adicionar novo contratado: ││
│ │ ││
│ │ MÊS 1-2: ││
│ │ • Mentor gasta 20% do tempo ajudando ││
│ │ • Novo contratado em 20-40% produtividade ││
│ │ • LÍQUIDO: Leve diminuição na saída da equipe ││
│ │ ││
│ │ MÊS 3-4: ││
│ │ • Menos mentoria necessária (10%) ││
│ │ • Novo contratado em 60-80% produtividade ││
│ │ • LÍQUIDO: Equilíbrio ││
│ │ ││
│ │ MÊS 5+: ││
│ │ • Novo contratado contribuindo totalmente ││
│ │ • LÍQUIDO: ROI positivo ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PLANEJE PARA A QUEDA antes de esperar ganhos │
└─────────────────────────────────────────────────────────────┘
Planejamento a Longo Prazo
Roadmap de Capacidade
PLANEJAMENTO DE CAPACIDADE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ROADMAP DE CAPACIDADE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ Q1 Q2 Q3 Q4 ││
│ │ ── ── ── ── ││
│ │ ││
│ │ Equipe A 6 6 7 8 ││
│ │ (estável) (estável) (+1 dev) (+1 dev) ││
│ │ ││
│ │ Equipe B 5 6 6 6 ││
│ │ (estável) (+1 dev) (estável) (estável) ││
│ │ ││
│ │ Equipe C 0 0 4 5 ││
│ │ (nova equipe) (+1 dev) ││
│ │ ││
│ │ TOTAL 11 12 17 19 ││
│ │ ││
│ │ ─────────────────────────────────────────────────────── ││
│ │ ││
│ │ PLANO DE CONTRATAÇÃO: ││
│ │ Q1: 0 contratações ││
│ │ Q2: 2 contratações (Equipe A, Equipe B) ││
│ │ Q3: 5 contratações (Equipe A, bootstrap Equipe C) ││
│ │ Q4: 2 contratações (Equipe A, Equipe C) ││
│ │ ││
│ │ NOTAS: ││
│ │ • Equipe C: Nova iniciativa de produto ││
│ │ • Comece contratação 2-3 meses antes de necessário ││
│ │ • Conte para conversão de funil de entrevista ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ALINHE COM: │
│ • Roadmap do produto │
│ • Ciclos de orçamento │
│ • Atrito esperado │
│ • Lacunas de habilidades │
└─────────────────────────────────────────────────────────────┘
Lidando com Atrito
PLANEJANDO PARA ROTATIVIDADE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ESPERE ATRITO: │
│ ───────────── │
│ Média da indústria: 10-20% rotatividade anual │
│ Equipe de 10: Espere 1-2 saídas por ano │
│ │
│ ESTRATÉGIAS DE MITIGAÇÃO: │
│ ───────────────────────── │
│ │
│ REDUZA DEPENDÊNCIA DE PESSOA CHAVE: │
│ • Documente conhecimento crítico │
│ • Treine cruzado em sistemas importantes │
│ • Programação em par espalha conhecimento │
│ │
│ MANTENHA PIPELINE DE CONTRATAÇÃO: │
│ • Sempre esteja entrevistando (lentamente) │
│ • Construa relacionamentos com candidatos │
│ • Reduza tempo-para-contratação quando necessário │
│ │
│ PLANEJE COM ANTECEDÊNCIA: │
│ • Saiba que saída está vindo (período de aviso) │
│ • Comece busca de reposição imediatamente │
│ • Transferência de conhecimento durante aviso │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PLANEJAMENTO DE SUCESSÃO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ CARGOS CRÍTICOS ││
│ │ ││
│ │ CARGO PRIMÁRIO BACKUP RISCO ││
│ │ ──── ─────── ────── ──── ││
│ │ Tech Lead @alex @jordan Baixo ││
│ │ DBA @sam ❌ Alto ⚠️ ││
│ │ DevOps @pat @taylor Médio ││
│ │ Product Owner @morgan @chris Baixo ││
│ │ ││
│ │ AÇÃO: Treine alguém em responsabilidades DBA ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘