O que são as métricas DORA e por que importam ao contratar um squad de desenvolvimento?

As métricas DORA são os quatro indicadores que a indústria de software usa para medir, de forma objetiva, quão rápido e confiável um time de engenharia entrega: frequência de deploy, lead time for changes (tempo entre o commit e a produção), taxa de falha de mudança e tempo de restauração do serviço. Foram definidas pelo time de pesquisa DORA (DevOps Research and Assessment), hoje parte do Google Cloud, e se tornaram o padrão de fato para comparar a performance de entrega de um time sem depender do que esse time diz sobre si mesmo.

Nenhuma das quatro mede linhas de código ou horas trabalhadas —elas medem o resultado real: com que frequência o time consegue colocar mudanças em produção, quanto tempo uma mudança leva para chegar lá, que porcentagem dessas mudanças quebra alguma coisa, e quanto tempo o time leva para consertar quando isso acontece. É a diferença entre perguntar “quantas horas trabalharam?” e perguntar “com que frequência entregam valor sem quebrar nada?”.

O que cada uma das 4 métricas DORA mede?

• Frequência de Deploy (Deployment Frequency) — com que frequência o time coloca código novo em produção: várias vezes ao dia, uma vez por semana, uma vez por mês.
• Lead Time for Changes — o tempo entre um commit e esse código estar rodando em produção.
• Taxa de Falha de Mudança (Change Failure Rate) — a porcentagem de deploys que acaba causando um incidente, um rollback ou um hotfix em produção.
• Tempo de Restauração do Serviço (Time to Restore Service) — quanto tempo o time leva para restaurar o serviço depois de uma falha em produção.

De onde vêm essas métricas e quem as definiu?

O programa de pesquisa DORA foi fundado por Nicole Forsgren, Jez Humble e Gene Kim, e começou a publicar o State of DevOps Report em 2013 —originalmente em parceria com a Puppet. A síntese dessa pesquisa chegou em 2018 com o livro Accelerate: The Science of Lean Software and DevOps, que conectou pela primeira vez essas quatro métricas a resultados de negócio mensuráveis (rentabilidade, produtividade, participação de mercado) usando métodos estatísticos rigorosos, não opinião do setor. O Google adquiriu o programa pouco depois, e a DORA opera hoje como um time de pesquisa dentro do Google Cloud.

O que diferencia um time de alta performance de um de baixa performance?

A diferença é muito maior do que a intuição sugere. Segundo o Accelerate State of DevOps Report 2019, da DORA/Google Cloud, os times de performance “elite” tinham 973 vezes mais chances de fazer deploy sob demanda e se recuperavam de uma falha em produção 6.570 vezes mais rápido do que os times de baixa performance. Não é uma diferença de grau —é uma diferença de categoria.

O relatório mais recente, DORA State of AI-assisted Software Development 2025 (quase 5.000 profissionais de tecnologia entrevistados), mostra que essa diferença continua valendo: só 19% dos times chegam ao nível “elite”, apenas 16,2% fazem deploy sob demanda, e 23,9% ainda fazem deploy menos de uma vez por mês. A adoção de IA no desenvolvimento chegou a 90% nesse mesmo relatório —mas mais volume de código escrito não move esses números sozinho: sem as práticas de base (controle de versão, testes automatizados, feedback rápido) que as métricas DORA medem, um time simplesmente produz mais rápido o mesmo que já vinha produzindo.

Por que essas métricas importam ao escolher um squad externo, e não só internamente?

Internamente, um time de engenharia tem gestor, histórico e visibilidade diária. Com um squad externo, essa visibilidade não existe de cara: a empresa avalia um perfil, algumas referências e uma demo, e confia que o que esse time diz sobre si mesmo é verdade. Esse é exatamente o problema que as métricas DORA resolvem —substituem o que é autodeclarado (“somos sênior”, “trabalhamos com agile”, “entregamos rápido”) por evidência que pode ser verificada olhando o repositório: quantos deploys houve, quanto duraram, quantos quebraram alguma coisa, quanto tempo levou para consertar.

A Zenit mede algo parecido com isso?

O ZenitRank segue a mesma lógica de fundo das métricas DORA: substituir a reputação autodeclarada por evidência objetiva de entrega —cumprimento de milestones, evidência do GitHub, consistência de um projeto para o outro— em vez de estrelas ou depoimentos que ninguém pode auditar. Não é coincidência: é o mesmo problema (como confiar na capacidade de entrega de um time que você não vê trabalhar todo dia) resolvido com o mesmo princípio.

Esse mesmo princípio —evidência em vez de relatórios de status— é a razão pela qual o Kaizen monta o match cruzando o histórico real de entregas, não só um formulário de disponibilidade, e pela qual cada milestone que um squad executa na Zenit fica documentado com evidência do GitHub, não com uma atualização escrita à mão.

As métricas DORA não são uma certificação que um time ganha uma vez e mantém para sempre —são uma fotografia contínua de como ele entrega, projeto após projeto. Essa é a pergunta que vale a pena fazer antes de contratar um squad externo: não “o que eles dizem sobre si mesmos”, mas “que evidência sobra do que realmente entregaram da última vez”.