Julio César Rodas
En 1983 tuve delante un ZX Spectrum de 16K. Sin saberlo, aquel ordenador terminaría marcando mi forma de entender la tecnología hasta hoy.
Mi relación con la tecnología empezó mucho antes de que se convirtiera en mi profesión. Aquel manual de BASIC, los primeros programas y los experimentos con POKE despertaron una curiosidad que todavía sigue ahí: entender cómo funcionan las cosas por dentro y qué problemas resuelven.
Primero fueron juegos pequeños, pruebas, errores y muchas horas intentando comprender por qué algo funcionaba o por qué se rompía. No había YouTube, Stack Overflow ni ChatGPT. Había que leer, probar, equivocarse y volver a empezar.
Después llegaron decenas de lenguajes, sistemas y plataformas —muchos de los cuales ya han desaparecido—, pero el patrón siguió siendo el mismo: tocar, probar, mirar debajo de la superficie y construir criterio. Con los años entendí que mi interés no estaba en perseguir tecnologías, sino en comprender cada vez mejor los problemas que intentaban resolver.
Llevo 26 años trabajando en tecnología. Actualmente dirijo el área de TI y asumo responsabilidades que abarcan la dirección tecnológica, la seguridad de la información y la gestión de los riesgos asociados a los sistemas.
Esta web es un proyecto personal. No hablo en nombre de ninguna organización ni comparto información interna o identificable. Cuando una reflexión parte de una experiencia profesional, conservo únicamente el aprendizaje general y elimino cualquier contexto que pueda identificar a personas, empresas, proyectos o sistemas.
Mantengo un contacto directo con la tecnología. No por nostalgia ni porque pretenda ocuparme personalmente de cada detalle, sino porque creo que, para dirigir con criterio, hay que comprender cómo funcionan los sistemas, qué dependencias crean y qué consecuencias pueden tener las decisiones técnicas.
Ese contacto sigue siendo práctico. Cuando un problema lo requiere, continúo entrando en el detalle técnico, analizando, probando e incluso participando directamente en la ejecución. No porque quiera hacerlo todo yo, sino porque en determinados momentos comprender cómo funciona algo y trabajar sobre ello también forma parte de decidir bien.
No me considero especialista en una única disciplina. Mi trabajo consiste en comprender sistemas complejos, coordinar conocimientos diferentes, evaluar riesgos y tomar decisiones tecnológicas que puedan mantenerse en el tiempo.
Pensaba que el reto era entender el programa
Durante años pensé que lo importante era entender la tecnología. Abrir ejecutables, examinar cadenas, seguir llamadas, saltos, instrucciones CALL y JMP, y reconstruir el flujo de ejecución. Aprendí que lo que aparece en pantalla casi nunca explica por qué ocurren realmente las cosas.
Nunca he visto la tecnología como una colección de herramientas aisladas. 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é ocurre si falla.
Me hacía esas preguntas entonces sobre un programa en BASIC y sigo haciéndomelas hoy ante cualquier tecnología nueva.
Pero con el tiempo descubrí que entender el programa no 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, antes de escribir código necesitaba 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 emitía una factura, cómo circulaba la información y cómo se coordinaban quienes participaban en el proceso.
Muchas veces el problema no estaba en el programa, sino en el proceso. Y, en ocasiones, 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 comprender el trabajo de las personas y ayudarlas a trabajar mejor con la tecnología.
Esa forma de trabajar —primero observar, después cuestionar y 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 y solo entonces plantear una solución.
Cuanto más entendía los procesos, más evidente resultaba que dependían de un sistema mucho más amplio: la organización, sus riesgos, sus proveedores, su continuidad, su seguridad y su regulación.
Hoy, cuando intento comprender una tecnología, una dependencia externa o un riesgo, sigo planteándome preguntas parecidas: ¿qué problema resuelve?, ¿qué dependencia crea?, ¿qué ocurre si falla?, ¿cómo se recupera?, ¿quién lo mantiene?, ¿qué alternativas existen?
Las preguntas no han cambiado. Lo que ha cambiado es 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 incluso a la continuidad del negocio.
Con el tiempo descubrí que mi trayectoria no consistía únicamente en resolver problemas técnicos, sino también en ayudar a que las organizaciones tomaran mejores decisiones sobre tecnología. A veces eso significa implantar algo nuevo; otras, cuestionar una propuesta, anticipar un riesgo o recomendar que no se siga adelante. En muchas ocasiones consiste simplemente en plantear preguntas que todavía nadie se había hecho.
Por eso intento conectar ámbitos que suelen vivir 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 configuración incorrecta puede convertirse en un riesgo. Una copia de seguridad que nunca se ha probado puede fallar cuando más se necesita. Una dependencia externa sin suficiente control puede ser tan crítica como el propio sistema. La seguridad, la continuidad y la regulación no son capas separadas de la tecnología: forman parte de una misma conversación.
Con la inteligencia artificial ocurre lo mismo. Aparecen nuevas herramientas y nuevos riesgos, 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 mi forma de razonar. Aquí conviven artículos técnicos, reflexiones sobre gestión, historia personal y análisis de riesgos, unidos por una misma idea: entender mejor para decidir mejor.
Sigo leyendo, probando y equivocándome. No porque crea que tengo todas las respuestas, sino porque sigo disfrutando haciéndome preguntas.
Cuando miro hacia atrás, han cambiado los ordenadores, los lenguajes, las herramientas y la forma de trabajar. Lo que no ha cambiado es la curiosidad que nació delante de aquel ZX Spectrum: intentar comprender cómo funcionan realmente las cosas.