Quando falamos de performance em times de desenvolvimento, a primeira tentação é medir “o que é fácil”: número de commits, linhas de código, quantidade de tasks entregues, pontos de história… Só que isso quase sempre gera efeito colateral: otimização para o número, não para o resultado.
É aqui que entram as métricas DORA (DevOps Research and Assessment). Elas ficaram populares por um motivo simples: ajudam a medir capacidade real de entrega, estabilidade e velocidade de aprendizado — sem incentivar comportamentos ruins.
As quatro métricas DORA são:
- Frequência de Deploy (Deployment Frequency)
- Lead Time para Mudanças (Lead Time for Changes)
- Taxa de Falha em Mudanças (Change Failure Rate)
- Tempo de Restauração (MTTR — Mean Time to Restore)
A beleza do modelo é que ele equilibra velocidade e qualidade. Se você acelera e quebra tudo, as métricas “de estabilidade” denunciam. Se você mantém tudo estável, mas entrega pouco, as métricas “de fluxo” mostram.
1) Frequência de Deploy: “Com que frequência entregamos valor?”
O que mede: quantas vezes o time coloca mudanças em produção em um período.
Por que importa: times com deploy frequente tendem a trabalhar com lotes menores, feedback rápido e menos risco por entrega.
Como interpretar bem:
- Deploy frequente não significa deploy irresponsável.
- Melhor olhar a tendência: estamos reduzindo o tamanho do lote e entregando com consistência?
Exemplo prático:
- Time A: 1 deploy por semana, com um pacote enorme.
- Time B: 3 deploys por dia, com mudanças pequenas.
Geralmente, o Time B tem mais controle de risco, porque cada mudança é menor e mais fácil de reverter.
Boas práticas para melhorar:
- CI/CD confiável (pipeline rápido e estável)
- Feature flags (lançar sem “expor” de imediato)
- Quebra de tarefas em fatias pequenas (vertical slicing)
2) Lead Time para Mudanças: “Quanto tempo uma mudança leva para chegar ao usuário?”
O que mede: tempo entre a mudança estar pronta (ex.: commit/merge) e estar em produção.
Por que importa: lead time baixo é sinal de fluxo saudável. Quanto maior o tempo, maior o acúmulo de fila, dependência e risco.
Onde esse tempo costuma estourar:
- PR grande e revisão lenta
- Falta de automação de testes
- Handoff entre áreas (dev → QA → infra → aprovação)
- Pipeline lento e instável
Como melhorar sem “cobrar velocidade”:
- PRs menores e mais frequentes
- Políticas de review claras (SLA de review, pairing, mob review em PRs críticos)
- Testes automatizados + pirâmide de testes equilibrada
- Ambientes padronizados e provisionamento automatizado
3) Change Failure Rate: “Com que frequência uma mudança causa problema?”
O que mede: percentual de deploys que geram incidente, rollback, hotfix ou degradação relevante.
Por que importa: é o termômetro da qualidade real do processo, não do “capricho individual”.
Ponto importante: falha não é “culpa”. Falha é um sinal de sistema.
Exemplos do que contar como falha:
- rollback após deploy
- hotfix emergencial
- incidente de produção causado por mudança recente
- queda de disponibilidade ligada a release
Como reduzir sem travar entregas:
- Observabilidade (logs, métricas, tracing) para detectar rápido
- Canary release / blue-green
- Testes de contrato (especialmente em microserviços)
- Revisão de risco por mudança (não burocracia, e sim checklist leve)
4) MTTR: “Quando dá ruim, quanto tempo levamos para recuperar?”
O que mede: tempo médio para restaurar o serviço após um incidente.
Por que importa: incidentes vão acontecer. Times maduros não são os que “nunca quebram”, e sim os que se recuperam rápido e aprendem.
O que normalmente aumenta MTTR:
- Falta de monitoramento e alertas úteis
- Playbooks inexistentes
- Processo de rollback lento
- Deploy “big bang” difícil de reverter
- Conhecimento concentrado em poucas pessoas
Como melhorar:
- Alertas com ação clara (menos ruído, mais precisão)
- Runbooks e playbooks (passo a passo do que fazer)
- Rollback automatizado
- Postmortem sem caça às bruxas (foco em melhoria do sistema)
O que as métricas DORA NÃO são
Para evitar que elas virem “arma de cobrança”, vale reforçar:
- Não são métricas para avaliar pessoas.
São métricas do sistema de entrega (processo, ferramentas, dependências, arquitetura). - Não são metas isoladas.
A métrica só faz sentido no conjunto. Aumentar deploy e piorar falha é regressão, não evolução. - Não substituem contexto.
Um produto regulado (banco/saúde) tem restrições diferentes de um app de marketing. O objetivo é melhorar dentro do contexto.
Como aplicar na prática sem burocracia
Se você quer começar simples, aqui vai um caminho seguro:
1) Defina “produção” e “mudança”
- O que conta como deploy? (serviço principal? qualquer app? infra?)
- O que é “mudança”? (merge na main? release tag? deploy bem-sucedido?)
2) Comece coletando automaticamente
Evite planilhas manuais. Em geral, dá para integrar via:
- GitHub/GitLab (commits, merges, PRs)
- Ferramenta de CI/CD (build, release, deploy)
- Observabilidade (incidentes, downtime)
3) Use como ferramenta de melhoria contínua
Uma rotina que funciona muito bem:
- Semanal: olhar tendências (fluxo e estabilidade)
- Mensal: escolher 1 gargalo e atacar (pipeline, testes, review, deploy)
- Após incidentes: postmortem e melhoria do sistema
4) Combine com métricas de produto
DORA mede a capacidade de entrega. Não garante que você está entregando a coisa certa.
Por isso, combine com:
- métricas de adoção
- NPS/CSAT
- conversão/retention
- métricas de valor por entrega
Um exemplo real de “meta saudável”
Em vez de dizer “dobrar frequência de deploy”, uma abordagem melhor seria:
- reduzir o tamanho médio de PRs
- reduzir tempo de fila de review
- estabilizar pipeline (menos falhas e retrabalho)
- habilitar rollback/feature flag para mudanças arriscadas
Resultado: deploy aumenta naturalmente e falhas caem.
Fechamento
As métricas DORA são um dos melhores modelos para quem quer evoluir engenharia sem cair em “métrica de vaidade”. Elas ajudam a responder quatro perguntas simples:
- Entregamos com frequência?
- O fluxo está rápido?
- Estamos quebrando com frequência?
- Quando quebra, recuperamos rápido?
Se você mede isso com consistência e usa os dados para aprender (e não punir), o time melhora — e o produto sente.
