Fundamentos
Métricas DORA: o placar honesto da sua IA em produção
As quatro métricas DORA medem entrega de software há uma década. Com IA no time, elas viraram o teste mais honesto de quem entrega e de quem só produz volume.
Quase toda empresa que colocou IA para trabalhar em 2026 tem uma sensação forte e nenhum número. A sensação é que ficou mais rápido. O número não existe porque ninguém mediu antes. É por isso que vale desenterrar um framework de dez anos atrás, que não foi feito para IA e por isso mesmo é o melhor teste que existe para ela: as métricas DORA.
O que são, em duas frases
DORA é o nome do programa de pesquisa DevOps Research and Assessment, tocado por Nicole Forsgren, Jez Humble e Gene Kim, cujas conclusões foram consolidadas no livro Accelerate, de 2018, e que segue publicando um relatório anual sobre o estado da entrega de software. A contribuição mais durável foi reduzir a saúde da entrega a quatro números:
| Métrica | O que mede | Pergunta prática |
|---|---|---|
| Frequência de deploy | Com que frequência você põe mudança em produção | De quanto em quanto tempo o cliente vê algo novo? |
| Tempo de lead da mudança | Do commit até rodar em produção | Quanto tempo uma ideia pronta fica na fila? |
| Taxa de falha da mudança | Percentual de mudanças que degradam o serviço | Quantas vezes a gente quebra ao mexer? |
| Tempo de restauração | Do incidente até o serviço voltar | Quando quebra, quanto tempo dói? |
A genialidade não está em nenhuma delas isolada. Está no par. As duas primeiras medem throughput, as duas últimas medem estabilidade, e o achado original da pesquisa foi contraintuitivo para a época: as duas coisas não se trocam. Times de alta performance eram melhores nas quatro ao mesmo tempo. Ir devagar não comprava qualidade, comprava só lentidão.
Qualquer métrica isolada aqui é fácil de trapacear. Frequência de deploy sozinha te dá um time que joga lixo em produção toda hora. Taxa de falha sozinha te dá um time que não entrega nada, porque nada que não sai quebra. O quarteto é uma pinça: só melhora junto quem realmente melhorou.
Por que isso ficou urgente agora
O relatório DORA de 2025, dedicado ao desenvolvimento assistido por IA, achou duas coisas que precisam ser lidas juntas. A primeira: existe relação positiva entre adoção de IA e throughput de entrega, uma melhora em relação ao ano anterior. A segunda: a adoção de IA segue tendo relação negativa com a estabilidade da entrega.
Isso não é um paradoxo, é uma conta. A IA acelera a geração de código e reduz o atrito de começar tarefa. O tempo economizado na criação é realocado para auditoria e verificação. E quando o volume de mudança sobe sem que os sistemas de controle acompanhem (teste automatizado forte, versionamento maduro, feedback rápido), o resultado é instabilidade. Você não ganhou velocidade, você antecipou a dívida.
A frase que resume o relatório é a que mais dói: a IA não conserta o time, ela amplifica o que já está lá. Time forte usa IA para ficar melhor. Time com problema descobre que a IA ilumina e intensifica o problema que já existia. Se 90% dos profissionais de tecnologia já usam IA no trabalho e mais de 80% acham que ficaram mais produtivos, mas a estabilidade caiu, você tem uma indústria inteira medindo a sensação e ignorando o placar.
Métrica de esforço morreu quando o esforço ficou barato. Sobrou métrica de resultado.
O que muda quando o agente entra no time
Três coisas quebram, e é bom saber quais.
Velocity vira ficção. Story point mede esforço estimado. Com agente gerando código, o esforço deixa de ser o custo escasso. Um time pode triplicar a saída e piorar o negócio. DORA não se importa com o que você produziu, se importa com o que chegou em produção e sobreviveu lá. É por isso que ela envelhece bem: nunca mediu esforço.
Tempo de lead vira o diagnóstico principal. Se a IA acelerou a escrita e o tempo de lead não caiu, o gargalo nunca foi escrever. Estava no code review, na fila de aprovação, no ambiente de homologação, na burocracia de release. Isso é Teoria das Restrições na prática: otimizar fora do gargalo não produz nada além de estoque. Ver o tempo de lead teimar depois de adotar IA é o dado mais valioso que você vai receber esse ano, porque ele aponta o gargalo real com o dedo.
Taxa de falha vira o preço da pressa. É aqui que a instabilidade achada pelo DORA aparece na sua casa. Se ela subiu, você não está mais rápido, está empurrando conserto para frente. E conserto empurrado sempre vence no juros.
Como começar sem virar projeto
O erro clássico é montar um comitê de métricas. Não faça. Três passos e uma semana:
1. Meça antes. Se você vai adotar IA num time, tire uma linha de base das quatro métricas antes. Trinta dias de histórico já servem. Sem isso, toda conversa futura sobre ROI de IA é opinião com gráfico.
2. Use o que já existe. Frequência de deploy e tempo de lead saem do seu git e do seu CI, não precisam de ferramenta nova. Taxa de falha e tempo de restauração saem do seu registro de incidentes, mesmo que ele seja um canal do Slack. Métrica aproximada e disponível vence métrica perfeita e futura.
3. Olhe as quatro na mesma tela, sempre. Uma métrica DORA sozinha é uma meta perversa esperando para acontecer. As quatro juntas são um placar. Coloque num quadro que o time vê toda semana, não num relatório trimestral.
E uma regra de higiene: DORA é métrica de sistema, não de pessoa. No segundo em que virar avaliação individual, ela morre, porque as pessoas otimizam o que são cobradas e ninguém vai deployar coisa arriscada se a taxa de falha estiver no bônus. Isso vale em dobro com IA no time, quando é tentador medir "quantas linhas o agente escreveu". Essa métrica não significa nada. Team Topologies e OKRs resolvem melhor a pergunta sobre quem é responsável por quê.
O teste honesto
No fim, DORA faz ao seu programa de IA a pergunta que ninguém quer ouvir na reunião de diretoria: se a IA está funcionando, por que o cliente não está recebendo mais coisa boa, mais rápido, com menos quebra?
Se as quatro melhoraram, você tem o caso pronto, com número e data. Se o throughput subiu e a estabilidade caiu, você tem um diagnóstico e um trabalho: reforçar sensor, teste e feedback antes de acelerar mais. E se nada mudou, você economizou o próximo trimestre de investimento numa direção que não estava rendendo.
Qualquer um desses três resultados vale mais que a sensação de que ficou mais rápido. E os três custam a mesma coisa: quatro números, medidos antes.
Quer montar a linha de base DORA do seu time antes de escalar IA? Chama a gente no WhatsApp.
Perguntas frequentes
Quais são as quatro métricas DORA?
Frequência de deploy (com que frequência você coloca código em produção), tempo de lead da mudança (quanto tempo um commit leva do repositório até produção), taxa de falha da mudança (que percentual das mudanças causa degradação) e tempo de restauração do serviço (quanto tempo você leva para se recuperar de uma falha). As duas primeiras medem throughput, as duas últimas medem estabilidade.
Por que medir DORA se a gente já mede velocity ou story points?
Porque velocity mede quanto trabalho o time diz que fez, e DORA mede o que chegou em produção e o que aconteceu depois. Com agentes de IA gerando código, a métrica de esforço perde qualquer sentido: o volume de saída deixa de ser um custo. O que continua caro é revisar, integrar e consertar, e é exatamente isso que DORA enxerga.
Métricas DORA servem para time que não é de software?
A mecânica sim. Toda operação tem uma unidade que sai (uma proposta, um laudo, um atendimento), um tempo de fila até ela sair, um percentual que volta errado e um tempo de conserto. Trocar 'deploy' pela sua unidade dá quatro números com a mesma tensão útil entre velocidade e qualidade.