Metricas de productividad de ingenieria: 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 operacion. Cinco metricas en el dashboard: lineas de codigo 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 operacion del dashboard, la rotacion de Staff Engineers de la compania llego al 38% anualizado, el code review promedio demoraba 52 horas, el codigo se inflaba con duplicaciones para subir las metricas y los dos arquitectos mas senior renunciaron el mismo trimestre. El dashboard medio actividad, no productividad. La compania pago el costo durante todo el anio siguiente.

La pregunta de como medir productividad de ingenieria es una de las mas mal respondidas en la industria. Cualquiera con experiencia de mas de una decada en la disciplina ha visto al menos cinco companias intentar resolverla con metricas individualistas (lineas de codigo, horas, tickets) y todas terminar con el mismo resultado: rotacion alta, deuda tecnica acumulada, manipulacion silenciosa de la metrica y desconfianza profunda entre managers e ingenieros. Felizmente, dos investigaciones empiricamente solidas resolvieron el problema en la ultima decada y entregaron los frameworks que hoy usan los equipos de ingenieria 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 dimension 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 introduccion academica: es una guia operacional para CTOs y VPs Engineering que necesitan instrumentar metricas DORA y SPACE en su organizacion sin destruir lo que ya funciona.

1. Por que medir productividad de ingenieria es dificil (y por que no es lineas de codigo)

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

Por estas cinco razones, las metricas individuales y de activity (lineas de codigo, horas, tickets, story points por persona) son uniformemente malas para evaluar productividad. Lo unico que esas metricas miden con precision es la voluntad del equipo de cooperar con la metrica, no la productividad real. La industria llevo veinte anios chocando con esto antes de que la investigacion empirica produjera dos marcos validos. Ningun framework de productividad serio se basa en metricas individuales. Todos se basan en metricas de sistema (equipo + servicio + flujo) y combinan datos cuantitativos con percepcion del equipo.

2. El problema de las vanity metrics y como destruyen cultura de equipo

Vanity metric, en lenguaje de medicion de productividad, es toda metrica que se ve bien en un dashboard pero no predice ningun outcome relevante. Las cinco mas comunes en equipos de ingenieria son: lineas de codigo 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 faciles de medir, se ven serias en una presentacion 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 dano real de las vanity metrics es cultural, no tecnico. Cuando un equipo de ingenieria descubre que se le evalua por lineas de codigo, las tres cosas que mas hace un ingeniero senior dejan de ocurrir: refactor agresivo, eliminacion de codigo muerto y abstracciones que reducen duplicacion. Esas tres practicas restan lineas de codigo. Penalizar refactor en un sistema vivo es exactamente lo opuesto a lo que la compania 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 faciles para inflar el numero. La metrica equivocada no solo es inutil: penaliza activamente las practicas de los equipos elite. Cinco anios despues de instalar una vanity metric, el equipo es estructuralmente peor que cuando no median nada.

3. DORA: las 4 metricas que mide Google Cloud DORA Research

DORA, originalmente DevOps Research and Assessment, es un grupo de investigacion 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 publica anualmente. Mas de diez anios de research empirico sobre decenas de miles de desarrolladores aislaron cuatro metricas que correlacionan de manera estadisticamente significativa con desempenio organizacional y comercial. Esas cuatro metricas son la unica respuesta empirica que la industria tiene a la pregunta de productividad de ingenieria a nivel de delivery.

Deployment frequency

Con que frecuencia el equipo despliega cambios a produccion. Es la metrica 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 mas pequenios) y mejor capacidad de respuesta al mercado. La medicion 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 dia sin friccion.

Lead time for changes

Tiempo desde que un cambio se commitea al repositorio hasta que llega a produccion. Es la metrica de eficiencia del flujo. Mide la friccion total acumulada del sistema de delivery: code review, CI, QA, gates manuales, ambientes de staging, deploys orquestados. Es la metrica mas reveladora porque agrega visibilidad sobre todo el sistema, no solo sobre la actividad de un equipo. Equipos elite mueven cambios desde commit a produccion en menos de un dia. Equipos low operan con leads times mayores a un mes, lo cual significa, en la practica, que la compania no es agil sin importar lo que diga su sitio web.

Change failure rate

