Capacity Planning: Alocação Inteligente de Recursos

Conteúdo

Resposta Rápida (Featured Snippet):
Capacity planning é calcular quanto trabalho sua equipe consegue fazer em um período (semana, mês, trimestre) e alocar esse trabalho (projetos, bugs, suporte) de forma inteligente para evitar gargalos e maximizar throughput. Responde: Temos pessoas suficientes para fazer X? Quando? E se priorizarmos Y em vez de Z?

TL;DR (5 bullets):
– Calcule FTE disponível: (Horas úteis do período / Horas na semana) × número de pessoas
– Suporte ≠ Projeto: separe alocação de suporte/manutenção de projetos
– Forecast trimestral: veja quando pessoal sai (férias, rotação) e reajuste planos
– Gargalos antecipados: recursos críticos (DBAs, DevOps, arquitetos) costumam ser bottleneck
– Ferramenta: Planview AdaptiveWork, Jira, ou planilha bem estruturada

Artigo Completo

Por Que Capacity Planning Importa

Cenário comum em TI brasileira:

Uma empresa tem 5 seniordevs. Chefe diz: “Vamos fazer 3 projetos em paralelo”. PMO faz cronograma e aloca dev por projeto. Resultado: cada dev recebe ~20 atividades em paralelo, contexto-switching infinito, nada sai. Ou pior: projeto crítico atrasa porque “dev que conhecia aquela parte saiu de férias”.

Capacity planning evita esse caos. Responde:

• Quantas pessoas você realmente tem disponíveis? (não basta contar cabeças; elas têm suporte, pesquisa, reuniões)
• Quanto trabalho cada pessoa consegue fazer em um período?
• Se temos 3 projetos, qual é o melhor sequenciamento/paralelismo?
• Quando recursos vão sair (férias, rotação)? Como replanejar?
• Qual recurso é gargalo (bottleneck)?

Definições Rápidas

• FTE (Full-Time Equivalent): unidade de capacidade. 1 FTE = 1 pessoa trabalhando 40h/semana dedicada. 0.5 FTE = 20h/semana (pessoa em 2 projetos).

• Capacity: quantidade total de horas de trabalho disponível em um período. Exemplo: 10 devs × 160h/mês = 1.600 horas.

• Demand: quantidade total de horas necessárias para fazer todos os projetos aprovados. Exemplo: 3 projetos × 300h cada = 900 horas.

• Slack (ou Buffer): diferença entre capacity e demand. Se demand = 900h e capacity = 1.600h, slack = 700h. Slack é importante para suporte, reuniões, absências.

• Utilization: % de capacity alocado. (Demand / Capacity) × 100. Ideal: 70-85%. Abaixo = pessoas ociosas; acima = burnout e atrasos.

Passo 1: Calcular Capacity Disponível

Fórmula Básica:

FTE Disponível = (Horas úteis do período / 40) × Número de pessoas

Detalhe importante: horas úteis ≠ horas totais do mês.

Cálculo para 1 mês (Exemplo Brasil):

• Total de horas no mês: 30 dias × 8h = 240h
• Menos: 4 semanas × 8 horas de reuniões (estimate) = 32h
• Menos: 1 semana de férias coletivas = 40h
• Menos: feriados nacionais (típico 2-3/mês) ≈ 16h
• Menos: doença, absências imprevistas (estimativa 2%) ≈ 5h

Horas úteis mês: 240 – 32 – 40 – 16 – 5 = 147h

Se você tem 10 pessoas, capacity = 10 × 147h = 1.470 horas.

Em FTE: 1.470h / 160h (padrão mensal) ≈ 9.2 FTE (não 10!)

Essa diferença de 0.8 FTE é crítica: planejar como se fossem 10 FTE e depois ter apenas 9.2 resulta em atraso.

Passo 2: Mapear Demand Atual

Liste todos projetos/iniciativas aprovadas, com estimativa de horas:

Seu capacity = 9.2 FTE, mas demand = 9.8 FTE.

Você está 6% oversized. Resultado: atraso ou burnout.

Passo 3: Decisões de Trade-off

Agora vêm as decisões duras:

Opção A: Reduzir Demand
– Adiar projeto “Inovação” (200h) até Q2
– Novo demand: 2.300h ≈ 7.6 FTE. Utilization: 82%. Saudável.

Opção B: Aumentar Capacity
– Contratar 1 dev (custo ~R$12K/mês)
– Demand mantém, agora você tem folga para lidar com riscos

Opção C: Sequenciar em vez de Paralelizar
– “Transformação App” (Jan-Mar), depois “Modernização BD” (Apr-Jun)
– Reduz paralelismo, mas aumenta timeline total

Opção D: Outsourcing
– Contratar consultoria para parte do projeto (e.g., infra de FinOps)
– Reduz demand em-house

Melhor prática: combinar. Exemplo: adiar inovação (Opção A) + contratar 0.5 FTE consultoria (Opção D).

Passo 4: Prever Saídas (Turnover, Férias, Ausências)

Matriz de Capacidade por Mês:

Insight: Fevereiro é crítico. DBA é gargalo. Projeto “Modernização BD” (que precisa de DBA) não deve estar no pico em fevereiro.

Passo 5: Alocação de Projetos por Período

Com base na análise acima, recomendação:

Janeiro (4.0 FTE disponível):
– Transformação App: 1.5 FTE
– Modernização BD: 1.2 FTE (DBA começa desenho)
– Suporte/Manutenção: 1.3 FTE

Fevereiro (3.5 FTE disponível — tight!)
– Transformação App: 1.2 FTE (continua)
– Modernização BD: 1.0 FTE (DBA B sai, reduz escopo)
– Suporte: 1.3 FTE

