Com assistentes de código por IA virando parte do kit padrão de todo dev, muitos times de engenharia passaram a produzir muito mais código. Pull requests se acumulam e os pipelines de CI ficam rodando o tempo todo. À primeira vista, isso parece um grande salto de produtividade. O problema é que esse aumento de velocidade costuma esconder novos gargalos. Sem uma forma clara de medir o desempenho da entrega de software, fica difícil saber se o time está realmente entregando mais rápido ou apenas gerando mais retrabalho. É nesse ponto que as métricas DORA ajudam a trazer clareza, desde que sejam usadas para entender o sistema, e não apenas para acompanhar números isolados.
O desafio não está em conhecer as quatro métricas, mas em usá-las de forma consistente e saber interpretá-las em um cenário em que a forma de escrever código muda rapidamente. Números isolados em um dashboard não geram melhoria se não refletem todo o ciclo de desenvolvimento ou se os times estão medindo os mesmos conceitos de maneiras diferentes.
O que exatamente estamos medindo
Para que o DORA gere algum valor real, é essencial que todo mundo esteja alinhado sobre o que está sendo medido. Definições vagas acabam produzindo dados inconsistentes, que mais atrapalham do que ajudam. Em muitos casos, é melhor não medir nada do que basear decisões em números que cada time interpreta de um jeito diferente.
Esse guia é exatamente sobre isso: como medir as DORA Metrics do jeito certo e usar cada uma como alavanca pra melhorar entregas.
Deployment Frequency
Essa é a métrica mais direta: ela mede quantas vezes por dia, semana ou mês seu time faz deploy em produção. E embora pareça simples, ela revela muito mais do que parece.
Se o time faz deploy frequente, significa que os ciclos são curtos, o risco é menor e o feedback vem mais rápido. Se o deploy demora pra acontecer, pode ter gargalo em revisão de PRs, medo de quebrar algo, ou falta de automação no pipeline.
Como calcular:
- Defina o período (ex: 10 dias)
- Conte quantos deploys aconteceram
- Divida o número de deploys pelos dias
Se foram 20 deploys em 10 dias, você tem uma média de 2 deploys por dia.
Benchmarks (State of DevOps Report):
- Baixa performance: menos de 1 vez por mês
- Média: entre 1x/mês e 1x/semana
- Alta: pelo menos 1x por semana ou mais
Lead Time for Changes
Essa é uma das métricas mais reveladoras pra qualquer liderança técnica. O Lead Time for Changes mede o tempo entre o primeiro commit e a chegada daquela mudança em produção.
Se esse tempo é alto, tem algo travando o fluxo. Pode ser revisão demorada, ambiente de staging instável, testes manuais ou burocracia demais no processo.
Como medir:
- Registre o timestamp do primeiro commit
- Anote a data do deploy da mesma mudança
- Subtraia uma data da outra
Exemplo:
- Commit inicial: 1º de janeiro
- Deploy: 5 de janeiro
- Lead Time = 4 dias
Benchmarks:
- Baixa: mais de um mês
- Média: entre 1 semana e 1 mês
- Alta: menos de 1 semana
Quer dar um passo a mais? Quebre o lead time em partes (ex: tempo até abrir PR, tempo até o merge, tempo até o deploy) pra descobrir onde está o real gargalo.
Change Failure Rate
Essa métrica mostra a proporção de deploys que resultam em rollback, hotfix ou incidentes em produção. Ela é essencial pra entender a estabilidade das suas entregas.
Se o time está entregando rápido, mas sempre quebrando algo, o problema não está na velocidade, mas na qualidade. Essa é a métrica que te obriga a olhar pra testes, cobertura de QA, revisões e validação de requisitos.
Como calcular:
- Conte todos os deploys feitos em um período
- Conte quantos deram problema
- Divida os com falha pelo total e multiplique por 100
Exemplo:
- 20 deploys, 3 com falha
- CFR = (3 / 20) × 100 = 15%
Benchmarks:
- Baixa performance: acima de 15%
- Média: entre 5% e 15%
- Alta: menos de 5%
Mean Time to Recovery
Falhas vão acontecer. A questão é: seu time consegue reagir rápido?
O MTTR mostra quanto tempo leva, em média, pra restaurar o serviço depois de um problema em produção. É uma medida da sua resiliência operacional.
Como calcular:
- Liste os incidentes no período
- Registre o timestamp de início e fim de cada um
- Calcule o tempo de duração e tire a média
Exemplo:
- Incidentes: 3
- Duração total: 135 minutos
- MTTR = 135 / 3 = 45 minutos
Benchmarks:
- Baixa performance: mais de 1 dia
- Média: entre 1h e 1 dia
- Alta: menos de 1h
Um MTTR alto geralmente aponta pra falta de observabilidade, processos de resposta mal definidos ou pouca autonomia do time em incidentes.
Por que medir bem essas métricas muda o jogo
Olhar pra essas métricas de forma superficial não resolve. O valor está em usá-las pra responder perguntas reais:
- Por que nossas entregas estão lentas?
- O que está travando mais: review, testes, deploy ou incidentes?
- Estamos entregando mais rápido ou só gerando mais retrabalho?
Criando um pipeline das métricas DORA
Depois de ter definições claras, você precisa automatizar a coleta de dados. Acompanhamento manual não é confiável e não escala. O objetivo é puxar dados diretamente das ferramentas que seus times já usam.
Integrando ferramentas para coleta de dados
Você consegue quase tudo de que precisa a partir das suas ferramentas do dia a dia
- Sistemas de controle de versão (Git): Sua fonte de verdade para dados de commits, que é o ponto de partida para o Change Lead Time.
- Plataformas de CI/CD (GitHub Actions, Jenkins, CircleCI): Essas ferramentas sabem quando os deploys acontecem, se tiveram sucesso ou falharam, fornecendo a Deployment Frequency e o ponto final do Change Lead Time.
- Sistemas de gerenciamento de incidentes (PagerDuty, Opsgenie): Essenciais para acompanhar o MTTR, pois registram quando um incidente é aberto, reconhecido e resolvido.
- Plataformas de monitoramento e observabilidade (Datadog, New Relic): Críticas para detectar falhas desde o início e correlacioná-las com deploys específicos para calcular o Change Failure Rate.
Garantindo consistência dos dados
Automação só é útil se os dados forem precisos. O passo mais importante é padronizar as definições das métricas em todos os times de engenharia. Estabeleça pontos claros de captura de dados nos seus fluxos, como usar labels específicas em pull requests ou logs de eventos padronizados no pipeline de CI/CD. Isso remove ambiguidades e garante que, ao olhar para um dashboard, você esteja comparando coisas equivalentes entre diferentes times e serviços.
Usando métricas DORA para melhorar de verdade
Números sozinhos dizem pouco. O valor aparece quando você observa como eles mudam ao longo do tempo e usa essas métricas para entender o que está acontecendo no sistema, não para avaliar pessoas ou comparar times.
Olhando para tendências e contexto
Em vez de se prender a valores absolutos, vale observar padrões. O Change Lead Time vem subindo aos poucos? A Deployment Frequency caiu depois de uma reestruturação grande? Quando você relaciona essas variações com mudanças no processo, na arquitetura ou nas ferramentas do time, começa a ficar claro onde estão os problemas.
Por exemplo, se o lead time aumenta ao mesmo tempo em que cresce o volume de código gerado por IA, isso costuma indicar que o processo de review não acompanhou essa mudança e virou um gargalo.
Também é importante lembrar que essas métricas refletem o sistema como ele é hoje, incluindo arquitetura e complexidade do domínio. Um time trabalhando em um monólito legado naturalmente terá números diferentes de um time desenvolvendo um microserviço novo. Comparar esses dois cenários diretamente quase sempre leva a conclusões erradas. O objetivo do DORA não é ranquear times, mas ajudar cada um a melhorar em relação ao seu próprio ponto de partida.
Um jeito simples de usar DORA de forma contínua
Passo 1: Entenda o ponto de partida e levante hipóteses
Antes de automatizar qualquer coisa, registre como as métricas estão hoje, mesmo que sejam estimativas. Em seguida, formule uma hipótese clara sobre um problema que você acredita existir.
Por exemplo:
“Acreditamos que o aumento de código gerado por IA está tornando os reviews mais difíceis, dobrando o tempo de revisão dos pull requests e puxando o Change Lead Time para cima.”
Isso te dá uma pergunta específica para investigar.
Passo 2: Colete dados de forma automática
Com uma hipótese definida, fica claro quais dados você precisa. Configure as ferramentas que o time já usa para coletar essas informações automaticamente. Comece com um dashboard simples, focado só nas métricas essenciais.
Antes de compartilhar esses números, vale gastar um tempo validando se eles fazem sentido e se estão alinhados com as definições combinadas. Dado errado atrapalha mais do que ajuda.
Passo 3: Revise com regularidade e aja sobre o que aparecer
Defina uma cadência fixa, como uma reunião mensal do time, para olhar as métricas DORA. Quando surgir algo fora do padrão, trate isso como um sinal para investigar.
Se a Change Failure Rate subiu no último mês, olhe para os incidentes e rollbacks desse período. O que eles têm em comum? A partir disso, escolha uma melhoria pequena e específica para testar no processo.
FAQ: DORA Metrics na prática
Preciso medir todas as 4 métricas desde o início?
Não. Comece com uma ou duas que sejam mais simples de extrair e que respondam perguntas urgentes do seu time. Lead Time e Deployment Frequency são boas portas de entrada.
Com que frequência devo acompanhar essas métricas?
Depende do seu ciclo. Revisar a cada sprint ou quinzenalmente costuma ser o suficiente pra identificar tendências sem sobrecarregar.
Essas métricas funcionam mesmo em times pequenos?
Sim. Times pequenos têm a vantagem de poder agir rápido com base nos dados. As métricas só precisam ser adaptadas para não reagir a variações muito bruscas.
Como garantir que essas métricas não sejam usadas pra microgerenciar?
Deixe claro que o foco é melhorar o sistema, não medir indivíduos. Compartilhe os dados com o time, estimule conversas, não cobranças. Cultura vem antes do dashboard.
