Llega a la raíz del problema con la técnica de los cinco por qué (five whys)

A medida que una startup va creciendo se pueden empezar a producir errores que si no son analizados correctamente para conocer su origen, pueden ser arrastrados mediante parches provocando grandes problemas a larga.

Eric Ries, el autor del fantástico libro The Lean Startup, propone una técnica adaptada una técnica de resolución sistemática de problemas creada por Toyota, una de tantas grandes innovaciones que han producido su magníficos ingenieros. Este método lleva por nombre “los cinco por qué (five whys)”, describiendo la forma de conseguir llegar a la raíz de un problema.

La aproximación estándar cuando se produce un problema en una startup es la de mirar que ha pasado, encontrar el problema aparente y finalmente solucionarlo. Todo este proceso lo más rápido posible para no bajar el ritmo. De esta forma parece que no se frena la evolución de la empresa pero podemos encontrarnos más adelante que solo hemos tratado un síntoma y no el auténtico origen del problema, por lo que podemos ir arrastrando y parcheando los problemas hasta que finalmente explotan en nuestra cara y entonces todos a correr.

En una startup, tan importante es mantener la velocidad como ir solucionando adecuadamente los problemas a medida que se van presentando. Así que con el método de los cinco por qué podemos ver frenada momentáneamente nuestra progresión para poder volver a coger la velocidad crucero en poco tiempo, y con la seguridad de que estamos erradicando la enfermedad y no tratando un simple síntoma.

Funcionamiento de la técnica de los cinco por qué

La técnica es autoexplicativa, por lo que no tiene mucho misterio, más allá de hacerla nuestra y aplicarla siempre que sea necesario. El funcionamiento consiste en preguntar el por qué del problema 5 veces para llegar a la verdadera raíz, de forma que a cada paso nos encontramos un poco más cerca.

Utilizaré el mismo ejemplo que utiliza Eric Ries en su blog, porque me parece muy ilustrativo: tu web ha caído, así que después de recuperla lo más rápido que puedas, en vez de dar el tema por solucionado procedes a hacer un análisis, en el que a cada paso preguntas el por qué:

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

Como vemos es un análisis bastante normal, lo que pasa es que en mucho casos no pasaríamos del punto 2, haciendo lo justo y necesario para seguir adelante. En cambio si aplicamos esta técnica, además de llegar a la raíz del problema, nos tenemos que comprometer a hacer una inversión proporcional a nivel correctivo en cada etapa del análisis. Con el ejemplo sería lo siguiente:

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

Con este grado de detalle podemos arreglar el problema a todos sus niveles incluido el origen del mismo, eso sí, en cada etapa el esfuerzo a realizar es mayor, pero también lo es su recompensa. Si realizamos hasta el último punto de las acciones correctivas, este problema, previsiblemente, no se producirá nunca más, si nos quedamos a medias quién sabe.

Aunque el coste de arreglar todos los niveles del problemas es mucho más elevado que arreglar el problema en sí, de manera que tendremos que invertir bastante más tiempo, a la larga veremos que habernos frenado un poco ahora nos permitirá seguir acelerando en un futuro, ya que no tendremos que interrumpir el trabajo constantemente para apagar fuegos.

De este pequeño ejemplo se puede deducir una importante conclusión: lo que parecía a primera vista un problema técnico se deducido que se trataba de un problema humano. Esta conclusión es extrapolable a una gran mayoría de problemas, ya que las personas somos mucho menos fiables que la tecnología.

Como todo en la vida hay que saber cuando conviene aplicar esta técnica y ver en cada caso hasta qué extremo vale la pena invertir tiempo en cada uno de los puntos a corregir. Es bueno empezar con alguna tipología concreta de problema para irnos familiarizando con el proceso y poco a poco ver su utilidad en otras áreas. En cuanto al esfuerzo a dedicar a la solución, siempre dependerá del coste de la solución vs el destrozo que provoca el problema, teniendo en cuenta si es un problema que puede ser reiterativo. Por ejemplo si el problema lo encontramos en el núcleo de nuestro proyecto y nos hace perder mucho dinero, es importante invertir muchos recursos en solucionar todo los niveles. En cambio si es un error molesto pero que no se suele repetir muy a menudo y el coste de su solución es elevado, merece más la pena fastidiarse de vez en cuando que gastar nuestros valioso recursos.

Si queréis ampliar la información podéis leer el libro Lean Startup, que contiene muchos más detalles, o el artículo original de Eric Ries: Five Whys.