Métricas que todo equipo de software debería medir (y pocas empresas miden)

La mayoría de las empresas medianas en España que tienen un equipo de software —interno o externalizado— no miden casi nada de lo que de verdad importa. Miden horas imputadas, tickets cerrados y, con suerte, fechas de entrega. Y luego se sorprenden cuando los proyectos se retrasan, la calidad cae o el equipo se quema. El problema no es que falten métricas de equipo de desarrollo de software: el problema es que las que se miden no dicen nada útil, y las que sí importan no se están mirando.

Este artículo resume los indicadores que en 2026 usan los equipos senior del sector para decidir con datos, no con sensaciones. Si diriges una empresa que depende de software y no estás revisando estos números cada dos semanas, estás pilotando a ciegas.

Por qué “tickets cerrados por sprint” no es una métrica

Antes de entrar en las métricas que sí sirven, conviene desmontar un mito muy extendido: la idea de que un equipo es más productivo cuantos más tickets cierra por sprint. No lo es. Y cualquier ingeniero con más de cinco años de experiencia lo sabe.

Los tickets cerrados dependen del tamaño del ticket, del criterio de quien los abre, de cuánto bugfix se cuela respecto a feature nueva, y de si hay deuda técnica encubierta dentro de tareas aparentemente pequeñas. Medir por tickets es medir ruido.

La productividad de un equipo de software no se mide por actividad, sino por resultado. Un equipo que entrega menos “cosas” pero con menos bugs, menos incidentes en producción y más valor de negocio es, objetivamente, un equipo mejor. Pero esto requiere mirar métricas que la mayoría de empresas ni siquiera tiene instrumentadas.

En Everglow hemos visto equipos que cerraban 80 tickets por sprint y provocaban incidentes críticos cada semana, y equipos que cerraban 25 tickets y no rompían producción en seis meses. Uno es mucho más productivo que el otro, y no es el que parece.

Las cuatro métricas DORA: el estándar que casi nadie aplica bien

DORA (DevOps Research and Assessment, ahora parte de Google Cloud) lleva más de una década publicando el informe State of DevOps. De su investigación han salido cuatro métricas que correlacionan de forma consistente con el rendimiento de negocio: los equipos que puntúan alto en estas cuatro cifras entregan más valor, con mayor calidad y con menor desgaste.

Son estas:

• Deployment Frequency (frecuencia de despliegue): cada cuánto despliegas cambios a producción. Los equipos élite despliegan varias veces al día. Los equipos medios, una vez al mes o menos.
• Lead Time for Changes (tiempo de entrega): cuánto pasa desde que un ingeniero hace el primer commit hasta que ese código está en producción. Los equipos élite están por debajo de una hora. Los equipos bajos, por encima de un mes.
• Change Failure Rate (tasa de fallo): de todos los despliegues, qué porcentaje provoca un bug, un incidente o requiere rollback. Los equipos élite están por debajo del 15%. Los equipos bajos, por encima del 45%.
• Time to Restore Service (tiempo de recuperación): cuánto tardas en recuperar el servicio cuando algo se rompe. Los equipos élite, menos de una hora. Los equipos bajos, días.

Estas cuatro métricas son el mínimo común denominador de cualquier equipo de software serio. Y la buena noticia es que todas son instrumentables con herramientas estándar (GitHub, GitLab, Datadog, Sentry, New Relic). No requieren magia ni consultoras de seis cifras.

La mala noticia es que la mayoría de las empresas medianas no las tienen instrumentadas. Y sin datos, cualquier conversación sobre “cómo va el equipo técnico” acaba siendo una discusión de opiniones.

Más allá de DORA: el modelo SPACE

DORA mide resultados de entrega. Pero no mide todo lo que importa. Un equipo puede tener buenas métricas DORA y, a la vez, estar quemado, desalineado o dejando deuda técnica que explotará en seis meses.

Por eso en 2021 Microsoft Research, GitHub y la Universidad de Victoria publicaron el framework SPACE, que amplía la mirada con cinco dimensiones. Es, a día de hoy, la forma más completa de medir a un equipo de software:

• S — Satisfaction and well-being: si el equipo está sano, retenido y motivado. Se mide con encuestas cortas, periódicas y anónimas. No es opcional.
• P — Performance: resultados del trabajo, no cantidad. Aquí entran las métricas DORA, pero también calidad del código, bugs por release y feedback de usuario.
• A — Activity: cantidad de trabajo ejecutado. Commits, PRs, líneas de código. Por sí sola engaña, pero contextualizada con las demás, ayuda.
• C — Communication and collaboration: cuánto colabora el equipo entre sí y con negocio. Tiempo medio de revisión de PR, discusiones de diseño, onboarding de nuevos miembros.
• E — Efficiency and flow: capacidad de avanzar sin fricción. Tiempo bloqueado en revisiones, interrupciones, context switching, reuniones innecesarias.

El valor de SPACE es que obliga a mirar el equipo como un sistema, no como una máquina de producir tickets. Cuando una empresa pide a un estudio de ingeniería como Everglow que tome el control de un proyecto en crisis, casi siempre hay un desequilibrio claro en una de estas cinco dimensiones.

Métricas de calidad de código que sí importan

Existen decenas de métricas de calidad de código, pero la mayoría son ruido académico. Estas son las pocas que de verdad te dirán si tu codebase va por buen camino o va a costarte caro en 24 meses:

• Cobertura de tests en código crítico: no obsesiones con el 90% global. Exige 80-90% en las rutas de negocio críticas (pagos, datos sensibles, lógica core). El resto no compensa.
• Tiempo medio de revisión de PR: si supera 24-48 horas, tu equipo tiene un cuello de botella en code review. Es uno de los mayores asesinos silenciosos de productividad.
• Número de dependencias desactualizadas con CVEs conocidos: revísalo cada semana. Es un indicador directo de riesgo de seguridad. Dependabot, Snyk o similar deberían estar activos.
• Ratio de bugs introducidos por feature nueva: un equipo sano debería estar por debajo de 0,3 bugs críticos por feature entregada. Si estás por encima de 1, tienes un problema de diseño o de testing, no de esfuerzo.

Un detalle importante: estas métricas no se miran en absoluto, se miran en tendencia. Un equipo con 60% de cobertura subiendo dos puntos cada mes es más sano que uno con 85% que baja un punto cada mes.

Métricas de producto que conectan ingeniería con negocio

Aquí es donde casi todas las empresas fallan. Tienen métricas técnicas por un lado y métricas de negocio por otro, y nadie las cruza. Así es imposible saber si el esfuerzo técnico está moviendo la aguja del negocio.

Las métricas que deberían estar en el mismo dashboard que las de ingeniería:

• Time to value de una feature: cuánto tarda una feature en ser usada por, al menos, el 30% de su público objetivo. Si una feature tarda más de dos meses en adoptarse, algo falla en producto, en onboarding o en su utilidad real.
• Coste de oportunidad por release retrasada: cuánto dinero pierdes (en ingresos, en churn evitable, en ventaja competitiva) por cada semana que una funcionalidad clave se retrasa. Si no tienes esta cifra, no puedes priorizar bien.
• Tasa de uso de funcionalidades: qué porcentaje de lo que has construido se usa de verdad. En muchos productos, el 70% de las funcionalidades las usa menos del 5% de los usuarios. Detectarlo evita seguir invirtiendo en cosas muertas.
• Customer-reported bugs vs internally-reported bugs: si los usuarios te reportan más bugs que los que detecta tu QA interno, tu proceso de testing está roto. Es una métrica dura pero clarísima.

Qué métricas NO medir (o medir con cuidado)

Hay métricas que suenan razonables, pero que usadas como KPI acaban generando incentivos perversos. Las peores:

• Líneas de código por ingeniero: castiga el código limpio y refactorizado. Un buen ingeniero a menudo borra más líneas de las que escribe.
• Horas trabajadas: no mide nada excepto presencia. Ni productividad, ni calidad, ni resultado. En equipos de conocimiento es una métrica anti-ingeniería.
• Número de features entregadas al mes: incentiva entregar mucho y mal. Es la receta para acumular deuda técnica.
• Velocity (story points por sprint): útil dentro de un equipo para planificar, inútil para comparar equipos o como KPI ejecutivo. Si te ponen la velocity en un dashboard de dirección, está mal usada.

Una regla simple: si una métrica es fácil de manipular y difícil de conectar con valor de negocio, es probable que esté haciendo más daño que bien.

Cómo empezar si hoy no mides nada

La tentación cuando una empresa descubre todo esto es montar un dashboard de treinta indicadores. Es un error. La diferencia entre medir bien y medir por medir es saber priorizar.

Una hoja de ruta realista para una empresa mediana que hoy no tiene métricas instrumentadas:

• Semana 1-2: instrumentar las cuatro métricas DORA. Automatizable con GitHub Actions + Datadog/Grafana. Es el primer dashboard obligatorio.
• Semana 3-4: sumar las cuatro métricas de calidad de código clave (cobertura en zonas críticas, tiempo de revisión de PR, dependencias con CVE, ratio bugs/feature).
• Mes 2: encuesta trimestral de bienestar del equipo (5 preguntas, anónima, siempre las mismas). Base para la dimensión S de SPACE.
• Mes 3: cruzar ingeniería con producto. Un único dashboard que muestre DORA + adopción de features + bugs reportados por cliente.

Con esto, una empresa mediana pasa de pilotar a ciegas a tener una foto honesta del estado de su operación tecnológica. Y esa foto, casi siempre, cambia las conversaciones en comité de dirección.

El papel de un socio técnico externo

Muchas empresas medianas no tienen la capacidad interna de instrumentar estas métricas, interpretarlas y actuar en consecuencia. Es perfectamente normal: requiere un perfil senior que no siempre justifica una contratación a jornada completa.

En Everglow trabajamos con un máximo de cinco clientes simultáneos precisamente para poder meter estas métricas en la operación real del equipo, no dejarlas en una presentación bonita. Instrumentar DORA, ajustar el proceso de code review, medir calidad de código y conectar ingeniería con producto no es teoría: son decisiones que cambian la cuenta de resultados.

Si tu equipo de software —interno, externalizado o mixto— hoy no puede responder con datos a preguntas como “¿con qué frecuencia desplegamos?”, “¿cuánto tardamos en recuperarnos de un incidente?” o “¿qué funcionalidades de las que hemos entregado se están usando?”, probablemente es momento de una conversación. Puedes escribirnos desde el contacto de nuestra web y lo revisamos juntos.

Medir no es un fin en sí mismo. Pero sin métricas reales, cualquier decisión sobre el equipo técnico —presupuesto, contratación, arquitectura, proveedores— se toma desde la intuición. Y en 2026, la intuición ya no es suficiente para competir en serio.