DORA Metrics

Toda vez que uma liderança técnica é questionada sobre performance do time, duas perguntas aparecem por baixo da conversa: “estamos entregando rápido?” e “estamos entregando bem?”. O problema é que, sem dado, a resposta vira sensação. E sensação varia conforme o humor de quem está respondendo, o último incidente que aconteceu na sexta-feira à noite, e a quantidade de café da reunião.

📊 DORA Metrics

“Um conjunto de quatro métricas que indicam o desempenho de uma equipe de desenvolvimento de software: frequência de implantação, tempo de entrega para mudanças, taxa de falha de mudanças e tempo para restaurar o serviço. Juntas, elas proporcionam um equilíbrio entre velocidade e estabilidade.”

— Google Cloud / DORA

O DORA (DevOps Research and Assessment) é um programa de pesquisa do Google Cloud que, há mais de uma década, vem estudando o que separa times de software que performam bem dos que não performam. O resultado mais conhecido desse trabalho está sintetizado no livro Accelerate e no State of DevOps Report anual. As DORA Metrics se tornaram, na prática, o padrão ouro pra medir entrega de software (DORA — Software delivery metrics).

Como qualquer ferramenta que vira “padrão ouro”, elas também viraram alvo fácil de uso equivocado. É comum ver time adotando as métricas pelo motivo errado, configurando o dashboard errado, e tirando a conclusão errada. Esse artigo é uma tentativa de explicar o conceito, mostrar como adotar de forma saudável, e — talvez mais importante — mapear as armadilhas em que é fácil cair.

As 4 (na verdade 5) métricas

O framework original do DORA tem 4 métricas, divididas em dois grupos: velocidade (throughput) e estabilidade. Em 2024, o DORA atualizou o conjunto para 5 métricas, trocando o nome de uma e adicionando outra (A history of DORA’s metrics). Vou focar nas 4 clássicas, que continuam sendo as mais usadas e referenciadas, e mencionar a evolução no fim da seção.

Velocidade

1. Deployment Frequency — com que frequência o time sobe código pra produção. É a métrica mais visível e talvez a mais mal-interpretada (já chego nisso). Times elite fazem múltiplos deploys por dia; times low fazem um a cada poucos meses.

2. Lead Time for Changes — quanto tempo leva entre um commit ser feito e essa mudança chegar em produção. Mede o “atrito” do pipeline de entrega: quanto demora um PR pra virar valor pro usuário.

Estabilidade

3. Change Failure Rate — porcentagem de deploys que precisaram de intervenção urgente (rollback, hotfix, patch emergencial). É um proxy de qualidade do que está sendo entregue.

4. Mean Time to Restore (MTTR) — quanto tempo o time leva pra restaurar o serviço depois de um incidente em produção. Mede capacidade de resposta a falha, não capacidade de evitar falha.

Combinando os benchmarks publicados nos relatórios mais recentes (Octopus Deploy — DORA 2024/25, DORA report), os tiers de performance ficam mais ou menos assim:

Sobre a evolução para 5 métricas: o DORA renomeou MTTR para Failed Deployment Recovery Time (mais específico — mede só recuperação de deploy ruim, não qualquer incidente), e adicionou a Deployment Rework Rate (porcentagem de deploys não-planejados gerados por incidente em produção). A documentação oficial está em DORA’s software delivery performance metrics. Pra quem está começando, as 4 clássicas já cobrem 90% do valor — não precisa esperar adotar as 5 pra começar.

Um ponto que o relatório DORA bate há anos e que muita gente ignora: velocidade e estabilidade não são trade-off. Os times elite vão bem nas quatro métricas simultaneamente. Quem ataca só deploy frequency e ignora change failure rate não vira time elite — vira time que produz incidente rápido.

Métricas como meta (mas nem tanto 🫠)

Esse é o ponto que precisa ser dito antes de qualquer dashboard ser criado: DORA Metrics não são metas. Elas são lagging indicators — termômetros que mostram como o sistema de entrega está performando ao longo do tempo. No momento em que viram OKR de time ou critério de avaliação individual, a coisa azeda muito rápido.

Existe um princípio chamado Lei de Goodhart que resume bem o problema:

“Quando uma medida se torna uma meta, ela deixa de ser uma boa medida.”

Na prática, quando você diz pro time “precisamos chegar em 5 deploys por dia até o fim do trimestre”, o que acontece? O time encontra uma forma. E quase sempre essa forma envolve algum tipo de “trapaça” não-intencional. Vamos olhar alguns cenários reais que o pessoal do InfoQ documentou:

