Desperdicio 1: Trabajo Parcialmente Terminado
Inventario en software: código que existe pero no está en producción.
1Inventario en el Trabajo del Conocimiento
En manufactura, el inventario son piezas y productos en estantes: dinero inmovilizado, espacio consumido, valor no entregado. La manufactura esbelta famosamente minimizó el inventario casi a cero.
En software, el inventario es menos visible pero igualmente problemático:
- Ramas sin fusionar: Código escrito pero no integrado
- Pull requests abiertos: Cambios esperando revisión
- Funcionalidades sin liberar: Trabajo completado detrás de feature flags
- Elementos del backlog: Ideas documentadas pero no construidas
- Documentos de requisitos: Especificaciones escritas pero no implementadas
- Diseños: Mockups creados pero no construidos
Esto es trabajo parcialmente terminado: esfuerzo invertido pero valor no entregado. Es la forma más costosa de desperdicio porque representa inversión real con cero retorno.
El Problema de la Degradación
El inventario físico se queda en un estante. El inventario de software se degrada. Una rama sin fusionar se vuelve más difícil de fusionar cada día mientras la rama principal evoluciona. Los documentos de requisitos se vuelven obsoletos conforme cambia el entendimiento. Mientras más tiempo permanece el trabajo parcialmente terminado, más esfuerzo se necesita para completarlo.
2Por Qué se Acumula el Inventario
Los equipos rara vez crean inventario intencionalmente. Se acumula a través de:
Tamaños de lote grandes: Mientras más grande la funcionalidad, más tiempo hasta que esté terminada. Un proyecto de tres meses son tres meses de inventario antes de que se entregue cualquier valor.
Sistemas de empuje: Trabajo asignado basado en disponibilidad en lugar de capacidad. Cuando inicias más de lo que puedes terminar, el inventario crece.
Retroalimentación retrasada: Esperar revisiones de código, QA o aprobaciones. Cada cola es acumulación de inventario.
Trabajo prematuro: Iniciar elementos antes de que se necesiten. Escribir especificaciones para funcionalidades que podrían no construirse. Diseñar para requisitos futuros imaginados.
Miedo a fusionar: Los equipos que tienen miedo de integrar mantienen los cambios aislados. Mientras más esperan, más aterradora se vuelve la integración, creando un ciclo vicioso.
La solución no es trabajar más rápido, es trabajar en lotes más pequeños. Reducir tamaños de lote. Implementar integración continua. Jalar trabajo basado en capacidad, no empujar basado en asignaciones.
Un equipo tiene 47 pull requests abiertos, algunos de meses de antigüedad. Cada uno representa inversión que no entrega valor. Los conflictos de fusión se acumulan. Se pierde el contexto. Eventualmente, los PRs se abandonan por completo: 100% desperdicio.
Un equipo hace commits a main varias veces al día. Ninguna rama vive más de unas horas. Los PRs son pequeños y se revisan rápidamente. El inventario se mantiene cerca de cero. El lead time baja de semanas a horas.
3Reducir el Trabajo Parcialmente Terminado
Estrategias para reducir el inventario:
Terminar antes de iniciar: Establecer límites WIP. Antes de iniciar algo nuevo, termina algo en progreso. "Deja de iniciar, empieza a terminar."
Reducir tamaños de lote: Dividir funcionalidades grandes en incrementos pequeños e independientemente valiosos. Libera cada incremento antes de iniciar el siguiente.
Integración continua: Fusionar a main constantemente. No dejes que las ramas vivan más de un día. Haz que la integración sea aburrida a través de la frecuencia.
Ciclos de retroalimentación rápidos: Si los PRs esperan días para revisión, eso es inventario. Prioriza la revisión. Hazla rápida. Mejor aún, programa en parejas para que la revisión esté integrada.
Eliminar trabajo previo: No escribas especificaciones para funcionalidades que no son las siguientes. No diseñes sistemas que no estás construyendo este sprint. Planificación justo a tiempo.
El objetivo es flujo: el trabajo se mueve a través del sistema sin acumularse en ninguna etapa. Cuando ves que el inventario se acumula, has encontrado un obstáculo al flujo.
Mídelo
Cuenta tu trabajo en progreso. ¿Cuántos elementos están iniciados pero no terminados? ¿Cuántos PRs están abiertos? ¿Cuánto código sin liberar existe? Rastrea estos números. Reducirlos es usualmente el camino más rápido hacia una entrega más rápida.
- El trabajo parcialmente terminado es inventario: inversión sin retorno
- El inventario de software se degrada, a diferencia del inventario físico
- Los lotes grandes y los sistemas de empuje crean acumulación de inventario
- Termina antes de iniciar: deja de iniciar, empieza a terminar
- La integración continua mantiene el inventario cerca de cero