De una idea a un problema que se puede resolver
La mayoría de las ideas llegan formuladas como solución: “quiero un sistema que responda a los clientes”. Es una forma natural de decirlo, y también la razón principal de que los proyectos se atasquen en el tercer mes. Una solución sin problema definido es un blanco móvil: cada persona en la mesa imagina algo distinto y no hay manera de zanjar una discusión.
Tres preguntas que deben responderse por escrito
Quién, y en qué momento del día. No “los clientes”, sino una agente de soporte que abre un ticket y pasa ocho minutos buscando entre documentos. Cuanto más concreta la descripción, más claro queda qué debe hacer el sistema y, sobre todo, qué no.
Cuál es la solución actual. Todo problema ya tiene una solución, aunque sea mala: una hoja de cálculo, una pregunta en un grupo, el veterano al que todos consultan. Ese es tu punto de comparación real.
Cómo se ve el éxito en un número. Tiempo de gestión, porcentaje de casos cerrados sin intervención humana, minutos ahorrados por semana. Si no puedes formular una métrica, la idea todavía es una intuición; está bien, pero entonces el siguiente paso es investigar, no desarrollar.
Un documento de una página
Antes de la primera línea de código: la persona y el momento, la solución actual y su punto débil, la métrica de éxito, tres ejemplos reales de entrada y salida deseada, y una lista de lo que no entrará en la primera versión.
Los tres ejemplos son la parte importante: convierten una discusión abstracta en una conversación sobre un caso concreto. Si cuesta escribirlos, ese es el hallazgo: todavía no hay acuerdo sobre qué debe devolver el sistema.
En profundidad
Los ejemplos recogidos en la fase de definición son la semilla de tu conjunto de evaluación. Reúne entre 20 y 50 casos reales del terreno — incluidos casos límite y casos sin buena respuesta — antes de empezar a desarrollar. Es la inversión que se amortiza más rápido.