El papel del gurú en DevOps

Todas las grandes organizaciones TI tienen su elenco de gurús. Me refiero a esas personas con conocimientos técnicos elevados que resultan absolutamente imprescindibles cuando se desarrolla un proyecto en el que la empresa se la juega, o cuando surge algún incidente complejo que exige contar con la dedicación de los mejores. Hasta en las estructuras más pequeñas los hay pero si hablamos de una gran empresa habrá varios identificados: el gurú de las comunicaciones, el de las base de datos, el experto en sistemas operativos, el de la seguridad… Y no solo en cuestiones tecnológicas, a veces también hay gurús de los procesos que incluso llegan a bautizar con su nombre a elementos creados por ellos: la red de Fernández, el servidor de base de datos de Maria Luisa, la cloud de Martínez…

Pero ¿es bueno para las organizaciones que haya gurús o una excesiva dependencia de los mismos puede resultar perjudicial? Y ¿cuál puede ser su papel en un proyecto DevOps?

Una de las grandes películas western de la historia, “Raíces profundas” (Shane, George Stevens, 1953), cuenta la historia de un pistolero en busca de su redención que entra a trabajar para el granjero Starret. Pero los granjeros son acosados por el potentado Ryker y sus secuaces, que quieren echarlos del valle con malas artes, por lo que Shane, el pistolero, al final se ve forzado a demostrar sus habilidades y se enfrenta a ellos. Logra salvar a los granjeros, pero se ve obligado a marcharse de allí para seguir huyendo de su pasado.

El mayor inconveniente que puede surgir entre los gurús y el modelo de trabajo DevOps es, como ya comenté  en “La cultura de trabajo de un equipo DevOps”, que este tipo de equipos se forma entre iguales, es decir, no hay un jefe entre ellos que lidere al resto. Y, desgraciadamente, al poner a un gurú entre una serie de profesionales “comunes”, éstos tenderán a mirarlo como líder oficioso, lo que dará al traste con la necesaria evolución de los miembros del equipo hacia una responsabilidad y un compromiso compartidos.

En segundo lugar, hay una terca realidad que no podemos obviar: la capacidad técnica y la experiencia del gurú continuarán siendo reclamadas en numerosas ocasiones fuera del equipo DevOps. Esto terminará afectando no solo a su rendimiento en el proyecto, sino también a la motivación del resto del equipo, que verá cómo quien debería ser baluarte y garante de los resultados, desaparece de tanto en cuanto para atender otras labores.

Pero si el gurú no puede formar parte de un proyecto DevOps,  ¿cómo se puede aprovechar entonces su conocimiento?

Como ya he explicado en este blog, en DevOps el equipo es pequeño, corresponsable y multidisciplinar. Posee las habilidades core necesarias para realizar su trabajo pero, evidentemente, no puede (ni debe) incluir todas las capacidades técnicas. Por poner un ejemplo, en la mayoría de los casos el equipo DevOps no deberá incluir especialistas en tecnologías tales como seguridad, middleware, bases de datos, almacenamiento, comunicaciones, etc. Sin embargo, los conocimientos en dichas áreas seguramente serán fundamentales en la mayoría de los proyectos.

Para resolver este aspecto cada una de dichas unidades técnica, debe ofrecer dos modalidades de trabajo: una en modo despacho para los proyectos convencionales y otra en modo servicio, que será adecuada para muchos proyectos, entre ellos, los DevOps. Veámoslo:

• El modo despacho permite garantizar una gestión de los flujos de trabajo adecuada y maximizar las eficiencias. Se basa en que la unidad administra las colas de solicitudes y las asigna al personal que atiende cada una de ellas, según sus propios criterios de prioridad, cliente, plazo de resolución, etc.
• El modo servicio consiste en asignar uno o más técnicos para atender los proyectos en los que se les necesita, donde participan de forma proactiva. El técnico se reúne regularmente con cada uno de los equipos DevOps para entender no solo cuáles son las tareas concretas que se le van a requerir, sino que tratará de conocer el propósito del proyecto en desarrollo y deberá ofrecer las alternativas existentes. Por otra parte, en este caso el técnico no esperará a que haya un registro de solicitud, sino que será él quien resuelva el trámite administrativo antes, durante o después de la ejecución de la actuación que se le solicite.

Esta dedicación del personal técnico en una parte o la totalidad de su tiempo de trabajo a los equipos DevOps sí que encaja con la contribución que un gurú puede realizar a los proyectos de este tipo. De hecho, su prestigio en calidad de los resultados y fiabilidad le granjeará el respeto de los equipos DevOps para aportar nuevas ideas.

En el pequeño pueblo de Wyoming donde transcurre “Raices profundas”, la contribución del gurú interpretado por el flemático Alan Ladd consigue cambiar el destino de los granjeros. Pero una de las consecuencias de su significativa aportación es que, una vez terminado el trabajo en el que es especialista, debe marcharse a otro lugar. Y ésa es la condena del gurú que, a pesar de su reconocimiento y precisamente por ello,  no puede permanecer en un mismo sitio. No pertenece a ningún lugar.

Imagen: Cartel de Shane, “Raíces profundas”

Gráfico: Eduardo Méndez Polo