¿Qué son los indicadores de productividad?

Los indicadores de productividad son métricas que nos permiten comparar los resultados obtenidos con el tiempo, la capacidad y los recursos utilizados para producirlos.

En un equipo de software, por ejemplo, pueden ayudarnos a responder preguntas como:

• ¿Cuánto trabajo completa el equipo por sprint o por mes?
• ¿Cuánto tarda una tarea desde que comienza hasta que termina?
• ¿Cuántos elementos están siendo trabajados al mismo tiempo?
• ¿Cuánto tiempo se dedica realmente a trabajar en una tarea?
• ¿Cuánto tiempo permanece esperando entre etapas?
• ¿Qué diferencia existe entre lo planificado y lo entregado?
• ¿La previsibilidad del equipo está mejorando o empeorando?

No existe un único KPI de productividad capaz de responder todas estas preguntas.

Por eso prefiero analizar la productividad como un conjunto de señales, y no como un único número utilizado para clasificar equipos o personas.

Ser productivo sí, pero ¿comparado con qué?

Siempre me gusta comenzar este tema con una conversación de Alicia en el País de las Maravillas, de Lewis Carroll:

- ¿Qué camino debo seguir?

- ¿Hacia dónde quieres ir?

- No lo sé.

- Entonces, no importa.

Con la productividad ocurre algo parecido.

Antes de decidir si un equipo es productivo, necesitamos una referencia. Sin ella, decir que un equipo está produciendo “mucho” o “poco” tiene muy poco significado.

Algunas referencias que suelo utilizar son:

• ¿Se alcanzó el objetivo del sprint?
• ¿Se cumplió el objetivo de la PI?
• ¿Qué diferencia existe entre lo planificado y lo entregado?
• ¿Qué KPI de productividad alcanzaron el resultado esperado?
• ¿Qué indicadores quedaron por debajo de lo esperado?
• ¿La capacidad de entrega está aumentando, disminuyendo o permaneciendo estable?

A partir de estas comparaciones podemos comprender la producción real del equipo en relación con lo que se esperaba.

Ese es el primer paso para entender si estamos dentro de lo planificado, por encima de las expectativas o por debajo de lo necesario.

Con Saint Jude, este análisis puede consolidarse entre diferentes proyectos, equipos y períodos. En lugar de observar cada tablero de forma aislada, el liderazgo puede identificar dónde la productividad está mejorando, dónde la previsibilidad está disminuyendo y qué proyectos necesitan atención.

Una advertencia importante: tener un indicador no significa que debamos intentar aumentarlo indefinidamente.

Es mejor completar un viaje a 100 km/h que conducir a 180 km/h y romper el motor a mitad del camino.

Los indicadores deberían ayudarnos a trabajar mejor, no convertirse automáticamente en una razón para exigir cada vez más entregas.

¿Cuáles son los principales indicadores de productividad para un equipo?

Existen muchos indicadores de productividad laboral y métricas de rendimiento. Sin embargo, para equipos de software y proyectos, considero especialmente útiles aquellos que pueden obtenerse directamente del flujo de trabajo.

Entre ellos:

• Distribución del trabajo por tipo de actividad;
• Throughput o volumen de entregas;
• Velocidad de entrega;
• Cycle time;
• Work in Progress - WIP;
• Tiempo de espera;
• Eficiencia del flujo;
• Trabajo planificado versus trabajo entregado.

1. Distribución del trabajo por tipo de actividad

Uno de los primeros indicadores de productividad que observo es cómo se está utilizando la capacidad disponible del equipo.

En un proyecto de software, por ejemplo, podemos dividir el trabajo entre:

• Historias de usuario;
• Mantenimiento y correcciones;
• Enablers técnicos.

Las historias de usuario normalmente representan avance funcional del producto. Las tareas de mantenimiento corrigen problemas o preservan la experiencia existente. Los enablers crean la base técnica necesaria para arquitectura, infraestructura, integraciones, seguridad o escalabilidad.

Analizar esta distribución nos permite entender dónde se está consumiendo realmente la capacidad.

Un equipo puede parecer extremadamente ocupado y, al mismo tiempo, avanzar muy poco con el producto porque gran parte de su tiempo se está utilizando en correcciones, deuda técnica, dependencias o mantenimiento.

Por eso contar simplemente el número de tareas terminadas suele ser un mal indicador de productividad.

2. Throughput y velocidad de entrega

Otro KPI de productividad importante es cuánto trabajo logra completar el equipo dentro de períodos comparables: sprint, PI, mes o trimestre.