Março (3.5 FTE disponível):
– Transformação App: 1.0 FTE (reta final)
– Modernização BD: 1.2 FTE (Dev A volta de férias, intensifica)
– Suporte: 1.3 FTE

Resultado: cada mês está balanceado, não há burst de demanda em um mês e vácuo em outro.

Passo 6: Identificar Gargalos (Bottlenecks)

Nesse portfólio, DBA D é gargalo crítico:

• Necessário em 2 dos 3 projetos
• Sem backup (único DBA sênior)
• Se sai de férias ou sai da empresa, portfólio inteiro atrasa

Ações:

1. Cross-training: preparar dev pleno para suportar tarefas simples de BD
2. Contratação: adicionar outro DBA sênior (ROI: evita atraso)
3. Outsourcing: infraestrutura BD para consultoria (e.g., Accenture, DXC)
4. Ferramental: automação de tarefas (Apptio para analysis, ferramentas de monitoring)

Para Quem é Técnico:

Data model de capacity planning:

Resource (pessoa)
  ├── Capacity (FTE total/mês)
  ├── Alocações (lista de projetos)
  │   ├── Project
  │   ├── FTE alocado
  │   ├── Start date
  │   └── End date
  └── Skill (Dev, DBA, DevOps, QA, etc.)

Project
  ├── Total effort (horas)
  ├── Skill requirements (DBA: 1, Dev: 2.5, QA: 1)
  ├── Timeline (start, end)
  └── Alocações (lista de recursos)

Demand vs. Capacity Report
  ├── Total capacity available (período)
  ├── Total demand (soma de projetos)
  ├── Gap (capacity - demand)
  ├── Gargalos (skills com >90% utilization)
  └── Forecast (próximos 3 meses)

Integrações:

• RH System (SuccessFactors, Workday): dados de pessoas, férias, ausências
• Planview AdaptiveWork: alocações de projeto, progresso real
• Jira: se você usa Jira, dados de estimativa (story points) e actual
• Planview Portfolios: capacity view do portfólio inteiro

Queries úteis:

-- Que recursos estão 100% alocados?
SELECT resource, SUM(fte_allocated) as total_allocated
FROM allocations
WHERE status = 'active'
GROUP BY resource
HAVING total_allocated >= 1.0

-- Qual skill tem maior demand?
SELECT skill, COUNT(DISTINCT project_id) as num_projects
FROM allocations
WHERE status = 'active'
GROUP BY skill
ORDER BY num_projects DESC

-- Timeline de capacity vs. demand por mês
SELECT month, SUM(capacity) as capacity, 
       SUM(demand) as demand,
       (SUM(capacity) - SUM(demand)) as gap
FROM capacity_report
GROUP BY month
ORDER BY month

Checklist: Implementando Capacity Planning

• [ ] Coletar dados: listar recursos (nome, skill, seniority, start/end date)
• [ ] Calcular capacity: horas úteis/mês × número de pessoas por skill
• [ ] Mapear demand: listar projetos aprovados, estimativas, timeline
• [ ] Comparar: capacity vs. demand por período (há gap?)
• [ ] Decidir: ajustar (priorização, contratação, outsourcing)
• [ ] Alocar: designar pessoas a projetos de forma inteligente
• [ ] Identificar gargalos: que skills/pessoas estão bottleneck?
• [ ] Comunicar: publicar roadmap de capacidade para stakeholders
• [ ] Monitorar: atualizar mensalmente com actual horas vs. planejado
• [ ] Revisar: a cada trimestre, analisar variância e ajustar

Se Você Só Fizer 3 Coisas…

1. Calcule capacity real: Não basta contar cabeças. Compute horas úteis corretamente (desconte reuniões, férias, absências, suporte).

2. Mapeie demand atual: Listar TODOS os projetos/trabalho, com estimativas em horas. Responda: Temos gente suficiente?

3. Identifique gargalos: Que skills/pessoas são críticas? Quais têm >90% utilization? Faça plano de mitigation (cross-training, contratação, outsourcing).

FAQs

P: Como estimar horas se projetos são vagos?
R: Use técnicas como Planning Poker, 3-point estimate (otimista/pessimista/esperado), ou dados históricos de projetos similares.

P: E se demand > capacity?
R: Repriorize (adiar low-impact), contrate, terceirize, ou aceite prazo maior. Não force pessoas a fazer 12h/dia (resulta em atrito).

P: Qual ferramenta usar?
R: Planview AdaptiveWork (melhor overall), Jira (se você usa Jira), Excel bem estruturado (funciona para times pequenos).

P: Com que frequência revisar?
R: Mensal (ajustes tático), trimestral (planejamento), anual (orçamento de headcount).

P: Como lidar com incerteza? Projetos sempre estouram.
R: Use buffer de 15-20% acima do demand. Exemplo: se demand = 8.5 FTE, aloque 9.5 FTE máximo.

Leitura & Referências

• “Capacity Planning” (capítulo de “The Phoenix Project”)
• Planview “Resource Capacity Planning Best Practices”
• Estudo de caso: capacity planning em transformação digital

CTA Final:

“Seus projetos sempre estouram prazo? Pessoas sobrecarregadas? Implementar capacity planning muda o jogo. Agende workshop de 4h: estruturamos seu modelo, identificamos gargalos, e criamos forecast de recursos para os próximos 3 trimestres. Fale com especialista TWRT.“

Leitura Relacionada

• PPM vs SPM
• Dashboards de Portfólio
• Gestão de Riscos
• Métricas Kanban

Eduardo Salerno

Eduardo Salerno é especialista em gestão de portfólios e projetos de TI, com ampla experiência em implementações Planview e transformação digital. Na TWRT, lidera iniciativas que conectam estratégia de negócio à execução tecnológica.

See Full Bio