• Inflar Deployment Frequency: o time quebra um PR único em 5 PRs artificiais, ou faz “deploys de no-op” só pra subir o número. Resultado: a métrica sobe, o valor entregue não muda, e o overhead de revisão e deploy cresce.
• Reduzir Lead Time pulando review: pra commit virar prod mais rápido, alguém afrouxa o review, ou pula testes em PRs “pequenos”. Lead Time melhora, Change Failure Rate piora — e como ninguém olha as duas juntas, parece que melhorou.
• Mascarar MTTR com rollback agressivo: rollback é rápido, então toda vez que algo dá ruim em prod, o time desfaz. MTTR fica ótimo. Só que rollback significa que o valor da release foi tirado do usuário — você não está mais entregando, está só não-quebrando.
• Diluir Change Failure Rate com deploys triviais: se você sobe 100 deploys de mudança de copy e 5 deploys que quebraram, sua taxa de falha despenca. A métrica mente, e o time acredita.

Então qual é o ponto de medir, se mexer na métrica deixa ela mentirosa? O ponto é usar as métricas como gatilho de conversa, não como nota da prova. Quando o Lead Time sobe três sprints seguidas, isso é informação. Não é castigo nem crachá: é sinal pra abrir o capô e investigar. Pode ser CI lento, pode ser fila de review, pode ser PR muito grande, pode ser ambiente de staging instável. As métricas não te dizem o que fazer, elas te dizem onde olhar.

Métrica de time vs. métrica individual

Esse é um corolário tão importante que merece subseção própria: DORA Metrics são métricas de sistema, não de pessoa. A própria documentação oficial é explícita sobre isso (DORA — DORA metrics): elas devem ser aplicadas no nível de aplicação ou serviço, não comparadas entre times diferentes, e jamais usadas pra avaliar engenheiros individualmente.

O motivo é direto: se eu, como dev, sei que minha promoção depende do meu Lead Time, eu vou otimizar pro meu Lead Time. Vou evitar PRs grandes mesmo quando faz sentido, vou evitar pegar bug difícil porque ele leva mais tempo, vou criar atrito político em revisões alheias pra acelerar as minhas. Métrica de time virando incentivo individual destrói o time e mente sobre a performance.

Pra avaliação individual de engenheiro, existe outro framework chamado SPACE (Satisfaction, Performance, Activity, Communication, Efficiency), que é explicitamente pensado pra capturar dimensões individuais e de bem-estar. Os dois são complementares. DORA mede o sistema; SPACE mede as pessoas e a colaboração. Não confunda.

Como aplicar no time

Beleza, então como adotar isso de forma saudável? A receita não é complicada, mas tem alguns pré-requisitos.

Pré-requisitos

Existem várias plataformas que se propõem a calcular DORA Metrics em cima do seu fluxo de desenvolvimento — Swarmia, LinearB, Sleuth, entre outras. Independente da escolha de tooling, três coisas precisam estar no lugar antes:

1. Integrações conectadas: o ponto central costuma ser o app da plataforma instalado no GitHub/GitLab — ele puxa PRs, commits, reviews e eventos de deploy. Pra contexto de projeto/iniciativa, vale plugar também o issue tracker (Linear, Jira, etc). E pra fechar o loop de notificações com o time, conecta o Slack.
2. Definições explícitas e acordadas: o que conta como “deploy”? Subir pra staging conta ou só prod? Toggle de feature flag conta? O que é “falha”? Bug reportado por usuário ou só incidente que paginou? Essas perguntas precisam ser respondidas antes de começar a medir, e por escrito. O Bryan Finster tem um whitepaper bom sobre essas ambiguidades. Na maioria das ferramentas, parte dessa decisão vira configuração concreta: você escolhe entre GitHub Deployments, GitHub Checks ou alguma Deployment API pra dizer à ferramenta o que ela deve contar como deploy de produção.
3. Buy-in da liderança de que é métrica de sistema: se o head de eng vai usar isso pra ranking de time ou pra justificar PIP, melhor não começar. O dano de adotar mal é maior do que o benefício de não adotar.

Comece pequeno

Você não precisa medir as 4 métricas no dia 1. Conectar a plataforma no GitHub e ligar deployments já te dá Deployment Frequency e Lead Time for Changes funcionando praticamente sem trabalho — saem direto do histórico de PRs mergeados na main e dos eventos de deploy. Comece por elas, que juntas já desenham uma foto razoável da saúde do pipeline.

Change Failure Rate vem em seguida, mas depende de um sinal explícito: a maioria das ferramentas detecta automaticamente quando um deploy é seguido de revert, rollback ou hotfix, e marca o deploy original como falha. Pra essa detecção ser confiável, o time precisa adotar uma convenção pra esses deploys — mensagem de commit padronizada, label de PR, ou tag específica. Sem convenção, a métrica vai subestimar a realidade silenciosamente.

