Pensaba que el reto era entender el programa

Durante años pensé que lo importante era entender la tecnología. Abrir ejecutables, mirar cadenas, seguir llamadas, saltos, CALL, JMP y flujo de ejecución. Aprendí que lo que ves en pantalla casi nunca es toda la historia.

Nunca he visto la tecnología como una colección de herramientas sueltas. Siempre me ha interesado lo que hay detrás: qué problema resuelve algo, qué dependencia crea, cómo se mantiene, cómo se protege, cómo se recupera y qué pasa si falla. Esas preguntas me las hacía entonces sobre un programa en BASIC. Me las sigo haciendo hoy sobre cualquier tecnología que cruza mi mesa.

Recuerdo tener que ingeniármelas para sacar datos de sistemas antiguos cuando no había exportación limpia. Programar utilidades en C para capturar información por puerto serie, convertir bases en archivos de texto y migrarlas a sistemas más modernos. Ese tipo de problemas te obligan a entender el sistema completo, sus limitaciones y cómo llevar la información de un sitio a otro sin perder nada por el camino.

Pero con el tiempo descubrí que entender el programa nunca era suficiente. Antes de escribir una sola línea de código, había algo más importante que comprender.

El programa era solo una consecuencia

Cada vez que tenía que desarrollar una aplicación, me daba cuenta de que antes de escribir código tenía que entender cómo trabajaban realmente las personas.

Cómo llegaba un pedido. Cómo se preparaba. Cómo se movía un producto por un almacén. Cómo se distribuía. Cómo se emitía una factura. Cómo circulaba un documento. Cómo se comunicaban los departamentos.

Muchas veces el problema no estaba en el programa. Estaba en el proceso. Y muchas veces el proceso tampoco era el verdadero problema: era el reflejo de una forma de trabajar que podía mejorarse.

En aquella época nadie hablaba de ERP, BPM ni transformación digital. Simplemente intentábamos entender el trabajo de las personas y ayudar a que pudieran hacerlo mejor con la tecnología.

Nunca empecé por la herramienta. Siempre empecé por comprender. Y esa forma de trabajar —primero observar, después cuestionar, solo entonces proponer— terminó siendo la base de todo lo demás.

Poco a poco, el software dejó de ser el objetivo y pasó a ser una consecuencia. Primero había que comprender el trabajo. Después decidir cómo mejorarlo. Solo entonces tenía sentido plantear una solución.

Y cuanto más entendía los procesos, más descubría que dependían de un nivel aún más amplio: la organización, sus riesgos, sus proveedores, su continuidad, su seguridad, su regulación.

Las preguntas son las mismas. Solo el sistema es más grande.

Hoy, cuando analizo una tecnología, un proveedor o un riesgo, me hago las mismas preguntas que me hacía sobre un programa en BASIC: ¿qué problema resuelve?, ¿qué dependencia crea?, ¿qué pasa si falla?, ¿cómo se recupera?, ¿quién lo mantiene?, ¿qué alternativa tenemos?

Las preguntas no han cambiado. Solo ha cambiado el tamaño de las consecuencias. Antes un error podía romper un programa. Hoy una mala decisión puede afectar a procesos, equipos, proveedores o a la continuidad del negocio.

Con el tiempo descubrí que mi trabajo no consistía únicamente en resolver problemas técnicos. Consistía en ayudar a que una organización pudiera tomar mejores decisiones sobre tecnología. Algunas veces significaba implantar algo nuevo. Otras veces significaba decir que no. Muchas significaba reducir un riesgo antes de que apareciera. Y otras simplemente consistía en hacer preguntas que todavía nadie se había planteado. Y eso, con los años, ha terminado siendo la parte que más disfruto de mi trabajo.

Por eso hoy intento aportar algo que considero importante. No consiste en conocer más herramientas, sino en conectar mundos que normalmente viven separados: tecnología y negocio, estrategia y operación, innovación y gestión del riesgo, normativa y realidad técnica, usuarios y sistemas, proveedores y continuidad.

Una mala configuración puede convertirse en un riesgo. Un backup sin probar puede fallar cuando más lo necesitas. Un proveedor mal gestionado puede ser tan crítico como un fallo del sistema. La seguridad, la continuidad y la regulación no son capas separadas de la tecnología: son la misma conversación, ampliada.

Y hoy ocurre lo mismo con la inteligencia artificial. Aparecen herramientas nuevas, riesgos nuevos, preguntas nuevas. Pero el método sigue siendo el mismo: primero entender, después decidir.

Para qué escribo esta web

No escribo para demostrar lo que sé. Escribo para ordenar lo que voy aprendiendo y compartir cómo razono. Aquí encontrarás artículos técnicos, reflexiones sobre gestión, historia personal y análisis de riesgos. Unas veces hablo de tecnología. Otras de procesos. Otras de decisiones que tomé y de lo que aprendí.

Todas las herramientas y tecnologías sobre las que escribo —sean de ayer o de hoy— responden a la misma idea: entender mejor para decidir mejor.

Sigo leyendo. Sigo probando. Sigo equivocándome. Y sigo disfrutando aprendiendo. No porque crea que tengo todas las respuestas, sino porque sigo disfrutando haciéndome preguntas.

Nunca perseguí tecnologías. Siempre perseguí comprender mejor los problemas.

Con el tiempo descubrí que mi trabajo nunca consistió en gestionar tecnología. Consistió en ayudar a las personas y a las organizaciones a trabajar mejor utilizando la tecnología cuando realmente aportaba valor.

Cuando miro hacia atrás, me doy cuenta de que han cambiado los ordenadores, los lenguajes, las herramientas y la forma de trabajar. Pero sigo intentando responder a la misma pregunta que me hacía delante de aquel ZX Spectrum: ¿cómo funciona realmente esto?

Creo que comprender los problemas antes de intentar resolverlos sigue siendo, hoy, la mejor forma de tomar buenas decisiones. Y probablemente esa sea también la mejor forma de entender la tecnología.