Medindo Produtividade de Desenvolvedores
Rastreie métricas significativas de produtividade de desenvolvedores sem microgerenciar. Use dados para melhorar processos e apoiar times efetivamente.
7 min de leitura
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.