6 min leitura • Guide 582 of 877
Melhores Práticas de Alocação de Recursos
Alocação de recursos é a arte de combinar capacidade do time com demandas do projeto—colocar as pessoas certas no trabalho certo no momento certo. Dashboards multi-projeto do GitScrum e features de planejamento de capacidade ajudam gestores a ver carga de trabalho do time entre iniciativas, prevenindo super-alocação e garantindo que projetos críticos tenham os recursos necessários.
Abordagens de Alocação
| Abordagem | Melhor Para | Desvantagens |
|---|---|---|
| Times dedicados | Projetos grandes, foco | Menos flexibilidade |
| Recursos compartilhados | Projetos pequenos, habilidades | Context switching |
| Baseada em capacidade | Trabalho previsível | Ignora matching de skills |
| Baseada em habilidades | Trabalho especializado | Pode criar gargalos |
Planejamento de Capacidade
FRAMEWORK DE PLANEJAMENTO DE CAPACIDADE
CÁLCULO DE CAPACIDADE:
┌─────────────────────────────────────────────────┐
│ Capacidade Total Disponível: │
│ │
│ Tamanho do time: 8 desenvolvedores │
│ Duração do sprint: 2 semanas │
│ Dias por sprint: 10 dias por pessoa │
│ Total de dias: 80 pessoa-dias │
│ │
│ Ajustes de Capacidade: │
│ ├── Férias/Feriados: -8 dias (10%) │
│ ├── Reuniões: -8 dias (10%) │
│ ├── Suporte/bugs: -8 dias (10%) │
│ └── Buffer: -8 dias (10%) │
│ │
│ Disponível para trabalho planejado: 48 dias │
│ Com ~1 story point por dia: ~48 pontos/sprint │
└─────────────────────────────────────────────────┘
RASTREAMENTO DE CAPACIDADE:
┌─────────────────────────────────────────────────┐
│ Visão Geral de Capacidade Q2 2025: │
│ │
│ Sprint Capacid. Planejado Real Notas │
│ ────────────────────────────────────────── │
│ S1 48 pts 46 pts 44 pts Bom │
│ S2 40 pts 42 pts 38 pts 2 folgas│
│ S3 48 pts 50 pts 45 pts Acima │
│ S4 44 pts 44 pts (atual) │
│ │
│ Velocidade média: 42 pontos/sprint │
│ Planejar em: 42 pontos (realista) │
└─────────────────────────────────────────────────┘
Alocação por Tipo de Trabalho
ALOCAÇÃO POR TIPO DE TRABALHO
DIVISÃO RECOMENDADA:
┌─────────────────────────────────────────────────┐
│ Tipo de Trabalho Alocação Propósito │
│ ────────────────────────────────────────── │
│ Features 60-70% Novo valor │
│ Dívida Técnica 15-20% Sustentabilid. │
│ Bugs/Suporte 10-15% Qualidade │
│ Inovação 5-10% Valor futuro │
└─────────────────────────────────────────────────┘
POR MATURIDADE DO PRODUTO:
┌─────────────────────────────────────────────────┐
│ Produto Novo (0-2 anos): │
│ ├── Features: 80% │
│ ├── Dívida Técnica:10% │
│ ├── Bugs: 5% │
│ └── Inovação: 5% │
│ │
│ Produto em Crescimento (2-5 anos): │
│ ├── Features: 65% │
│ ├── Dívida Técnica:20% │
│ ├── Bugs: 10% │
│ └── Inovação: 5% │
│ │
│ Produto Maduro (5+ anos): │
│ ├── Features: 50% │
│ ├── Dívida Técnica:25% │
│ ├── Bugs: 15% │
│ └── Inovação: 10% │
└─────────────────────────────────────────────────┘
Alocação Baseada em Habilidades
MATRIZ DE HABILIDADES E ALOCAÇÃO
MATRIZ DE HABILIDADES DO TIME:
┌─────────────────────────────────────────────────┐
│ Pessoa Frontend Backend DevOps Mobile │
│ ────────────────────────────────────────── │
│ Alex ● ◐ ○ ○ │
│ Jordan ◐ ● ◐ ○ │
│ Sam ● ● ○ ○ │
│ Taylor ○ ◐ ● ○ │
│ Chris ○ ○ ○ ● │
│ │
│ ● Expert ◐ Proficiente ○ Aprendendo │
└─────────────────────────────────────────────────┘
ALOCAÇÃO POR NECESSIDADE DE SKILL:
┌─────────────────────────────────────────────────┐
│ Projeto A (Redesign Dashboard): │
│ ├── Necessidade: 2 Frontend, 1 Backend │
│ ├── Alocar: Alex (FE), Sam (FE+BE) │
│ └── Duração: 6 sprints │
│ │
│ Projeto B (Migração API): │
│ ├── Necessidade: 2 Backend, 1 DevOps │
│ ├── Alocar: Jordan (BE), Taylor (DevOps) │
│ └── Duração: 4 sprints │
│ │
│ Projeto C (App Mobile): │
│ ├── Necessidade: 1 Mobile, 1 Backend │
│ ├── Alocar: Chris (Mobile) │
│ ├── Gap: Precisa suporte Backend do Projeto B │
│ └── Duração: 8 sprints │
└─────────────────────────────────────────────────┘
ENDEREÇANDO GAPS DE HABILIDADES:
┌─────────────────────────────────────────────────┐
│ Opções quando habilidades não combinam: │
│ │
│ 1. Cross-training │
│ └── Parear junior com expert │
│ │
│ 2. Realocação temporária │
│ └── Emprestar de outro time │
│ │
│ 3. Ajuda externa │
│ └── Contractor ou consultor │
│ │
│ 4. Ajuste de escopo │
│ └── Reduzir escopo para combinar skills │
│ │
│ 5. Ajuste de cronograma │
│ └── Estender para permitir aprendizado │
└─────────────────────────────────────────────────┘
Resolvendo Conflitos
RESOLUÇÃO DE CONFLITOS DE RECURSOS
CENÁRIO DE CONFLITO:
┌─────────────────────────────────────────────────┐
│ Situação: │
│ ├── Projeto A precisa Jordan full-time │
│ ├── Projeto B precisa Jordan full-time │
│ ├── Jordan é único expert backend disponível │
│ └── Ambos projetos são "alta prioridade" │
└─────────────────────────────────────────────────┘
FRAMEWORK DE RESOLUÇÃO:
┌─────────────────────────────────────────────────┐
│ Passo 1: Coletar dados │
│ ├── Impacto em receita de cada projeto │
│ ├── Deadlines contratuais │
│ ├── Importância estratégica │
│ └── Consequência de atraso para cada │
│ │
│ Passo 2: Apresentar opções │
│ ├── Opção A: Jordan no Projeto A │
│ │ Impacto: Projeto B atrasado 4 semanas │
│ │ │
│ ├── Opção B: Jordan no Projeto B │
│ │ Impacto: Projeto A atrasado 6 semanas │
│ │ │
│ ├── Opção C: Dividir Jordan 50/50 │
│ │ Impacto: Ambos atrasados 3 semanas, risco │
│ │ │
│ └── Opção D: Contractor para um projeto │
│ Impacto: R$30K custo, sem atraso │
│ │
│ Passo 3: Escalar para decisor │
│ └── Apresentar opções com dados, obter decisão │
│ │
│ Passo 4: Documentar e comunicar │
│ └── Registrar decisão e racional │
└─────────────────────────────────────────────────┘
Melhores Práticas
Para Alocação de Recursos
- Visibilidade — Saiba onde todos estão
- Buffer — Nunca 100% alocado
- Máximo 2 projetos — Por pessoa
- Revisão regular — Ajuste semanal/quinzenal
- Dados para decisões — Não intuição
Anti-Padrões
ERROS DE ALOCAÇÃO:
✗ Todos a 20% em 5 projetos
✗ Único ponto de falha
✗ Sem buffer para urgências
✗ Alocar capacidade futura muito cedo
✗ Ignorar context switching
✗ Decisões sem dados
✗ Conflitos resolvidos na última hora
✗ Habilidades não consideradas