Antes del producto: cómo decidir qué problema resolver
Cuando construir se vuelve fácil, acertar con el problema se vuelve la parte difícil. Nuestro primer trabajo es hacer visible qué decisión de negocio hay detrás de una petición de software.
«Necesitamos un agente para propuestas» es una petición. Todavía no es una definición del problema.
Puede que el equipo tarde en redactar. También puede que redacte en una hora y espere tres días a que alguien confirme precio, disponibilidad y condiciones. Las dos situaciones producen propuestas lentas; solo una se resuelve escribiendo más rápido. Si elegimos la herramienta antes de entender el recorrido, podremos automatizar el paso equivocado.
Del síntoma a la causa.
Problem Solving empieza siguiendo el trabajo tal como ocurre. ¿Qué activa una solicitud? ¿Quién reúne el contexto? ¿Dónde se decide el precio? ¿Qué excepciones vuelven a abrir un expediente? Miramos los puntos de espera, las versiones de información y las decisiones que nadie ha hecho explícitas. Escuchamos a quienes ejecutan el proceso y a quienes responden por su resultado.
Con ese mapa formulamos una hipótesis causal. La contrastamos con casos reales y con una línea base: tiempo completo, retrabajo, errores, margen o capacidad perdida. La línea base no tiene que ser perfecta para empezar; sí tiene que permitir distinguir una mejora real de una demo convincente.
Petición: «Un copiloto que redacte propuestas».
Observación: el borrador aparece pronto; la espera está en buscar tarifas vigentes, comprobar capacidad y conseguir el visto bueno.
Problema reformulado: cada oportunidad carece de un expediente compartido que reúna fuentes, reglas y responsables de decisión.
Consecuencia: el producto debe coordinar contexto y aprobaciones antes de optimizar la redacción.
La economía obliga a elegir.
Una fricción puede ser molesta y no justificar un producto. Comparamos el coste de mantener el estado actual con el valor esperable de cambiarlo. Incluimos tiempo humano, errores, oportunidades retrasadas, revisión, infraestructura y mantenimiento. También miramos restricciones: acceso a datos, seguridad, adopción y dependencia de otros sistemas.
El resultado es una decisión entre alternativas: cambiar una regla, configurar una herramienta, comprar una solución, construir sobre Nuxeia OS o dejar el problema como está. La decisión se revisa cuando aparece evidencia nueva.
Qué sale de esta capa.
- Problema
- Un trabajo concreto que hoy falla, para personas concretas, con su causa probable.
- Línea base
- La medida actual del resultado que queremos mover y las incertidumbres pendientes.
- Alternativas
- Opciones comparadas por valor, coste, riesgo y tiempo hasta el uso.
- Decisión
- Qué merece cambiar, qué construir y cómo sabremos si acertamos.
Una buena fase previa puede terminar con una decisión de no construir. También puede dejar a ingeniería un problema lo bastante claro como para construir algo que importe.