Métricas DORA explicadas: las cinco métricas actuales, cómo medirlas y errores comunes

Por Felipe Traina · 28/9/2026 · 6 min · dora, devops, liderazgo-tecnico, metricas

Si tu equipo aprendió las "cuatro métricas DORA" hace unos años, hay una actualización importante: DORA hoy usa cinco métricas de desempeño en la entrega de software, y una de las clásicas, el MTTR, fue redefinida. La guía oficial, actualizada en enero de 2026, las agrupa en dos factores: throughput (cuántos cambios pasan por el sistema) e instability (qué tan bien salen esos cambios).

DORA es un programa de investigación que hoy opera Google Cloud, y sus métricas se volvieron un estándar de la industria. Precisamente por eso, también son de las métricas más malinterpretadas y peor usadas. Esta guía repasa qué son hoy, cómo cambiaron y cómo usarlas para mejorar, no para armar rankings.

Las cinco métricas actuales

Throughput

Métrica Definición de DORA
Change lead time Tiempo que tarda un cambio desde que se commitea en control de versiones hasta que está desplegado en producción
Deployment frequency Cantidad de despliegues en un período, o tiempo entre despliegues
Failed deployment recovery time Tiempo para recuperarse de un despliegue que falla y requiere intervención inmediata

Instability

Métrica Definición de DORA
Change fail rate Proporción de despliegues que requieren intervención inmediata (típicamente un rollback o un hotfix)
Deployment rework rate Proporción de despliegues no planificados que ocurren como consecuencia de un incidente en producción

Un detalle que suele sorprender: en el modelo actual, el tiempo de recuperación de despliegues fallidos aparece dentro del grupo de throughput, no de estabilidad.

Cómo llegamos de cuatro a cinco

La página de historia de DORA resume la evolución:

Si tus dashboards todavía muestran "MTTR" calculado sobre todos los incidentes, no estás midiendo lo mismo que DORA.

Velocidad y estabilidad no son un trade-off

El hallazgo central que DORA repite desde hace años es que velocidad y estabilidad no compiten: para la mayoría de los equipos, las métricas están correlacionadas. Los equipos de mejor desempeño salen bien en las cinco y los de peor desempeño, mal en las cinco. La guía cita a Dave Farley (Modern Software Engineering, 2021): en el largo plazo, el verdadero trade-off es entre "better software faster" y "worse software slower".

En la práctica, esto desarma un argumento frecuente: "si desplegamos más seguido, vamos a romper más cosas". Los datos de DORA muestran que, en la mayoría de los equipos, ambas cosas van juntas. Y su recomendación para mejorar las dos a la vez es trabajar con cambios más chicos, no saltearse controles.

Cómo medirlas sin un proyecto de seis meses

DORA recomienda aplicar las métricas por aplicación o servicio, no promediadas para toda la organización, porque el contexto de cada sistema es distinto. También advierte que construir integraciones precisas con todos tus sistemas puede no valer la inversión inicial. Se puede empezar con conversaciones, con el DORA Quick Check o con herramientas existentes.

Si ya registrás tus despliegues en una tabla, una primera aproximación es simple. Un ejemplo ilustrativo en SQL (PostgreSQL), asumiendo una tabla deploys con una fila por despliegue:

-- deploys(servicio, desplegado_en, primer_commit_en, fallido, recuperado_en, no_planificado)
SELECT
  servicio,
  count(*)                                                     AS despliegues_30d,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY desplegado_en - primer_commit_en)                 AS lead_time_mediana,
  avg(CASE WHEN fallido THEN 1 ELSE 0 END)                     AS change_fail_rate,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY recuperado_en - desplegado_en)
    FILTER (WHERE fallido)                                     AS recuperacion_mediana,
  avg(CASE WHEN no_planificado THEN 1 ELSE 0 END)              AS rework_rate
FROM deploys
WHERE desplegado_en >= now() - interval '30 days'
GROUP BY servicio;

Lo difícil no es la consulta, sino ponerse de acuerdo en las definiciones:

Anotá esas definiciones y mantenelas estables. Un cambio de definición puede "mejorar" una métrica sin que haya mejorado nada.

Errores comunes (según la propia DORA)

La guía oficial lista estas trampas:

  1. Convertir las métricas en metas. Frases como "todas las aplicaciones deben desplegar varias veces por día a fin de año" invitan a manipular los números (la ley de Goodhart).
  2. Una métrica para gobernarlas a todas. Hay que mirar varias, incluidas algunas con tensión sana entre sí.
  3. Usar la industria como escudo. Por ejemplo, decir que la regulación impide cambiar cualquier cosa.
  4. Comparaciones dispares. Comparar una app móvil con un mainframe no tiene sentido.
  5. Ownership en silos. Las cinco métricas deberían ser compartidas por desarrollo, operaciones y release, no repartidas por equipo.
  6. Competir. El objetivo es mejorar respecto de uno mismo, no ganarle a otro equipo.
  7. Medir en lugar de mejorar. Invertir meses en dashboards antes de cambiar una sola práctica.

Cómo mejorar: lotes más chicos y un ciclo corto

La recomendación más concreta de DORA es reducir el tamaño de los cambios. Los cambios chicos son más fáciles de entender, de mover por el proceso de entrega y de revertir si fallan. El proceso sugerido para un equipo multifuncional:

  1. Establecer una línea base con el DORA Quick Check.
  2. Conversar sobre los puntos de fricción del proceso de entrega (mapear el flujo ayuda).
  3. Comprometerse a mejorar el cuello de botella más importante.
  4. Convertir ese compromiso en un plan, con indicadores adelantados (por ejemplo, cuánto tardan las code reviews).
  5. Hacer el trabajo.
  6. Revisar el progreso y repetir.

Qué hacer con esto

¿Cuál de las cinco métricas te costaría más medir hoy con los datos que ya tenés?

Lecturas relacionadas

Fuentes

← Volver al blog