En 1637 Pierre de Fermat enunciaba el conocido como su último teorema:

“Es imposible descomponer un cubo en dos cubos, un bicuadrado en dos bicuadrados, y en general, una potencia cualquiera, aparte del cuadrado, en dos potencias del mismo exponente. He encontrado una demostración realmente admirable, pero el margen del libro es muy pequeño para ponerla.”

En álgebra moderna diríamos que la ecuación  x^n + y^n = z^n \,no se cumple para ningún conjunto de números enteros positivos n, x, y, z si n es mayor que dos.

Fermat tenía la costumbre de ensayar demostraciones de los teoremas en los márgenes de los libros donde los leía, por eso su afirmación de que había encontrado una demostración resultó creíble para los matemáticos de su tiempo. Pero si lo logró se llevó el secreto a la tumba. Durante más de 300 años muchísimos otros matemáticos intentaron encontrar la demostración, algunos llegando al borde de la locura y recomendando a sus sucesores que se mantuviesen apartados de este infernal problema.

Finalmente, en 1995 Andrew Wiles consiguió la tan perseguida demostración tras 8 años de trabajo dedicados casi en exclusiva a este problema. Él mismo describió el proceso de la siguiente manera:

Uno entra en la primera habitación de una mansión y está en la oscuridad. En una oscuridad completa. Vas tropezando y golpeando los muebles, pero poco a poco aprendes dónde está cada elemento del mobiliario. Al fin, tras seis meses más o menos, encuentras el interruptor de la luz y de repente todo está iluminado. Puedes ver exactamente dónde estás. Entonces vas a la siguiente habitación y te pasas otros seis meses en las tinieblas. 

Exactamente así me he sentido trabajando este último año en un equipo de soporte de Murex, sólo que con ciclos de un mes en cada habitación oscura.

Un mundo complejo

Murex es sin duda el producto de software más complejo que yo haya conocido en toda mi carrera. Sus funcionalidades son virtualmente infinitas y el uso que hacen de ellas sus clientes es muy diverso. El propósito del producto se podría resumir como la gestión de la posición de tesorería, cálculo de riesgos y resultados y control del flujo de operaciones para una entidad que opere con productos financieros mínimamente complejos.

Ser eficiente en un equipo IT de Murex requiere un conocimiento bastante avanzado de:

  • Productos financieros: cómo se calculan los beneficios y cuáles son los riesgos de cada uno de ellos.
  • Varias ramas IT: Bases de datos, Linux, Middleware y experiencia en programación.
  • El ciclo de vida de las operaciones en los mercados financieros: Qué hacen los Ventas, los Traders, Riesgos, el Backoffice…
  • Estar acostumbrado a trabajar con datos: ser muy ordenado para no naufragar en el océano de información.
  • Conocer bien tu organización: Muchos usuarios de muchos departamentos trabajan en la aplicación. Casi nadie sabe lo que hace su departamento vecino. Si mezclas la respuesta de uno con la que has dado a otro no le ayudas y además le confundes.

La misión con la que llegué a este equipo fue la reducción de costes en un momento complicado para mi organización. Era la primera vez en mi carrera que me incorporaba a un equipo donde no tenía conocimiento técnico sobre la labor que desempeña el equipo. Y ese era mi desafío: un rol de gestión sin conocimiento profundo de lo que tenía que gestionar. Hace no mucho tiempo no creía que fuese posible desempeñarse con eficacia en una situación como la que me esperaba. Una cosa más que he desaprendido.

Trabajar en un equipo de Murex requiere gestionar la complejidad. Y esto aplica tanto en el desarrollo de nuevos proyectos como en la explotación del sistema implantado. Este es el resumen de mi experiencia en cada uno de los dos ámbitos.

Proyectos

La evolución del software la realiza el proveedor y la capacidad de añadir funcionalidad a ese software desde el lado del cliente es ciertamente limitada. Se le pueden solicitar cambios específicos pero su entregable será (casi siempre) una versión completa del producto. Cada nueva versión, por tanto, requiere de un esfuerzo brutal de pruebas de compatibilidad regresiva. Estas pruebas son necesarias tanto si los cambios solicitados son enormes como si son meramente cosméticos. El riesgo en el que se pone la organización a implantar incorrectamente una versión es tan grande que el parámetro de la calidad en las de pruebas no es negociable: seguridad total.

La situación por tanto es que el coste marginal de cualquier cambio es enorme y el beneficio económico marginal es en muchos casos solamente hipotético. La única forma de que salgan las cuentas para actualizar el software es incluir muchos cambios en la misma versión para reducir el coste de las pruebas. Pero muchos cambios hacen que el entregable tarde más tiempo en estar disponible.

Esto nos lleva al siguiente conflicto: la negociación de qué cambios se incluyen y cuales se dejan fuera. Cuando no conoces bien tu organización te tropezarás en la oscuridad con más muebles de los necesarios. En general, las expectativas depositadas sobre el software son infinitas. Esperamos que resuelvan incluso los problemas de comunicación con nuestros compañeros.

