7 min leitura • Guide 223 of 877
Gerenciando Balanço de Carga de Trabalho do Time
Cargas de trabalho desbalanceadas criam problemas: membros sobrecarregados sofrem burnout enquanto outros esperam por trabalho. Gestão efetiva de workload garante ritmo sustentável, previne gargalos e mantém todo o time produtivo—não apenas as pessoas mais ocupadas.
Problemas de Workload
| Sinal de Desbalanceamento | Consequência | Solução |
|---|---|---|
| Uma pessoa sempre ocupada | Gargalo + burnout | Distribuir + cross-train |
| Algumas pessoas ociosas | Capacidade desperdiçada | Melhor alocação |
| Hora extra como normal | Insustentável | Planejamento realista |
| Mesma pessoa on-call | Risco de burnout | Rotação justa |
| Silos de conhecimento | Ponto único de falha | Compartilhar conhecimento |
Visibilidade
Dashboard de Workload
VISIBILIDADE DE WORKLOAD DO TIME
════════════════════════════════
ALOCAÇÃO DO SPRINT ATUAL:
─────────────────────────────────────
┌─────────────────────────────────────────────────────────┐
│ Workload do Time - Sprint 26 │
├─────────────────────────────────────────────────────────┤
│ │
│ SARAH │
│ ████████████████░░░░ 85% (17h atribuídas) │
│ Tasks: GS-400, GS-401, GS-402 │
│ Status: Na capacidade │
│ │
│ MIKE │
│ ██████████░░░░░░░░░░ 55% (11h atribuídas) │
│ Tasks: GS-403, GS-404 │
│ Status: Pode pegar mais │
│ │
│ ALEX │
│ ████████████████████ 100% (20h atribuídas) ⚠️ │
│ Tasks: GS-405, GS-406, GS-407, GS-408 │
│ Status: SOBRECARREGADO │
│ │
│ EMMA │
│ ████████████░░░░░░░░ 65% (13h atribuídas) │
│ Tasks: GS-409, GS-410 │
│ Status: Bom │
│ │
├─────────────────────────────────────────────────────────┤
│ AÇÃO: Reatribuir GS-408 de Alex para Mike │
└─────────────────────────────────────────────────────────┘
REBALANCEAR:
├── Mover trabalho do sobrecarregado
├── Adicionar trabalho ao subutilizado
├── Considerar match de skills
└── Revisar na planning
Análise de Tendência
ANÁLISE DE TENDÊNCIA DE WORKLOAD
════════════════════════════════
ALOCAÇÃO POR PESSOA AO LONGO DO TEMPO:
─────────────────────────────────────
Sprint 22 Sprint 23 Sprint 24 Sprint 25
Sarah 85% 90% 95% 100% ⚠️
Mike 60% 55% 50% 45%
Alex 75% 80% 85% 90%
Emma 70% 75% 70% 65%
PADRÕES:
├── Sarah: Tendência subindo → aproximando burnout
├── Mike: Tendência descendo → subutilizado
├── Alex: Tendência subindo → monitorar de perto
├── Emma: Estável → saudável
INVESTIGAR:
─────────────────────────────────────
Por que Sarah está sempre sobrecarregada?
├── Única que conhece sistema de pagamento
├── Recebe todos os bugs urgentes
├── Não consegue dizer não
├── Outros não foram treinados
AÇÃO:
├── Cross-train Mike em sistema de pagamento
├── Rotacionar atribuição de bugs urgentes
├── Proteger capacidade de sprint da Sarah
└── Longo prazo: Reduzir ponto único de falha
Estratégias de Balanceamento
Justiça na Atribuição
ATRIBUIÇÃO JUSTA DE TRABALHO
════════════════════════════
ROUND-ROBIN BUGS:
─────────────────────────────────────
Em vez de: Atribuir para quem conhece
Faça: Rotacionar pelo time
Semana 1: Sarah lida com bugs chegando
Semana 2: Mike lida com bugs chegando
Semana 3: Alex lida com bugs chegando
Semana 4: Emma lida com bugs chegando
Repetir
BENEFÍCIOS:
├── Todos aprendem diferentes áreas
├── Ninguém vira único especialista
├── Carga distribuída
├── Reduz silos
EXCEÇÕES:
├── Bug muito específico → especialista pode ajudar
├── Mas especialista mentor → outro executa
└── Meta: distribuir conhecimento
Cross-Training
ESTRATÉGIA DE CROSS-TRAINING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ IDENTIFICAR SILOS: │
│ ──────────────── │
│ • Pagamentos: Só Sarah conhece │
│ • Infraestrutura: Só Alex conhece │
│ • Mobile: Só Emma conhece │
│ │
│ PLANO DE CROSS-TRAINING: │
│ ────────────────────── │
│ Q1: Mike faz par com Sarah em pagamentos │
│ Q2: Emma faz par com Alex em infra │
│ Q3: Sarah faz par com Emma em mobile │
│ │
│ COMO: │
│ ───── │
│ • Pair programming em tarefas reais │
│ • Segunda pessoa faz, primeira revisa │
│ • Documentação durante o processo │
│ • Gradualmente dar mais autonomia │
│ │
│ META: │
│ ───── │
│ Cada área crítica → pelo menos 2 pessoas sabem │
│ │
└─────────────────────────────────────────────────────────────┘
WIP Limits
Limitando Trabalho em Progresso
WIP LIMITS POR PESSOA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ REGRA: Máximo de tarefas em andamento por pessoa │
│ │
│ RECOMENDAÇÃO: │
│ • Desenvolvimento: 2 tarefas max │
│ • Bug fixes: 1-2 tarefas max │
│ • Code review: Não conta no limite de dev │
│ │
│ POR QUE: │
│ • Reduz context switching │
│ • Termina coisas em vez de começar muitas │
│ • Mantém fluxo saudável │
│ • Evita sobrecarga │
│ │
│ NO GITSCRUM: │
│ ────────────── │
│ Configurar WIP limit na coluna "Doing" │
│ Limite = número de pessoas × 2 │
│ │
│ VISUALIZAÇÃO: │
│ ───────────── │
│ Doing (4/8) → Saudável │
│ Doing (8/8) ⚠️ → No limite │
│ Doing (9/8) 🔴 → Acima do limite, não adicionar mais │
│ │
└─────────────────────────────────────────────────────────────┘
Prevenção de Burnout
Sinais de Alerta
INDICADORES DE BURNOUT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ 🚨 SINAIS INDIVIDUAIS: │
│ • Commits à noite/fim de semana regularmente │
│ • Mensagens fora de horário │
│ • Sempre na capacidade máxima │
│ • Reclamações frequentes de cansaço │
│ • Qualidade caindo │
│ • Cinismo aumentando │
│ │
│ 🚨 SINAIS DO TIME: │
│ • Uma pessoa é sempre gargalo │
│ • Mesma pessoa em todas as discussões urgentes │
│ • Férias não tiradas │
│ • "Só [nome] sabe fazer isso" │
│ │
│ AÇÕES IMEDIATAS: │
│ ───────────────── │
│ 1. Redistribuir trabalho agora │
│ 2. Proteger tempo de descanso │
│ 3. Priorizar cross-training │
│ 4. Reduzir escopo do sprint se necessário │
│ │
└─────────────────────────────────────────────────────────────┘
Práticas Sustentáveis
PRÁTICAS DE RITMO SUSTENTÁVEL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ROTAÇÃO DE ON-CALL: │
│ • Rotação justa (não mesma pessoa sempre) │
│ • Tempo de recuperação após on-call pesado │
│ • Backup definido │
│ │
│ PROTEÇÃO DE FOCO: │
│ • Blocos de 4h sem reuniões │
│ • No-meeting days │
│ • Resposta async esperada (não instant) │
│ │
│ CAPACIDADE REALISTA: │
│ • Não planejar 100% da capacidade │
│ • Buffer para imprevistos (20%) │
│ • Aceitar que estimativas são imprecisas │
│ │
│ FÉRIAS E FOLGAS: │
│ • Encorajar uso de férias │
│ • Não contatar em folga │
│ • Cobertura planejada │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Checklist de Implementação
CHECKLIST DE BALANÇO DE WORKLOAD
════════════════════════════════
VISIBILIDADE:
☐ Dashboard de alocação visível
☐ Tendências rastreadas
☐ Silos identificados
☐ Sobrecarga visível
BALANCEAMENTO:
☐ Rotação de bugs/urgentes
☐ Cross-training planejado
☐ Atribuição considerando carga atual
☐ Rebalanceamento quando necessário
WIP:
☐ Limites de WIP definidos
☐ Time respeita limites
☐ Terminar > começar
☐ Board reflete realidade
SUSTENTABILIDADE:
☐ On-call rotacionado
☐ Tempo de foco protegido
☐ Capacidade realista planejada
☐ Férias encorajadas
PREVENÇÃO:
☐ Sinais de burnout monitorados
☐ Ação antes de crônico
☐ Conversas individuais regulares
☐ Cultura de pedir ajuda
Workload bem balanceado significa times sustentáveis—capacidade distribuída, silos eliminados e ritmo que pode ser mantido indefinidamente.