Por: Carlos Alexander Cercado Chirinos
Hay una frase que siempre me ha acompañado en mi carrera como ingeniero de software:
“Aquello que no se puede medir, no se puede controlar.”
Parece simple, pero encierra una verdad profunda.
La temperatura se mide, por eso podemos controlarla con un termostato.
El sonido se mide, por eso puedo ajustar el volumen de mi Alexa — subirlo o bajarlo según lo necesite.
Todo aquello que podemos cuantificar, podemos entender y ajustar.
El reto surge cuando las cosas que queremos medir son intangibles o complejas: el desempeño de un equipo, la calidad del código, la velocidad de entrega o la eficiencia del flujo de trabajo.
Ahí es donde comienza el trabajo creativo del liderazgo técnico: encontrar formas de medir lo que parece no tener forma de medirse.
Medir no es desconfiar, es entender
Uno de los errores más comunes en la gestión técnica es trabajar “al ojo por ciento”, confiando únicamente en la intuición.
Aunque la experiencia guía, no es lo mismo sentir que el equipo va bien que saberlo con datos.
Contar con métricas objetivas y dashboards instrumentados permite identificar patrones, tomar decisiones informadas y acompañar al equipo con evidencia, no con percepciones.
De Lean Manufacturing a la ingeniería de software
Las métricas de flujo como Lead Time y Cycle Time provienen del pensamiento Lean, el mismo que inspiró metodologías como Kanban y DevOps.
· Lead Time mide el tiempo total desde que se solicita un cambio o historia de usuario hasta que llega a producción o es entregado a un stakeholder.
Refleja cuánto tarda el valor en llegar al usuario final o al negocio.
· Cycle Time mide el tiempo desde que un desarrollador inicia una historia (“In Progress”) hasta que está lista para deploy (“Ready for Deploy”). Refleja qué tan eficiente es el flujo interno del equipo y cómo se comportan los cuellos de botella del proceso.
Estas métricas permiten entender la fluidez de trabajo y detectar demoras ocultas en el proceso de desarrollo.
Las métricas DORA y su adopción global en DevOps
Las métricas DORA nacen de un esfuerzo de investigación científica para identificar las capacidades y prácticas que distinguen a los equipos de desarrollo de software de alto rendimiento.
Sus hallazgos se consolidaron en el libro Accelerate (Forsgren, Humble y Kim, 2018), que definió cuatro métricas fundamentales:
Deployment Frequency: frecuencia con la que el equipo libera a producción.
Lead Time for Changes: tiempo desde que se realiza un cambio en el código hasta que se despliega en producción.
Change Failure Rate: porcentaje de despliegues que fallan y requieren intervención.
Mean Time to Recovery (MTTR): cuánto tarda el equipo en recuperarse de una falla en producción.
Hoy en día, las métricas DORA son ampliamente utilizadas por organizaciones de todos los tamaños, desde startups hasta grandes corporativos, porque permiten correlacionar la performance técnica con resultados de negocio, como la velocidad de entrega, la calidad del software y la estabilidad operativa.
Sin embargo, no todos los equipos tienen la autonomía o infraestructura para medirlas completamente, principalmente por estos problemas:
- Políticas que impiden desplegar la producción con frecuencia.
- Pipelines rígidos o centralizados.
- Procesos de liberación mensuales o trimestrales.
En estos escenarios, usar DORA como métrica de madurez puede ser injusto o poco realista.
Por eso conviene complementarlas con métricas Lean más simples y aplicables.
Métricas prácticas para equipos pequeños o en crecimiento
Si un equipo aún no cuenta con pipelines automatizados o despliegues frecuentes, puede comenzar midiendo métricas más inmediatas y accionables:
1. Cycle Time (Tiempo de Ciclo):
Mide cuánto tarda un desarrollador desde que inicia una historia hasta que está lista para deploy.
Permite analizar la agilidad y fluidez del trabajo diario.
2. Lead Time for Changes (Tiempo de Entrega):
Mide el tiempo desde que se solicita una historia o cambio hasta que se entrega a producción o a un stakeholder. Refleja la rapidez con que el valor llega al cliente o al negocio.
3. Flow Efficiency (Eficiencia de Flujo):
Porcentaje del tiempo total que se dedica realmente a trabajo activo, según la fórmula:
Flow Efficiency = (Cycle time / Lead Time) × 100
Indica cuánto tiempo se dedica a construir frente a cuánto se pierde en esperas, revisiones o aprobaciones.
Lo que las métricas revelan y las decisiones que permiten tomar
Estas métricas no solo muestran tiempos: revelan oportunidades de mejora y decisiones tácticas concretas.
Cycle Time
Si el tiempo de ciclo es alto, puede significar:
- Historias demasiado grandes o mal divididas.
- Exceso de trabajo en paralelo.
- Revisiones de código lentas o interrumpidas.
Decisiones posibles:
Reducir el tamaño de las tareas, limitar el WIP (Work in Progress), establecer políticas claras de revisión o automatizar validaciones con CI/CD.
Lead Time for Changes
Un Lead Time largo puede señalar:
- Cuellos de botella en testing o QA.
- Procesos de aprobación manual o lentos.
- Dependencias externas antes del despliegue.
Decisiones posibles:
Implementar pruebas automatizadas, pipelines de integración continua y liberar versiones más pequeñas con mayor frecuencia.
Flow Efficiency
Un porcentaje bajo de eficiencia indica que gran parte del tiempo se gasta esperando: revisiones, aprobaciones o recursos.
Decisiones posibles:
- Reducir bloqueos con comunicación asíncrona.
- Mejorar la coordinación entre equipos.
- Introducir políticas de pull requests rápidas o pair programming.
En conjunto, estas métricas ayudan a construir un proceso más predecible, sostenible y transparente, donde los líderes técnicos o gestores de proyectos pueden detectar tendencias antes de que los problemas se agraven.
Cómo medirlo en la práctica
Existen herramientas maduras que facilitan el seguimiento de estas métricas sin necesidad de cálculos manuales:
Para métricas Lean (Cycle Time, Lead Time, Flow Efficiency)
- Jira Software / Advanced Roadmaps
Permite visualizar tiempos de ciclo y tiempos de entrega por historia o sprint. - LinearB
Analiza flujos de trabajo de Git y PRs para calcular Cycle Time y eficiencia del equipo. - DevLake (Apache)
Plataforma open source para integrar datos de GitHub, Jira y CI/CD y construir dashboards personalizados.
Para métricas DORA
- Google Cloud DevOps Research & Assessment (DORA Metrics Dashboard)
Herramienta nativa de Google Cloud para capturar las 4 métricas DORA. - Sleuth.io
Plataforma que automatiza la recolección de métricas DORA a partir de repositorios y despliegues. - GitLab Analytics / GitHub Insights
Muestran Lead Time for Changes y frecuencia de despliegues directamente desde pipelines CI/CD.
Una herramienta open source para explorar estas métricas
También existen proyectos comunitarios enfocados en democratizar la medición de desempeño de equipos.
Uno de ellos es Team Performance Dashboard, una herramienta web que permite:
- Visualizar Cycle Time, Lead Time y Flow Efficiency por sprint o miembro del equipo.
- Identificar cuellos de botella visualmente mediante paneles interactivos.
- Analizar la evolución de la eficiencia y los tiempos de entrega a lo largo del tiempo.
Su código está disponible públicamente en GitHub: https://github.com/carloscercado/team-performance-dashboard
Midiendo para crecer
Medir no es un fin, sino un medio para apoyar al equipo, tomar decisiones basadas en evidencia y construir una cultura de mejora continua.
No todo lo que importa se puede medir, pero sí podemos observar, aprender y ajustar con datos.
Porque al final, liderar equipos de ingeniería no es solo escribir buen código, sino construir sistemas medibles, sostenibles y predecibles.
Liderar con datos es liderar con responsabilidad.
