Planteamiento del problema

¿Qué pasó exactamente, dónde y cuándo?

La versión 4.2 salió con dos días de retraso, la tercera entrega tardía de este trimestre.
Los errores en el checkout subieron al 3% de los pedidos tras el despliegue del martes.
La semana pasada, cuarenta tickets de soporte esperaron más de 48 horas a una primera respuesta.
Lo que sabemos

¿Qué hechos y datos describen el problema?

La build estaba en verde el viernes y la rama de release se creó el lunes.
Los logs de errores muestran timeouts del proveedor de pagos a partir de las 14:05.
Dos de nuestros cuatro revisores estaban de vacaciones esa semana.
¿Por qué ocurrió?

¿Qué causó directamente el problema?

Las pruebas finales empezaron tarde porque la última funcionalidad se fusionó el día de la entrega.
La nueva configuración de reintentos saturó de peticiones la API del proveedor de pagos.
No había nadie en el turno de soporte los lunes por la mañana.

¿Qué es la técnica de los 5 porqués?

Los 5 porqués son una técnica de análisis de causa raíz. Planteas un problema, preguntas por qué ocurrió y repites la pregunta con cada respuesta hasta llegar a una causa que el equipo pueda resolver. Viene del Sistema de Producción Toyota. En su ejemplo de los 5 porqués, el propio Taiichi Ohno parte de una máquina parada y pasa por un fusible fundido, un cojinete sin lubricar y un eje de bomba desgastado hasta dar con la causa raíz: la bomba no tenía filtro. Esta plantilla de los 5 porqués recorre toda la cadena en una sola retrospectiva de TeamRetro. Escribe el planteamiento del problema en la primera columna y los hechos que ya conoces en la segunda. Después, todos responden al primer porqué, "¿Por qué ocurrió?", en la tercera columna. El equipo agrupa las respuestas y vota la causa más probable. En la fase Debatir, abres esa tarjeta y planteas los cuatro porqués siguientes como un hilo de comentarios, en el que cada respuesta contesta a la anterior. La última respuesta es tu causa raíz, y la copias a una acción con un responsable y una fecha límite. Los 5 porqués funcionan mejor cuando un problema sigue una línea principal de causa y efecto: una entrega con retraso, un incidente que se repite, un defecto que se escapó de las pruebas. Seguir una sola cadena hasta el final evita que el equipo se conforme con la primera respuesta y lleva la conversación de quién se equivocó a qué parte del proceso lo permitió. Cuando un problema tiene muchas causas que contribuyen, mapéalas primero y luego aplica los 5 porqués a las más probables.

Formato de retrospectiva de los 5 porqués

Planteamiento del problema

¿Qué pasó exactamente, dónde y cuándo?

Acordad un único planteamiento del problema antes de que nadie añada una causa, y limítalo a una sola tarjeta. Que sea concreto: qué pasó, dónde, cuándo y con qué magnitud, sin adivinar la causa. "La versión 4.2 salió con dos días de retraso" le da al equipo algo sobre lo que preguntar por qué. "Las entregas son un desastre" no.

Lo que sabemos

¿Qué hechos y datos describen el problema?

Reúne los hechos antes que las causas: cronologías, métricas, logs, informes de clientes y lo que ha cambiado recientemente. Cada respuesta de la cadena de porqués debería apoyarse en algo de aquí o en algo que el equipo pueda comprobar. Si falta un dato, anótalo y convierte su búsqueda en una acción.

¿Por qué ocurrió?

¿Qué causó directamente el problema?

Cada tarjeta aquí es un primer porqué, una causa directa del planteamiento del problema. Céntrate en qué pasó, no en quién. Después de agrupar, vota la causa que mejor explique el problema. En la fase Debatir, abre la tarjeta más votada y plantea los cuatro porqués siguientes como un hilo de comentarios, en el que cada respuesta contesta a la anterior. Si dos respuestas son válidas en un mismo nivel, contesta dos veces al mismo comentario y sigue cada rama.

Cuándo utilizar esta retrospectiva

  • Un problema vuelve a aparecer después de haberlo resuelto y quieres encontrar la causa que se le escapó a la última solución.
  • Después de un incidente, un defecto que llegó a producción o una fecha límite incumplida, cuando el equipo necesita saber por qué antes de acordar qué cambiar.
  • Un tema de una retrospectiva se llevó la mayoría de los votos y merece analizarse a fondo en su propia sesión.
  • El problema parece tener una línea principal de causa y efecto. Si tiene muchas causas que contribuyen, mapéalas primero con un diagrama de Ishikawa.

