Parto del problema y de lo que todavía no sabemos sobre él.
El trabajo combina análisis, investigación, ingeniería y validación. Dependiendo del encargo puede dar lugar a una decisión estratégica, un modelo organizativo, una arquitectura, un prototipo, un MVP o una solución tecnológica.
Antes de elegir tecnología o plantear una solución necesito entender qué está ocurriendo realmente: qué intenta conseguir la organización, qué actores intervienen, qué restricciones existen, qué se ha probado y qué consecuencias tiene el problema.
¿Qué estamos intentando resolver realmente?
Los problemas complejos suelen estar distribuidos entre personas, procesos, sistemas y documentos. Construir una representación compartida —un modelo, un flujo, un mapa o una arquitectura conceptual— permite razonar sobre el conjunto y detectar relaciones que de otro modo permanecen ocultas.
¿Cómo podemos representar la situación para poder pensar sobre ella?
Cuando quedan incógnitas, hay que reducirlas. Puede implicar revisar conocimiento existente, analizar datos, evaluar tecnologías, construir experimentos, contrastar hipótesis o estudiar cómo se ha resuelto un problema similar en otros contextos.
Según el problema, pueden intervenir técnicas de aprendizaje automático, IA generativa, visión artificial, NLP, grafos, simulación u otros enfoques. Son medios para obtener evidencia y decidir mejor, no el punto de partida.
¿Qué necesitamos averiguar antes de decidir?
Investigar no es el objetivo final. El conocimiento adquirido debe convertirse en criterio: elegir una dirección, reducir alcance, priorizar, descartar alternativas o decidir que todavía hace falta evidencia.
Con lo que sabemos ahora, ¿qué camino tiene más sentido?
Una decisión útil debe poder convertirse en algo real. Según el problema, puede materializarse en una estrategia, una hoja de ruta, una gobernanza, un proceso, una arquitectura, un prototipo, un MVP o un sistema. Cuando la respuesta es tecnológica, puedo participar también en la arquitectura, el desarrollo y la validación de una primera solución, sin reducir el trabajo a mera ejecución técnica.
¿Qué necesitamos construir o definir para poner la decisión en práctica?
La validación no consiste solo en comprobar que algo funciona técnicamente. Hay que comprobar que resuelve el problema que originó el trabajo, que puede utilizarse en su contexto y que las hipótesis iniciales siguen siendo válidas.
La validación puede incluir criterios de QA, métricas, pruebas funcionales y de carga, comportamiento del sistema completo, operación y feedback de uso.
¿La respuesta funciona para aquello que realmente necesitábamos resolver?
Una prueba puede obligar a revisar una hipótesis. Un problema de integración puede cambiar la arquitectura. Un hallazgo puede modificar la comprensión inicial. Volver atrás no es desviarse del proceso; es aprender antes de seguir invirtiendo.