Desperdicios 3 y 4: Traspasos y Esperas

Cada vez que el trabajo pasa de una persona o equipo a otro, se pierde contexto.

El gerente de producto escribe los requisitos. Conoce el dolor del usuario, las restricciones del negocio, las compensaciones de prioridad. Entrega esto a un diseñador.

El diseñador lee los requisitos, hace preguntas aclaratorias (algunas de las cuales el gerente de producto ya no puede responder porque el contexto se ha desvanecido), y crea maquetas. Entrega esto a los desarrolladores.

Los desarrolladores leen los requisitos y maquetas, hacen preguntas aclaratorias (algunas de las cuales ni el gerente de producto ni el diseñador pueden responder ya), y construyen algo. Lo entregan a QA.

QA prueba contra los requisitos, encuentra problemas, y lo devuelve a los desarrolladores.

En cada traspaso, se pierde información. Para cuando la funcionalidad llega a los usuarios, apenas se parece a lo que el gerente de producto originalmente entendió sobre las necesidades del usuario. Y cada traspaso tomó tiempo—a veces días esperando en colas.

Los traspasos son donde el contexto va a morir.

La mayor parte del tiempo de entrega es tiempo de espera, no tiempo de trabajo. Una tarea que toma 2 horas de trabajo activo podría tener 2 semanas de tiempo de entrega. ¿A dónde va el resto?

• Tiempo en cola: Esperando en backlogs para priorización
• Esperando revisión: PRs sin revisar
• Esperando aprobación: Decisiones atascadas en la gerencia
• Esperando dependencias: Bloqueado por otros equipos
• Esperando entornos: No se puede probar porque staging está roto
• Esperando información: Preguntas sin responder
• Esperando programación: Reuniones que no pueden ocurrir hasta la próxima semana

Cada espera introduce demora y a menudo requiere refamiliarización cuando se reanuda el trabajo. Lees el código, entiendes el contexto, te interrumpen, y tienes que reconstruir ese contexto después.

La eficiencia de flujo mide el tiempo de valor agregado como porcentaje del tiempo de entrega. En la mayoría de las organizaciones de software, es del 5-15%. Eso significa que el 85-95% del tiempo, el trabajo está esperando, no siendo trabajado.

Equipos multifuncionales: Reúne todas las habilidades necesarias para entregar valor en un solo equipo. Producto, diseño, desarrollo, pruebas—todos juntos. Los traspasos se convierten en conversaciones.

Especialistas generalizados: Personas que tienen experiencia profunda en un área pero pueden contribuir en otras. Cuando el trabajo se acumula en revisión, los desarrolladores pueden ayudar a revisar. Menos colas.

Programación en parejas y en grupo: Dos o más personas trabajando juntas elimina los traspasos dentro del trabajo. La revisión está integrada. La transferencia de conocimiento es continua.

Colaboración en tiempo real: Reemplaza los traspasos asincrónicos con colaboración sincrónica. En lugar de escribir una especificación, ten una conversación. En lugar de reportar un bug, acércate y muéstrale al desarrollador.

Elimina aprobaciones: La mayoría de los pasos de aprobación no agregan valor—son mecanismos de control de entornos de baja confianza. Cuestiona cada aprobación: ¿Qué valor agrega esto? ¿Podríamos obtener el mismo beneficio de otra manera?

Automatiza traspasos: Si el trabajo debe transferirse, automatiza la cola. Pipelines de CI/CD que despliegan automáticamente. Bots de PR que notifican a los revisores inmediatamente. Integraciones de Slack que muestran el trabajo bloqueado.

El objetivo no es trabajar más rápido—es esperar menos. Ataca el 85%, no el 15%.