Metricas de productividad de ingeniería: framework DORA y SPACE explicado

Un VP of Engineering de una scale-up regional fintech con 90 ingenieros heredo, al asumir el cargo, un dashboard de productividad que llevaba dos anios en operación. Cinco métricas en el dashboard: líneas de código por desarrollador por semana, story points completados por sprint, tickets cerrados por persona, horas registradas en el time tracker interno y porcentaje de cobertura de tests. Las cinco se publicaban semanalmente al Engineering Leadership Team. Los managers comparaban entre equipos. Los ingenieros lo sabian. A los nueve meses de operación del dashboard, la rotación de Staff Engineers de la compañía llego al 38% anualizado, el code review promedio demoraba 52 horas, el código se inflaba con duplicaciones para subir las métricas y los dos arquitectos más senior renunciaron el mismo trimestre. El dashboard medio actividad, no productividad. La compañía pago el costo durante todo el anio siguiente.

La pregunta de cómo medir productividad de ingeniería es una de las más mal respondidas en la industria. Cualquiera con experiencia de más de una decada en la disciplina ha visto al menos cinco compañías intentar resolverla con métricas individualistas (líneas de código, horas, tickets) y todas terminar con el mismo resultado: rotación alta, deuda técnica acumulada, manipulación silenciosa de la métrica y desconfianza profunda entre managers e ingenieros. Felizmente, dos investigaciones empiricamente solidas resolvieron el problema en la última decada y entregaron los frameworks que hoy usan los equipos de ingeniería de elite a nivel global: DORA (DevOps Research and Assessment, hoy parte de Google Cloud) y SPACE (publicado por investigadoras de Microsoft Research, GitHub y la Universidad de Victoria en ACM Queue). En 2023 se sumo un tercer marco complementario, DevEx, que cubre la dimensión humana de feedback loops, cognitive load y flow.

Este reporte explica los tres frameworks, sus benchmarks, sus modos de uso correcto y sus fallas tipicas. Tres mil quinientas palabras escritas para que el lector salga con un plan ejecutable. No es una introducción académica: es una guía operacional para CTOs y VPs Engineering que necesitan instrumentar métricas DORA y SPACE en su organización sin destruir lo que ya funciona.

1. Por qué medir productividad de ingeniería es difícil (y por qué no es líneas de código)

La productividad de ingeniería es estructuralmente difícil de medir por cinco razones que no aplican a otras disciplinas como ventas, soporte o producción industrial. Primero, el output de ingeniería es código, y el código no es comparable entre tareas: 50 líneas de código que resuelven un problema arquitectonico complejo valen más que 2.000 líneas de boilerplate generadas para CRUD trivial. Segundo, el trabajo de ingeniería es colaborativo por estructura: ninguna feature productiva sale del computador de una sola persona, todo pasa por Pull Request review, integración, QA y deploy. Tercero, la productividad real solo se mide en outcomes (impacto del código en negocio, estabilidad del servicio, velocidad de entrega), no en activity (cuanto se tipea por hora). Cuarto, el código es un activo de largo plazo: una decisión arquitectonica tomada en un sprint puede afectar la velocidad del equipo durante anios. Quinto, el trabajo de ingeniería depende fuertemente de contexto y herramientas: un Senior con un build local rápido y un CI verde produce el triple que el mismo Senior con un build de 22 minutos.

Por estas cinco razones, las métricas individuales y de activity (líneas de código, horas, tickets, story points por persona) son uniformemente malas para evaluar productividad. Lo único que esas métricas miden con precisión es la voluntad del equipo de cooperar con la métrica, no la productividad real. La industria llevo veinte anios chocando con esto antes de que la investigación empirica produjera dos marcos validos. Ningun framework de productividad serio se basa en métricas individuales. Todos se basan en métricas de sistema (equipo + servicio + flujo) y combinan datos cuantitativos con percepción del equipo.

2. El problema de las vanity metrics y cómo destruyen cultura de equipo

Vanity metric, en lenguaje de medición de productividad, es toda métrica que se ve bien en un dashboard pero no predice ningun outcome relevante. Las cinco más comunes en equipos de ingeniería son: líneas de código escritas, story points completados por persona, tickets cerrados por persona, horas registradas en el time tracker y porcentaje de cobertura de tests. Las cinco comparten una caracteristica peligrosa: son fáciles de medir, se ven serias en una presentación y son completamente manipulables por el equipo. La ley de Goodhart describe exactamente este fenomeno: cuando una medida se convierte en objetivo, deja de ser una buena medida.

