Cuando empecé en la terminal, quería morirme.
Estás descargando un petrolero a 800 metros cúbicos por hora. Coordinas a un equipo —por suerte, gente que camina sola— y por debajo de todo eso corre un río de datos que no puedes soltar: volúmenes, tiempos, factores de corrección, densidades, temperaturas. Un número mal apuntado mueve toneladas de producto en la dirección equivocada. Y yo, al principio, no tenía ni idea de nada de eso.
Venía de otro mundo. Había estudiado sistemas interactivos, había diseñado páginas web en una agencia de internet en Berlín. Cuando entré en la industria —al principio solo cubriendo bajas y vacaciones como loading master en Shell y en Aegean, soltero, sin saber si aquello iba a durar— llegué sin nada de este oficio. Pero traía una forma de trabajar que no se apaga porque cambies de uniforme.
Mi manera siempre ha sido la misma: observa, aprende, copia, aguanta, y cuando sepas hacerlo con soltura, trata de simplificar. No se simplifica desde la ignorancia. Ese derecho te lo ganas haciéndolo primero a mano, el tedio entero, hasta dominarlo. Así que las primeras rotaciones las pasé callado, copiando lo que hacían los demás, aguantando.
Las noches
El trabajo a turnos tiene una cosa que nadie cuenta: te regala horas muertas. Noches interminables en las que a veces no hay faena, pero hay revisiones que tocan igual. Una de ellas era repasar el schedule para asegurarse de que toda la información estaba correcta al cien por cien.
Ahí empecé. Con mejoras de andar por casa: campos que, al meter un dato, rellenaban solos otros por defecto; listas desplegables para elegir en vez de escribir; filtros por categoría. Nada espectacular. Solo quitar pasos manuales de en medio, uno a uno.
Esas mismas noches daban también para otra cosa: buscar en internet. Y en una de ellas di con las fórmulas para calcular los factores de corrección de la tabla 54 de fuelóleos.
Esa fórmula me cambió la vida.
Con ella monté un Excel en el que metías el volumen de un tanque y te devolvía el volumen corregido a 15 grados, y las toneladas al aire y al vacío. Lo que hasta entonces significaba ir a un libro desgastado, buscar la página, la columna, interpolar a mano y apuntar —cada vez, cada tanque, cada liquidación de un petrolero— pasó a ser meter un número y leer el resultado.
Ese es exactamente el trabajo del que hablo cuando digo monkeywork: tareas para las que se podría entrenar a un mono, hechas por profesionales cualificados, un turno detrás de otro. No es que fuera duro. Es que era indigno del tiempo de alguien que sabe lo que está haciendo. Y era, además, donde entraban los errores: no por falta de conocimiento, sino por repetición y cansancio.
Compartirlo fue el verdadero salto
Cuando las tuve comprobadas, las compartí.
Podría no haberlo hecho. Un fichero así te hace ir más rápido que el resto, y en un entorno de turnos eso se nota. Pero no tenía ningún sentido: el tedio no era mío, era de todos. En poco tiempo el resto de supervisores las estaban usando, porque a todos nos ahorraban lo mismo.
Ahí, sin saberlo, dejé de ser alguien con un truco y empecé a ser alguien que fabrica herramientas para otros. La diferencia parece pequeña. No lo es. Es la primera vez que lo que construyes deja de servirte solo a ti y empieza a sostener una operación entera.
La mezcla que salió mal
Pero antes de eso hubo una lección que me costó cara, y que en realidad es la más importante de este capítulo.
En aquella época, en las mezclas de IFO se trabajaba con hojas de cálculo que ya venían dadas. Una de ellas estaba mal configurada: el porcentaje del fuel estaba puesto donde tenía que ir el del gasoil. Yo la usé. Y le di a un barco una mezcla bastante desviada de lo que había pedido.
Eso no se olvida. Un cliente pide un producto con unas características concretas y tú le entregas otra cosa, no porque no supieras hacerlo, sino porque confiaste en una casilla que estaba en el sitio equivocado.
La conclusión que saqué no fue “no te fíes de las hojas de cálculo”. Fue algo mucho más útil: una herramienta amplifica lo que le pongas dentro, para bien y para mal. Si automatizas un cálculo, dejas de revisarlo. Y si dejas de revisarlo, el día que esté mal, estará mal muchas veces seguidas y con total seguridad aparente.
A partir de ahí supe cómo tenía que montar una hoja: a prueba de fallos. Que no te deje meter lo que no toca. Que enseñe lo que está calculando. Que chille cuando algo se sale de rango. Que el error, si llega, salte antes que el producto.
Cuando llegué a Oryx implementé también los cálculos de IFO para bunker, y con el tiempo adaptamos blenders mucho más sofisticados, en buena medida gracias a información que otros colaboradores nos fueron enseñando. Pero el criterio con el que montaba aquello no venía de un manual. Venía de aquel barco.
Oryx: de plantillas a sistema
A Oryx no me llevé solo las fórmulas. Me encontré con compañeros que las mejoraron —y esa es otra cosa que aprendí ahí: una herramienta que se comparte, evoluciona; una que te guardas, se muere contigo.
Entre todos dejamos de automatizar solo el cálculo de volúmenes y empezamos a trabajar directamente desde los niveles de los tanques, de modo que el fichero devolvía todas las medidas de una vez.
Y atacamos el siguiente trabajo de mono, que era rellenar documentación: plantillas que volcaban solas los datos en los documentos, en lugar de teclearlos otra vez donde ya estaban.
Después vinieron los archivos de seguimiento de cargas y descargas de petroleros. Y ahí hice, sin ponerle nombre, algo que sería importante años más tarde: sistematizar la recogida de datos para poder analizarlos después. Dejar de apuntar cosas para rellenar un hueco, y empezar a capturarlas pensando en qué se podrá saber con ellas más adelante.
La tabla Access: el día que dejé de construir para diseñar
La culminación de todo aquello fue una base de datos en Access.
No la construí yo. Y esa frase, que entonces no significaba nada, hoy explica casi todo lo que hago.
Yo puse la lógica. Volcamos dentro buena parte de las hojas que había ido creando para la planificación de barcos, y le añadimos lo que el trabajo a turnos te enseña por las malas: que toda la información que te llega a ti en tu turno tiene que llegarle igual a quien te releva. Todo lo que se queda en tu cabeza, o en tu libreta, o en un correo que solo tú leíste, desaparece a las ocho de la mañana cuando te vas a casa. El Access capturaba eso. No era un almacén de datos: era el traspaso.
Ahí, sin tener ni idea de que existiera una palabra para eso, hice de arquitecto. Alguien con más manos que yo lo levantó, y mi trabajo fue decidir qué tenía que existir, qué información no podía perderse y cómo tenía que fluir. Mi vieja pasión por la lógica de programación encontró por fin un sitio donde vivir dentro de una terminal de graneles.
Cuando llegó el momento de llevarlo en serio con una empresa de software, yo me fui a Dow. El proyecto se quedó dormido.
Lo que no supe hasta mucho después
Nadie me pidió nada de esto. No formaba parte de mi puesto, no había un proyecto, no había presupuesto. Lo hacía porque no soportaba que el trabajo repetitivo se comiera horas de gente que sabía hacer cosas difíciles.
Tampoco tenía permiso para montar software, ni un equipo de IT esperando mis peticiones. Tenía Excel y las noches. Así que hice la guerra con lo que había.
Lo que no supe hasta mucho después es que en esos años, entre tanques y libros desgastados, ya estaba haciendo tres cosas que hoy son mi oficio: quitar de en medio el trabajo que podría hacer un mono, montar las herramientas a prueba de fallos porque una herramienta amplifica el error igual que el acierto, y asegurar que lo que sabe un turno le llegue entero al siguiente.
El arma era pobre. El instinto era el mismo que veinte años después movería una fábrica entera de agentes.