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 de forma consecutiva. Cada respuesta se convierte en el punto de partida de la siguiente pregunta. El objetivo es ir más allá de los síntomas y sacar a la luz la falla del proceso o del sistema que realmente puedes corregir.
Quién puede usarla
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
Escribe una declaración del problema clara — qué pasó, cuándo y cuál fue el impacto.
Pregunta "¿Por qué ocurrió esto?" y registra la respuesta (Respuesta 1).
Pregunta "¿Por qué ocurrió la 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 el sistema — esa es tu causa raíz.
Define acciones correctivas: asigna a cada acción un propietario y una fecha de vencimiento.
Consejo: una buena causa raíz señala a un proceso o 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 — aprox. $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: La versión del 8 de agosto no cierra las conexiones antiguas a la base de datos.
Por qué 4: La versión nunca se sometió a pruebas de carga antes de entrar en producción.
Por qué 5: La 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/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 la checklist de lanzamiento y capacitar al equipo (gerente de ingeniería, 20 de agosto)
¡Saludos!
Khawaja Rizwan