El daño real de las vanity metrics es cultural, no técnico. Cuando un equipo de ingeniería descubre que se le evalua por líneas de código, las tres cosas que más hace un ingeniero senior dejan de ocurrir: refactor agresivo, eliminación de código muerto y abstracciones que reducen duplicación. Esas tres prácticas restan líneas de código. Penalizar refactor en un sistema vivo es exactamente lo opuesto a lo que la compañía necesita. Algo similar ocurre con story points: si el dashboard muestra story points por persona, los ingenieros senior dejan de hacer pair programming, dejan de mentorear y empiezan a tomar tickets fáciles para inflar el número. La métrica equivocada no solo es inútil: penaliza activamente las prácticas de los equipos elite. Cinco anios después de instalar una vanity metric, el equipo es estructuralmente peor que cuando no median nada.

3. DORA: las 4 métricas que mide Google Cloud DORA Research

DORA, originalmente DevOps Research and Assessment, es un grupo de investigación fundado en 2014 por Nicole Forsgren, Jez Humble y Gene Kim, adquirido por Google Cloud en 2018 y responsable del Accelerate State of DevOps Report que se pública anualmente. Más de diez anios de research empirico sobre decenas de miles de desarrolladores aislaron cuatro métricas que correlacionan de manera estadisticamente significativa con desempenio organizacional y comercial. Esas cuatro métricas son la única respuesta empirica que la industria tiene a la pregunta de productividad de ingeniería a nivel de delivery.

Deployment frequency

Con qué frecuencia el equipo despliega cambios a producción. Es la métrica de velocidad pura. Mide el output del sistema en cantidad de releases por unidad de tiempo. La hipotesis empirica que valida DORA es que equipos que despliegan con frecuencia tienen menos riesgo por release (cambios más pequenios) y mejor capacidad de respuesta al mercado. La medición se hace por equipo o por servicio, no por individuo, capturando el evento de release exitoso desde el sistema de CI/CD (GitHub Actions, GitLab CI, CircleCI, Jenkins, Argo CD o similar). Equipos elite hacen deployment on-demand: multiples veces por día sin fricción.

Lead time for changes

Tiempo desde que un cambio se commitea al repositorio hasta que llega a producción. Es la métrica de eficiencia del flujo. Mide la fricción total acumulada del sistema de delivery: code review, CI, QA, gates manuales, ambientes de staging, deploys orquestados. Es la métrica más reveladora porque agrega visibilidad sobre todo el sistema, no solo sobre la actividad de un equipo. Equipos elite mueven cambios desde commit a producción en menos de un día. Equipos low operan con leads times mayores a un mes, lo cual significa, en la práctica, que la compañía no es ágil sin importar lo que diga su sitio web.

Change failure rate

Porcentaje de despliegues a producción que requieren rollback inmediato, hotfix urgente o causan incidente cliente-impactante en las cuatro horas siguientes. Es la métrica de estabilidad. Equilibra a deployment frequency: una compañía que despliega 100 veces por mes con 8% de failure rate es objetivamente mejor que una que despliega 4 veces por mes con 0%. Definir failure operacionalmente y por adelantado es crucial. Equipos elite tienen change failure rate entre 0% y 15% manteniendo deployment on-demand, lo cual es matematicamente exigente y solo se logra con buena instrumentación y cultura blameless.

Mean time to recover (MTTR)

Tiempo promedio para restaurar el servicio cuando ocurre un incidente cliente-impactante. Es la métrica de resiliencia. La hipotesis empirica de DORA es que equipos resilientes recuperan rápido, no evitan errores completamente. La diferencia entre un equipo elite y uno low en MTTR es dramatica: menos de una hora versus más de una semana. La medición se hace integrando el sistema de incidentes (PagerDuty, Opsgenie, Statuspage) con la captura de eventos. Equipos con MTTR alto tipicamente tienen runbooks obsoletos, falta de observabilidad y poca cultura de on-call disciplinado.

4. Cómo medir cada DORA metric: instrumentación práctica

Instrumentar DORA en la práctica requiere conectar tres sistemas que la compañía probablemente ya tiene: el repositorio (GitHub o GitLab), el sistema de CI/CD (GitHub Actions, GitLab CI, CircleCI, Jenkins, Buildkite, Argo CD) y el sistema de incidentes (PagerDuty, Opsgenie). El equipo no debe completar formularios manuales para alimentar la métrica: si lo hace, la métrica se ensucia en seis semanas y se abandona en seis meses. La instrumentación debe ser automática desde sistemas que ya existen.