MTTR é onde algumas ferramentas têm uma limitação que vale conhecer: elas costumam calcular recovery a partir do tempo entre o deploy quebrado e o deploy de fix. Isso funciona bem pra falhas que são visíveis no pipeline, mas não captura incidentes detectados externamente (alerta de produção, bug reportado por usuário) — esse dado de incident management acaba ficando de fora da conta. Pra grande maioria dos times a aproximação por deploy basta; só vale ter clareza de que essa é a definição.

Sobre cadência de revisão: semanal ou por sprint é suficiente. Diário vira ruído (a variância natural do dia-a-dia engole o sinal). Mensal funciona pra time mais maduro com volume baixo de deploy.

Um recurso comum que casa bem com essa cadência são as Working Agreements: você define alvos coletivos (ex.: “PRs abertos por menos de 24h”, “Lead Time abaixo de X dias”) e a ferramenta notifica no Slack quando o time se afasta. Útil pra automatizar parte do feedback sem virar microgerenciamento — o alerta vai pro time, não pro indivíduo.

Um caso prático

Vou pegar um exemplo real documentado pelo pessoal da BossaBox, que ilustra bem o ciclo virtuoso:

O time tinha deploy a cada 15 dias e quase todo deploy vinha seguido de hotfix (daí o failure rate beirando 100%). Recuperação levava em média 90 horas. Quando esses dados foram levantados e apresentados de forma quantitativa, abriu espaço pra discussão estrutural — o problema não era “esforço” do time, era arquitetura, processo de deploy, e cobertura de testes. Depois das mudanças, deploy diário com MTTR de 90 minutos.

Repare no padrão: a métrica não consertou nada. Ela só tornou visível um problema que todo mundo sentia mas ninguém conseguia dimensionar. O conserto foi nas práticas (CI/CD, testes, arquitetura) e na cultura (deploy não é mais evento de risco). A ferramenta é o que torna esse “tornar visível” rápido — mas não é mágica.

Conversas de melhoria

Quando o time olha as métricas em ritual recorrente (uma boa pedida é encaixar na retro de sprint), as perguntas certas a fazer são abertas:

• “Nosso Lead Time subiu 30% no último mês. O que mudou no nosso fluxo?”
• “Esse spike de Change Failure veio de qual área? É repetição ou foi isolado?”
• “Estamos com Deploy Frequency caindo. É decisão consciente ou está aparecendo gargalo?”

A ferramenta ajuda nesse momento porque permite filtrar por repositório, time, autor ou janela de tempo — dá pra ver rápido se o sintoma está concentrado em um serviço ou se é sistêmico, e dá pra cruzar com dados do issue tracker pra entender se foi um tipo específico de mudança. Mas o ferramental não substitui a discussão. Note que nenhuma das perguntas acima é “quem foi o culpado?”. Métrica que culpabiliza vira métrica manipulada — e isso vale igual com ou sem dashboard bonito.

Resultado esperado

O que esperar de adotar DORA Metrics direito? Em horizontes diferentes:

• Curto prazo (semanas): visibilidade. Você passa a ver onde o tempo se perde, qual etapa do pipeline é a mais lenta, e quanto o time gasta apagando incêndio vs. entregando feature.
• Médio prazo (meses): o time começa a usar as métricas como ferramenta de melhoria. Lead Time cai porque alguém percebe que o ambiente de CI estava lento. Change Failure Rate cai porque alguém percebe que faltava cobertura em uma área específica. Deploy Frequency sobe porque o medo de subir código diminuiu.
• Longo prazo (anos): o relatório DORA documenta correlação consistente entre alto desempenho nessas métricas e métricas de negócio (lucratividade, market share) e de pessoas (retenção, menor burnout). Não é mágica — é que time que entrega rápido e estável trabalha em cima de fundamentos saudáveis (CI, testes, trunk-based development, observabilidade), e esses fundamentos são bons em si.

Mas é honesto fechar com o disclaimer: as métricas não dizem como melhorar. Elas só apontam onde olhar. O trabalho de fato — que envolve trunk-based development, continuous delivery, feature flags, testes automatizados, cultura de blameless postmortem, observabilidade — é o que move os números. O dashboard não, ele só conta a história.

O recado final é o mesmo do começo: dashboard não conserta time. Conversa baseada em dado conserta. As DORA Metrics são uma ótima desculpa pra começar essa conversa de forma estruturada — desde que ninguém transforme a métrica em meta no caminho.