Preguntas sugeridas para romper el hielo

  • ¿Qué pequeño arreglo hiciste alguna vez que resolvió un problema mucho mayor?
  • ¿Qué es algo que solo entendiste después de preguntar por qué más de una vez?

¿Te gustaría que tu equipo realizara un ejercicio de calentamiento, en lugar de limitarse a responder en voz alta? Echa un vistazo a los rompehielos gratuitos →

Ideas y consejos para tu reunión de retrospectiva

  • Acordad el planteamiento del problema en voz alta antes de la lluvia de ideas y añádelo como única tarjeta en Planteamiento del problema. La plantilla configura la lluvia de ideas con Mostrar ideas inmediatamente, así que todos ven cada tarjeta en cuanto se añade. Puedes cambiarlo en la configuración de la reunión.
  • La plantilla configura la fase Debatir con Debatir todo, para que el planteamiento del problema y los hechos sigan en pantalla junto a la causa más votada. Puedes cambiarlo en la configuración de la reunión.
  • Recorre la cadena como un hilo de comentarios en la causa más votada. Esa tarjeta es el primer porqué. Añade un comentario que responda a "¿Por qué ocurrió eso?", contesta a ese comentario con la siguiente respuesta y sigue contestando. Las respuestas se anidan hasta tres niveles, así que la tarjeta, un comentario y tres respuestas te dan cinco porqués.
  • Detente cuando llegues a una causa que el equipo pueda cambiar, ya sea en tres porqués o en siete. Si necesitas un sexto, añade un nuevo comentario en la tarjeta que continúe desde la última respuesta.
  • Pregunta por el proceso, no por la persona. Si una respuesta acaba en "alguien se equivocó", pregunta por qué el proceso dejó pasar ese error.
  • Convierte la causa raíz en una contramedida. Abre el menú de la última respuesta, elige Copiar a acción y asigna a la acción un responsable y una fecha límite. Revísala en la fase Acciones abiertas de una retrospectiva posterior para comprobar que la solución funcionó.

Preguntas frecuentes

¿Qué es la técnica de los 5 porqués de Taiichi Ohno?
Es la práctica de preguntar por qué una y otra vez cuando ocurre un problema, para ir más allá del síntoma evidente hasta la causa raíz. Forma parte del Sistema de Producción Toyota, que Taiichi Ohno ayudó a crear, y su ejemplo de una máquina parada llega a la causa raíz, una bomba sin filtro, en el quinto porqué.
¿Cómo se usan los 5 porqués?
Empieza con un problema concreto, pregunta por qué ocurrió y luego pregunta por qué ante cada respuesta hasta llegar a una causa que puedas resolver. Un ejemplo de los 5 porqués: la entrega se retrasó porque las pruebas empezaron el día de la entrega, porque la última funcionalidad se fusionó esa mañana, porque esperó tres días a la revisión, porque solo una persona puede aprobar cambios en la base de datos, porque nadie más ha recibido formación sobre el esquema. La solución es formar a una segunda persona que pueda aprobar, no pedir a la gente que pruebe más rápido.
¿Cuáles son las técnicas de análisis de causa raíz?
Las técnicas habituales son los 5 porqués, el diagrama de Ishikawa (espina de pescado), el análisis de Pareto, el análisis de árbol de fallos y el análisis de cambios. Los 5 porqués siguen una sola cadena de causa y efecto, así que cuando un problema tiene varias causas que contribuyen, mapéalas primero con una retrospectiva de diagrama de Ishikawa y luego aplica los 5 porqués a las más probables.
¿Cómo se redacta un análisis de causa raíz?
Plantea el problema con hechos: qué pasó, dónde, cuándo y con qué magnitud. Rastrea las causas hasta llegar a una causa raíz, comprobando cada paso con evidencias, y después registra las acciones correctivas con responsables, fechas límite y cómo comprobarás que funcionaron. En esta plantilla, el problema y los hechos son columnas, el hilo de comentarios en la causa principal es la cadena de porqués y las acciones son las acciones correctivas.
¿Cuál es la mejor plantilla para el análisis de causa raíz?
Depende del problema. Una plantilla de los 5 porqués encaja con un problema que tiene una línea principal de causa y efecto, y un diagrama de Ishikawa encaja con un problema que tiene muchas causas posibles entre personas, procesos y herramientas. Cualquiera de las dos funciona mejor cuando el equipo la completa en conjunto, con los hechos delante y un responsable para cada solución.
¿Estás listo para llevar a cabo esta retrospectiva?Prueba esta retrospectiva en directo