El detalle por métrica es el siguiente. Deployment frequency se captura registrando cada evento de release exitoso a producción desde el pipeline CI/CD, con timestamp, servicio, hash del commit, autor y resultado. Lead time for changes se calcula desde el timestamp del primer commit del Pull Request mergeado hasta el timestamp del deploy productivo de ese commit; requiere correlacionar repo y CI. Change failure rate se calcula sobre el total de deployments del periodo, marcando como failure los que aparecen en el sistema de incidentes en las cuatro horas siguientes al deploy o que generan rollback automático. MTTR se mide desde el timestamp de apertura del incidente cliente-impactante hasta el timestamp de cierre, considerando solo incidentes con impacto productivo real (no incidentes internos triviales).

Una vez instrumentadas las cuatro, el dashboard debe mostrarlas siempre juntas y siempre por equipo, nunca por individuo. Publicar al Engineering Leadership Team agregado semanal, dejar el detalle por equipo accesible solo a sus managers. Tres meses de datos consistentes son suficientes para tener una línea base y empezar a comparar con benchmarks. Nunca usar las métricas para evaluación individual de desempenio: hacerlo destruye la métrica en menos de un trimestre.

5. SPACE: el framework de Microsoft Research que complementa a DORA

SPACE fue publicado en marzo de 2021 en la revista ACM Queue por Nicole Forsgren (la misma autora original de DORA), Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck y Jenna Butler, sintetizando trabajo de Microsoft Research, GitHub y la Universidad de Victoria. El paper original esta disponible en ACM Queue y es lectura obligatoria para cualquier VP of Engineering serio. La intención explicita de SPACE fue cubrir la dimensión que DORA dejaba afuera: la senial humana detrás de los outcomes de delivery.

SPACE propone cinco dimensiones para medir productividad. La regla central del framework, repetida hasta el cansancio por las autoras, es que nunca debe usarse una sola dimensión de SPACE: hacerlo invariablemente convierte la dimensión elegida en vanity metric. La regla operacional es combinar al menos tres dimensiones simultaneas. Las cinco son las siguientes.

Satisfaction (S)

Satisfacción del desarrollador con su trabajo, su equipo, sus herramientas y la organización. Se mide con surveys recurrentes, tipicamente trimestrales, usando preguntas Likert validadas (eNPS, intención de permanecer, orgullo, recomendación). Es la dimensión más predictiva de rotación futura: un equipo con satisfacción baja perdera Senior y Staff en los próximos dos a cuatro trimestres con probabilidad alta. Ignorar Satisfaction es la causa número uno por la que compañías que solo miden DORA pierden talento clave a los dieciocho meses.

Performance (P)

Resultado del trabajo medido en outcome de negocio: features liberadas, cumplimiento de SLOs, satisfacción del cliente con la calidad del producto, defectos en producción, performance de tests automatizados. Es la dimensión de output efectivo, no de activity. Aqui caben varias métricas DORA (lead time, change failure rate) que pueden compartirse entre frameworks. La regla es medir Performance por equipo y servicio, nunca por individuo aislado.

Activity (A)

Acciones de desarrollo: cantidad de Pull Requests abiertos, cantidad de commits, cantidad de revisiones realizadas, frecuencia de despliegues. Es la dimensión más peligrosa del framework si se usa aislada porque es la más parecida a las vanity metrics tradicionales. Se usa correctamente cuando se combina con Satisfaction y Performance: por ejemplo, Activity bajando mientras Satisfaction sube puede indicar exhaustion previa; Activity subiendo mientras Performance baja puede indicar manipulación de la métrica.

Communication and collaboration (C)

Cualidad de la comunicación y colaboración del equipo: claridad de objetivos, velocidad y calidad de Pull Request reviews, calidad de la documentación compartida, eficiencia de reuniones, calidad del onboarding de nuevos miembros. Se mide combinando datos cuantitativos (tiempo medio de PR review, tiempo medio entre commit y primer comentario de review, número de iteraciones por PR) con survey de percepción del equipo. Es la dimensión que más predice la velocidad efectiva del equipo a mediano plazo.

Efficiency and flow (E)

Eficiencia y estado de flujo del desarrollador. Mide cuantas horas de uninterrupted focus tiene el desarrollador en una semana tipica, cuantas veces fue interrumpido en su trabajo profundo, cuanta fricción administrativa enfrenta para hacer su trabajo (build local lento, CI lento, ambientes inestables, gates manuales arbitrarios). Tres horas o menos de uninterrupted focus diario es la senial roja: el equipo no está en flow y la productividad real está capada.

6. DORA vs SPACE: cuándo usar cuál y cómo combinarlas