A medida que avanzan los proyectos se van ajustando los compromisos: no toda la funcionalidad prevista en el Power Point original se consigue, no todos los errores se logran corregir y además aparecen errores nuevos. Al mismo tiempo sí que se consigue implantar nueva funcionalidad y se corrigen algunos errores. ¿Habría alguna forma de conseguir todos los objetivos iniciales sin tener que sufrir nuevos problemas? Seguro qué sí, pero llevaría mucho más tiempo y mucho más coste. Y los tiempos y los costes son dos parámetros muy importantes en todas las implantaciones de Murex. Si llegas demasiado tarde tal vez el negocio ya no pueda obtener la ganancia que esperaba. Si tu proyecto cuesta demasiado eres tú quien se come su ganancia.

No hay que olvidar que los usuarios principales son traders. Su trabajo es negociar. El software es una ciencia ciertamente compleja, pero en última instancia está basada en la electrónica. Y con los electrones no se negocia. Hacen exactamente lo que se les pidió que hiciesen. Si aparece una situación inesperada y requiere cambio de software hay que repetir todas las pruebas desde cero: más tiempo, más coste…

Con todo esto en la coctelera, los proyectos de Murex se convierten en una máquina de generar frustración. Las expectativas son inmensas y la realidad las defrauda continuamente. Todos los participantes acabamos con la impresión de que se podría haber hecho mejor. Todos tenemos una lista de cosas que se hicieron mal. La tarea del director del proyecto es administrar esa complejidad y canalizar esa frustración hacia acciones de mejora para futuros proyectos. También hay quien se enfada y patalea. Incluso hay quien amenaza con no respirar. Luego nunca lo cumple.

Soporte

Después de los primeros seis meses en mi equipo lo rebautizamos informalmente como Soporte Espiritual Murex. La mayoría de las cuestiones que nos llegaban son preguntas de gente que ya sabe lo que tiene que hacer, pero que necesita una de estas dos cosas:

  • Una mera confirmación de alguien que conozca mejor la herramienta.
  • Un descargo de responsabilidad por si se equivoca.

No hay presupuesto que soporte a un equipo de expertos en Murex que pueda proteger a todos los usuarios de las dos contingencias arriba descritas. Por eso mi función principal ha sido reducir la necesidad de soporte por la vía de dotar de confianza a los equipos que ya estaban haciendo las tareas. Para los dos casos apliqué la misma medicina: procedimiento, procedimiento y más procedimiento.

La complejidad asusta: en general todo el mundo pide permiso. En un sistema como Murex tiene sentido que sea así, y con la experiencia de las consecuencias de errores pasados la gente aprende a temer. Al mismo tiempo los operadores que trabajan con el sistema saben hacer muchas más cosas de las que creen. Implantar confianza manteniendo la seguridad sólo se puede lograr con unos procedimientos suficientemente sólidos y suficientemente flexibles para incorporar cambios cuando se estime necesario.

Negociar procedimientos con todos los equipos participantes puede llegar a ser una tarea agotadora. Siempre participan muchos actores y no todos tienen incentivos para llegar a un acuerdo. Pero si se consigue se obtienen dos beneficios inmediatos: reducción de los costes operativos y disposición al compromiso de todas las partes para los procedimientos que estén por venir.

También hay incidencias del producto muy complejas que nadie más sabe resolver en la organización. Y todos los días llega alguna. Estas eran mi principal temor cuando me hice cargo del servicio. Mi experiencia en este sentido se limita a acercarle el botijo a quien las está resolviendo. Y conozco a personas en mi organización que en medio del fuego (y el fuego de Murex calienta mucho) no se paran ni a quitarse el sudor de la frente. Cuando sea mayor yo quiero ser como ellos.

Conclusión

En realidad, Andrew Wiles no demostró el teorema de Fermat. Lo que demostró fue un caso particular de la conjetura de conjetura de Taniyama-Shimura que era el último paso en una larga serie de teoremas, que en conjunto demostraban el teorema de Fermat. Fue el chute que metió el balón en la portería e hizo subir el gol al marcador, pero no otra cosa que la culminación de una sucesión de pasos en el desarrollo de la matemática de los últimos siglos. Conviene recordar la cita de Newton “Si he logrado ver más lejos, ha sido porque he subido a hombros de gigantes”.

Si yo fui capaz de sobrevivir a dirigir un equipo de soporte de una aplicación en la que nunca me había logado, fue gracias a la colaboración que han tenido conmigo absolutamente todos los equipos que conviven en este ecosistema. Equipos que, en su conjunto, cubren con creces todos los criterios necesarios para ser eficiente en un equipo de IT Murex. Y, por qué no decirlo, algunos individuos que también los tienen todos a la vez, gente a la que sólo teniendo cerca ya aprendes un montón.

P.D.: Apenas una semana antes de cumplir mi año de Murex, cuando ya tenía en mente el boceto de este artículo, como si fuera una premonición y mis jefes me metieron en una sala para darme la licencia y encomendarme una nueva misión. Ya he empezado a buscar el primer interruptor.