Ejemplo · Diagnóstico
Bloque 5 · Diagnóstico

Diagnóstico de las fallas

La primera versión del sistema se entregó... y casi nadie la usó. Veamos cómo encontrar la verdadera causa.
Ejemplo
El sistema de matrícula se entregó, pero los instructores siguieron usando el papel.
Paso 1 · Síntomas
¿Qué se observó?
Los síntomas son lo que se ve. No son la causa: son la pista para buscarla.
1
Los instructores siguieron matriculando en papel.
2
Se quejaban de que registrar un aprendiz «tomaba demasiado».
3
Muchos campos del formulario quedaban vacíos.
4
Al final del trimestre, casi no había datos en el sistema.
Paso 2 · Ubicar
¿En qué fase nació el problema?
Ubicar la fase correcta evita «arreglar» lo que no está roto.
Fase:
El formulario pedía datos que nadie necesitaba
Nunca se preguntó al instructor qué datos usa
El código funcionaba sin errores
Se entregó a tiempo

El código estaba bien y se entregó a tiempo. El problema real estaba en los requisitos: se pidieron datos que el usuario no necesitaba. Culpar al código habría sido un error.

Paso 3 · Causa raíz
Los 5 porqués
Pregunta «¿por qué?» varias veces hasta llegar a la causa que, si se corrige, evita todo lo demás.
Problema
Los instructores no usaron el sistema.
¿Por qué? 1
Porque les parecía más lento que el papel.
¿Por qué? 2
Porque pedía 15 datos por aprendiz.
¿Por qué? 3
Porque se incluyeron campos que nadie había pedido.
Causa raíz
Los requisitos se asumieron en vez de levantarlos con el instructor (el usuario real).
Cierre
Síntoma vs. causa raíz

👁El síntoma

«Nadie usa el sistema.» Es tentador culpar al software o al usuario.

🌱La causa raíz

No se levantaron los requisitos con el usuario real. Esa es la que hay que corregir.

Con la causa principal identificada, el siguiente paso (Bloque 6) es convertirla en un compromiso concreto para que no se repita en el próximo proyecto.

01