Dependiendo de la forma de trabajo, podemos utilizar historias completadas, puntos, horas, días u otra unidad que el equipo utilice consistentemente.

La pregunta principal es:

¿Cuál es la capacidad real de entrega de este equipo?

Con varios períodos de información histórica empiezan a aparecer patrones y se vuelve más sencillo estimar entregas futuras.

Sin embargo, hay que tener cuidado al comparar velocidad o story points entre equipos diferentes. Cada equipo puede estimar de manera distinta, por lo que diez puntos para un equipo no necesariamente significan lo mismo para otro.

Normalmente resulta más útil comparar la evolución del mismo equipo a lo largo del tiempo.

Saint Jude puede ayudar en este análisis consolidando la velocidad de entrega entre proyectos y tableros y mostrando variaciones entre lo planificado y lo entregado.

3. Cycle time: ¿cuánto tarda una tarea en completarse?

El cycle time mide cuánto tiempo transcurre desde que el trabajo comienza hasta que la tarea se completa.

Es uno de los indicadores de productividad más útiles para equipos de software porque muestra la velocidad real del flujo de entrega.

La información se vuelve todavía más útil cuando se analiza por tipo de trabajo.

Por ejemplo:

• Las tareas de mantenimiento tardan una media de 5 días;
• Las historias de usuario tardan 3 días;
• Los enablers técnicos tardan 8 días.

Esto permite entender qué tipos de actividad consumen más tiempo y cuáles tienen mayor impacto sobre el calendario del proyecto.

También puede revelar algo muy importante: una tarea puede tardar muchos días no porque sea difícil de desarrollar, sino porque permanece parada durante demasiado tiempo entre una etapa y otra.

4. WIP: ¿cuántos elementos están activos al mismo tiempo?

WIP significa Work in Progress y representa la cantidad de trabajo que está activo simultáneamente.

Para mí, es uno de los indicadores más importantes para cualquier responsable de proyectos o tecnología.

Si tienes cinco personas en el equipo y diez, quince o veinte tareas aparecen como activas, probablemente algunas están bloqueadas, mal distribuidas, esperando información o simplemente no están avanzando.

Más trabajo iniciado no significa necesariamente más productividad.

Muchas veces significa exactamente lo contrario: más cambios de contexto, menos foco y mayor tiempo para completar cada actividad.

También debemos entender dónde se está acumulando el trabajo:

• Análisis;
• Desarrollo;
• Code review;
• Pruebas;
• Validación;
• Finalización.

Con Saint Jude, esta información puede consolidarse en dashboards que muestran exceso de WIP, cuellos de botella por etapa y posibles riesgos de retraso antes de que aparezcan en el cronograma ejecutivo.

5. Eficiencia del flujo: ¿cuánto tiempo es trabajo y cuánto es espera?

Una tarea puede tardar diez días en completarse sin que nadie esté trabajando activamente en ella durante diez días.

Por ejemplo:

• 2 días en desarrollo;
• 3 días esperando revisión;
• 1 día realizando correcciones;
• 4 días esperando pruebas.

En este caso, buena parte del tiempo total de entrega no fue trabajo activo. Fue espera.

La eficiencia del flujo permite comparar el tiempo activo con el tiempo total del flujo.

Tiempo total del flujo = tiempo activo + tiempo de espera

Eficiencia del flujo = tiempo activo / tiempo total del flujo × 100

Cuanto mayor sea el porcentaje de tiempo activo, más eficiente tiende a ser el flujo.

Una eficiencia baja puede indicar colas, dependencias, bloqueos o cuellos de botella entre etapas.

Este es también un buen ejemplo de por qué medir la productividad no debería significar medir únicamente a las personas.

Muchas veces el problema está en el sistema que las rodea.

¿Cómo mejorar la productividad de un equipo?

Medir solo tiene sentido si utilizamos la información para tomar mejores decisiones.

A lo largo de los años trabajando en gestión de proyectos y programas, he observado algunos patrones que, cuando se corrigen, pueden aumentar la velocidad de entrega, mejorar la previsibilidad y reducir el time-to-market.

Entiende dónde se está utilizando la capacidad del equipo

Mi visión — quizás un poco polémica — es:

• Una historia de usuario significa avanzar;
• Un enabler significa preparar el camino;
• El mantenimiento significa recuperar terreno perdido.

Eso no significa que mantenimiento y enablers sean malos. Ambos son necesarios.

El problema comienza cuando consumen una parte excesiva de la capacidad disponible.

Las tareas de mantenimiento pueden aparecer porque el proceso no estaba suficientemente definido, faltaba información o la entrega anterior no tenía la claridad necesaria.

