La batuta en IT

Recuerdo que hace mucho tiempo me enviaron a dirigir un proyecto en una empresa de cuyo nombre no quiero acordarme. Se trataba de un desarrollo sobre sistemas Linux que tenía un 30% de retraso y yo sustituía al anterior Jefe de Proyecto que era, al mismo tiempo, el principal experto en la tecnología. Con su marcha, nuestro conocimiento técnico era tal que, cuando nos fuimos de vacaciones de navidad, no apagamos los servidores porque nos preocupaba no saber arrancarlos a la vuelta.

Meses después, recibimos una felicitación formal de la empresa porque, según nos dijeron, fue la primera vez que un proyecto había terminado bien y en la fecha prevista.

El secreto fue la gestión de los recursos humanos, emocionales y técnicos. Comprender al cliente y lo que realmente necesitaba. Como gestor del proyecto, mi trabajo fue ser intermediario entre todos los involucrados, escuchar las auténticas necesidades de todos y cambiar complejas funcionalidades con alto costo de desarrollo por otras más necesarias y, al tiempo, más sencillas de implementar.

En IT suele haber un abismo entre el equipo técnico y el cliente. El problema existe desde hace décadas y el gestor del proyecto debería ser el encargado de resolverlo pero, en la práctica, la mayoría de Jefes de Proyecto o Gerentes son analistas promocionados o consultores de negocio a cargo del equipo técnico y, por lo general, el primero no comprende al cliente ni sabe liderar un equipo y el segundo no comprende al técnico y trata de satisfacer al cliente presionando al equipo técnico.

En otra ocasión, me pusieron a cargo de un equipo de 30 programadores dispersos en otra empresa que no consigo recordar, mi memoria ya no es la que era. Estaban siendo "dirigidos" por un consultor de negocio que aceptaba todo lo que el cliente pedía y lo trasladaba al equipo de desarrollo exigiendo constantes cambios de alcance, replanificaciones, retrasos, etc. Vamos, lo que viene siendo habitual desde hace 40 años.

Cuando llegué, me reuní individualmente con todos los programadores y analistas y les pedí honestidad para conocer sus expectativas, pretensiones y opinión. Creé un equipo dividido en áreas de especialización técnico-funcional y situé a cada persona de manera que tuvieran el mayor equilibrio posible entre lo que podría ofrecer y lo que quería lograr. Yo también fui honesto con todos ellos respecto a la situación, lo que les pedía y lo que estaba en mi mano ofrecer.

Un año después, tuvimos un paso a producción de 20 horas que involucró a unas 50 personas de varios departamentos y diferentes empresas. De aquel día recuerdo varias cosas. La primera es una escena en el que tres personas, ya entrada la noche, estaban sentados juntos en sendos ordenadores intentando resolver un inesperado error en la impresión de las facturas. Lo que hizo que ese momento se me grabara en la memoria es que esas tres personas eran un programador junior, un analista senior y el director de explotación de la empresa. Durante más de una hora, nadie fue jefe de nadie y a nadie se le cayeron los anillos. Eran tres personas que no convivían en el día a día, pero, había que resolver un problema, cada uno hizo lo que pudo y lo resolvieron.

Más tarde, más de madrugada, o más temprano, según se mire, apareció el director de sistemas, con su elegante traje (lo era, de verdad), para ver cómo iba el asunto. Me vio sentado en una silla, con los pies en alto y un cuaderno en la mano, me preguntó, le enseñé el cuaderno y le dije: "cuando todas estas casillas estén marcadas, saldremos". Creo que faltaban unas 3h para abrir las puertas a los clientes y ya habíamos pasado el punto de "no retorno", como el Apollo XIII, pero más terrenal, ya no podíamos anular el proceso y restaurar los sistemas. Se quedó sentado a mi lado un rato, hasta que tuve que levantarme para atender las necesidades que cada equipo iba requiriendo. Porque ese era mi trabajo, atender necesidades, resolver problemas y tomar decisiones. En una noche hice más de 40 llamadas telefónicas, todas a personas que estaban en el mismo edificio que yo.

El otro momento que recuerdo como si hubiera sido ayer sucedió después de marcar en el cuaderno como completa la última incidencia pendiente, pasando de detectada a resuelta y finalmente probada en producción. Entré en la sala a las 5:30 de la mañana, donde había unas 20 personas esperando, me miraron y dije "salimos". Fue como dar una palmada en una manada de moscas, todos los problemas habían sido resueltos y podíamos abrir los sistemas de producción. Taquillas, máquinas expendedoras, backend, frontend, lectores portátiles, todo debía estar en marcha en 10 minutos y cada persona tenía su responsabilidad.

Yo no era el jefe de todas esas personas, de hecho, la mayoría tenían responsabilidades mayores a las mías y eran clientes de mi empresa, pero aquel día la batuta era mía. Yo trazaba las líneas que unían los puntos que eran cada programador, analista, técnico, arquitecto, coordinador y director de área para formar el dibujo del nuevo sistema de .... caray, que no consigo recordarlo.

Como un director de orquesta, el responsable del proyecto debe saber coordinar a personas diferentes y más o menos expertas en su área, con diferentes necesidades, recursos, conocimientos y responsabilidades. Y no tiene que saber de todo, ni tiene que ser el mejor o "el que más" de nada. Porque en su equipo todos sabrán más que él de algo y habrá personas con mayor y menor experiencia, incluso profesionales con mayor nivel salarial, responsabilidad y prestigio.

La batuta es sólo un palito, el trabajo lo hace la orquesta, pero la orquesta está mirando la batuta. Es un círculo que puede ser muy virtuoso o un desastre, si el palito está mal movido.