Las preguntas que deben responderse
El Problem Phase se estructura alrededor de seis preguntas fundamentales. No son un cuestionario que rellenar, son direcciones de investigación. Cada una abre un ángulo distinto del problema y, juntas, componen una imagen lo suficientemente completa como para producir un Problem Statement de calidad.
1. ¿Cuál es el problema real, no el síntoma?
Esta es la pregunta más importante y la más difícil. Lo que te cuentan primero es casi siempre un síntoma. "Necesitamos un dashboard" es un síntoma. "No tenemos visibilidad sobre el inventario y perdemos ventas cuando nos quedamos sin stock" es el problema. La diferencia parece sutil pero determina toda la solución.
Hay una distinción que ayuda: el síntoma es lo que se ve. El problema es la brecha entre la realidad y lo que debería estar ocurriendo. "El equipo tarda una semana en hacer informes" es un síntoma. La brecha es: "Las decisiones de negocio se toman con una semana de retraso sobre los datos reales, y en ese tiempo la situación ya ha cambiado."
Pregunta repetidamente "¿y eso por qué es un problema?". Usa la técnica de los 5 por qués. No te detengas en la primera respuesta. Cuando la persona dice "porque siempre ha sido así" o "porque el sistema no lo permite", estás cerca de la causa raíz.
2. ¿A quién afecta y cómo lo vive?
Un problema no existe en abstracto. Existe en la experiencia de personas concretas. Necesitas entender quién lo vive, cómo lo experimenta en su día a día, qué emociones genera y cómo impacta en su trabajo o su vida.
Pero aquí hay un matiz que muchos equipos pasan por alto: no todas las personas afectadas lo viven igual, y no todas importan igual para la definición del problema. El gerente de tienda que pierde ventas por falta de stock vive el problema de una forma. El responsable de almacén que recibe quejas constantes lo vive de otra. El cliente que encuentra la estantería vacía lo vive de una tercera. El Problem Statement necesita integrar estas perspectivas, no elegir una y descartar las demás.
Pide historias concretas: "Cuéntame la última vez que te pasó esto. Qué hiciste. Cómo te sentiste." Las historias contienen detalles que las respuestas genéricas no revelan. Las emociones son datos. Un usuario que dice "me da rabia" te está dando información sobre la intensidad del problema que ninguna métrica captura.
3. ¿Qué lo causa?
Entender las causas es crítico para no resolver un síntoma. Las causas pueden ser múltiples, estar interconectadas y operar a distintos niveles: personal, de proceso, de sistema, organizacional.
Mapea causas en capas. Distingue entre causas raíz y causas contribuyentes. Un diagrama de Ishikawa o un mapa causal pueden ayudar a visualizar la estructura del problema. La causa raíz es la que, si se elimina, hace que el problema desaparezca. Las causas contribuyentes son las que lo agravan pero no lo generan.
4. ¿Qué ha intentado ya y por qué no funcionó?
Esta pregunta es una mina de oro de información. Los intentos previos fallidos te dicen qué no funciona, qué restricciones existen y, frecuentemente, qué parte del problema el usuario ya entiende mejor que tú.
No juzgues los intentos anteriores. Explora qué parte funcionó, qué parte no y por qué. Las soluciones parciales a menudo contienen el germen de la solución real. Pregunta: "¿Qué workaround has creado? ¿Qué parte de ese workaround funciona bien?" Esas respuestas revelan restricciones invisibles que ningún análisis técnico mostraría.
5. ¿Qué coste tiene no resolverlo?
El coste del problema es lo que justifica resolverlo. Si no puedes cuantificar (en tiempo, dinero, oportunidad perdida, desgaste emocional o riesgo) el impacto de no resolver el problema, no tienes un caso de negocio. Tienes una hipótesis.
Pero aquí hay un punto que muchos equipos evitan por incómodo: el coste de no resolver el problema es también el criterio más honesto para decidir si merece la pena resolverlo. No todos los problemas justifican una solución. Un discovery riguroso puede concluir, legítimamente, que el problema existe pero su coste no justifica la inversión. Eso no es un fracaso del discovery. Es su resultado más valioso: evitar construir algo que no tiene sentido económico.
Cuantifica siempre que puedas. "Me cuesta 3 horas semanales" es mejor que "me cuesta mucho tiempo". Los números concretos anclan la conversación y facilitan la priorización posterior. Cuando la cuantificación directa no sea posible, usa proxies: "¿Cuántas veces al mes ocurre? ¿Cuánto tiempo pierdes cada vez? ¿Cuántas personas se ven afectadas?"
6. ¿Cuándo ocurre, con qué frecuencia, en qué contexto?
El contexto temporal y situacional del problema revela patrones que no aparecen en una descripción estática. Un problema que ocurre todos los días es distinto de uno que ocurre una vez al mes. Un problema que aparece solo cuando hay presión sugiere causas diferentes a uno que es constante.
Busca triggers y condiciones. "¿Cuándo aparece este problema? ¿Hay días o momentos en que es peor? ¿Hay algo que lo activa?" Los patrones contextuales frecuentemente revelan la causa raíz de forma más efectiva que las preguntas directas sobre causas.