Por que medir produtividade de devs é tão difícil
Engenharia de software é um trabalho de conhecimento — e trabalho de conhecimento é notoriamente difícil de medir. Contar linhas de código é como medir a qualidade de um romance pelo número de palavras. Contar commits é como avaliar um músico pelo número de notas tocadas.
O problema mais sério com métricas mal escolhidas não é que sejam inúteis — é que são ativamente prejudiciais. Quando você mede a coisa errada, as pessoas otimizam para a coisa errada. Um time que é cobrado por linhas de código produz código verboso. Um time cobrado por número de tickets fechados fecha tickets rápido e cria novos bugs. Um time cobrado por coverage de testes escreve testes que passam, não testes que detectam bugs.
A questão central de métricas de engenharia não é "o que podemos medir?" — é "o que queremos que o time otimize?" A métrica é uma consequência dessa resposta.
DORA metrics: o que são e por que importam
As DORA metrics (DevOps Research and Assessment) são o conjunto mais bem validado de métricas para times de engenharia de software. Foram desenvolvidas por pesquisadores do Google Cloud com base em dados de milhares de times ao redor do mundo, e a pesquisa mostrou correlação consistente entre essas métricas e performance organizacional.
Há quatro métricas no conjunto, e elas medem dois aspectos distintos e complementares do trabalho de engenharia: velocidade de entrega e estabilidade do sistema.
Deployment Frequency e Lead Time
Deployment Frequency mede com que frequência o time faz deploy em produção. Times de elite fazem múltiplos deploys por dia. Times de alto desempenho fazem deploys diários a semanais. Times de médio desempenho fazem deploys mensais. Times de baixo desempenho, a cada 6 meses ou menos frequentemente.
A Deployment Frequency é um proxy de outras coisas: maturidade da pipeline de CI/CD, capacidade do time de fazer mudanças pequenas e seguras, confiança do time no processo de deploy. Quando a frequência é baixa, geralmente é porque o processo de deploy é doloroso — e isso é o problema a resolver, não a frequência em si.
Lead Time for Changes mede o tempo do primeiro commit até o deploy em produção. Esse é o tempo que leva para uma mudança de código chegar ao usuário. Times elite medem isso em horas; times de médio desempenho, em semanas. Um Lead Time alto geralmente indica gargalos no processo: code review lento, ambiente de staging instável, processo de QA manual, burocracia de aprovação.
"DORA metrics não medem a qualidade de desenvolvedores individuais — medem a saúde dos processos e sistemas que permitem ou impedem que o time entregue bem."
Change Failure Rate e MTTR
Change Failure Rate é a porcentagem de deploys que causam algum tipo de incidente — desde um bug menor até uma indisponibilidade total. Times elite têm Change Failure Rate abaixo de 5%. Times de baixo desempenho chegam a 15-30% de deploys problemáticos.
Um Change Failure Rate alto com Deployment Frequency alta é especialmente preocupante — o time está fazendo deploy frequente mas causando problemas com frequência proporcional. Isso indica problemas de qualidade: testes insuficientes, code review superficial, ou falta de feature flags para rollout gradual.
MTTR (Mean Time to Restore) mede quanto tempo o time leva para recuperar de um incidente. Times elite se recuperam em menos de uma hora. O MTTR captura a maturidade do processo de incidente: capacidade de detectar problemas rapidamente (observabilidade), comunicar (runbooks e processos claros) e reverter (deploy seguro e rápido).
O que velocity de sprint realmente mede
Velocity — story points completados por sprint — é uma das métricas mais usadas e mais mal interpretadas em times de TI. Ela surgiu no Scrum como ferramenta interna de planejamento: se o time completa em média 40 pontos por sprint, o planner pode estimar que no próximo sprint faremos cerca de 40 pontos de trabalho.
Velocity não é comparável entre times — porque story points são estimativas relativas dentro de um time, não unidades absolutas. Um ponto para o time A pode ser equivalente a três pontos para o time B, dependendo de como cada time calibra suas estimativas.
Velocity não é um indicador de produtividade — porque ela mede atividade (trabalho completado dentro do sistema de estimativa do time) e não valor entregue. Um time que fragmenta histórias em partes menores vai ter velocity mais alta sem ser mais produtivo.
Métricas que criam incentivos perversos
Algumas métricas parecem razoáveis até que você vê o comportamento que criam:
- Número de commits por dia: devs fazem commits sem propósito para aparecer no gráfico de atividade.
- Coverage de testes como meta fixa: devs escrevem testes que passam sem falha mas não testam o que importa, apenas para atingir o percentual.
- Tickets fechados por desenvolvedor: devs pegam os tickets mais fáceis e evitam os complexos que levariam mais tempo mas agregar mais valor.
- Velocity crescente como meta: equipes inflam estimativas de story points para mostrar "aumento" de velocity quando na prática estão entregando a mesma quantidade de trabalho.
"Quando uma medida se torna uma meta, ela deixa de ser uma boa medida." Esta lei, formulada pelo economista Charles Goodhart, explica exatamente o que acontece com métricas de engenharia mal gerenciadas. A solução não é ter mais métricas — é usar métricas como diagnóstico, não como objetivo.
Como apresentar dados de engenharia para C-level
Apresentar métricas para a diretoria exige tradução — não simplificação. A diretoria não precisa entender o que é Lead Time; precisa entender que "features chegam ao usuário 3x mais rápido do que há seis meses" ou que "o tempo médio de resolução de incidente caiu de 4 horas para 45 minutos, reduzindo o impacto nos nossos clientes premium."
Apresente métricas em conjunto — uma métrica isolada raramente conta a história completa. Um deployment frequency alto com Change Failure Rate também alto é muito diferente de deployment frequency alto com Change Failure Rate baixo. O contexto importa tanto quanto o número.
Sempre apresente tendências, não snapshots. Um número isolado não significa nada. A trajetória ao longo do tempo — de onde estávamos, para onde estamos, para onde estamos indo — é o que permite que stakeholders entendam o progresso e o que ainda precisa mudar.