Métricas de ingeniería que importan: DORA y más allá

“Lo que no se mide no se puede mejorar” es uno de esos aforismos que suenan bien pero que en la práctica causan tanto daño como beneficio. La obsesión por medir ha llevado a muchos equipos de desarrollo a optimizar las métricas equivocadas, con resultados que van desde la desmotivación del equipo hasta la degradación activa de la calidad del software.

La pregunta correcta no es “qué métricas deberíamos medir”. Es “qué decisiones necesitamos tomar y qué datos nos ayudarían a tomarlas mejor”. Las métricas son herramientas de decisión, no objetivos en sí mismas.

Este artículo cubre las métricas que realmente importan para evaluar y mejorar el rendimiento de un equipo de ingeniería: las métricas DORA como base, el framework SPACE para una visión más completa, y los errores que destruyen la utilidad de cualquier programa de métricas.

Las cuatro métricas DORA (y la quinta)

Las métricas DORA (DevOps Research and Assessment) son el estándar de la industria para medir el rendimiento de la entrega de software. Desarrolladas por el equipo de investigación liderado por Nicole Forsgren, son el resultado de años de investigación con miles de equipos.

1. Frecuencia de despliegue (Deployment Frequency)

Qué mide: Con qué frecuencia tu equipo despliega cambios en producción.

Por qué importa: La frecuencia de despliegue es un proxy de la capacidad del equipo para entregar valor de forma continua. Equipos que despliegan frecuentemente tienden a tener cambios más pequeños, más fáciles de debuggear, y con menor riesgo.

Benchmarks 2026:

• Elite: Múltiples despliegues al día
• High: Entre una vez al día y una vez a la semana
• Medium: Entre una vez a la semana y una vez al mes
• Low: Menos de una vez al mes

Cómo medirla: Cuenta los despliegues exitosos a producción por período. La mayoría de herramientas de CI/CD (GitHub Actions, GitLab CI, Jenkins) registran esto automáticamente.

Trampa común: Medir despliegues sin medir lo que contienen. Un equipo que despliega 10 veces al día pero solo config changes no es más productivo que uno que despliega features completas semanalmente.

2. Lead time for changes (tiempo de entrega de cambios)

Qué mide: El tiempo desde que un commit se integra al trunk hasta que está en producción.

Por qué importa: Un lead time corto significa que el equipo puede responder rápidamente a las necesidades del negocio. Un lead time largo indica cuellos de botella en el proceso de entrega.

Benchmarks 2026:

• Elite: Menos de una hora
• High: Entre un día y una semana
• Medium: Entre una semana y un mes
• Low: Más de un mes

Cómo medirla: Marca el timestamp del merge al trunk y el timestamp del despliegue a producción. La diferencia es tu lead time.

Matiz importante: El lead time incluye espera en code review, espera en QA, espera para ventana de despliegue, etc. Desglosar dónde se gasta el tiempo es más útil que el número agregado.

3. Tasa de fallos en cambios (Change Failure Rate)

Qué mide: El porcentaje de despliegues que causan un fallo en producción que requiere intervención (rollback, hotfix, fix-forward).

Por qué importa: Equilibra la frecuencia de despliegue. Desplegar 50 veces al día no sirve si el 30% de los despliegues rompen algo. Las mejores organizaciones combinan alta frecuencia con baja tasa de fallos.

Benchmarks 2026:

• Elite: 0-5%
• High: 5-10%
• Medium: 10-15%
• Low: Más del 15%

Cómo medirla: Número de despliegues que causan incidentes / número total de despliegues. Requiere una definición clara de “incidente” que sea consistente.

Debate actual: El informe DORA 2025 señaló que equipos que adoptan IA de forma intensiva muestran mayor throughput pero también mayor inestabilidad. La tasa de fallos puede aumentar temporalmente durante la adopción de herramientas de coding con IA.

4. Tiempo de recuperación de despliegues fallidos (Failed Deployment Recovery Time)

Qué mide: Cuánto tiempo tarda el equipo en restaurar el servicio después de un despliegue fallido.

Por qué importa: Los fallos son inevitables. Lo que diferencia a los equipos de élite no es que no fallen, sino que se recuperan rápidamente. Un MTTR bajo indica procesos de respuesta a incidentes maduros.

