La trampa de la solución
Antes de describir cómo se ejecuta esta fase, necesitamos hablar de una fuerza invisible que sabotea la mayoría de los procesos de discovery: la urgencia irrefrenable de saltar a las soluciones.
Es un mecanismo casi fisiológico. El cerebro humano no está diseñado para sostener la incomodidad de un problema abierto. Cuando escuchamos un problema, nuestra mente empieza a generar soluciones de forma automática, muchas veces antes de que la otra persona haya terminado de hablar. En un contexto profesional, esta urgencia se amplifica por la presión de los deadlines, la cultura de la ejecución rápida y la creencia de que el valor se mide por lo que produces, no por lo que entiendes.
Esta urgencia es la trampa de la solución. Y es el enemigo número uno de un buen discovery.
La trampa funciona así: alguien describe un síntoma ("nuestro equipo pierde demasiado tiempo buscando información"), tu mente construye instantáneamente una solución ("necesitan un buscador interno con IA"), y a partir de ese momento todo lo que escuchas se filtra a través de esa solución. Las entrevistas se convierten en validación. Las preguntas se orientan a confirmar. Los datos que no encajan se descartan. No es mala fe. Es el funcionamiento normal de un cerebro que busca certidumbre en un entorno de ambigüedad.
El antídoto no es intentar no pensar en soluciones. Eso es imposible. El antídoto es hacer explícita la solución que tu mente ha generado, escribirla, ponerla en un papel, colgarla en la pared, y luego hacer el trabajo deliberado de buscar evidencia que la contradiga. No que la confirme. Que la contradiga.
La escena: En una reunión de kickoff, el director de operaciones dice: "Necesitamos una herramienta de IA que automatice los informes mensuales. Nuestro equipo pierde una semana entera cada mes preparándolos."
Lo que el equipo escucha: "Hay que construir un generador de informes con IA."
Lo que un discovery riguroso descubre: El equipo no pierde una semana preparando informes. Pierde tres días recopilando datos de siete sistemas distintos que no se hablan entre sí, y dos días formateando esos datos en el template que exige la dirección. El problema no es la generación del informe. Es la fragmentación de los datos y un formato heredado que nadie ha cuestionado en cinco años.
La solución cambia completamente cuando el problema se define correctamente.
Cómo detectarlo: La solución propuesta se parece sospechosamente a la primera idea que alguien dijo en la reunión de kickoff. El Problem Statement describe un síntoma ("el equipo pierde tiempo haciendo informes") en lugar de la brecha real entre la situación actual y la deseada.
Cómo prevenirlo: Antes de aceptar la formulación del problema, aplica el test de los 5 por qués. Si la descripción del problema contiene una solución implícita ("necesitamos un X que haga Y"), destrúyela y reformula en términos de brecha. La brecha nunca contiene la palabra "necesitamos".