Identificando Gargalos no Workflow de Desenvolvimento

Gargalos são as restrições ocultas que limitam toda a produção do seu time. Um time de 10 pessoas com um gargalo de code review de 1 pessoa é efetivamente um time de 1 pessoa para review. Encontrar e eliminar gargalos é a melhoria de maior alavancagem que você pode fazer.

Indicadores de Gargalo

Encontrando Gargalos

Análise de Dados

ANÁLISE DE BREAKDOWN DE CYCLE TIME
═════════════════════════════════════

MEDIR TEMPO EM CADA ESTÁGIO:
─────────────────────────────────────
Estágio         Tempo Médio  % do Total
─────────────────────────────────────
Pronto → Início 0.5 dias     10%
Desenvolvimento 2.0 dias     40%
Code Review     1.5 dias     30%  ← Gargalo?
Testes QA       0.5 dias     10%
Deploy          0.5 dias     10%
─────────────────────────────────────
Total           5.0 dias     100%

ANÁLISE:
├── Review é 30% do cycle time total
├── Relativo a desenvolvimento (40%), é desproporcional
├── Tempo de fila em review = desperdício
└── Foque melhoria aqui

TENDÊNCIA SEMANAL:
Semana 1: Review 1.2 dias
Semana 2: Review 1.5 dias
Semana 3: Review 1.8 dias ← Piorando
Semana 4: Review 2.1 dias

Tempo de review crescente = gargalo de capacidade

Observação do Board

DETECÇÃO VISUAL DE GARGALO
════════════════════════════

OLHE SEU BOARD:
┌────────────────────────────────────────────────────────┐
│  Pronto    │ Em Progresso│  Review   │  QA  │  Done   │
├────────────────────────────────────────────────────────┤
│  [T1]      │  [T5]       │  [T8]     │ [T14]│ [Done]  │
│  [T2]      │  [T6]       │  [T9]     │      │ [Done]  │
│  [T3]      │  [T7]       │  [T10]    │      │ [Done]  │
│  [T4]      │             │  [T11]    │      │         │
│            │             │  [T12] ←──│──────│── PILHA │
│            │             │  [T13]    │      │         │
└────────────────────────────────────────────────────────┘

GARGALO: Coluna de Review
├── 6 itens esperando
├── Mais que outros estágios
├── Idade: Alguns com 3+ dias
└── QA está faminta (apenas 1 item)

IMPACTO:
├── Desenvolvedores terminam mas não conseguem entregar
├── Esperar = inventário = desperdício
├── Atrasa feedback para cliente
└── Frustração para o time

Input do Time

PESQUISA DE GARGALOS COM O TIME
═══════════════════════════════

PERGUNTE AO TIME:
─────────────────────────────────────
1. "Onde você espera mais frequentemente?"
2. "O que te impede de entregar?"
3. "Qual processo te frustra?"
4. "Se pudesse eliminar uma espera, qual?"

RESPOSTAS COMUNS:
├── "Esperando code review"
├── "Esperando esclarecimento de requisitos"
├── "Esperando aprovação de design"
├── "Esperando acesso a ambiente"
├── "Esperando API de terceiros"
└── "Esperando janela de deploy"

EXERCÍCIO DE RETROSPECTIVA:
1. Cada pessoa escreve top 3 esperas
2. Agrupe itens similares
3. Vote no maior impacto
4. Foque nos top 1-2
5. Crie action item

Gargalos Comuns

Code Review

GARGALO DE CODE REVIEW
═══════════════════════

SINTOMAS:
├── PRs abertos por dias
├── Comentários de review chegam tarde demais
├── Desenvolvedores "passam para frente" para pegar novo trabalho
└── Merge conflicts aumentam

CAUSAS RAIZ:
├── Poucos reviewers qualificados
├── PRs muito grandes
├── Falta de prioridade para reviews
└── Falta de tempo dedicado

