Medir lo que sienten los clientes vs. lo que experimentan los trabajadores.
Estos términos se confunden frecuentemente pero son crucialmente diferentes:
Tiempo de Entrega: El tiempo total transcurrido desde que un cliente hace una solicitud hasta que recibe el valor. Esto es lo que experimenta el cliente. Incluye toda la espera, todo el procesamiento, todo.
Tiempo de Ciclo: El tiempo que el trabajo pasa siendo activamente trabajado. Esto es lo que experimentan los trabajadores durante su porción del flujo.
Ejemplo: Un cliente solicita una funcionalidad el lunes. Se prioriza y se incorpora al desarrollo el miércoles. Un desarrollador trabaja en ella durante 2 días. Permanece en revisión de PR durante 3 días. Las pruebas toman 1 día. Se despliega el viernes de la siguiente semana.
Nota: el trabajo activo fue tal vez 4 días en total. El tiempo de entrega fue 12 días. Ocho días fueron de espera.
La Métrica que Probablemente Mides Está Equivocada
La mayoría de los equipos miden el tiempo de ciclo o la velocidad—lo que producen los trabajadores. Pero a los clientes no les importa tu velocidad. Les importa el tiempo de entrega—cuánto tiempo esperan. Optimiza para lo que sienten los clientes, no para lo que se ve bien internamente.
La brecha entre el tiempo de entrega y el tiempo de ciclo es el tiempo de espera. Y el tiempo de espera típicamente domina.
Tiempo en cola: Trabajo esperando en backlogs, esperando ser priorizado, esperando que alguien lo tome.
Retrasos en transferencias: Trabajo terminado en una etapa, esperando que la siguiente etapa tenga capacidad.
Retrasos por lotes: Trabajo que está terminado pero esperando ser desplegado con otro trabajo.
Dependencias externas: Esperando otros equipos, proveedores o aprobaciones.
Retrasos de calendario: Trabajo que está listo pero "solo desplegamos los martes".
En la mayoría de las organizaciones de software, el tiempo de espera es del 80-95% del tiempo de entrega. Eso significa que solo el 5-20% del tiempo, el trabajo está siendo realmente trabajado.
La implicación: mejorar qué tan rápido trabajas tiene un impacto mínimo. Si trabajas el doble de rápido pero las esperas permanecen iguales, el tiempo de entrega apenas cambia. El apalancamiento está en las esperas.
Una corrección simple de bug: 2 horas de tiempo de desarrollador. Pero: 3 días esperando asignación, 2 días esperando revisión de PR, 1 día esperando QA, 3 días esperando el despliegue semanal, 2 días monitoreando en producción. Tiempo de entrega: 11 días.
Misma corrección de bug, equipo diferente: PR revisado en horas (PRs pequeños, prioridad del equipo en revisión). Sin cola de QA (los desarrolladores prueban su propio código). Despliegue continuo (sin ventanas de despliegue). Tiempo de entrega: 3 horas.
Otro desglose útil:
Tiempo de Contacto: Tiempo cuando el trabajo está siendo activamente progresado por un humano. Manos en el teclado. Cerebro enfocado en este problema.
Tiempo de Espera: Todo el tiempo intermedio. En colas. Esperando revisión. Esperando despliegue. Esperando información.
Tiempo de Procesamiento: Tiempo de contacto más tiempo de máquina (compilaciones, pruebas, despliegues). Esto es el tiempo de ciclo.
Cuando entiendes este desglose, puedes dirigir las mejoras correctamente:
La mayoría de los equipos intentan hacer el tiempo de contacto más rápido (mejores herramientas, más desarrolladores) cuando el problema es el tiempo de espera (demasiado WIP, lotes, colas). Es como intentar hacer que los autos vayan más rápido cuando están atascados en el tráfico.
Si tienes un problema de tiempo de entrega, probablemente tienes un problema de tiempo de espera. Si tienes un problema de tiempo de espera, probablemente tienes un problema de WIP. Reducir el WIP es usualmente el camino más rápido hacia tiempos de entrega más cortos.