Cuando una profesora nombró lo que era

Estaba en Valencia, España, en una clase del máster, cuando una profesora dijo algo que se me quedó grabado.

Dijo que el equipo perfecto para resolver un problema complejo era la triada: un ingeniero industrial, un matemático y un programador.

El industrial para entender el negocio desde adentro — no desde un manual, sino desde las personas que hacen el trabajo todos los días. El matemático para convertir ese problema en lógica, en fórmulas, en algo que se puede optimizar. Y el programador para construir lo que el industrial y el matemático ya tienen claro.

Lo que no le dije a mi profesora ese día es que yo ya había visto eso antes. Solo que nunca lo había llamado así.

# Venezuela: El Proceso Físico

En Venezuela, antes de emigrar, trabajaba como contratista industrial. Una de las cosas que más hacía era entrar a una planta, mirar cómo estaba organizada, y preguntarme por qué las cosas estaban donde estaban. A veces la respuesta era que nadie lo había cuestionado nunca.

Había una máquina cuya posición tenía sentido en el pasado — cuando la materia prima se traía directamente desde afuera de la empresa. Pero la empresa creció, cerró el galpón por completo, y de repente esa alimentación directa ya no era posible. La máquina seguía en el mismo lugar. El proceso había cambiado, pero nadie había movido nada. Seguían trabajando así porque siempre se había hecho así — hasta que presioné para cambiarlo.

Eso es lo que hace un ingeniero industrial: ve la empresa como un proceso. Y un proceso siempre tiene la misma estructura básica, sin importar la industria. Siempre hay una materia prima, una transformación y un producto terminado. Todo lo demás es detalle. Importante, pero detalle.

# Chile y el Giro a los Datos

Cuando llegué a Chile en plena pandemia y formé una empresa para importar máquinas láser desde China, no sabía nada de esas máquinas. Sí sabía vender, negociar y entender qué necesitaba un cliente. Lo primero que hice fue aprender cómo funcionaban — no para ser técnico, sino para poder traducir el problema del cliente a una solución concreta.

Cuando decidí estudiar el máster en logística en Valencia, no fue por acumular un título. Fue porque quería ponerle nombre y estructura formal a algo que ya hacía de forma intuitiva. Y cuando después hice el máster en Big Data, fue porque entendí que los datos son la materia prima del siglo XXI — y un industrial sin datos trabaja a ciegas.

# El Sistema 3PL: Construir desde Adentro

El primer sistema que construí fue para la empresa 3PL donde trabajo. Una operación real, con carga moviéndose entre Irlanda, Estados Unidos y América Latina, gestionada con Excel, WhatsApp y correos que se traspapelaban. Había un ERP llamado Magaya — bueno, potente, completo. Y nadie lo usaba. No porque el equipo fuera incapaz, sino porque estaba sobredimensionado para lo que necesitábamos.

Así que decidí construir algo a medida. Y ahí empezó el aprendizaje real.

Cada módulo que terminaba me dejaba con la misma duda: ¿está bien? ¿Cómo sé que está bien? ¿Cómo me doy cuenta de los errores silenciosos?

Esas preguntas me llevaron a entender el testing, la validación, los triggers de base de datos que garantizan consistencia sin depender de que alguien recuerde hacer algo manualmente. Aprendí desarrollo asistido con IA — no como atajo, sino como conversación: tú planteas el problema, el sistema propone, tú cuestionas.

# La Academia: El Problema Real

Un día, en una conversación con un amigo, me preguntó a qué me dedicaba. Acepté el reto de construir un sistema para su academia. Pero antes de abrir el editor, le pregunté qué le preocupaba.

Me dijo que no llevaba bien la asistencia. Le pregunté por qué eso le preocupaba. Me dijo que cuando iba a pagar a los profesores, no sabía si estaba pagando bien o mal.

Ahí estaba el problema real. No era la asistencia — era que sin asistencia confiable, no había forma de calcular lo que le correspondía a cada profesor.

Fui hacia atrás: si el pago depende de la asistencia, necesito controlar quién entra a cada clase. Si necesito controlar entradas, necesito que sea rápido para que no sea una tarea que nadie quiera hacer. Y ya que el dueño quería carnets — listo: QR, lector USB, entrada en dos segundos.

Entendí el flujo completo antes de escribir una sola línea de código. En dos semanas, el sistema estaba en producción con más de 240 alumnos activos.

Un equipo de desarrollo convencional habría necesitado semanas de reuniones para entender lo que yo entendí en una conversación de media hora. No porque sean peores — sino porque primero tendrían que estudiar cómo funciona una academia. Yo ya tenía esa información. No en un documento de requisitos — en la conversación.

# Los Tres Idiomas

Hay algo que me pasa cuando algo no me cuadra: no lo puedo soltar. No es ansiedad — es curiosidad con dientes. Me quedo hasta encontrar el porqué. Busco, me documento, investigo la mejor manera, planteo la solución. Y cuando la encuentro, no solo la implemento — la entiendo.

Esa pregunta constante — ¿por qué duele?, ¿por qué se hace así?, ¿por qué el flujo no es confiable? — es lo que conecta el ingeniero industrial con el desarrollador en mí. No son dos modos distintos. Son el mismo modo aplicado a materiales distintos: antes eran procesos físicos y máquinas, ahora son tablas, triggers y flujos de datos.

La triada de mi profesora no necesita ser tres personas. A veces puede ser una sola, si esa persona aprendió a moverse entre los tres mundos — y si aprendió que la pregunta más poderosa no es '¿cómo se hace?' sino '¿por qué duele?'

Sé que no hago las cosas perfectamente. Y como se dice que todos los caminos llevan a Roma, en el desarrollo es igual — siempre llego al resultado. Mi esfuerzo está en que sea lo más eficiente posible. Y cuando funciona, lo audito para mejorarlo.