DORA y SPACE no son frameworks competidores sino complementarios. Cada uno cubre una dimensión que el otro deja afuera. DORA mide los outcomes objetivos de delivery; SPACE cubre la senial humana detrás de esos outcomes. La pregunta correcta no es cuál usar sino cómo combinarlas. Las compañías que aplican uno solo y no el otro caen en uno de dos modos de falla bien documentados: solo DORA termina con un equipo rápido pero quemado y con rotación alta; solo SPACE termina con un equipo contento pero con velocidad de delivery por debajo del competidor.

La regla práctica de combinación, validada en implementaciones reales con clientes B2B en scale-ups regionales, es la siguiente: medir simultaneamente las cuatro métricas DORA y al menos tres dimensiones de SPACE (idealmente Satisfaction, Communication y Efficiency, dejando Performance solapado con DORA y Activity como complemento opcional). En total, entre siete y ocho indicadores. Más que eso satura al equipo y diluye el foco; menos que eso deja angulos ciegos. El stack mínimo viable se ve así.

7. Benchmarks de elite, high, medium, low performers DORA

Los benchmarks vigentes provienen del DORA Accelerate State of DevOps Report 2023, último report publicado al momento de redacción. La distancia entre los cuatro clusters es tan grande que la primera vez que un equipo ve donde esta en la tabla suele tomar dos semanas para asimilar el dato. La diferencia entre un equipo elite y uno low en lead time for changes es 2.604 veces; en deployment frequency es 973 veces; en MTTR es 2.293 veces. Esos números no son tipograficos, salen del estudio empirico.

8. DevEx: las métricas que importan para retención de Staff Engineers

El framework DevEx (Developer Experience) fue publicado en mayo de 2023 en ACM Queue por Abi Noda, Margaret-Anne Storey, Nicole Forsgren y Michaela Greiler, disponible en ACM Queue. Es la sintesis más reciente del trabajo de las autoras de SPACE y DORA y la respuesta empirica a la pregunta de por qué los Staff Engineers eligen un equipo y no otro. La hipotesis central es que la retención de los perfiles más senior no depende del sueldo marginal sino de la calidad de la experiencia técnica del día a día. DevEx propone tres dimensiones medibles.

Feedback loops

Qué tan rápido el desarrollador recibe senial sobre su trabajo. Incluye tiempo de feedback del test unitario al ejecutarlo, tiempo de feedback del CI completo, tiempo de feedback del Pull Request review, tiempo de feedback del despliegue a staging. Equipos donde el feedback total es de segundos a minutos generan engagement profundo; equipos donde el feedback total es de horas a días generan frustración y bajan la velocidad real al menos 30%. Es la dimensión más tangible y la que más rápido mejora con inversión focalizada en CI/CD.

Cognitive load

Cuánta complejidad innecesaria carga el desarrollador para hacer su trabajo. Incluye complejidad del código (deuda técnica), complejidad de la infraestructura, complejidad de los procesos administrativos, complejidad de la documentación ausente. Se mide con survey de percepción: la pregunta validada es "para hacer mi trabajo, debo recordar demasiado contexto que no se relaciona directamente con el problema que estoy resolviendo". Cuando esa pregunta tiene puntaje alto, la productividad real esta capada sin importar cuántas horas trabaje el equipo.

Flow state

Cuánto tiempo de foco profundo no interrumpido tiene el desarrollador en una semana tipica. Es la dimensión más relacionada con productividad cognitiva real: el flow es el estado mental en el que el desarrollador resuelve problemas complejos. Tres horas o menos de uninterrupted focus diario es senial roja; menos de una hora es senial crítica. Las causas tipicas son exceso de reuniones, exceso de interrupciones de Slack, expectativa cultural de respuesta inmediata. Equipos donde el flow está capado pierden a sus mejores ingenieros antes que el resto.

DevEx es la capa explicativa de DORA y SPACE. Cuando DORA muestra que el lead time es alto, DevEx explica si la causa es feedback lento, cognitive load excesiva o falta de flow. Cuando SPACE muestra que Satisfaction está baja, DevEx explica qué está detrás. Para compañías serias sobre retener Staff Engineers, DevEx es el framework más operacional de los tres.

9. Errores comunes al implementar métricas de productividad

Despues de auditar implementaciones de medición de productividad en compañías de Serie A hasta corporativos digitales, los siete errores siguientes se repiten con claridad. Cinco son errores de diseño (que métrica usar). Dos son errores de cultura (cómo usar la métrica que tenes).

Error 1: usar métricas individuales en trabajo colaborativo

