16 nodos#Framework#FiveWhys#RootCause#Retrospective

Five Whys

Un mapa para aplicar Five Whys, desde el síntoma hasta el defecto del proceso: cómo definir el problema, qué ocurre en cada nivel de los cinco porqués, las tres trampas de culpar a las personas, conformarse con la primera respuesta y encadenar conjeturas, además de comprobar que la solución realmente evita que el problema se repita.

El informe completo

Cinco no es un número mágico; es una referencia orientativa que indica que un defecto del proceso suele aflorar en torno a ese punto. El objetivo no es encontrar un culpable, sino corregir el sistema para que el mismo problema no pueda repetirse. Cada porqué debe enlazarse únicamente mediante hechos confirmados, no conjeturas, o la cadena se desmorona. La herramienta en sí es sencilla; la mayoría de los fallos se deben a cómo se aplica, no a la herramienta.

Define el problema#

Una frase medible, sin adjetivos

No empieces con 'los despliegues fallan a menudo', sino con una frase que incluya cifras y un período, como 'se revirtieron 3 de los 12 despliegues de las últimas 4 semanas'. Si la definición del problema es imprecisa, los participantes empiezan a analizar problemas distintos desde el primer porqué. Cada análisis de Five Whys aborda un solo incidente; si agrupas varios incidentes, sus causas también se mezclan.

Porqué 1#

La causa directa: qué ocurrió en ese momento

La respuesta al primer porqué suele ser un hecho técnico o físico observable, por ejemplo, 'falló el script de migración'. Si aparecen varias respuestas en este punto, elige la que más contribuyó al problema y separa las demás en cadenas independientes. Las respuestas de este nivel deben poder verificarse de inmediato mediante registros, documentación o la reproducción del fallo.

Porqué 2#

Por qué se produjo esa causa directa

A partir del segundo porqué, las respuestas pasan de los hechos a las condiciones, como 'el entorno de preproducción no tenía los mismos datos que el de producción'. Aquí es donde empieza a colarse el 'parece que', así que anota el método de verificación junto a cada respuesta y no pases al siguiente porqué sin confirmarla. Un tercer porqué basado en una conjetura es trabajo totalmente desperdiciado.

Porqué 3#

Por qué se mantuvo esa condición

En torno al tercer porqué suele aparecer la acción de una persona: 'el ingeniero se saltó la comprobación'. Aquí es donde la tentación de detenerse es mayor. Cuando aparezca un error humano, cambia la pregunta: ¿por qué fue posible cometer ese error y por qué no se detectó? El sistema que permitió el error es el objeto del siguiente porqué.

Porqué 4#

El nivel donde afloran defectos de estructura y proceso

En una cadena bien desarrollada, en torno al cuarto porqué la respuesta deja de ser un suceso concreto y pasa a ser un patrón que puede repetirse: 'la lista de comprobación no incluye ese punto', 'ninguna etapa tiene asignada esa verificación'. Si la respuesta sigue refiriéndose a una persona concreta o a las circunstancias de un día específico, la cadena se ha desviado; vuelve al porqué 2 o 3 y elige de nuevo la rama.

Porqué 5 = posible causa raíz#

El punto donde corregirla evita que el problema se repita

La prueba de una causa raíz no es su profundidad, sino su efecto: si corriges esto, ¿dejan de producirse los problemas de la misma familia? Confírmalo con la prueba inversa: empieza por el porqué 5 y recorre la cadena hacia arriba enlazando con 'por lo tanto'; si fluye con naturalidad hasta la definición del problema, la cadena se sostiene. El objetivo no es completar cinco porqués, así que, si llegas a la causa raíz en el tercero, detente en el tercero.

Dónde detenerse#

Al llegar a un proceso que controlas

Una cadena que sigue descendiendo indefinidamente no es un análisis, sino una evasión. El punto de parada es el proceso más profundo que tu equipo puede controlar. Cuando la respuesta sea algo fuera de tu alcance, como 'la recesión' o 'la naturaleza humana', sube un nivel y toma esa respuesta como causa raíz. Las causas que escapan a tu control no son algo que debas corregir; son condiciones de partida que debes tener en cuenta al diseñar el sistema para que pueda resistirlas.

Contramedidas#

Elimina la causa o absorbe el error

