Gestionar las relaciones profesionales: un arte olvidado que mejora los equipos de TI

El éxito de un líder de TI requiere dominar una amplia gama de habilidades. Hay que tener perspicacia técnica y conocimientos empresariales, ser un gran comunicador y solucionador de problemas y saber cómo conseguir financiación y capitalizarla. Pero sacar el máximo partido del personal de TI y generar sinergias entre los equipos de esta área es una de las habilidades más infravaloradas que debe tener un líder de TI para optimizar los esfuerzos de su organización. Para ello debe desarrollar un asombroso don para la gestión de relaciones y comprender cómo se imponen las distintas personalidades y hacer que unas trabajen con otras.

Al fin y al cabo, en TI confluyen perfiles muy diversos, desde estadísticos, matemáticos y desarrolladores arraigados en los rigores de la informática, hasta estudiantes de humanidades que podrían escribir una novela si con ello pudieran pagar las facturas. 

¿Cómo puede el director de TI unificar estos roles tan dispares en un equipo de proyecto cohesionado? La respuesta corta es que no hay que intentar cambiar a nadie. En su lugar, hay que aprovechar los objetivos comunes de la mayoría de los miembros del equipo: ver el éxito, sentirse bien con el trabajo que hacen y contribuir de forma que se aprovechen sus puntos fuertes, evitando al mismo tiempo lo que consideran desagradable o improductivo.

Claves para gestionar las relaciones personales en un equipo informático

Dominar esto, por supuesto, no es fácil. Para los CIO puede requerir tanta psicología como la adecuación de competencias cuando se crea un equipo de proyecto. Y por mucho que se hable de equilibrio de aptitudes en la creación de equipos, la química entre las personalidades implicadas (sus relaciones y formas de aportar lo mejor de sí mismos a las tareas que tienen entre manos) suele ser la clave para desbloquear sinergias que de otro modo estarían ocultas en sus equipos.

He aquí un ejemplo: supongamos que está desarrollando un sistema de venta al por menor que se utilizará en Europa y Estados Unidos. Los países europeos cobran un impuesto sobre el valor añadido (IVA) a los productos, mientras que EE.UU. utiliza un impuesto sobre las ventas que varía según el Estado. En Europa, los impuestos del IVA también varían según el país, por lo que los analistas de negocio trabajan con los usuarios finales en los formatos de pantalla y los flujos de procesos para la entrada de pedidos de venta, etc., pero también se cuenta con un programador de infraestructura de TI para desarrollar un módulo interno de calculadora de impuestos que se pueda llamar y que pueda aplicar el tipo correcto del IVA o del impuesto sobre las ventas a una transacción determinada en función del país o estado de EE.UU. de que se trate.

En nuestro ejemplo, la programadora de infraestructuras suele trabajar (y prefiere hacerlo) por su cuenta. Su dominio es ponderar y desarrollar trabajos técnicos de gran complejidad, y si no habla con nadie en un día, es preferible.

Tú lo entiendes, así que para limitar el tiempo de esta persona en el lado "personal" de TI, asignas el control de calidad al equipo de control de calidad, así como al analista de negocio y al usuario final implicados en el proyecto. Si por alguna razón surge un problema con el módulo de la calculadora de impuestos, es el analista de negocio experto en TI, que puede hablar el idioma de la programadora de infraestructuras, quien se compromete con ella a realizar los cambios necesarios.

Este ejemplo parece sencillo, pero subraya algo sutil sobre la gestión de las relaciones que va más allá de los acuerdos de trabajo basados en funciones. Al contrario que en metodologías de desarrollo como la ágil, aquí no se trata de implicar a todo el equipo en cada fase del proyecto. Lo que se hace es tener en cuenta el modo de actuación preferido de cada uno para que puedan hacer su mejor trabajo.

Cómo poner a trabajar a cada personalidad

He hablado con otros directores de sistemas de información sobre situaciones como ésta y les he preguntado si tienen en cuenta la personalidad de los empleados a la hora de establecer procesos de trabajo. Muchos contraargumentan: "No pensamos en las personalidades. Pero acabamos dirigiendo nuestros proyectos así de todos modos, porque no queremos que nuestros programadores de infraestructuras más caros pierdan el tiempo en reuniones de usuarios".

Touché. Pero también hay un ingrediente en la dotación de personal de los equipos de proyecto que debe tener en cuenta las sinergias naturales entre las personas. Y esto requiere conocer las personalidades individuales de tu equipo.

Entre los tipos de personalidad que he encontrado al dirigir organizaciones de TI, estos son los más frecuentes:

- El analista de negocio y consumado comunicador y empático que tiene un talento natural para trabajar con los usuarios finales en los proyectos.

- El programador que disfruta más trabajando por su cuenta en cuestiones técnicas, pero que tratará los fallos técnicos con un analista de negocio experto en TI que sirva de enlace con los usuarios finales.

- El solucionador de problemas que "salva el día", que trabaja mejor bajo alta presión y es natural para resolver problemas críticos de producción e instalación de sistemas.

- El mentor "solidario" que podría estar llegando al final de una ilustre carrera en TI y está interesado en formar a nuevas personas en responsabilidades informáticas, y que podría ser la persona perfecta para trabajar junto a un miembro junior de un equipo de proyecto.

- El emprendedor que podría cambiar por completo el enfoque o el calendario de un proyecto con un golpe de genio porque ve una forma mejor de diseñar un elemento clave de un sistema.

- El profesional de TI administrativo que sobresale en la administración de contratos, cumplimiento o proyectos, trabajos importantes que la mayoría del personal de TI no prefiere hacer, pero que deben hacerse.

También he visto tipos de personalidad destructiva, como el gurú técnico que se convierte en una prima donna a la que todo el mundo rinde pleitesía y decide qué proyectos apoyará y cuáles no. Conocí este tipo de personalidad en mi primer trabajo de gestión de proyectos informáticos en una empresa de software. Mi proyecto competía con otros proyectos de la empresa por la atención de esta experta en bases de datos, y ella seguía retrasando mi proyecto porque prefería trabajar en los proyectos de directivos más veteranos. Día tras día, veía cómo se retrasaban los plazos de mi proyecto porque no podíamos actualizar los esquemas de datos. Al final resolví el dilema recurriendo a una persona mucho más joven de mi equipo de proyecto para que hiciera el trabajo. Se cometieron errores y el trabajo se hizo más despacio, pero se hizo.

Lo que aprendí fue que, como responsables de TI, no siempre podemos permitirnos el lujo de colocar a las personas adecuadas en las funciones que mejor les convienen. Pero cuanto más sensibles seamos tanto a las personalidades como a las aptitudes, más cohesionados estarán nuestros proyectos y más contentos estarán los miembros del equipo con su trabajo.