Lineas de código por persona, story points por persona, tickets por persona. Todo lo que se pública con nombre del desarrollador al lado destruye cooperación en menos de un trimestre. Los Senior dejan de hacer code review (no suma a su métrica), dejan de mentorear (no suma) y dejan de hacer pair programming (divide la métrica entre dos personas). Las métricas siempre por equipo o servicio, nunca por individuo aislado.

Error 2: medir solo deployment frequency sin las otras tres DORA

El antipatron más comun en compañía que recien adopta DORA. El equipo optimiza para deployment frequency única y termina deplegando cambios cosmeticos triviales, fracturando features artificialmente, y sacrificando estabilidad en silencio. Las cuatro métricas DORA están diseñadas para usarse juntas: cada una corrige el sesgo de las otras. Nunca publicar deployment frequency sin lead time, change failure rate y MTTR al lado.

Error 3: usar una sola dimensión de SPACE

Equivalente del error anterior pero del lado humano. Compañía que solo mide Satisfaction termina con un equipo contento pero lento; compañía que solo mide Activity (PRs por persona, commits por persona) cae en la trampa de las vanity metrics tradicionales. La regla es siempre tres o más dimensiones simultaneas, según publicaron las autoras del paper original.

Error 4: usar las métricas para evaluación individual de desempenio

El error que destruye la implementación más rápido. Si el manager usa los datos del dashboard para evaluar desempenio individual, el equipo lo descubre en una semana y empieza a manipular los datos. Documentar por escrito, en la primera reunion del proyecto y firmada por el CTO y RRHH, que las métricas nunca se usaran para evaluación individual. Sin esa promesa documentada, el proyecto fracasa.

Error 5: publicar ranking de equipos al management team

Tentación natural del management pero antipatron operacional. Publicar ranking de equipos crea competencia interna toxica, incentiva a los equipos a no compartir aprendizajes con otros equipos y, peor aún, incentiva a manipular las métricas para no quedar último. Publicar agregado organizacional al management; mantener detalle por equipo accesible solo a sus managers respectivos.

Error 6: instrumentar con formularios manuales en lugar de captura automática

Si el equipo debe completar formularios manuales para alimentar la métrica, en seis semanas los formularios están llenos de basura y en seis meses la implementación se abandona. La instrumentación debe ser automática desde sistemas que ya existen: CI/CD, repo, sistema de incidentes. Surveys de SPACE son la excepción (por su naturaleza requieren survey humana), pero deben ser anonimas, cortas y trimestrales, no semanales.

Error 7: tomar decisiones con menos de 90 días de baseline

Compañías que reciben los primeros datos del primer mes y empiezan a tomar decisiones críticas. Los primeros 30 a 60 días de baseline siempre tienen ruido: la instrumentación se está calibrando, los equipos se están acostumbrando, las definiciones operacionales se están estabilizando. La regla es esperar tres meses de datos consistentes antes de cualquier decisión irreversible. Reportes diagnosticos antes, decisiones después.

10. Roadmap 90 días para implementar DORA + SPACE en una compañía de 30-150 ingenieros

El roadmap siguiente es la sintesis operacional de implementaciones reales con equipos de tecnología de scale-ups B2B regionales. El plazo de 90 días es realista para llegar a baseline confiable; otros 90 días adicionales para llegar a uso productivo de las métricas en toma de decisiones. Empresas que prometen instrumentación completa en cuatro semanas o están vendiendo humo o están instalando dashboards sin baseline real detrás.

El plazo se duplica si la compañía no tiene CI/CD maduro o si no existe un Engineering Manager con tiempo dedicado al proyecto. En casos extremos (compañía con releases manuales, sin pipeline automatizado, sin sistema de incidentes formal) el plazo realista es de seis a nueve meses. Antes de instrumentar DORA conviene tener CI/CD funcionando: instrumentar sobre un proceso roto solo mide cuán roto está.

El paso final, frecuentemente ignorado, es repetir el ciclo cada trimestre. DORA y SPACE no son un proyecto único de instalación sino una capacidad organizacional permanente. Los benchmarks se mueven (lo que era elite en 2020 hoy es solo high), las herramientas evolucionan (AI assistants impactan feedback loops), el equipo cambia. Compañías serias revisan los siete indicadores cada trimestre con la misma rigurosidad con la que revisan los OKRs de producto. Las que tratan la medición como proyecto único abandonan el dashboard en doce meses; las que la tratan como capacidad permanente son las que llegan a elite y se mantienen.

11. FAQ: 10 preguntas que recibimos de CTOs y VPs Engineering