Desperdicios 5 y 6: Cambio de Tareas y Defectos
Los costos ocultos de la multitarea y el costoso retrabajo de los bugs.
1El Impuesto del Cambio de Contexto
Cada vez que cambias de tarea, pagas un impuesto.
La investigación muestra consistentemente que el cambio de contexto cuesta 15-25 minutos para volver a la productividad completa. No para empezar a trabajar—para alcanzar la misma profundidad de enfoque que tenías antes de la interrupción.
Si cambias de contexto 4 veces en una tarde, podrías pasar más tiempo reorientándote que realmente trabajando.
En manufactura, este desperdicio se llama "transporte" y "movimiento"—movimiento innecesario de materiales o personas. En software, es el movimiento innecesario de atención.
Fuentes del cambio de tareas:
- Demasiado WIP: Hacer malabares con múltiples proyectos significa cambio constante
- Interrupciones: Mensajes de Slack, toques en el hombro, "preguntas rápidas"
- Reuniones: Cada reunión es un cambio de contexto de ida y vuelta
- Email/notificaciones: Revisar constantemente fragmenta la atención
- Prioridades poco claras: No saber en qué trabajar lleva a la confusión
El costo no es solo tiempo—es calidad. El trabajo superficial produce resultados superficiales. El trabajo profundo requiere enfoque sostenido. El cambio de tareas impide el trabajo profundo.
El Mito de la Multitarea
Los humanos no hacen multitarea—cambiamos de tarea. Somos malos en eso. Lo que se siente como productividad es en realidad sobrecarga cognitiva. La persona que 'hace muchas cosas' haciendo malabares con tareas a menudo es menos productiva que alguien enfocado en una sola cosa.
2El Multiplicador de Defectos
Los defectos son desperdicio por razones obvias: requieren retrabajo. Pero el costo real es peor de lo que parece.
Los defectos encontrados tarde cuestan exponencialmente más que los defectos encontrados temprano. Un bug detectado en desarrollo podría tomar 10 minutos arreglar. El mismo bug encontrado en pruebas podría tomar una hora (reproducción, diagnóstico, corrección, re-prueba). Encontrado en producción, podría tomar días (investigación, comunicación con clientes, corrección de emergencia, post-mortem).
Los defectos generan defectos. Arreglar un bug bajo presión a menudo introduce nuevos bugs. El código base se convierte en un campo minado. Los desarrolladores se ralentizan. La calidad cae en espiral.
Los defectos destruyen la confianza. Después de suficientes incidentes en producción, cada cambio requiere aprobación extensa, pruebas extensas, autorización extensa. El proceso se infla para proteger contra los defectos que el proceso crea.
El desperdicio oculto: inspección y pruebas. Si tienes defectos, necesitas QA extensivo. QA es desperdicio necesario—no agrega valor, solo atrapa el desperdicio creado por los defectos. Construye calidad desde el inicio, y necesitas menos inspección.
Un desarrollador maneja 'preguntas rápidas' durante todo el día: mensajes de Slack, toques en el hombro, email. Se siente útil. Pero su propio trabajo nunca alcanza profundidad. Las tareas complejas toman semanas. Los bugs se escapan porque el enfoque está fragmentado.
Un equipo establece 'tiempo de enfoque' de 10am-2pm: sin reuniones, sin Slack, sin interrupciones. El trabajo complejo se hace en la mañana. La comunicación ocurre en ventanas agrupadas. La calidad y la velocidad mejoran.
3Reduciendo el Cambio y los Defectos
Para el cambio de tareas:
Límites de WIP: La intervención más directa. Si solo puedes trabajar en una cosa a la vez, no puedes cambiar de contexto. Termina antes de empezar.
Comunicación agrupada: Revisa email/Slack en intervalos definidos, no constantemente. Deja que la gente sepa cuándo estás disponible y cuándo no.
Tiempo sin reuniones: Designa bloques para trabajo enfocado. Protégelos ferozmente.
Prioridades más claras: Si la gente no sabe en qué trabajar, se confunde. Haz las prioridades explícitas y estables.
Para defectos:
Desarrollo guiado por pruebas: Escribe las pruebas primero. Construye calidad desde el inicio, no la inspecciones al final.
Programación en parejas: La revisión en tiempo real atrapa errores antes de que se conviertan en bugs.
Integración continua: Encuentra bugs de integración inmediatamente, cuando el contexto está fresco y las correcciones son baratas.
Detente y corrige: Cuando encuentras un bug, corrígelo ahora. No lo agregues a un backlog para que envejezca. El principio del cordón andon de Toyota.
Post-mortems sin culpa: Cuando los bugs escapan, entiende por qué sin culpar. Corrige el sistema que permitió el bug, no solo el bug en sí.
La Falacia de la Detección
Agregar más pruebas no reduce los defectos—los detecta. Y la detección es costosa. El objetivo es prevenir que los defectos se creen en primer lugar. Construye calidad desde el inicio; no la inspecciones después.
- El cambio de contexto cuesta 15-25 minutos por cambio
- La multitarea es un mito—los humanos cambian de tarea pobremente
- Los defectos encontrados tarde cuestan exponencialmente más que los tempranos
- Las pruebas atrapan defectos pero no los previenen
- Los límites de WIP y TDD abordan las causas raíz
- •Agregar más QA en lugar de construir calidad desde el inicio
- •Permitir interrupciones porque 'la colaboración es importante'
- •Tratar los backlogs de defectos como normales en lugar de alarmantes
- •Creer que la multitarea te hace más productivo