A conversa sobre métricas de engenharia costuma ficar presa nas coisas erradas. Acabamos acompanhando atividades como linhas de código ou número de commits por semana, o que diz quase nada sobre a saúde do nosso sistema ou a efetividade do time. Na prática, essas métricas são fáceis de manipular e criam incentivos para comportamentos errados, como quebrar uma única mudança lógica em dez commits minúsculos.
Isso fica ainda mais complicado com assistentes de código baseados em IA. O relatório DORA de 2025 destaca como a IA atua como um amplificador de problemas. Times que usam IA estão entregando código mais rápido, mas também estão vendo a estabilidade piorar. O que acontece é que a IA facilita gerar muito código rapidamente, mas se seus processos de review, cultura de testes e pipelines de deploy forem fracos, você só está colocando código quebrado em produção mais rápido do que antes.
O problema central continua o mesmo: precisamos de uma forma de medir a saúde do sistema como um todo, não apenas a velocidade de desenvolvedores individuais.
DORA: Um framework para entender a saúde do sistema
As métricas DORA (Deployment Frequency, Lead Time for Changes, Change Failure Rate e Mean Time to Recovery) oferecem uma forma de fazer isso. Elas focam em resultados no nível do sistema, em vez de output individual. Ao olhar para essas quatro métricas em conjunto, você tem uma visão mais clara sobre velocidade e estabilidade, que muitas vezes se complementam. Melhorar uma sem considerar as outras geralmente você vai ter um problema.
Deployment Frequency
Essa métrica mede com que frequência você consegue fazer deploy em produção com sucesso. Uma frequência mais alta geralmente indica um pipeline de CI/CD mais saudável e automatizado, além de um fluxo de trabalho baseado em mudanças pequenas e gerenciáveis. Quando a frequência de deploy é baixa, normalmente é sintoma de lotes grandes e arriscados, etapas manuais de deploy ou medo de quebrar coisas. Para um tech lead, acompanhar isso pode ajudar a justificar investimentos em um CI melhor ou em testes mais robustos.
Lead Time for Changes
Esse é o tempo que um commit leva para chegar à produção. É uma das métricas de diagnóstico mais úteis para um time. Um lead time longo pode apontar para vários problemas diferentes: PRs grandes demais, um processo de code review lento, testes instáveis no pipeline de CI ou gates manuais de QA. Ao quebrar o lead time em etapas (tempo até o primeiro review, tempo em review, tempo até o merge, tempo até o deploy), você consegue identificar exatamente onde o trabalho está travando. Se PRs ficam parados por dias esperando review, isso é uma conversa sobre processo do time, não sobre a velocidade individual de um desenvolvedor.
Change Failure Rate
Essa métrica acompanha com que frequência um deploy em produção causa uma falha, como uma indisponibilidade ou um rollback. É uma medida direta de qualidade e estabilidade. Uma taxa alta de falha sugere que seus processos de teste e review não estão pegando problemas antes de eles chegarem aos usuários. Isso costuma se correlacionar com lotes grandes, porque mudanças maiores são mais difíceis de entender e testar a fundo.
Mean Time to Recovery (MTTR)
Quando uma falha acontece, quanto tempo leva para restaurar o serviço? Isso é o MTTR. Um MTTR baixo é sinal de um sistema resiliente e de um processo de resposta a incidentes bom. Mostra que você consegue detectar problemas rapidamente, diagnosticá-los de forma mais eficaz e fazer rollback ou corrigir sem causar novos problemas.
IA e métricas de engenharia
Ferramentas de IA para código não mudam os princípios básicos de como software é entregue. O que elas fazem é amplificar o que já existe. A IA funciona como um multiplicador dos sistemas e práticas que o time já tem. Se você tem bons fundamentos técnicos, o hábito de trabalhar em pequenos lotes e um processo de review saudável, a IA tende a acelerar tudo isso e reduzir o atrito.
O risco realmente aparece quando essas práticas não existem. Se o seu time já costuma a criar pull requests enormes, a IA vai ajudar a criar PRs ainda maiores, só que mais rápido. Se já existe muita dívida técnica, o código gerado por IA sem contexto pode facilmente aumentar isso.
É por isso que boas práticas ficam ainda mais importantes com IA, especialmente trabalhar em pequenos lotes, se tornam ainda mais críticas. Uma mudança pequena e bem compreendida é sempre mais segura de colocar em produção, seja ela escrita por uma pessoa ou com a ajuda de uma IA.
O que precisa estar em ordem antes de usar IA, segundo a DORA
Para tirar proveito da IA sem acabar ampliando problemas, os times precisam ter uma base bem resolvida. A pesquisa da DORA resume isso em sete capacidades essenciais para adotar IA do jeito certo:
1. Direcionamento claro sobre o uso de IA
Todo mundo no time precisa saber quais são as regras do jogo: quais ferramentas podem ser usadas, que tipo de dado pode ser compartilhado e como lidar com código gerado por IA no dia a dia.
2. Ecossistemas de dados saudáveis
A qualidade da ajuda que a IA oferece depende diretamente da qualidade dos dados por trás dela. Dados ruins entram, sugestões ruins saem.
3. Dados internos acessíveis à IA
Para ser realmente útil, a IA precisa de contexto. Isso inclui bibliotecas internas, APIs, padrões da empresa e documentação relevante.
4. Trabalho em pequenos lotes
Trabalhar com mudanças pequenas reduz risco e mantém o ciclo de feedback curto. Isso fica ainda mais importante quando o código pode ser gerado muito rápido.
5. Foco no usuário final
IA é meio, não fim. Ela deve ajudar a resolver problemas reais dos usuários, não apenas aumentar a quantidade de código produzido.
6. Plataformas internas bem cuidadas
Uma boa plataforma interna elimina trabalho repetitivo e oferece caminhos claros para testar e fazer deploy. Isso torna muito mais seguro integrar código gerado por IA.
7. Fundamentos técnicos fortes
Arquitetura pouco acoplada, automação de testes abrangente e bons padrões de engenharia não são opcionais.
Outras métricas que podem ajudar
As métricas da DORA ajudam muito a entender a saúde do pipeline de entrega, mas sozinhas não explicam tudo. Outros frameworks complementam essa visão ao ligar performance de entrega à experiência do desenvolvedor e ao fluxo de valor como um todo.
SPACE
O framework SPACE amplia a visão sobre o que realmente torna desenvolvedores produtivos e satisfeitos. Ele defende que você não pode medir apenas output. Para entender produtividade de verdade, você precisa olhar para vários sinais ao mesmo tempo:
- Satisfação e bem-estar: Quão realizados e saudáveis estão seus engenheiros? Burnout é um grande destruidor de produtividade.
- Performance: Como indivíduos e times percebem a própria performance?
- Atividade: Métricas de output, como commits ou PRs. Elas são úteis, mas perigosas quando analisadas isoladamente.
- Comunicação e colaboração: Quão bem as pessoas e os times trabalham juntos? Pense na facilidade de encontrar informações e na qualidade dos reviews.
- Eficiência e fluxo: Quão efetivamente os desenvolvedores conseguem trabalhar sem interrupções ou atrito? Isso se conecta diretamente ao Lead Time para Mudanças do DORA.
O objetivo do SPACE é criar um conjunto equilibrado de métricas para que você não otimize acidentalmente uma área às custas de outra, como aumentar atividade ao custo de burnout.
Value Stream Management (VSM)
Value Stream Management é uma forma de visualizar, medir e melhorar todo o processo, desde a concepção de uma ideia até a entrega ao cliente.
Enquanto o DORA te dá resultados-chave (como lead time), o VSM ajuda a mapear todas as etapas intermediárias para entender por que seu lead time é o que é. Ele foca em métricas de fluxo como:
- Velocidade de Fluxo: Quantos itens de trabalho são concluídos por unidade de tempo?
- Tempo de Fluxo: Quanto tempo um item leva do início ao fim? (Similar ao Lead Time)
- Carga de Fluxo: Quantos itens estão atualmente em progresso? (Um proxy para WIP)
- Eficiência de Fluxo: Que porcentagem do tempo total de fluxo é gasta em trabalho ativo versus espera? Essa costuma ser a métrica mais reveladora. É comum descobrir que um ticket passa 90% do tempo apenas esperando por um review, um build ou um handoff.
O VSM dá contexto às métricas DORA. Sua Taxa de Falha de Mudanças pode estar alta, e um mapa de value stream pode mostrar que isso acontece porque não há tempo dedicado para QA, forçando os desenvolvedores a correr com os testes no último minuto.
Usando métricas para melhorar o time
Coletar métricas não serve de muita coisa se você não faz nada com elas. A ideia é usar esses dados para puxar boas conversas e melhorar o time, não para criar mais um dashboard que ninguém abre. O ciclo de melhoria da DORA ajuda a fechar esse loop.
O ciclo de melhoria da DORA
Defina uma linha de base: Primeiro, apenas meça suas quatro métricas principais para entender onde você está agora. Não dá para melhorar o que você não mede.
Tenha uma conversa: As métricas dizem o que está acontecendo, mas não por quê. O próximo passo é conversar com o time. Um exercício de value stream mapping pode ser extremamente útil para visualizar todo o processo, da ideia à produção, e identificar onde está o atrito real.
Comprometa-se a melhorar a maior restrição: Não tente consertar tudo de uma vez. Identifique o maior gargalo que está desacelerando o time ou causando falhas e foque nele.
Transforme o compromisso em um plano: Crie um plano concreto com indicadores de antecedência. Por exemplo, se o gargalo for o tempo de code review, um indicador pode ser “tamanho médio dos PRs” ou “tempo do PR aberto até o primeiro comentário”.
Faça o trabalho: Isso envolve mudanças sistemáticas, não soluções rápidas. Pode significar investir em ferramentas melhores, mudar um processo do time ou pagar uma parte específica da dívida técnica.
Cheque o progresso e itere: Depois de algumas semanas ou de uma sprint, confira suas métricas DORA e os indicadores para ver se as mudanças tiveram o efeito esperado. Em seguida, escolha a próxima maior restrição e repita o ciclo.
Também é útil lembrar que a DORA não é o único framework. O framework SPACE é um ótimo complemento, pois traz satisfação, bem-estar e colaboração dos desenvolvedores.
Os erros mais comuns ao usar métricas de engenharia
Ao começar a usar essas métricas, é fácil cair em algumas armadilhas comuns.
Usar métricas para avaliar performance individual: Essa é a forma mais rápida de destruir a confiança e incentivar a manipulação das métricas. Métricas DORA medem performance do time e do sistema, ponto. Elas nunca devem ser usadas em avaliações individuais.
A armadilha do “gaming” das métricas: Se você incentiva uma métrica específica, as pessoas vão encontrar um jeito de otimizá-la, muitas vezes às custas do que realmente importa. Por exemplo, focar apenas em Deployment Frequency pode levar o time a entregar mudanças minúsculas e sem sentido só para inflar o número.
Sobrecarga de métricas: não tente medir tudo. Comece com as quatro métricas principais da DORA. Quando tiver domínio delas, você pode adicionar outras métricas, mas mantenha o foco em poucos indicadores diretamente ligados aos seus objetivos de melhoria.
Não agir com base nos dados: O pior resultado é gastar tempo e esforço coletando dados e depois não fazer nada com eles. Métricas devem sempre ser um catalisador para conversa e ação. Se não forem, vale questionar por que você está coletando esses dados.
Algumas recomendações
Se a ideia é usar dados de forma mais consciente para melhorar o time, aqui vai um caminho que você pode seguir:
– Estabeleça métricas DORA de linha de base: Use uma ferramenta ou script para obter uma leitura inicial das quatro métricas principais. Isso te dá um ponto de partida.
– Foque os esforços de melhoria na maior restrição do time: Identifique junto com o time qual é o gargalo mais doloroso no momento e façam um acordo claro de focar em melhorar isso primeiro.
– Encare a adoção de IA como uma mudança sistêmica: Não é só dar uma licença de Copilot para todo mundo e torcer para dar certo. Defina diretrizes claras e reforce bons hábitos para evitar que a IA apenas acelere problemas que já existiam.
– Complemente a DORA com outros frameworks: Considere usar elementos do SPACE para ter uma visão mais completa que inclua experiência do desenvolvedor.
– Abrace a melhoria contínua como prática cultural: O objetivo não é alcançar uma pontuação “perfeita” nas métricas. É construir uma cultura em que o time esteja constantemente buscando melhorar seu fluxo de trabalho e a saúde dos seus sistemas.
