7 min lectura • Guide 544 of 877
Midiendo la Productividad de Desarrolladores
La medición de productividad debe identificar mejoras sistémicas, no rankear desarrolladores individuales. Los analytics de GitScrum proporcionan insights a nivel de equipo sobre velocity, cycle time y throughput que ayudan a managers a identificar cuellos de botella y mejoras de proceso. La clave es medir el sistema, no las personas—y usar datos para remover obstáculos en lugar de aplicar presión.
Categorías de Métricas
| Categoría | Buenas Métricas | Malas Métricas |
|---|---|---|
| Output | Features entregadas, PRs mergeados | Líneas de código, commits |
| Calidad | Tasa de bugs, incidentes | Solo % coverage |
| Velocidad | Cycle time, lead time | Horas loggeadas |
| Flujo | WIP, tiempo bloqueado | Tareas iniciadas |
| Impacto | Valor al cliente, revenue | Story points absolutos |
Métricas DORA
LAS 4 MÉTRICAS DORA
═══════════════════
DEPLOYMENT FREQUENCY (Velocidad):
┌─────────────────────────────────────────────────────────────┐
│ ¿Con qué frecuencia deployamos a producción? │
│ │
│ Elite: Múltiples veces al día │
│ High: Entre diario y semanal │
│ Medium: Entre semanal y mensual │
│ Low: Menos de una vez al mes │
│ │
└─────────────────────────────────────────────────────────────┘
LEAD TIME FOR CHANGES (Velocidad):
┌─────────────────────────────────────────────────────────────┐
│ ¿Cuánto toma ir de commit a producción? │
│ │
│ Elite: Menos de 1 hora │
│ High: Entre 1 día y 1 semana │
│ Medium: Entre 1 semana y 1 mes │
│ Low: Más de 1 mes │
│ │
└─────────────────────────────────────────────────────────────┘
CHANGE FAILURE RATE (Estabilidad):
┌─────────────────────────────────────────────────────────────┐
│ ¿Qué % de deployments causan fallo? │
│ │
│ Elite: 0-15% │
│ High: 16-30% │
│ Medium: 31-45% │
│ Low: 46-100% │
│ │
└─────────────────────────────────────────────────────────────┘
TIME TO RESTORE (Estabilidad):
┌─────────────────────────────────────────────────────────────┐
│ ¿Cuánto toma recuperarse de un fallo? │
│ │
│ Elite: Menos de 1 hora │
│ High: Menos de 1 día │
│ Medium: Entre 1 día y 1 semana │
│ Low: Más de 1 semana │
│ │
└─────────────────────────────────────────────────────────────┘
Métricas de Equipo vs Individual
POR QUÉ MÉTRICAS DE EQUIPO
══════════════════════════
MÉTRICAS INDIVIDUALES (EVITAR):
┌─────────────────────────────────────────────────────────────┐
│ │
│ Problemas con métricas individuales: │
│ │
│ 📊 "Juan hizo 50 commits este mes" │
│ └── ¿Y qué? ¿Valor? ¿Calidad? │
│ │
│ 📊 "María completó 8 story points" │
│ └── ¿Comparado con qué? Story points varían │
│ │
│ 📊 "Pedro tiene 2 bugs este sprint" │
│ └── ¿Tomó tareas más riesgosas? ¿Fue QA más estricto? │
│ │
│ RESULTADO: Gaming, competencia tóxica, evitar riesgos │
│ │
└─────────────────────────────────────────────────────────────┘
MÉTRICAS DE EQUIPO (PREFERIR):
┌─────────────────────────────────────────────────────────────┐
│ │
│ 📊 "El equipo entregó 5 features este sprint" │
│ └── Resultado tangible, esfuerzo colectivo │
│ │
│ 📊 "Cycle time promedio bajó de 5 a 3 días" │
│ └── Mejora de proceso visible │
│ │
│ 📊 "Tasa de bugs en producción: 2%" │
│ └── Calidad del sistema completo │
│ │
│ RESULTADO: Colaboración, mejora de proceso, ownership │
│ │
└─────────────────────────────────────────────────────────────┘
Métricas de Flujo
MIDIENDO EL FLUJO DE TRABAJO
════════════════════════════
CYCLE TIME:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Inicio trabajo ──────────────────────► Completado │
│ │◄── Cycle Time ──►│ │
│ │
│ MIDE: Cuánto toma completar trabajo una vez iniciado │
│ META: Reducir, hacer más predecible │
│ │
│ Distribución ideal: │
│ │ █████████ │
│ │ █████████████ │
│ │ ███████ │
│ │ ████ │
│ │ ██ │
│ └────────────────────────► │
│ 1d 2d 3d 4d 5d │
│ │
└─────────────────────────────────────────────────────────────┘
THROUGHPUT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Items completados por período de tiempo │
│ │
│ Semana 1: ████████ 8 items │
│ Semana 2: ██████████ 10 items │
│ Semana 3: █████████ 9 items │
│ Semana 4: ███████ 7 items │
│ │
│ MIDE: Capacidad de entrega del equipo │
│ META: Consistencia (predecibilidad) │
│ │
└─────────────────────────────────────────────────────────────┘
WORK IN PROGRESS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ WIP promedio: 8 items en cualquier momento │
│ │
│ MIDE: Cuánto trabajo está activo simultáneamente │
│ META: Menor WIP = mejor flujo │
│ │
└─────────────────────────────────────────────────────────────┘
Evitando Ley de Goodhart
LA LEY DE GOODHART
══════════════════
"Cuando una medida se convierte en objetivo,
deja de ser una buena medida"
EJEMPLOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MÉTRICA: Líneas de código │
│ GAMING: Código verboso, duplicación, no refactorizar │
│ RESULTADO: Código inflado, baja calidad │
│ │
│ MÉTRICA: Número de commits │
│ GAMING: Commits pequeños artificiales │
│ RESULTADO: Historia de git ruidosa │
│ │
│ MÉTRICA: Tickets cerrados │
│ GAMING: Dividir trabajo en tickets pequeños │
│ RESULTADO: Overhead de proceso, trabajo fragmentado │
│ │
│ MÉTRICA: Bugs encontrados │
│ GAMING: Reportar trivialidades como bugs │
│ RESULTADO: Ruido, tiempo perdido triaging │
│ │
└─────────────────────────────────────────────────────────────┘
CÓMO EVITAR:
┌─────────────────────────────────────────────────────────────┐
│ 1. Nunca usar métrica individual como único indicador │
│ 2. Medir outcomes, no outputs │
│ 3. Usar métricas para entender, no para juzgar │
│ 4. Rotar métricas de foco periódicamente │
│ 5. Involucrar al equipo en elegir qué medir │
└─────────────────────────────────────────────────────────────┘
Dashboard de Productividad
DASHBOARD BALANCEADO
════════════════════
┌─────────────────────────────────────────────────────────────┐
│ PRODUCTIVIDAD DEL EQUIPO - Sprint 15 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ENTREGA │ CALIDAD │
│ ────────────────────────────│─────────────────────────── │
│ Features entregadas: 5 │ Bugs en prod: 2 │
│ Velocity: 34 pts │ Bugs resueltos: 8 │
│ Sprint goal: ✅ Logrado │ Cobertura: 78% │
│ │ │
│ FLUJO │ PROCESO │
│ ────────────────────────────│─────────────────────────── │
│ Cycle time: 3.2 días │ Carryover: 2 items (6%) │
│ Throughput: 12 items/sem │ Bloqueos: 4 (resueltos) │
│ WIP promedio: 6 │ Rework: 15% │
│ │
│ TENDENCIAS (últimos 6 sprints): │
│ Velocity: ████████████ ↗ (mejorando) │
│ Cycle time: ████████░░░░ ↘ (bajando, bueno) │
│ Bugs/sprint: ████░░░░░░░░ ↘ (bajando, bueno) │
│ │
└─────────────────────────────────────────────────────────────┘
Mejores Prácticas
MIDIENDO SIN DAÑAR
══════════════════
✅ HACER:
┌─────────────────────────────────────────────────────────────┐
│ • Medir el sistema, no las personas │
│ • Usar múltiples métricas balanceadas │
│ • Compartir métricas con el equipo │
│ • Enfocarse en tendencias sobre absolutos │
│ • Usar datos para remover obstáculos │
│ • Celebrar mejoras colectivas │
└─────────────────────────────────────────────────────────────┘
❌ EVITAR:
┌─────────────────────────────────────────────────────────────┐
│ • Rankear desarrolladores por métricas │
│ • Usar métricas para evaluaciones de desempeño │
│ • Comparar equipos con contextos diferentes │
│ • Métricas de actividad (commits, PRs, etc.) │
│ • Aplicar presión basada en números │
│ • Esconder métricas del equipo │
└─────────────────────────────────────────────────────────────┘