Porcentaje de despliegues a produccion que requieren rollback inmediato, hotfix urgente o causan incidente cliente-impactante en las cuatro horas siguientes. Es la metrica de estabilidad. Equilibra a deployment frequency: una compania 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 instrumentacion y cultura blameless.

Mean time to recover (MTTR)

Tiempo promedio para restaurar el servicio cuando ocurre un incidente cliente-impactante. Es la metrica de resiliencia. La hipotesis empirica de DORA es que equipos resilientes recuperan rapido, no evitan errores completamente. La diferencia entre un equipo elite y uno low en MTTR es dramatica: menos de una hora versus mas de una semana. La medicion 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. Como medir cada DORA metric: instrumentacion practica

Instrumentar DORA en la practica requiere conectar tres sistemas que la compania 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 metrica: si lo hace, la metrica se ensucia en seis semanas y se abandona en seis meses. La instrumentacion debe ser automatica desde sistemas que ya existen.

El detalle por metrica es el siguiente. Deployment frequency se captura registrando cada evento de release exitoso a produccion 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 automatico. 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 linea base y empezar a comparar con benchmarks. Nunca usar las metricas para evaluacion individual de desempenio: hacerlo destruye la metrica 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 intencion explicita de SPACE fue cubrir la dimension que DORA dejaba afuera: la senial humana detras 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 dimension de SPACE: hacerlo invariablemente convierte la dimension elegida en vanity metric. La regla operacional es combinar al menos tres dimensiones simultaneas. Las cinco son las siguientes.

Satisfaction (S)

Satisfaccion del desarrollador con su trabajo, su equipo, sus herramientas y la organizacion. Se mide con surveys recurrentes, tipicamente trimestrales, usando preguntas Likert validadas (eNPS, intencion de permanecer, orgullo, recomendacion). Es la dimension mas predictiva de rotacion futura: un equipo con satisfaccion baja perdera Senior y Staff en los proximos dos a cuatro trimestres con probabilidad alta. Ignorar Satisfaction es la causa numero uno por la que companias 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, satisfaccion del cliente con la calidad del producto, defectos en produccion, performance de tests automatizados. Es la dimension de output efectivo, no de activity. Aqui caben varias metricas 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 dimension mas peligrosa del framework si se usa aislada porque es la mas 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 manipulacion de la metrica.

Communication and collaboration (C)

Cualidad de la comunicacion y colaboracion del equipo: claridad de objetivos, velocidad y calidad de Pull Request reviews, calidad de la documentacion 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, numero de iteraciones por PR) con survey de percepcion del equipo. Es la dimension que mas 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 friccion 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 esta en flow y la productividad real esta capada.

6. DORA vs SPACE: cuando usar cual y como combinarlas

DORA y SPACE no son frameworks competidores sino complementarios. Cada uno cubre una dimension que el otro deja afuera. DORA mide los outcomes objetivos de delivery; SPACE cubre la senial humana detras de esos outcomes. La pregunta correcta no es cual usar sino como combinarlas. Las companias que aplican uno solo y no el otro caen en uno de dos modos de falla bien documentados: solo DORA termina con un equipo rapido pero quemado y con rotacion alta; solo SPACE termina con un equipo contento pero con velocidad de delivery por debajo del competidor.

La regla practica de combinacion, validada en implementaciones reales con clientes B2B en scale-ups regionales, es la siguiente: medir simultaneamente las cuatro metricas 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. Mas que eso satura al equipo y diluye el foco; menos que eso deja angulos ciegos. El stack minimo viable se ve asi.

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

Los benchmarks vigentes provienen del DORA Accelerate State of DevOps Report 2023, ultimo report publicado al momento de redaccion. 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 numeros no son tipograficos, salen del estudio empirico.

8. DevEx: las metricas que importan para retencion 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 mas reciente del trabajo de las autoras de SPACE y DORA y la respuesta empirica a la pregunta de por que los Staff Engineers eligen un equipo y no otro. La hipotesis central es que la retencion de los perfiles mas senior no depende del sueldo marginal sino de la calidad de la experiencia tecnica del dia a dia. DevEx propone tres dimensiones medibles.

Feedback loops

Que tan rapido 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 dias generan frustracion y bajan la velocidad real al menos 30%. Es la dimension mas tangible y la que mas rapido mejora con inversion focalizada en CI/CD.