Nota: En informes anteriores esta métrica se llamaba Mean Time to Recovery (MTTR). DORA la renombró a Failed Deployment Recovery Time para distinguirla de métricas de disponibilidad más amplias.

Benchmarks 2026:

• Elite: Menos de una hora
• High: Menos de un día
• Medium: Entre un día y una semana
• Low: Más de una semana

Cómo medirla: Desde que se detecta el incidente hasta que el servicio se restaura. Requiere timestamps claros del inicio y fin de cada incidente.

5. Rework Rate (la nueva incorporación)

Qué mide: El porcentaje de despliegues que son correcciones no planificadas de bugs que afectan a usuarios.

Por qué importa: DORA incorporó oficialmente la rework rate como quinta métrica. Captura el trabajo que no genera valor nuevo sino que corrige errores del trabajo anterior. Una rework rate alta indica problemas de calidad sistémicos.

Cómo medirla: Etiqueta los despliegues que son bugfixes reactivos (no mejoras planificadas) y calcula el porcentaje sobre el total.

Más allá de DORA: el framework SPACE

Las métricas DORA miden el rendimiento del sistema de entrega de software. Pero la productividad de un equipo de ingeniería es más amplia que eso. El framework SPACE, desarrollado por Nicole Forsgren (la misma investigadora detrás de DORA) junto con equipos de GitHub y Microsoft Research, amplía la perspectiva.

SPACE propone cinco dimensiones de la productividad del desarrollador:

Satisfaction and well-being (satisfacción y bienestar)

Qué captura: Cómo se siente el equipo sobre su trabajo, herramientas y entorno.

Por qué importa: La satisfacción es un indicador adelantado de rotación y un factor directo de calidad. Un equipo insatisfecho produce peor código, colabora menos y eventualmente se va.

Cómo medirla:

• Encuestas trimestrales anónimas (eNPS, Developer Experience Survey)
• Entrevistas one-on-one regulares
• Análisis de rotación y razones de salida

Métricas concretas:

• Developer Net Promoter Score (eNPS)
• Puntuación de satisfacción con herramientas y procesos
• Tasa de rotación voluntaria

Performance (rendimiento)

Qué captura: Los outcomes del trabajo, no el output. No cuánto código se produce, sino qué impacto tiene.

Cómo medirla:

• Impacto en métricas de producto (engagement, conversión, retención)
• Calidad medida por defectos en producción
• Fiabilidad del sistema (uptime, latencia)

Activity (actividad)

Qué captura: El volumen de trabajo observable: commits, PRs, code reviews, documentación.

Precaución fundamental: La actividad es la dimensión más peligrosa de medir aisladamente. Medir commits o PRs como indicador de productividad lleva directamente a la inflación de métricas: commits más pequeños y más frecuentes que no aportan más valor.

Uso correcto: Como contexto para las otras dimensiones, nunca como métrica primaria.

Communication and collaboration (comunicación y colaboración)

Qué captura: Cómo trabaja el equipo en conjunto. Calidad del code review, frecuencia de pair programming, participación en decisiones técnicas.

Cómo medirla:

• Tiempo medio de respuesta a code reviews
• Distribución del conocimiento (cuántas personas pueden trabajar en cada componente)
• Calidad de la documentación técnica

Efficiency and flow (eficiencia y flujo)

Qué captura: La capacidad de completar trabajo sin interrupciones innecesarias. Tiempo en estado de flow, ratio de trabajo planificado vs interrupciones.

Cómo medirla:

• Porcentaje de trabajo planificado vs reactivo
• Número de cambios de contexto por día/semana
• Tiempo medio para completar una historia de usuario

Qué NO medir (y por qué)

Líneas de código

Es la métrica más intuitiva y la más destructiva. Un developer que arregla un bug eliminando 500 líneas produce más valor que uno que añade 2.000 líneas de código mediocre. Medir líneas de código incentiva la verbosidad, no la calidad.

Número de commits

Similar a las líneas de código. Medir commits incentiva commits más pequeños y frecuentes, lo que no tiene correlación con productividad real. Además, con herramientas de IA generando código, el número de commits es aún menos significativo.

Horas trabajadas

