IDEA - Herramientas

Técnica de "Los cinco Por qué"

Anonymous

“Los Cinco Por Qués” o “¿Por qué...? Porque...” es una técnica sistemática de preguntas utilizada durante la fase de análisis de problemas para buscar posibles causas principales de un problema. Durante esta fase, los miembros del equipo pueden sentir que tienen suficientes respuestas a sus preguntas. Esto podría ocasionar que el equipo falle en identificar las causas más probables del problemas debido a que no buscaron con la suficiente profundidad.

 

La técnica requiere que el equipo pregunte "Por Qué" aproximadamente cinco veces, o trabaje a través de cinco niveles de detalle. Cuando llegue el momento en que sea difícil para el equipo responder al “Por Qué”, la o las causas más probables del problema habrán sido identificadas.

 

¿Cómo se utiliza?

Primero, se lleva a cabo una Lluvia de Ideas para identificar las causas probables del problema.

Una vez que dichas causas probables han sido identificadas, hay que empezar a preguntar “¿Por qué es así...?” o “¿Por qué está pasando esto...?”. Hay que continuar preguntando "Por Qué" al menos cinco veces; esto reta al equipo a buscar a fondo y no conformarse con causas ya "probadas y ciertas". Habrá ocasiones en las que se podrá ir más allá de las cinco veces preguntando Por Qué para poder obtener lea causes principales y otras en las que no será posible llegar a cinco veces pues la causa raíz ya fue encontrada.

Durante este tiempo se debe tener cuidado de NO empezar a preguntar “Quien”. Se debe recordar que el equipo está interesado en el proceso y no en las personas involucradas.

 

Ejemplo

Problema: La web de la empresa ha caído. Procedemos a hacer un análisis, en el que a cada paso preguntaremos el por qué:

  1. ¿Por qué ha caído la web? Porque la carga de la CPU se disparó al 100%.
  2. ¿Por qué se disparó la carga de la CPU? Porque una parte del código entraba en un bucle infinito.
  3. ¿Por qué estaba ese código defectuoso en producción? Porque el trabajador “X” tuvo un error.
  4. ¿Por qué su fallo pasó a producción? Porque el trabajador “X” no hizo un test unitario.
  5. ¿Por qué no hizo un test unitario? Porque “X” es un nuevo empleado y no ha sido formado para el desarrollo orientado a test.

Si aplicamos esta técnica, además de llegar a la raíz del problema, nos podremos comprometer a hacer una inversión proporcional a nivel correctivo en cada etapa del análisis:

  1. Recuperar la web.
  2. Eliminar el código defectuoso.
  3. Ayudar a “X” a entender por qué está mal su código.
  4. Formar a “X” en materia de Desarrollo orientado a test.
  5. Incluir la formación en Desarrollo orientado a test a la formación inicial para nuevos empleados.

 

Más información sobre esta técnica puede encontrarse en el Blog de Eric Ries: http://www.startuplessonslearned.com/2008/11/five-whys.html