Métricas DORA sem teatro
As quatro métricas dizem muito sobre a capacidade de entrega de um time — e viram encenação no dia em que alguém as transforma em meta individual.
As quatro métricas DORA — frequência de deploy, lead time para mudança, taxa de falha em mudança e tempo de restauração — são o melhor conjunto disponível para descrever a capacidade de entrega de um time. Também são das mais fáceis de manipular quando viram meta de avaliação.
O que cada uma revela
- Frequência de deploy: mede o tamanho do lote. Lote grande concentra risco; deploy frequente é consequência de lote pequeno, não a causa da qualidade.
- Lead time para mudança: do commit ao ambiente produtivo. Expõe fila, espera por aprovação e etapas manuais escondidas.
- Taxa de falha em mudança: percentual de deploys que exigem correção imediata. Mede confiabilidade do processo, não competência individual.
- Tempo de restauração: quanto leva para voltar ao normal. É a métrica que mais depende de observabilidade e de rollback ensaiado.
Como elas viram teatro
Basta transformá-las em meta de bônus. Frequência de deploy sobe quando o time passa a fazer deploys vazios. Lead time cai quando o commit é feito só depois do trabalho pronto. Taxa de falha despenca quando a correção é classificada como "melhoria". Os números melhoram e nada muda na realidade.
Toda métrica que vira meta deixa de ser uma boa métrica. DORA serve para o time enxergar a si mesmo, não para a gestão comparar times entre si.
Uso que produz efeito
- Colete automaticamente do pipeline e do sistema de incidentes — nunca por preenchimento manual.
- Mostre tendência, não valor absoluto. A pergunta útil é "melhorou em relação ao trimestre passado?".
- Leia as quatro em conjunto: velocidade sem estabilidade é dívida sendo acumulada.
- Discuta na retrospectiva do time, não no relatório mensal da diretoria.
- Ao identificar uma regressão, procure a etapa do fluxo que a causou — não a pessoa.
Bem usadas, essas quatro métricas transformam discussões subjetivas sobre produtividade em uma conversa sobre gargalos concretos do fluxo de entrega. É bem mais produtivo do que estimar em pontos.
Artigos relacionados
Quando microsserviços são a decisão errada
Microsserviço resolve um problema organizacional antes de resolver um problema técnico. Se o seu problema não é organizacional, você está comprando complexidade sem contrapartida.
RAG em produção: o que ninguém conta na demonstração
Um protótipo de RAG fica pronto em uma tarde. A distância entre esse protótipo e um sistema confiável é feita de avaliação, chunking, reranking e controle de custo.
Sua conta de nuvem não é um problema de infraestrutura
Custo de nuvem é sintoma de decisão de arquitetura. Cortar instância resolve o mês; mudar o que gera o gasto resolve o ano.