Simyl
simylflow
Inicio del curso
Módulo 3: Flujo de Valor y Flujo
Lección 3 de 5
12 min

Tiempo de Entrega vs. Tiempo de Ciclo

Medir lo que sienten los clientes vs. lo que experimentan los trabajadores.

1Definiciones que Importan

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.

  • Tiempo de Entrega: 12 días (lunes a viernes de la semana 2)
  • Tiempo de Ciclo (Desarrollo): 2 días
  • Tiempo de Ciclo (Revisión): Unas pocas horas
  • Tiempo de Ciclo (Pruebas): 1 día

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.

2De Dónde Viene la Brecha

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.

2 Horas de Trabajo, 2 Semanas de Tiempo de Entrega

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.

Mismo Trabajo, Sistema Diferente

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.

3Tiempo de Contacto y Tiempo de Espera

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:

  • ¿Tiempo de contacto largo pero alto valor agregado? Probablemente no es desperdicio—esto es trabajo especializado.
  • ¿Tiempo de contacto largo pero bajo valor agregado? Desperdicio potencial—automatiza o elimina.
  • ¿Tiempo de espera largo? Casi con certeza desperdicio—reduce lotes, limita WIP, elimina colas.

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.

Conclusiones clave
  • El tiempo de entrega es lo que experimentan los clientes; el tiempo de ciclo es el tiempo de trabajo
  • La brecha entre ellos es el tiempo de espera—usualmente 80-95% del tiempo de entrega
  • Mejorar la velocidad del trabajo tiene un impacto mínimo en el tiempo de entrega
  • El tiempo de espera es usualmente el punto de apalancamiento más grande para la mejora
  • Mide el tiempo de entrega como tu métrica principal—es lo que sienten los clientes