Hay dos tipos de contramedidas: las que eliminan la causa en sí y las barreras que impiden que la causa se convierta en un incidente aunque siga presente. 'Tener más cuidado' y 'dar formación' no son contramedidas, son deseos; necesitas cambios estructurales que no dependan de la memoria humana, como la automatización, la modificación de los valores predeterminados o las comprobaciones obligatorias. En esta etapa también se anotan los nuevos efectos secundarios que podría generar cada contramedida.

Verificación 1: métrica de recurrencia#

Fija un período para observar el efecto en cifras

Antes de aplicar la contramedida, decide qué observar y durante cuánto tiempo antes de considerarla un éxito, por ejemplo, 'cero reversiones del mismo tipo durante las 8 semanas posteriores a la implementación'. Un análisis de Five Whys que se da por cerrado sin una métrica y un período de observación se repite desde cero en el siguiente incidente. Si el problema vuelve a ocurrir, sospecha de un diagnóstico incorrecto antes de sospechar de una contramedida fallida.

Verificación 2: lectura inversa#

Audita la cadena con la prueba del 'por lo tanto'

Antes de dar por definitiva la contramedida, lee toda la cadena en sentido inverso. Empieza por la causa raíz y enlaza hacia arriba con 'por lo tanto'; el punto donde una frase deja de encajar es donde se esconde un salto lógico. Pedir a una tercera persona que la lea en sentido inverso es la auditoría más barata y rápida; quien la redacta no puede ver sus propios saltos.

Trampas habituales#

Tres hábitos que arruinan la cadena

Cuando Five Whys degenera en un ritual vacío, la causa está en su aplicación, no en la herramienta. Tres hábitos explican la mayoría de los fallos: detenerse en una persona, conformarse con la primera respuesta y enlazar mediante conjeturas. Basta con anunciar antes de la reunión tres reglas explícitas contra estos hábitos para cambiar la calidad de la cadena.

Trampa 1: detenerse al señalar un culpable#

Cuando aparece un 'quién', solo vas por la mitad

'La persona recién contratada cometió un error' nunca puede ser una causa raíz; si esa persona renuncia mañana, el mismo incidente seguirá ocurriendo. Cuando aparezca un nombre, vuelve a orientar la pregunta hacia la estructura: ¿por qué ese error pasó por el sistema sin ser detectado? El principio de no culpabilizar no es una cuestión de amabilidad, sino de precisión; en cuanto se espera un castigo, empieza a ocultarse información a partir del siguiente incidente.

Trampa 2: conformarse con la primera respuesta#

La respuesta plausible es la más peligrosa

La primera respuesta plausible suele ser una reformulación del síntoma o una hipótesis que todos ya daban por cierta. Preguntar una vez en cada nivel '¿hay otra explicación posible?' añade un nivel entero de profundidad a la cadena. Desconfía especialmente cuando la respuesta llega por unanimidad en los primeros cinco minutos de la reunión; el consenso sin verificación es memoria, no análisis.

Trampa 3: enlazar sin verificar#

Una cadena de hipótesis siempre se desmorona

La respuesta a cada porqué debe estar respaldada por uno de estos elementos: datos, registros o la confirmación de las personas implicadas. Si una sola respuesta es una conjetura, todo lo que viene después se apoya sobre arena. Cuando aparezca una respuesta que no se pueda verificar, pausa la cadena y verifica primero. Five Whys no es una ceremonia que deba terminar en una sola reunión; es una investigación en la que pueden pasar días entre una confirmación y la siguiente.

Cuando las causas se bifurcan#

La cadena se convierte en un árbol

Los problemas reales suelen tener más de una causa. Cuando un porqué produzca dos o más respuestas, no fuerces una única elección; divide la cadena en ramas. Pero no profundices por igual en todas: empieza por la rama que más contribuyó al problema y deja las demás marcadas explícitamente como aplazadas. El propio registro de la bifurcación se convierte en el mapa para el siguiente incidente similar.

¿Quieres llevarlo a la práctica?

Después de leer el informe, la siguiente pregunta suele ser cómo hacerlo realidad. Weple es un estudio de desarrollo externo que convierte estructuras como la de esta página en entregas pequeñas con un alcance definido. Incluye esta página en tu consulta.

Consultar sobre el desarrollo