8 min leitura • Guide 731 of 877
Alocação de Recursos em Ambientes Multi-Projeto
Gerenciar recursos entre projetos requer visibilidade e planejamento. GitScrum ajuda times alocar capacidade entre projetos com views de workload, planejamento de capacidade e rastreamento de utilização.
Desafios de Recursos
Problemas Comuns
PROBLEMAS DE RECURSOS MULTI-PROJETO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SUPER-ALOCAÇÃO: │
│ "Alex está alocado em 3 projetos a 50% cada" │
│ → 150% alocação = burnout e deadlines perdidos │
│ │
│ CONTEXT SWITCHING: │
│ "Sara trabalha nos Projetos A, B e C diariamente" │
│ → 40% do tempo perdido trocando entre contextos │
│ │
│ COMPROMISSOS INVISÍVEIS: │
│ "Eu não sabia que Jordan já estava full" │
│ → Alocações escondidas levam a surpresas │
│ │
│ CONFLITOS DE PRIORIDADE: │
│ "Ambos projetos dizem que são top priority" │
│ → Prioridades não claras = context switching │
│ │
│ TRABALHO NÃO PLANEJADO: │
│ "Pedidos de suporte continuam puxando pessoas" │
│ → Sem buffer para interrupções │
│ │
│ MISMATCHES DE HABILIDADES: │
│ "Só uma pessoa conhece o sistema de pagamentos" │
│ → Gargalos em indivíduos específicos │
│ │
│ RESULTADO: │
│ • Projetos atrasados │
│ • Time estressado │
│ • Qualidade sofre │
│ • Compromissos não cumpridos │
└─────────────────────────────────────────────────────────────┘
Custo do Context Switching
O CUSTO REAL DE DIVIDIR TEMPO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRODUTIVIDADE ESPERADA VS REAL: │
│ │
│ Projetos │ Esperado │ Real │ Perdido │
│ ─────────┼──────────────┼─────────────┼────────────── │
│ 1 │ 100% │ 100% │ 0% │
│ 2 │ 50% + 50% │ 40% + 40% │ 20% │
│ 3 │ 33% × 3 │ 20% × 3 │ 40% │
│ 4 │ 25% × 4 │ 10% × 4 │ 60% │
│ 5 │ 20% × 5 │ 5% × 5 │ 75% │
│ │
│ POR QUE ISSO ACONTECE: │
│ │
│ • Tempo para lembrar onde parou │
│ • Energia mental esgotada pela troca │
│ • Reuniões multiplicam com cada projeto │
│ • Overhead de comunicação aumenta │
│ • Nenhum trabalho profundo possível │
│ │
│ ESTADO IDEAL: │
│ • 1 projeto primário (80% foco) │
│ • 1 projeto secundário (20% foco) │
│ • Handoffs limpos, não switching constante │
│ │
│ SE ALGUÉM ESTÁ EM 3+ PROJETOS: │
│ → Eles são efetivos em nenhum deles │
└─────────────────────────────────────────────────────────────┘
Estratégias de Alocação
Planejamento de Capacidade
ABORDAGEM DE PLANEJAMENTO DE CAPACIDADE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PASSO 1: DETERMINAR CAPACIDADE DISPONÍVEL │
│ │
│ Pessoa: Alex (Full-time) │
│ Dias de trabalho no mês: 22 │
│ Horas por dia: 8 │
│ Capacidade total: 176 horas │
│ │
│ SUBTRAIR OVERHEAD: │
│ • Reuniões/cerimônias: -16 horas (10%) │
│ • Rotação de suporte: -16 horas (10%) │
│ • Folga este mês: -8 horas (1 dia) │
│ • Buffer para não planejado: -18 horas (10%) │
│ ───────────────────────────────── │
│ Capacidade alocável: 118 horas │
│ │
│ PASSO 2: ALOCAR PARA PROJETOS │
│ │
│ Projeto Alpha: 80 horas (68%) │
│ Projeto Beta: 38 horas (32%) │
│ Total: 118 horas (100%) │
│ │
│ REGRAS: │
│ • Nunca exceda 100% capacidade alocável │
│ • Máximo 2 projetos por pessoa │
│ • Um projeto deve ter foco majoritário │
│ • Revise e ajuste semanalmente │
└─────────────────────────────────────────────────────────────┘
Modelos de Alocação
MODELOS DE ALOCAÇÃO DE RECURSOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MODELO 1: TIMES DEDICADOS │
│ │
│ Projeto A: Time de 4 (100% dedicado) │
│ Projeto B: Time de 3 (100% dedicado) │
│ Projeto C: Time de 3 (100% dedicado) │
│ │
│ ✅ Sem context switching │
│ ✅ Ownership claro │
│ ✅ Time constrói velocidade │
│ ❌ Inflexível │
│ ❌ Pode não ter skills certos │
│ │
│ MODELO 2: MATRIZ (Recursos Compartilhados) │
│ │
│ Alex: Projeto A (50%) + Projeto B (50%) │
│ Jordan: Projeto B (50%) + Projeto C (50%) │
│ Maria: Projeto A (100%) │
│ │
│ ✅ Matching flexível de skills │
│ ✅ Conhecimento cross-projeto │
│ ❌ Overhead de context switching │
│ ❌ Prioridades não claras │
│ │
│ MODELO 3: HÍBRIDO │
│ │
│ Time core dedicado a cada projeto │
│ Especialistas compartilhados conforme necessário │
│ Atribuições primário/secundário claras │
│ │
│ ✅ Melhor dos dois mundos │
│ ✅ Requer bom planejamento │
└─────────────────────────────────────────────────────────────┘
Visibilidade de Workload
View de Alocação do Time
VIEW DE WORKLOAD GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ Alocação do Time - Janeiro 2024 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Pessoa │ Projeto A │ Projeto B │ Projeto C │ Total │
│ ───────────┼───────────┼───────────┼───────────┼───────────│
│ Alex │ ████ 80% │ │ ██ 20% │ 100% ✅ │
│ Jordan │ │ ████ 100% │ │ 100% ✅ │
│ Maria │ ██ 40% │ ██ 40% │ ██ 40% │ 120% ⚠️ │
│ Sam │ ██████100%│ │ │ 100% ✅ │
│ Taylor │ │ ██ 50% │ ██ 30% │ 80% ✅ │
│ │
│ CAPACIDADE DO PROJETO: │
│ Projeto A: 220% de pessoa (2.2 pessoas) │
│ Projeto B: 190% de pessoa (1.9 pessoas) │
│ Projeto C: 90% de pessoa (0.9 pessoas) │
│ │
│ ⚠️ ALERTAS: │
│ • Maria está super-alocada (120%) │
│ • Taylor tem 20% não alocado │
│ │
│ [Ajustar Alocações] [Ver por Semana] [Exportar] │
└─────────────────────────────────────────────────────────────┘
View por Sprint
BREAKDOWN DE WORKLOAD DO SPRINT:
┌─────────────────────────────────────────────────────────────┐
│ Sprint 24 - Workload do Time │
├─────────────────────────────────────────────────────────────┤
│ │
│ ALEX (Capacidade: 40 pontos) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Projeto A: 32 pontos ││
│ │ [████████████████████████████░░░░] ││
│ │ ├── Integração de pagamento (13 pts) ││
│ │ ├── Refatoração de API (8 pts) ││
│ │ └── Correções de bugs (11 pts) ││
│ │ ││
│ │ Projeto C: 8 pontos ││
│ │ [████████] ││
│ │ └── Review e suporte (8 pts) ││
│ │ ││
│ │ Total: 40/40 pontos (100%) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MARIA (Capacidade: 35 pontos) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ⚠️ SUPER-ALOCADA: 42/35 pontos (120%) ││
│ │ ││
│ │ Projeto A: 18 pontos ││
│ │ Projeto B: 14 pontos ││
│ │ Projeto C: 10 pontos ││
│ │ ││
│ │ RECOMENDAÇÃO: Mover 7 pontos para Taylor ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Gerenciando Conflitos
Decisões de Prioridade
RESOLVENDO CONFLITOS DE RECURSOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CONFLITO: Alex necessário em ambos Projetos A e B │
│ │
│ PASSO 1: ESCALAR PARA DECISOR │
│ Quem decide a prioridade? │
│ (Não o contribuidor individual) │
│ │
│ PASSO 2: COMPARAR IMPACTO │
│ │
│ Projeto A precisa de Alex para: │
│ • Sistema de pagamento (só Alex conhece) │
│ • Impacto se atrasar: Não pode lançar feature │
│ • Impacto no cronograma: 2 semanas de atraso │
│ │
│ Projeto B precisa de Alex para: │
│ • Otimização de performance │
│ • Impacto se atrasar: Experiência mais lenta │
│ • Impacto no cronograma: 1 semana de atraso │
│ │
│ PASSO 3: TOMAR DECISÃO │
│ Decisão: Alex foca no Projeto A │
│ Razão: Bloqueando lançamento vs melhoria de qualidade │
│ │
│ PASSO 4: COMUNICAR │
│ • Time do Projeto B informado do atraso │
│ • Alternativa explorada (alguém mais pode ajudar?) │
│ • Cronograma ajustado │
│ │
│ PASSO 5: DOCUMENTAR │
│ Registrar decisão e racional │
│ Prevenir mesmo conflito de recorrer │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Para Gestão Multi-Projeto
- Visibilidade total — Dashboard cross-projeto
- Máximo 2 projetos — Por pessoa
- Buffer de 15-20% — Capacidade não alocada
- Revisão semanal — Ajustes regulares
- Dados para decisões — Não política
Anti-Padrões
ERROS DE MULTI-PROJETO:
✗ Pessoas em 3+ projetos
✗ 100% alocação (sem buffer)
✗ Prioridades não claras
✗ Compromissos escondidos
✗ Decisões de última hora
✗ Ignorar context switching
✗ Único ponto de falha
✗ Sem rastreamento de utilização