O Desafio de Medir Produtividade
Medir a produtividade de desenvolvedores sempre foi controverso. Métricas simplistas como linhas de código ou número de commits são não apenas inúteis, mas prejudiciais. Developer Productivity Engineering (DPE) é a disciplina que aborda esse desafio de forma científica.
Métricas como “linhas de código por dia” incentivam comportamentos disfuncionais. Um desenvolvedor que refatora 1000 linhas para 100 está sendo mais produtivo, não menos.
DORA Metrics: O Padrão da Indústria
O programa DORA (DevOps Research and Assessment) identificou 4 métricas-chave que correlacionam com alta performance:
Deployment Frequency
Com que frequência a organização deploya código em produção
Lead Time for Changes
Tempo do commit ao código rodando em produção
Change Failure Rate
Percentual de deploys que causam falhas em produção
Time to Restore
Tempo para recuperar de uma falha em produção
Classificação de Performance DORA
| Métrica | Elite | High | Medium | Low |
|---|---|---|---|---|
| Deployment Frequency | On-demand (múltiplas/dia) | Diário a semanal | Semanal a mensal | Mensal+ |
| Lead Time for Changes | < 1 hora | 1 dia - 1 semana | 1 semana - 1 mês | 1 mês+ |
| Change Failure Rate | < 5% | 5-10% | 10-15% | 15%+ |
| Time to Restore | < 1 hora | < 1 dia | 1 dia - 1 semana | 1 semana+ |
A pesquisa DORA mostra que times Elite são 2x mais produtivos que times Low performers, ao mesmo tempo que têm 3x menos falhas.
SPACE Framework: Uma Visão Mais Completa
O framework SPACE (desenvolvido por Microsoft, GitHub e University of Victoria) complementa DORA com dimensões mais amplas:
Implementando SPACE
Métricas de Developer Experience
Além de DORA e SPACE, métricas específicas de DevEx são essenciais:
Build & Test Performance
# Exemplo de métricas de build
metrics:
build:
local_build_time_p50: 2m 30s
local_build_time_p95: 5m 15s
ci_build_time_p50: 4m
ci_build_time_p95: 8m
tests:
unit_test_time: 45s
integration_test_time: 3m
e2e_test_time: 12m
flaky_test_rate: 2.3%
# Targets
targets:
local_build_time_p95: < 3m
ci_build_time_p95: < 10m
flaky_test_rate: < 1%
Empresas que reduzem o tempo de build de 10 minutos para 2 minutos reportam aumento de 20-30% em deploys diários e melhoria significativa na satisfação dos desenvolvedores.
Code Review Metrics
code_review:
# Tempo para primeira revisão
time_to_first_review_p50: 2h
time_to_first_review_p95: 8h
# Tempo para merge após aprovação
time_to_merge_p50: 30min
time_to_merge_p95: 4h
# Tamanho dos PRs
pr_size_p50: 150 lines
pr_size_p95: 500 lines
# Qualidade
review_iterations_avg: 1.5
comments_per_pr_avg: 3
targets:
time_to_first_review_p95: < 4h
pr_size_p95: < 400 lines
review_iterations_avg: < 2
Implementando um Programa de DPE
1. Developer Survey
# Exemplo de survey trimestral
survey:
frequency: quarterly
anonymous: true
questions:
- category: satisfaction
items:
- "Quão satisfeito você está com as ferramentas de desenvolvimento?"
- "Você se sente produtivo no dia a dia?"
- "Você recomendaria trabalhar aqui para um amigo desenvolvedor?"
- category: friction
items:
- "Quais são os maiores obstáculos para sua produtividade?"
- "Quanto tempo você perde com builds/deploys lentos?"
- "Quanto tempo você gasta em reuniões por semana?"
- category: improvement
items:
- "O que mais melhoraria sua experiência de desenvolvimento?"
- "Quais ferramentas/processos você gostaria que fossem implementados?"
2. Dashboard de Métricas
# Exemplo de coleta de métricas com OpenTelemetry
from opentelemetry import metrics
meter = metrics.get_meter("developer-productivity")
# Métricas de build
build_duration = meter.create_histogram(
name="build.duration",
description="Build duration in seconds",
unit="s"
)
# Métricas de deploy
deploy_counter = meter.create_counter(
name="deploy.count",
description="Number of deployments"
)
deployment_lead_time = meter.create_histogram(
name="deploy.lead_time",
description="Time from commit to production",
unit="s"
)
# Métricas de PR
pr_review_time = meter.create_histogram(
name="pr.review_time",
description="Time to first review",
unit="s"
)
pr_merge_time = meter.create_histogram(
name="pr.merge_time",
description="Time from PR open to merge",
unit="s"
)
3. Automação de Coleta
# GitHub Actions para coletar métricas de PR
name: PR Metrics
on:
pull_request:
types: [opened, closed, review_requested, review_submitted]
jobs:
collect-metrics:
runs-on: ubuntu-latest
steps:
- name: Collect PR Metrics
uses: your-org/pr-metrics-action@v1
with:
metrics-endpoint: ${{ secrets.METRICS_ENDPOINT }}
pr-number: ${{ github.event.pull_request.number }}
event-type: ${{ github.event.action }}
Cultura de Melhoria Contínua
Transparência
Dashboards públicos com métricas acessíveis a todos os times
Ownership
Cada time é dono de suas métricas e planos de melhoria
Retrospectivas
Discussões regulares sobre métricas e ações de melhoria
Celebração
Reconhecer e celebrar melhorias, não apenas resultados finais
Armadilhas Comuns
- Gamificação destrutiva: Desenvolvedores vão otimizar o que é medido, mesmo que prejudique a qualidade
- Métricas individuais: Use métricas de time, nunca para avaliar indivíduos
- Muitas métricas: Foque em 5-7 métricas chave, não dezenas
- Métricas sem contexto: Números isolados não contam a história completa
- Comparação entre times: Times têm contextos diferentes, compare consigo mesmo
Stack Recomendada
# Stack para Developer Productivity Engineering
collection:
ci_cd: GitHub Actions / GitLab CI / Jenkins
source_control: GitHub / GitLab
observability: OpenTelemetry
storage:
metrics: Prometheus / InfluxDB
events: BigQuery / Snowflake
visualization:
dashboards: Grafana / Looker
surveys: Culture Amp / Lattice / Google Forms
analysis:
dora: Four Keys / LinearB / Sleuth
devex: DX / Pluralsight Flow / Jellyfish
Próximos Passos
Jornada de Implementação de DPE
- Semana 1-4BaselineColete métricas por 2-4 semanas antes de tentar melhorar qualquer coisa.
- Semana 5Survey InicialEntenda a percepção dos desenvolvedores antes de olhar os números.
- Semana 6-8Quick WinsIdentifique e resolva os friction points mais impactantes primeiro.
- Semana 9-10DashboardCrie visibilidade com dashboards acessíveis a todos.
- ContínuoRitmoEstabeleça cadência de revisão mensal/trimestral das métricas.
Quer implementar um programa de Developer Productivity Engineering? Fale com nossos especialistas para uma avaliação personalizada.