Este problema está directamente relacionado con otro artículo que escribí: “Definition of Done y Definition of Ready en Scrum: qué son, diferencias y ejemplos”.

El retrabajo puede surgir por escenarios incompletos, personas poco definidas, reglas de negocio ausentes, dependencias no identificadas o criterios de aceptación poco claros.

Dedicar algo más de tiempo a crear claridad antes del desarrollo puede parecer más lento al principio, pero puede ahorrar días de retrabajo posteriormente.

Los enablers también son necesarios porque crean la estructura técnica para que el producto continúe evolucionando: arquitectura, infraestructura, seguridad, ambientes, integraciones y mejoras internas.

La cuestión es entender qué porcentaje de la capacidad está siendo consumido por cada tipo de trabajo y si esta distribución es coherente con las prioridades del proyecto.

Compara lo planificado con lo entregado

Uno de los KPI de productividad que más valor aportan no es simplemente cuánto entregó el equipo, sino cuánto de lo que se había planificado terminó siendo entregado.

Personalmente, me gusta bastante el planning poker porque no sirve únicamente para obtener una estimación. La conversación necesaria para llegar a esa estimación también aumenta la claridad sobre lo que debe hacerse.

A partir de ahí podemos analizar puntos, horas, tareas completadas o días en sprints, PIs, meses o trimestres anteriores y utilizar ese histórico para conocer mejor la capacidad real del equipo.

Un equipo que planifica 100 y entrega consistentemente 95 puede ser mucho más saludable y previsible que otro que planifica 150, entrega 70 en un ciclo y 140 en el siguiente.

Para PMOs y responsables de tecnología, este es uno de los análisis en los que Saint Jude puede aportar valor: comparar lo planificado con lo realizado, identificar variaciones de productividad y mostrar qué proyectos están ganando o perdiendo previsibilidad.

Analiza el cycle time por tipo de actividad

No todas las tareas son iguales.

Historias de usuario, mantenimiento y enablers tienen características diferentes. Comparar el cycle time entre estas categorías permite mejorar estimaciones e identificar problemas específicos del flujo.

En determinados períodos también puede tener sentido modificar intencionadamente la distribución del trabajo.

Por ejemplo:

• Un sprint enfocado en reducir mantenimiento;
• Una PI con mayor concentración de enablers técnicos;
• Un ciclo con más historias de usuario para acelerar una entrega estratégica.

Reduce el tiempo de espera entre etapas

Si una tarea pasa dos días en desarrollo y cinco días esperando pruebas, probablemente el principal problema de productividad no esté en el desarrollo.

Puede estar en la cola.

Por eso el tiempo de espera puede ser tan importante como el tiempo de ejecución.

Este análisis suele llevarnos a una decisión ejecutiva muy sencilla:

¿Gasto tiempo o dinero?

Las tareas muchas veces quedan bloqueadas porque una etapa del proceso no tiene suficiente capacidad para acompañar al resto.

Si existen muchos desarrolladores y poca capacidad de QA, por ejemplo, puede comenzar a crecer una cola de trabajo esperando pruebas.

Agregar capacidad cuesta dinero. No agregarla cuesta tiempo.

El objetivo del indicador es hacer visible esa decisión para que el liderazgo pueda elegir conscientemente.

También debemos considerar los cambios de contexto. Las personas no ejecutan eficazmente cinco tareas complejas al mismo tiempo. Cada vez que alguien abandona una actividad para responder a otra prioridad, el trabajo original pierde foco y normalmente tarda más en finalizar.

Controla cuántos elementos están activos en el tablero

Cuando el trabajo no está claro, la cantidad de tareas activas normalmente comienza a aumentar.

Una persona toma una tarea, descubre que falta información, pregunta a otra persona y queda esperando una respuesta. Mientras espera, comienza otra actividad.

Después aparece otra dependencia y empieza una tercera tarea.

En poco tiempo existen muchas actividades “en progreso”, pero muy pocas avanzando realmente hacia su finalización.

Por eso vuelvo nuevamente al artículo: “Definition of Done y Definition of Ready en Scrum: qué son, diferencias y ejemplos”.

Mi regla es sencilla: si alguien toma una tarea y no entiende qué debe entregar, debe preguntar al equipo. Si nadie puede explicarla claramente, probablemente esa tarea todavía no debería estar dentro del sprint.

Con dashboards de carga, WIP y tareas activas, Saint Jude permite transformar este problema operativo en una visión de gestión: dónde se está acumulando trabajo, qué proyectos están perdiendo flujo y dónde pueden existir problemas de claridad, foco o capacidad.

¿Cuáles son los KPI de productividad más útiles?

