Capacity Planning: Intelligent Resource Allocation

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

Full Article

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)

For Technical Staff:

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

If You Only Do 3 Things…

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.

Reading & References

• “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.“

Related Reading

• PPM vs. SPM
• Portfolio Dashboards
• Risk Management
• Métricas Kanban

Eduardo Salerno

Eduardo Salerno is a specialist in IT portfolio and project management, with extensive experience in Planview implementations and digital transformation. At TWRT, he leads initiatives that bridge the gap between business strategy and technological execution.

See Full Bio