7 min leitura • Guide 547 of 877
Medindo Produtividade de Desenvolvedores
Medição de produtividade deve identificar melhorias sistêmicas, não rankear desenvolvedores individuais. As analytics do GitScrum fornecem insights em nível de time sobre velocidade, tempo de ciclo e throughput que ajudam gerentes a identificar gargalos e melhorias de processo. A chave é medir o sistema, não as pessoas.
Categorias de Métricas de Produtividade
| Categoria | Métricas Boas | Métricas Ruins |
|---|---|---|
| Output | Features entregues, PRs merged | Linhas de código, commits |
| Qualidade | Taxa de bugs, incidentes | % cobertura de código sozinho |
| Velocidade | Tempo de ciclo, lead time | Horas logadas |
| Fluxo | WIP, tempo bloqueado | Tarefas iniciadas |
| Impacto | Valor para cliente, receita | Story points como absoluto |
Framework de Métricas DORA
VISÃO GERAL DAS MÉTRICAS DORA
═════════════════════════════
FREQUÊNCIA DE DEPLOY (Velocidade):
┌─────────────────────────────────────────────────┐
│ Com que frequência você faz deploy em produção?│
│ │
│ Elite: Múltiplas vezes por dia │
│ Alto: Entre 1x/dia e 1x/semana │
│ Médio: Entre 1x/semana e 1x/mês │
│ Baixo: Menos de 1x/mês │
│ │
│ Seu time: Deploys semanais │
│ Status: Alto desempenho │
└─────────────────────────────────────────────────┘
LEAD TIME PARA MUDANÇAS (Velocidade):
┌─────────────────────────────────────────────────┐
│ Tempo do commit até produção │
│ │
│ Elite: Menos de uma hora │
│ Alto: Entre um dia e uma semana │
│ Médio: Entre uma semana e um mês │
│ Baixo: Mais de um mês │
│ │
│ Seu time: Média de 2-3 dias │
│ Status: Alto desempenho │
└─────────────────────────────────────────────────┘
TAXA DE FALHA DE MUDANÇA (Estabilidade):
┌─────────────────────────────────────────────────┐
│ % de deploys causando falha em produção │
│ │
│ Elite: 0-15% │
│ Alto: 16-30% │
│ Médio: 31-45% │
│ Baixo: 46-60% │
│ │
│ Seu time: 12% │
│ Status: Desempenho elite │
└─────────────────────────────────────────────────┘
TEMPO PARA RESTAURAR (Estabilidade):
┌─────────────────────────────────────────────────┐
│ Tempo para recuperar de falha em produção │
│ │
│ Elite: Menos de uma hora │
│ Alto: Menos de um dia │
│ Médio: Entre um dia e uma semana │
│ Baixo: Mais de uma semana │
│ │
│ Seu time: 2-4 horas │
│ Status: Alto desempenho │
└─────────────────────────────────────────────────┘
Métricas de Experiência do Desenvolvedor
MÉTRICAS DE EXPERIÊNCIA DO DEV (DX)
═══════════════════════════════════
FRAMEWORK SPACE:
┌─────────────────────────────────────────────────┐
│ S - Satisfação e Bem-estar │
│ ├── Pesquisas de satisfação do dev │
│ ├── Indicadores de burnout │
│ └── Scores de moral do time │
│ │
│ P - Performance │
│ ├── Tempo de turnaround de code review │
│ ├── Qualidade das reviews │
│ └── Resultados entregues │
│ │
│ A - Atividade (usar com cuidado) │
│ ├── PRs merged (nível de time) │
│ ├── Frequência de build/deploy │
│ └── NÃO: commits, linhas de código │
│ │
│ C - Comunicação e Colaboração │
│ ├── Compartilhamento de conhecimento │
│ ├── Qualidade de documentação │
│ └── Tempo de onboarding │
│ │
│ E - Eficiência e Fluxo │
│ ├── Tempo em reuniões │
│ ├── Tempo esperando/bloqueado │
│ └── Context switches por dia │
└─────────────────────────────────────────────────┘
PESQUISA DX TRIMESTRAL:
┌─────────────────────────────────────────────────┐
│ Escala 1-5: │
│ │
│ Q1: Consigo fazer meu melhor trabalho aqui │
│ Q2: Raramente preciso esperar por bloqueios │
│ Q3: Entendo no que devo trabalhar │
│ Q4: Nossas ferramentas me ajudam, não atrapalham│
│ Q5: Tenho tempo para deep work │
│ │
│ Tendência: Comparar trimestre a trimestre │
│ Meta: Média >4.0 │
└─────────────────────────────────────────────────┘
Métricas de Time
Dashboard de Produtividade
DASHBOARD DE MÉTRICAS DO TIME:
┌─────────────────────────────────────────────────────────────┐
│ │
│ THROUGHPUT: │
│ ─────────── │
│ • PRs merged/semana: 15 (média) │
│ • Features entregues/sprint: 8 │
│ • Tendência: Estável ✓ │
│ │
│ VELOCIDADE: │
│ ────────── │
│ • Tempo de ciclo médio: 3.2 dias │
│ • Lead time médio: 4.5 dias │
│ • Tendência: Melhorando ↓ │
│ │
│ QUALIDADE: │
│ ────────── │
│ • Bugs em produção/sprint: 2 │
│ • Taxa de falha de deploy: 8% │
│ • Tendência: Estável ✓ │
│ │
│ FLUXO: │
│ ────── │
│ • WIP médio: 12 itens │
│ • Tempo bloqueado: 15% do tempo de ciclo │
│ • Tendência: Precisa atenção ⚠️ │
│ │
└─────────────────────────────────────────────────────────────┘
Métricas para Evitar
Métricas Prejudiciais
MÉTRICAS QUE PREJUDICAM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ❌ LINHAS DE CÓDIGO: │
│ Incentiva código verboso │
│ Penaliza refatoração │
│ Não mede valor │
│ │
│ ❌ NÚMERO DE COMMITS: │
│ Incentiva commits pequenos e sem sentido │
│ Gaming fácil │
│ Não reflete trabalho real │
│ │
│ ❌ HORAS TRABALHADAS: │
│ Incentiva presenteísmo │
│ Penaliza eficiência │
│ Não mede output │
│ │
│ ❌ VELOCIDADE INDIVIDUAL: │
│ Incentiva inflar estimativas │
│ Cria competição destrutiva │
│ Quebra colaboração │
│ │
│ ❌ COMPARAR TIMES: │
│ Story points não são comparáveis │
│ Contextos são diferentes │
│ Incentiva gaming │
│ │
│ REGRA: Se uma métrica pode ser jogada facilmente, │
│ ela será jogada. E isso prejudica o time. │
│ │
└─────────────────────────────────────────────────────────────┘
Usando Dados Corretamente
Princípios de Uso
COMO USAR MÉTRICAS DE PRODUTIVIDADE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ✅ USAR PARA: │
│ • Identificar gargalos no processo │
│ • Entender tendências ao longo do tempo │
│ • Informar discussões de melhoria │
│ • Prever capacidade de entrega │
│ • Detectar problemas sistêmicos │
│ │
│ ❌ NÃO USAR PARA: │
│ • Rankear desenvolvedores individuais │
│ • Avaliação de performance individual │
│ • Justificar demissões │
│ • Pressionar por "números melhores" │
│ • Comparar times diferentes │
│ │
│ COMPARTILHAMENTO: │
│ ────────────────── │
│ • Métricas devem ser visíveis para o time │
│ • Discutir em retros │
│ • Time interpreta, não gerência sozinha │
│ • Transparência constrói confiança │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Checklist de Implementação
CHECKLIST DE MÉTRICAS DE PRODUTIVIDADE
══════════════════════════════════════
SELEÇÃO:
☐ Métricas focam em resultados, não atividade
☐ DORA metrics implementadas
☐ Métricas de time, não individuais
☐ Qualidade + velocidade balanceadas
COLETA:
☐ Automatizada quando possível
☐ Não requer trabalho manual do dev
☐ Dados confiáveis e consistentes
☐ Histórico preservado
USO:
☐ Discutido em retros
☐ Ação baseada em tendências
☐ Time tem acesso
☐ Não usado para punir
EVITAR:
☐ Linhas de código
☐ Commits
☐ Horas trabalhadas
☐ Comparação entre times
☐ Velocidade individual
Métricas de produtividade bem usadas são ferramentas para o time melhorar—não armas de gestão para pressionar.