SOLUÇÕES:
┌─────────────────────────────────────────────────────────────┐
│  CURTO PRAZO:                                               │
│  • Bloquear tempo diário para reviews (30-60 min)           │
│  • Limitar tamanho de PRs (< 400 linhas)                    │
│  • Notificações para PRs aguardando                         │
│                                                             │
│  MÉDIO PRAZO:                                               │
│  • Treinar mais pessoas para review                         │
│  • Pair programming (review built-in)                       │
│  • Linting automatizado para feedback rápido                │
│                                                             │
│  LONGO PRAZO:                                               │
│  • Cultura de "review primeiro"                             │
│  • WIP limits incluem PRs em review                         │
│  • Métricas de tempo de review                              │
└─────────────────────────────────────────────────────────────┘

QA e Testes

GARGALO DE QA
═════════════

SINTOMAS:
├── Trabalho acumula antes de QA
├── QA testando features de sprints anteriores
├── Bugs encontrados muito tarde
└── Releases atrasam esperando testes

SOLUÇÕES:
┌─────────────────────────────────────────────────────────────┐
│  CURTO PRAZO:                                               │
│  • Priorizar testes de features críticas                    │
│  • Developers fazem testes básicos antes de QA              │
│  • Limitar features em progresso                            │
│                                                             │
│  MÉDIO PRAZO:                                               │
│  • Investir em automação de testes                          │
│  • QA embarcado no time (shift-left)                        │
│  • Critérios de aceitação claros                            │
│                                                             │
│  LONGO PRAZO:                                               │
│  • TDD e testes unitários robustos                          │
│  • CI/CD com testes automatizados                           │
│  • Quality ownership compartilhado                          │
└─────────────────────────────────────────────────────────────┘

Eliminando Gargalos

ESTRATÉGIAS DE ELIMINAÇÃO DE GARGALOS

1. ADICIONAR CAPACIDADE:
┌─────────────────────────────────────────────────────────────┐
│  • Mais pessoas no gargalo                                  │
│  • Treinar pessoas existentes                               │
│  • Contratar para a skill específica                        │
│  Cuidado: Adicionar pessoas leva tempo para ser efetivo     │
└─────────────────────────────────────────────────────────────┘

2. REDUZIR DEMANDA:
┌─────────────────────────────────────────────────────────────┐
│  • Limitar trabalho entrando no gargalo                     │
│  • Batching de trabalho similar                             │
│  • Eliminar trabalho desnecessário                          │
└─────────────────────────────────────────────────────────────┘

3. AUTOMATIZAR:
┌─────────────────────────────────────────────────────────────┐
│  • Automatizar atividades repetitivas                       │
│  • Linting, formatação automática                           │
│  • Testes automatizados                                     │
│  • Deploy automatizado                                      │
└─────────────────────────────────────────────────────────────┘

4. MUDAR O PROCESSO:
┌─────────────────────────────────────────────────────────────┐
│  • Eliminar etapa se não agrega valor                       │
│  • Mover atividade para antes/depois                        │
│  • Dividir em etapas menores paralelas                      │
└─────────────────────────────────────────────────────────────┘

Métricas de Monitoramento

MONITORANDO GARGALOS

MÉTRICAS POR ESTÁGIO:
┌─────────────────────────────────────────────────────────────┐
│  Estágio    │ Tempo Médio │ Itens │ Tendência              │
│─────────────┼─────────────┼───────┼────────────────────────│
│  Pronto     │ 0.3 dias    │  5    │ → Estável              │
│  Dev        │ 1.8 dias    │  3    │ ↓ Melhorando           │
│  Review     │ 1.2 dias    │  4    │ ↗ Piorando             │
│  QA         │ 0.8 dias    │  2    │ → Estável              │
│  Deploy     │ 0.2 dias    │  1    │ → Estável              │
└─────────────────────────────────────────────────────────────┘

ALERTAS:
• Review piorando - investigar capacidade
• Nenhum estágio deve ter >30% do cycle time
• Itens esperando >3 dias = problema

Soluções Relacionadas

• Visualizando Gargalos
• Otimização de Workflow
• Limites WIP
• Code Review