Análisis de causa raíz de los 5 porqués
Resumen
El Análisis de causa raíz de los 5 porqués es una técnica estructurada de resolución de problemas en la que comienzas con una declaración del problema y preguntas "¿Por qué?" cinco veces en secuencia. Cada respuesta se convierte en el tema de la siguiente pregunta. El objetivo es ir más allá de los síntomas y sacar a la luz la falla subyacente del proceso o del sistema que realmente puedes corregir.
Quiénes pueden usarlo
Equipos de producto e ingeniería
Equipos de operaciones y DevOps
Equipos de soporte y atención al cliente
Gestores de proyectos
Equipos de aseguramiento de la calidad
Cualquier persona que investigue incidencias o incidentes recurrentes
Cómo usarlo
Redacta una declaración clara del problema — qué ocurrió, cuándo y cuál fue el impacto.
Pregunta "¿Por qué ocurrió esto?" y registra la respuesta (Respuesta 1).
Pregunta "¿Por qué ocurrió Respuesta 1?" y registra la respuesta (Respuesta 2).
Repite para las Respuestas 3, 4 y 5.
Detente cuando llegues a una causa que puedas abordar con un cambio en el proceso o en el sistema — esta es tu Causa raíz.
Define acciones correctivas: asigna a cada acción un propietario y una fecha límite.
Consejo: una buena causa raíz apunta a un proceso o al sistema, no a una persona. Si tu respuesta es un nombre, pregunta por qué una vez más.
Ejemplo
Declaración del problema: La página de pago estuvo caída durante 3 horas el 12 de agosto — aproximadamente $18 000 en pedidos perdidos y más de 40 tickets de soporte. (Investigado el 13 de agosto por el equipo de plataforma.)
Por qué 1: El servidor de pagos se quedó sin memoria y se bloqueó.
Por qué 2: El servicio de pagos tiene una fuga de memoria.
Por qué 3: El lanzamiento del 8 de agosto no cierra las conexiones antiguas a la base de datos.
Por qué 4: El lanzamiento nunca se sometió a pruebas de carga antes de entrar en producción.
Por qué 5: El checklist de lanzamiento no incluye un paso de pruebas de rendimiento.
Causa raíz: El proceso de lanzamiento no tiene un paso obligatorio de pruebas de carga o de rendimiento.
Acciones correctivas:
Agregar prueba de carga automatizada al pipeline de CI (líder de DevOps, 30 de agosto)
Configurar alertas de memoria al 80% de uso (equipo SRE, 22 de agosto)
Actualizar el checklist de lanzamiento y capacitar al equipo (gerente de ingeniería, 20 de agosto)
¡Saludos!
Khawaja Rizwan