Sentarse frente al ordenador 12 horas no indica productividad. Indica presencia. Un developer que trabaja 6 horas enfocadas y produce código de calidad es más productivo que uno que trabaja 10 horas con interrupciones constantes.

Velocidad de sprint en aislamiento

Los story points son una herramienta de planificación interna del equipo, no una métrica de productividad. Comparar la velocidad entre equipos es particularmente absurdo: cada equipo calibra los story points de forma diferente.

Métricas individuales de actividad

Crear rankings de “quién hace más commits” o “quién cierra más tickets” destruye la colaboración y favorece el trabajo individual en detrimento del trabajo en equipo.

Implementación práctica: por dónde empezar

Fase 1: Establece la línea base (2-4 semanas)

Antes de intentar mejorar nada, necesitas saber dónde estás.

Acciones:

1. Implementa el tracking de las 4 métricas DORA principales. La mayoría de plataformas CI/CD ya recopilan los datos necesarios.
2. Realiza una encuesta de satisfacción del equipo (puede ser tan simple como 5 preguntas en un formulario).
3. Documenta tu proceso actual de entrega sin intentar cambiarlo.

Resultado: Un snapshot de tu rendimiento actual que servirá como referencia.

Fase 2: Identifica cuellos de botella (2-4 semanas)

Con la línea base establecida, analiza dónde están los problemas.

Preguntas clave:

• ¿Tu lead time es largo porque el code review tarda mucho, porque los tests son lentos, o porque solo desplegáis en ventanas específicas?
• ¿Tu change failure rate es alta porque no hay tests, porque los tests son malos, o porque los despliegues son demasiado grandes?
• ¿Tu frecuencia de despliegue es baja por limitaciones técnicas o por cultura (“solo desplegamos los jueves”)?

Fase 3: Implementa mejoras focalizadas (trimestral)

Cada trimestre, elige 1-2 métricas para mejorar. No intentes mejorar todo a la vez.

Ejemplo:

• Problema: Lead time de 2 semanas. El desglose muestra que 8 días se pierden en espera de code review.
• Acción: Implementar una política de “code review en menos de 4 horas hábiles” con rotación de reviewers.
• Resultado esperado: Reducir lead time a 1 semana.

Fase 4: Revisa y ajusta (ongoing)

Revisa las métricas mensualmente. El objetivo no es alcanzar “elite” en todo, sino mejorar continuamente desde donde estás.

Importante: Las métricas DORA están correlacionadas. Mejorar una suele mejorar las demás. Pero forzar una métrica aisladamente puede degradar las otras. Si reduces el lead time eliminando code reviews, tu change failure rate subirá.

La trampa de las métricas: la ley de Goodhart

“Cuando una medida se convierte en objetivo, deja de ser una buena medida.”

Este es el riesgo más grande de cualquier programa de métricas. En el momento en que un developer sabe que se le evalúa por frecuencia de despliegue, optimizará para desplegar más frecuentemente, no para entregar más valor.

Cómo evitarlo:

• Nunca uses métricas individuales para evaluación de rendimiento. Las métricas DORA son métricas de equipo y de sistema, no de personas.
• Mide constelaciones, no métricas individuales. Las métricas DORA funcionan porque se equilibran entre sí. Medir solo deployment frequency sin change failure rate incentiva despliegues irresponsables.
• Usa las métricas para entender, no para juzgar. Las métricas son conversación starters, no veredictos. “Nuestro lead time aumentó un 30% este mes: ¿qué pasó?” es una pregunta útil. “Tu lead time es alto: mejora” es una orden inútil.

Cómo presentar métricas a stakeholders no técnicos

Para el CEO

El CEO necesita saber si la inversión en ingeniería está generando resultados. No necesita entender qué es un lead time.

Traduce las métricas DORA a lenguaje de negocio:

• “Deployment frequency” se convierte en “capacidad de responder rápidamente a las necesidades del mercado”
• “Lead time” se convierte en “tiempo desde que decidimos algo hasta que los usuarios lo tienen”
• “Change failure rate” se convierte en “fiabilidad del producto”
• “Recovery time” se convierte en “cuánto tiempo están los usuarios sin servicio cuando hay un problema”

Formato recomendado: Un dashboard mensual con 4-5 métricas que incluya tendencias (mejorando, estable, empeorando) y las 2-3 acciones que el equipo está tomando para mejorar.

