Medindo Performance de Time Efetivamente

Medir performance de time é essencial mas perigoso. Métricas erradas criam incentivos perversos, gaming e disfunção. Métricas certas iluminam a realidade, geram melhoria e respeitam complexidade. Foque em resultados sobre outputs, tendências sobre snapshots e time sobre métricas individuais.

Filosofia de Métricas

Métricas Perigosas

O que NÃO Medir

MÉTRICAS QUE CAUSAM DANO
════════════════════════

LINHAS DE CÓDIGO:
─────────────────────────────────────
Problema: Mais código ≠ melhor
Gaming: Código verboso, sem refatoração
Resultado: Codebase inchado, não manutenível

COMMITS POR DIA:
─────────────────────────────────────
Problema: Quantidade ≠ qualidade
Gaming: Commits minúsculos, dividir trabalho
Resultado: Histórico ruidoso, sem melhoria real

HORAS TRABALHADAS:
─────────────────────────────────────
Problema: Presença ≠ produtividade
Gaming: Ficar tarde fazendo nada
Resultado: Burnout, ressentimento

BUGS ENCONTRADOS (para testers):
─────────────────────────────────────
Problema: Incentiva encontrar bugs sobre prevenir
Gaming: Reportar issues menores, dividir bugs
Resultado: Foco em bugs, não qualidade

VELOCIDADE INDIVIDUAL:
─────────────────────────────────────
Problema: Desencoraja ajudar outros
Gaming: Inflar estimativas
Resultado: Disfunção do time

COMPARAR VELOCIDADES DE TIMES:
─────────────────────────────────────
Problema: Times estimam diferente
Gaming: Corrida armamentista de inflação de pontos
Resultado: Velocidade perde significado

Lei de Goodhart em Ação

EXEMPLOS DA LEI DE GOODHART
═══════════════════════════

"Quando uma medida se torna meta,
ela deixa de ser boa medida."

EXEMPLO 1: Meta de Code Coverage
─────────────────────────────────────
Meta: 80% code coverage
Gaming: 
├── Testes que não afirmam nada
├── Testar getters/setters triviais
├── Ignorar código complexo não testável
└── Coverage alto, confiança baixa

Melhor:
├── Rastrear coverage mas não definir meta
├── Focar em qualidade de testes
├── Revisar testes em code review
└── Mutation testing

EXEMPLO 2: Meta de Fechamento de Tickets
─────────────────────────────────────
Meta: Fechar 20 tickets/sprint
Gaming:
├── Dividir tickets artificialmente
├── Fechar sem fix adequado
├── Evitar tickets difíceis
└── Quantidade sobe, valor cai

Melhor:
├── Rastrear tempo de ciclo (menos manipulável)
├── Focar em valor entregue
├── Revisar qualidade de conclusão
└── Celebrar impacto, não contagem

EXEMPLO 3: Meta de Tempo de Resposta
─────────────────────────────────────
Meta: Responder bugs em < 4 horas
Gaming:
├── Respostas rápidas "reconhecido"
├── Sem progresso real
├── Manipulando o relógio
└── Resposta rápida, resolução lenta

Melhor:
├── Rastrear tempo até resolução
├── Satisfação do cliente
├── Endereçar causa raiz
└── Qualidade end-to-end

Métricas Efetivas

O que Medir

MÉTRICAS QUE AJUDAM
═══════════════════

MÉTRICAS DE ENTREGA:
─────────────────────────────────────
• Velocidade (tendência, não absoluto)
  └── Previsibilidade de entrega

• Tempo de Ciclo
  └── Quanto tempo leva do início ao done

• Throughput
  └── Itens completados por período

• Lead Time
  └── Ideia até produção

MÉTRICAS DE QUALIDADE:
─────────────────────────────────────
• Taxa de Defeitos em Produção
  └── Bugs encontrados por usuários

• MTTR (Mean Time To Recovery)
  └── Tempo para recuperar de falhas

• Cobertura de Testes (como indicador)
  └── Não como meta, como sinal

• Taxa de Falha de Deploy
  └── % de deploys que causam problemas

MÉTRICAS DE RESULTADO:
─────────────────────────────────────
• NPS/Satisfação do Usuário
  └── Impacto real no cliente

• Adoção de Features
  └── Features são usadas?

• Impacto de Negócio
  └── Receita, conversão, retenção

• Tempo Economizado
  └── Automatização, eficiência

Dashboard de Performance

DASHBOARD DE PERFORMANCE DO TIME:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│ ENTREGA:                                                    │
│ ─────────                                                   │
│ • Velocidade (6 sprints): 28 → 30 → 32 → 29 → 31 → 30     │
│   Tendência: Estável ✓                                     │
│ • Tempo de Ciclo: 4.2 dias (meta: <5)                      │
│ • Throughput: 12 itens/sprint                              │
│                                                             │
│ QUALIDADE:                                                  │
│ ──────────                                                  │
│ • Bugs em produção: 3/mês (meta: <5)                       │
│ • Taxa de falha de deploy: 8%                              │
│ • MTTR: 45 min                                             │
│                                                             │
│ RESULTADO:                                                  │
│ ──────────                                                  │
│ • NPS: 42 (subindo de 38)                                  │
│ • Adoção de features: 78%                                  │
│ • Receita impactada: +12% MoM                              │
│                                                             │
│ SAÚDE DO TIME:                                              │
│ ───────────────                                             │
│ • Satisfação (1-5): 4.1                                    │
│ • Burnout risk: Baixo                                      │
│ • Rotatividade: 0% (6 meses)                               │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Usando Métricas Corretamente

Princípios de Uso

COMO USAR MÉTRICAS DE PERFORMANCE:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│ ✅ USAR PARA:                                               │
│ • Informar discussões de melhoria                          │
│ • Identificar tendências e padrões                         │
│ • Detectar problemas sistêmicos                            │
│ • Celebrar progresso                                       │
│ • Planejar capacidade                                      │
│                                                             │
│ ❌ NÃO USAR PARA:                                          │
│ • Rankear indivíduos                                       │
│ • Avaliação de performance individual                      │
│ • Justificar punições                                      │
│ • Comparar times diferentes                                │
│ • Definir metas rígidas                                    │
│                                                             │
│ COMUNICAÇÃO:                                                │
│ ──────────────                                              │
│ • Métricas visíveis para o time                            │
│ • Time participa da interpretação                          │
│ • Contexto sempre incluído                                 │
│ • Ação baseada em padrões, não pontos isolados            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Melhores Práticas

Checklist de Implementação

CHECKLIST DE MÉTRICAS DE PERFORMANCE
════════════════════════════════════

SELEÇÃO:
☐ Métricas de time, não individuais
☐ Múltiplas métricas (não uma sozinha)
☐ Resultados + qualidade + entrega
☐ Difíceis de manipular

COLETA:
☐ Automatizada quando possível
☐ Dados confiáveis
☐ Histórico preservado
☐ Frequência apropriada

USO:
☐ Tendências, não snapshots
☐ Com contexto
☐ Para melhoria, não punição
☐ Time tem acesso

REVISÃO:
☐ Métricas ainda relevantes?
☐ Comportamento de gaming detectado?
☐ Ajustar baseado em aprendizado
☐ Remover métricas inúteis

Métricas de performance bem usadas iluminam o caminho para melhoria—não para pressão ou punição.

Soluções Relacionadas

• Produtividade de Desenvolvedores
• Métricas de Sprint
• DORA Metrics
• Velocidade de Sprint