Métricas de engenharia que importam: DORA, throughput e qualidade

1. O problema das métricas de engenharia: o que medir e por quê?

1.1. A armadilha de métricas de vaidade

Muitos times de engenharia caem na armadilha de métricas que parecem importantes, mas não geram valor real. Linhas de código escritas, número de commits por dia ou horas trabalhadas são exemplos clássicos de vanity metrics. Elas podem ser facilmente manipuladas e não refletem a qualidade ou o impacto do trabalho.

# Exemplo de dashboard de métricas de vaidade (evitar)
| Métrica            | Valor   | Problema                          |
|--------------------|---------|-----------------------------------|
| Linhas de código   | 12.450  | Não mede qualidade ou impacto     |
| Commits/dia        | 8       | Incentiva commits pequenos demais  |
| Horas trabalhadas  | 9,5h    | Ignora eficiência e foco           |
| Features entregues | 3       | Não considera débito técnico       |

1.2. O alinhamento entre métricas e objetivos de negócio

Métricas de engenharia só têm valor quando conectadas a resultados de negócio. Um time pode entregar 50 features por mês, mas se o NPS cai e a retenção de usuários despenca, essas entregas são irrelevantes.

1.3. Introdução ao framework DORA

O DevOps Research and Assessment (DORA) — iniciativa do Google Cloud — estabeleceu um conjunto de métricas que correlacionam diretamente com desempenho organizacional. Empresas de alta performance apresentam resultados significativamente melhores nas quatro métricas DORA.

2. As quatro métricas DORA essenciais

2.1. Frequência de deploy

Mede quantas vezes o time faz deploy para produção em um período. Times de elite fazem múltiplos deploys por dia; times de baixa performance, entre uma vez por mês e uma vez a cada seis meses.

# Cálculo de frequência de deploy (exemplo mensal)
Deploys no mês: 47
Dias úteis: 22
Frequência: 47/22 ≈ 2,14 deploys/dia
Classificação DORA: Elite (> 1 deploy/dia)

2.2. Lead time para mudanças

Tempo entre o primeiro commit e o deploy em produção. Times de elite têm lead time inferior a uma hora; times de baixa performance, entre um e seis meses.

# Exemplo de medição de lead time
Commit A: 09:15
Deploy A: 10:42
Lead time: 1h27min

Commit B: 14:30
Deploy B: 14:31
Lead time: 1 minuto (hotfix)

2.3. Tempo médio de recuperação (MTTR)

Quanto tempo leva para restaurar o serviço após um incidente. MTTR baixo indica resiliência operacional e boa automação de rollback.

2.4. Taxa de falha em mudanças

Percentual de deploys que causam incidentes ou degradação. Times de elite têm taxa inferior a 5%; times de baixa performance podem chegar a 30-45%.

# Cálculo de taxa de falha
Deploys totais no mês: 47
Deploys com incidente: 2
Taxa de falha: 2/47 = 4,25%
Classificação DORA: Elite (< 5%)

3. Throughput: produtividade real além do volume de entregas

3.1. Throughput vs. capacidade

Throughput mede itens entregues por unidade de tempo, enquanto capacidade é o trabalho máximo que o time pode realizar. O foco deve estar no fluxo contínuo, não no volume bruto.

3.2. Métricas de fluxo

  • Cycle time: tempo desde o início do trabalho até a entrega
  • Throughput rate: itens entregues por semana
  • CFD (Cumulative Flow Diagram): visualiza gargalos no fluxo
# Exemplo de métricas de fluxo (sprint de 2 semanas)
| Item           | Início  | Entrega | Cycle time |
|----------------|---------|---------|------------|
| Feature login  | 01/04   | 05/04   | 4 dias     |
| Fix checkout   | 03/04   | 04/04   | 1 dia      |
| API pagamento  | 01/04   | 10/04   | 9 dias     |

Throughput: 3 itens em 10 dias úteis = 0,3 itens/dia

3.3. Como evitar a armadilha de "entregar mais" sem qualidade

O throughput deve ser balanceado com métricas de qualidade. Um time que entrega 10 features mas introduz 5 bugs críticos está gerando débito técnico.

4. Qualidade interna: débito técnico, cobertura de testes e estabilidade

4.1. Cobertura de testes como indicador de confiança

Cobertura de 80%+ é desejável, mas não garante qualidade. Testes mal escritos ou focados em código trivial inflam a métrica sem valor real.