Para el board/inversores

Los inversores quieren saber si el equipo técnico es competente y si la inversión en tecnología está bien empleada.

Métricas a presentar trimestralmente:

• Velocidad de entrega (features entregadas vs planificadas)
• Fiabilidad del sistema (uptime, incidentes mayores)
• Eficiencia del equipo (coste por feature entregada, tendencia)
• Salud del equipo (retención, satisfacción)

No presentes: Métricas DORA en crudo. El board no sabe qué significa “lead time for changes de 3 días” ni tiene contexto para evaluarlo. Traduce siempre a impacto de negocio.

Para el equipo técnico

El equipo técnico necesita métricas actionables que les ayuden a mejorar su trabajo diario.

Formato recomendado: Dashboard en tiempo real accesible para todo el equipo. Sin rankings individuales. Con tendencias históricas para que el equipo vea su progreso. Revisión mensual en una reunión de equipo donde se discuten los cuellos de botella y se deciden acciones concretas.

Métricas específicas para equipos que usan IA

El informe DORA 2025 dedicó todo su análisis a la adopción de IA en el desarrollo de software. Los hallazgos principales:

• Los equipos que usan herramientas de IA muestran mayor throughput (más código producido, lead times más cortos).
• Pero también muestran mayor inestabilidad (change failure rates más altos).
• La calidad percibida del código generado por IA varía significativamente según cómo se use.

Métricas adicionales para equipos con IA:

• AI-assisted change failure rate: Tasa de fallos específica de cambios generados o asistidos por IA vs cambios puramente humanos
• Review effectiveness on AI code: Cuántos bugs se detectan en code review de código generado por IA
• Rework rate on AI-generated code: Con qué frecuencia hay que reescribir código generado por IA

Errores habituales al iniciar un programa de métricas

Empezar con demasiadas métricas

La tentación es medir todo desde el primer día. Resiste. Empieza con las cuatro métricas DORA. Añade dimensiones de SPACE una a una después de establecer la línea base de DORA. Un equipo ahogado en dashboards de métricas las ignorará todas.

No tener línea base antes de fijar objetivos

Fijar objetivos de mejora antes de saber dónde estás es adivinar, no planificar. Dedica el primer mes solo a medir sin intentar mejorar. La línea base probablemente revelará sorpresas que cambien tus prioridades.

Medir sin actuar

Los dashboards no son una estrategia. Si recoges métricas pero nunca las discutes, nunca identificas cuellos de botella y nunca implementas mejoras, el programa de métricas es overhead sin valor. Cada medición debería conectar con una decisión o acción.

Cambiar múltiples variables a la vez

Si implementas automatización de code review, reduces el tamaño de los despliegues y añades más tests en el mismo trimestre, no sabrás qué cambio mejoró (o empeoró) tus métricas. Cambia una cosa a la vez para poder atribuir causa y efecto.

Abandonar demasiado pronto

Las mejoras significativas en métricas DORA típicamente tardan 2-3 trimestres en materializarse. Si esperas cambios dramáticos en el primer mes, te decepcionarás y podrías abandonar el programa antes de que aporte valor.

Conclusión

Las métricas de ingeniería no son un fin en sí mismas. Son una herramienta para tener conversaciones informadas sobre cómo mejorar la forma en que tu equipo entrega software.

Empieza con las cuatro métricas DORA como base. Añade dimensiones del framework SPACE para una visión más completa. Y sobre todo, resiste la tentación de usar las métricas como herramienta de control individual. Las métricas que destruyen la confianza del equipo destruyen más valor del que cualquier optimización pueda crear.

El objetivo no es tener las mejores métricas. Es tener un equipo que entrega software de calidad de forma predecible y sostenible. Las métricas son el mapa, no el destino.

¿Quieres implementar métricas de ingeniería en tu equipo sin caer en las trampas habituales?

En una auditoría gratuita de 45 minutos podemos ayudarte a:

• Evaluar tu rendimiento actual de entrega de software
• Identificar los cuellos de botella principales en tu proceso
• Diseñar un programa de métricas adaptado a tu equipo y fase
• Establecer objetivos realistas de mejora trimestral

Solicitar auditoría gratuita