Cognitive load

Cuanta complejidad innecesaria carga el desarrollador para hacer su trabajo. Incluye complejidad del codigo (deuda tecnica), complejidad de la infraestructura, complejidad de los procesos administrativos, complejidad de la documentacion ausente. Se mide con survey de percepcion: 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 cuantas horas trabaje el equipo.

Flow state

Cuanto tiempo de foco profundo no interrumpido tiene el desarrollador en una semana tipica. Es la dimension mas 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 critica. Las causas tipicas son exceso de reuniones, exceso de interrupciones de Slack, expectativa cultural de respuesta inmediata. Equipos donde el flow esta 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 esta baja, DevEx explica que esta detras. Para companias serias sobre retener Staff Engineers, DevEx es el framework mas operacional de los tres.

9. Errores comunes al implementar metricas de productividad

Despues de auditar implementaciones de medicion de productividad en companias de Serie A hasta corporativos digitales, los siete errores siguientes se repiten con claridad. Cinco son errores de diseno (que metrica usar). Dos son errores de cultura (como usar la metrica que tenes).

Error 1: usar metricas individuales en trabajo colaborativo

Lineas de codigo por persona, story points por persona, tickets por persona. Todo lo que se publica con nombre del desarrollador al lado destruye cooperacion en menos de un trimestre. Los Senior dejan de hacer code review (no suma a su metrica), dejan de mentorear (no suma) y dejan de hacer pair programming (divide la metrica entre dos personas). Las metricas siempre por equipo o servicio, nunca por individuo aislado.

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

El antipatron mas comun en compania que recien adopta DORA. El equipo optimiza para deployment frequency unica y termina deplegando cambios cosmeticos triviales, fracturando features artificialmente, y sacrificando estabilidad en silencio. Las cuatro metricas DORA estan disenadas 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 dimension de SPACE

Equivalente del error anterior pero del lado humano. Compania que solo mide Satisfaction termina con un equipo contento pero lento; compania 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 mas dimensiones simultaneas, segun publicaron las autoras del paper original.

Error 4: usar las metricas para evaluacion individual de desempenio

El error que destruye la implementacion mas rapido. 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 metricas nunca se usaran para evaluacion individual. Sin esa promesa documentada, el proyecto fracasa.

Error 5: publicar ranking de equipos al management team

Tentacion 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 aun, incentiva a manipular las metricas para no quedar ultimo. 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 automatica

Si el equipo debe completar formularios manuales para alimentar la metrica, en seis semanas los formularios estan llenos de basura y en seis meses la implementacion se abandona. La instrumentacion debe ser automatica desde sistemas que ya existen: CI/CD, repo, sistema de incidentes. Surveys de SPACE son la excepcion (por su naturaleza requieren survey humana), pero deben ser anonimas, cortas y trimestrales, no semanales.

Error 7: tomar decisiones con menos de 90 dias de baseline

Companias que reciben los primeros datos del primer mes y empiezan a tomar decisiones criticas. Los primeros 30 a 60 dias de baseline siempre tienen ruido: la instrumentacion se esta calibrando, los equipos se estan acostumbrando, las definiciones operacionales se estan estabilizando. La regla es esperar tres meses de datos consistentes antes de cualquier decision irreversible. Reportes diagnosticos antes, decisiones despues.

10. Roadmap 90 dias para implementar DORA + SPACE en una compania de 30-150 ingenieros

El roadmap siguiente es la sintesis operacional de implementaciones reales con equipos de tecnologia de scale-ups B2B regionales. El plazo de 90 dias es realista para llegar a baseline confiable; otros 90 dias adicionales para llegar a uso productivo de las metricas en toma de decisiones. Empresas que prometen instrumentacion completa en cuatro semanas o estan vendiendo humo o estan instalando dashboards sin baseline real detras.

El plazo se duplica si la compania no tiene CI/CD maduro o si no existe un Engineering Manager con tiempo dedicado al proyecto. En casos extremos (compania 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 cuan roto esta.

El paso final, frecuentemente ignorado, es repetir el ciclo cada trimestre. DORA y SPACE no son un proyecto unico de instalacion 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. Companias serias revisan los siete indicadores cada trimestre con la misma rigurosidad con la que revisan los OKRs de producto. Las que tratan la medicion como proyecto unico 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