Si tuviera que resumir los indicadores de productividad que considero más útiles para equipos de software y proyectos, comenzaría por estos:

• Planificado vs. entregado: ayuda a medir la previsibilidad del equipo;
• Throughput: muestra cuántos elementos se completan durante un período;
• Cycle time: mide cuánto tarda el trabajo desde su inicio hasta su finalización;
• WIP: muestra cuántas actividades están siendo ejecutadas simultáneamente;
• Tiempo de espera: identifica cuánto tiempo del flujo permanece inactivo;
• Eficiencia del flujo: compara tiempo activo con tiempo total;
• Distribución del trabajo: muestra dónde se consume la capacidad disponible;
• Variación de capacidad: ayuda a identificar si la productividad está mejorando o empeorando a lo largo del tiempo.

Ninguno de estos indicadores debería analizarse de forma aislada.

Un equipo puede aumentar el throughput y al mismo tiempo aumentar el retrabajo. Puede reducir el cycle time simplemente creando tareas más pequeñas. Puede aumentar su velocidad cambiando la forma en que estima.

Por eso la productividad de un equipo debe entenderse como un sistema de señales y no como un único número.

¿Debemos medir la productividad individual?

Aquí es donde los indicadores de productividad pueden convertirse en algo peligroso.

Puede ser tentador clasificar profesionales utilizando número de tareas, story points, commits, pull requests u otras medidas individuales.

Pero el desarrollo de software es una actividad de equipo rodeada de dependencias, revisiones, decisiones de arquitectura, pruebas, requisitos, bloqueos y responsabilidades compartidas.

Una persona puede parecer “lenta” porque el trabajo no está claro, porque existe una cola de pruebas, porque depende de otro equipo o porque la tarea permanece bloqueada por razones externas.

Por eso prefiero medir primero el sistema de entrega.

Antes de preguntar:

“¿Por qué esta persona entregó menos?”

Yo preguntaría:

• ¿Por qué la tarea estuvo bloqueada?
• ¿Cuánto WIP existe?
• ¿Dónde está el cuello de botella?
• ¿Cuánto tiempo de espera tenemos?
• ¿Cuánta capacidad está siendo consumida por retrabajo?
• ¿Estamos planificando más de lo que realmente podemos entregar?

Cómo Saint Jude ayuda a medir los indicadores de productividad

La mayoría de las empresas ya posee gran parte de los datos necesarios para calcular estos indicadores.

La información está distribuida entre Jira, Azure DevOps, ClickUp, Monday.com, Asana y otras herramientas utilizadas por los equipos.

El desafío está en transformar cientos o miles de actividades en información útil para quien necesita tomar decisiones.

Saint Jude funciona como una capa de inteligencia sobre estos datos de proyectos, ayudando a gerentes, PMOs y responsables de tecnología a analizar:

• Productividad y capacidad de los equipos;
• Trabajo planificado versus entregado;
• Throughput y velocidad de entrega;
• Cycle time;
• WIP y carga de trabajo;
• Cuellos de botella y tareas bloqueadas;
• Riesgos de retraso;
• Costes y consumo de recursos;
• Previsibilidad de los proyectos.

El objetivo no es utilizar los datos para vigilar a las personas.

El objetivo es dar a los líderes suficiente visibilidad para entender dónde un proyecto está perdiendo productividad, tiempo y margen antes de que esos problemas aparezcan en el resultado final.

Mide el sistema antes de medir a las personas

Quiero terminar este artículo con una idea que considero más importante que cualquier fórmula de productividad.

Medir productividad no debería significar preguntar constantemente:

“¿Por qué este profesional no entregó más?”

Normalmente existen preguntas mejores:

• ¿Por qué esta tarea estuvo bloqueada?
• ¿Por qué tenemos tanto trabajo en progreso?
• ¿Dónde está el cuello de botella?
• ¿Por qué estamos planificando más de lo que podemos entregar?
• ¿Cuánta capacidad está siendo consumida por mantenimiento?
• ¿Dónde estamos generando retrabajo?

Es aquí donde los indicadores de productividad realmente empiezan a aportar valor.

Con los indicadores correctos — y con herramientas capaces de transformar datos de proyectos en visibilidad, como Saint Jude — líderes, PMOs y equipos pueden tomar mejores decisiones, mejorar la previsibilidad y aumentar la productividad sin depender únicamente de percepciones o reportes manuales.

¿Quieres continuar esta conversación? Comenta el artículo en LinkedIn o compártelo con alguien que también esté intentando entender mejor la productividad de sus equipos.

¡Hasta pronto!

Erik Scaranello