# Exemplo de relatório de cobertura
| Módulo          | Cobertura | Qualidade dos testes          |
|-----------------|-----------|-------------------------------|
| Autenticação    | 92%       | Testes de unidade + integração|
| Checkout        | 65%       | Faltam testes de fluxo crítico|
| Dashboard       | 45%       | Cobertura baixa, risco alto   |

4.2. Métricas de débito técnico

  • Code churn: percentual de código alterado em curto período (alta rotação indica instabilidade)
  • Complexidade ciclomática: mede caminhos lógicos no código
  • Hotspots: arquivos com alta frequência de mudanças e alta complexidade

4.3. Estabilidade do código

Taxas de defeito e reincidência indicam se o time está aprendendo com os erros ou repetindo padrões problemáticos.

5. Qualidade externa: impacto no usuário e no negócio

5.1. SLIs, SLOs e SLAs

  • SLI (Service Level Indicator): métrica técnica (ex: latência < 200ms)
  • SLO (Service Level Objective): meta interna (ex: 99,9% de disponibilidade)
  • SLA (Service Level Agreement): compromisso contratual com o cliente

5.2. Métricas de erro no frontend e backend

# Exemplo de dashboard de qualidade externa
| Métrica         | Atual  | SLO    | Status |
|-----------------|--------|--------|--------|
| Apdex           | 0,94   | 0,95   | ⚠️     |
| Erro rate (API) | 0,8%   | <1%    | ✅     |
| Latência p95    | 180ms  | <200ms | ✅     |
| Erro frontend   | 2,3%   | <2%    | ❌     |

5.3. Correlação entre métricas de engenharia e produto

Queda no Apdex geralmente antecede queda no NPS. Times maduros correlacionam dados de engenharia com métricas de produto para priorizar correções.

6. Como implementar um dashboard de métricas que gere ação

6.1. Escolha de ferramentas

  • Grafana + Prometheus: stack open source popular
  • Datadog: solução completa com APM e logs
  • Honeycomb: foco em observabilidade e debugging
  • Four Keys (Google): dashboard específico para DORA

6.2. Definição de thresholds e alertas acionáveis

Alertas devem ser específicos e evitar alarm fatigue. Um alerta de "erro rate > 5%" é melhor que "erro rate > 0%".

# Exemplo de regra de alerta (Prometheus)
alert: HighErrorRate
expr: |
  (
    sum(rate(http_requests_total{status=~"5.."}[5m]))
    /
    sum(rate(http_requests_total[5m]))
  ) > 0.05
for: 2m
labels:
  severity: critical

6.3. Ritmo de revisão

Retrospectivas orientadas a dados devem acontecer a cada sprint ou quinzenalmente, analisando tendências e propondo experimentos.

7. Armadilhas comuns e como evitá-las na prática

7.1. Goodhart's Law

"Quando uma métrica se torna um objetivo, ela deixa de ser uma boa métrica." Se o time é avaliado apenas por lead time, pode começar a fazer deploys sem testes adequados.

7.2. Comparações injustas entre times

Times de manutenção de sistemas legados terão métricas diferentes de times de greenfield. Contexto importa.

7.3. O risco de otimizar uma métrica isolada

Reduzir lead time ignorando taxa de falha pode gerar deploys frequentes mas instáveis. O equilíbrio entre as quatro métricas DORA é essencial.

8. Conclusão: construindo uma cultura de melhoria contínua baseada em dados

8.1. O equilíbrio entre velocidade, estabilidade e valor entregue

Métricas não são fim, mas meio. O objetivo é entregar valor ao usuário com qualidade e consistência.

8.2. Como evoluir as métricas ao longo do tempo

Times iniciantes podem começar com uma métrica (frequência de deploy) e gradualmente adicionar as demais. Com maturidade, passam a correlacionar com métricas de negócio.

8.3. Checklist final para implementar métricas que realmente importam

Checklist de implementação de métricas:
✅ Escolher 2-3 métricas DORA para começar
✅ Configurar coleta automatizada (CI/CD, APM)
✅ Definir SLOs realistas (baseados em dados históricos)
✅ Criar dashboard acessível a todo o time
✅ Revisar métricas em retrospectivas
✅ Correlacionar com métricas de produto (NPS, retenção)
✅ Evitar comparações entre times sem contexto
✅ Revisar e ajustar métricas a cada trimestre

Referências