DORA metrics são o termômetro errado para times de 5 pessoas — e o que medir no lugar

DORA virou jargão. Mas as 4 métricas foram desenhadas para times de 50+ devs com pipeline maduro. Em squad de 5 pessoas, elas distorcem decisão. Veja as 4 métricas alternativas que a Revin reporta — calibradas para o tamanho real.

Por Victhor Araújo

Victhor Araújo

DORA virou jargão obrigatório em conversa de engenharia. Deploy frequency, lead time for changes, change failure rate, time to restore. Todo founder ouviu, todo CTO menciona em board. Mas a maioria opera em squad de 4-8 pessoas — e essas 4 métricas foram desenhadas para times de 50+ com pipeline maduro.

Em squad pequeno, DORA distorce mais do que informa. A Revin propõe 4 métricas alternativas calibradas para 4-15 devs, que reportamos semanalmente em todos os clientes. Não é descartar DORA — é usar a régua certa para o time real.

Para CTOs e founders que adotaram DORA porque "o mercado usa" e estão tirando decisões questionáveis a partir delas em squad pequeno.

Deploy frequency alta em time pequeno pode mascarar entregas insignificantes

🚧 Por que DORA distorce em squad pequeno

Deploy frequency: maximizar incentiva fragmentação

Em time grande, alta deploy frequency é sinal de pipeline maduro. Em squad de 5, virar essa métrica vira a prioridade leva a deploys cosméticos (mudança de copy, ajuste de CSS) só para subir o número. Métrica sobe; produto não anda.

Lead time for changes: variância alta torna a mediana inútil

Time grande tem distribuição estatística que faz mediana ser representativa. Squad de 5 tem 1-2 features grandes (4 semanas) + 10 fixes pequenos (1 dia). A mediana mente sobre a realidade.

Change failure rate: amostra pequena vira ruído

Com 8 deploys por mês, 1 falha = 12.5% de change failure rate. Com 80 deploys, 1 falha = 1.25%. Mesma realidade, números 10x diferentes. Decisão baseada nessa métrica em squad pequeno é decisão baseada em ruído.

Time to restore: raramente acionado em time pequeno

Squad pequeno tem incidentes esparsos. Se você teve 2 incidentes no trimestre, "média de time to restore" tem N=2. Estatística sem peso para decisão.

📊 As 4 métricas que a Revin reporta no lugar

1. Feature outcome rate

De cada feature lançada no trimestre, quantas atingiram a métrica de negócio definida no escopo? Ex: "feature X devia aumentar conversão em 5% — atingiu?". Mede outcome real, não atividade.

2. Rework rate (% de PR reaberto em 14 dias)

PR mergeado e depois reverto/corrigido em 14 dias indica definição de pronto fraca, code review superficial ou requisito incompleto. Métrica direta de qualidade, robusta em amostra pequena.

3. Cost per shipped feature (USD)

Soma de dev × hora + infra + retrabalho ÷ features entregues no período. Métrica que o CFO entende. Robusta porque agrega dimensões.

4. Forecast accuracy (% de sprints fechados na data estimada)

Squad sênior estima e bate; squad reativo estima e raramente bate. Métrica direta de previsibilidade, valor enorme para stakeholder externo.

4 métricas calibradas para o tamanho real do squad: outcome, qualidade, custo, previsibilidade

🛠️ Como começar a medir essas 4

• Outcome rate: requer escopo de feature ter métrica de negócio definida ANTES da implementação. Tech lead reforça esse padrão.
• Rework rate: script simples em GitHub/GitLab que detecta PR revertido ou modificado em < 14 dias.
• Cost per feature: planilha mensal com horas alocadas + custo médio + features entregues. Não precisa ferramenta cara.
• Forecast accuracy: cada sprint, planejado vs. entregue. Acumular em 8 sprints já dá sinal estatístico.

📢 Quer implementar essas 4 métricas no seu squad em 2 semanas? Agende um Diagnostic Sprint — a Revin define cálculo, fonte de dados e dashboard para cada uma.

🎯 Conclusão: DORA é régua certa para o time errado

DORA é excelente para Google, Spotify, Netflix. É inadequado para squad de 5 pessoas. Squad sênior usa a régua certa para o tamanho real — não copia o que está no blog do Vale.

📢 A Revin reporta essas 4 métricas em todos os clientes desde 2024. Conheça o modelo de delivery.