Categoría: Agile

Lampistas y DevOps

Según el diccionario de la Real Academia Española, el “lampista” es el profesional que fabrica, vende o repara lámparas. Sin embargo, en Catalunya y otras regiones de España, suele usarse la palabra “lampista” para hacer referencia a un profesional que tiene conocimientos de fontanería y de electricidad. En mi caso, incluso he requerido de los servicios de uno de confianza para temas relacionados con el gas, la caldera, el aire acondicionado e incluso la antena de la TV.

Una experiencia que tuve precisamente hace unos años con mi lampista de confianza me recordó de una manera extraña a lo que sigue pasando en las empresas con el concepto de DevOps (vamos a llamarlo concepto de momento…).

El caso es que tuve en casa un tema complicado relacionado con unas tuberías, y mi lampista me dijo, más o menos textualmente: «yo podría ponerme y darte una solución, pero debido a lo que estoy viendo, casi que te recomiendo que llames a un fontanero que te lo deje fino fino y bien arreglado. Las cosas del agua son muy jodidas si no quedan del todo bien».

Considero que mi lampista de confianza es un muy buen profesional. Así me lo ha demostrado desde hace años con mil cosas que me ha arreglado, instalado, ajustado… y me fie de su consejo e hice venir a un fontanero profesional que solucionó el problema.

Muchas empresas insisten en ofrecer ofertas de trabajo para fichar a perfiles DevOps, y cada vez que veo una, me acuerdo de la experiencia con mi lampista y el fontanero. Si se trata de una empresa pequeña, normalmente están buscando un hombre o mujer orquesta que sepa programar, promocionar (con testing incluido) el código desde los entornos de test hasta el entorno de producción y, a la vez, ser capaz de administrar dichos entornos. Si la empresa es grande, la cosa suele cambiar y el perfil buscado se centra más en un ingeniero de operaciones de sistemas con conocimientos de herramientas para implementar un sistema de promoción de código (no olvidemos el testing), dejando el perfil de desarrollador a un lado, pero incluyendo la administración de dichas herramientas y de los entornos productivos y de desarrollo.

Pero realmente, DevOps no es un rol que pueda desarrollar y/o encargarse de los sistemas de promoción de código (con testing!!) y además administrar dichas herramientas, los entornos, etc… Cuando las cosas vayan mal dadas o cuando quieras garantías de éxito en tu empresa (como con el tema del agua en mi casa), vas a querer que venga el fontanero, y no alguien que, aunque tenga conocimientos de muchas cosas, no sea experto en ninguna de ellas… no? Y con eso no quiero decir que no pueda haber lampistas excelentes a la vez que excelentes perfiles capaces de hacerlo todo en un contexto de ALM, pero como digo, seguramente vas a preferir, y va a ser más fácil, encontrar un crack que desarrolle muy bien, otro experto en las herramientas de promoción (con testing automatizado!) y un equipo 7×24 que garantice el rendimiento y la estabilidad de los entornos.

devops-devolution-770x300

Así pues, para entender más claramente qué es realmente la metodología de creación de software DevOps, su relación con el agile, e incluso cómo surgió el concepto, os recomiendo estas dos lecturas: «Qué es DevOps (y sobre todo, que no es DevOps)» y «El legendario origen del movimiento DevOps», ambos de José Ruiz Cristina.

Por si no tenéis mucho tiempo, un resumen rápido :

  • DevOps es una metodología de desarrollo software basada en la integración entre desarrolladores y administradores de sistemas.
  • DevOps no es una cultura, pero es necesario un cambio cultural importante para utilizar dicha metodología.
  • Que el cloud ayuda, en mi opinión, a confundir el concepto al eximir a los equipos de IT de temas relacionados con la operación clásica al crear y configurar el hardware a través de software y delegar la administración tradicional en los proveedores del servicio (nada nuevo esto último en según que contextos).

Y, sobre todo, DevOps no es un lampista.

Las transformaciones y los egos.

Los retos tecnológicos de las transformaciones, si éstas son de calado, pueden ser complicados. Integraciones, cambios de framework, implantación de nuevos procesos… mil historias que pueden parecer, en más de un momento, una montaña que no vas a conseguir remontar.

Aun así creo que esos retos no son los que suelen hacer fracasar procesos de cambio. Al fin y al cabo, nuestra formación nos prepara para asumir este tipo de dificultades técnicas y, si no somos muy paquetes, mejor o peor ese tipo de cosas acaban saliendo adelante.

Pero para lo que no estamos formados es para tragarnos nuestro ego. Muchas veces las transformaciones requieren de redefiniciones de roles que pueden atacar a lo más profundo de nuestro corazoncito profesional. De aquellas situaciones en las que alguien puede sentir que una situación le saca de su zona de confort, las más difíciles de llevar no son aquellas que suponen un reto técnico, sino las que interpretamos que pueden provocar un cambio significativo de funciones dentro del ecosistema de la organización, siendo las peores las que leemos como pérdida de atribuciones, poder, estatus… en definitiva, un golpe seco a nuestro ego.

Para una empresa que, de forma más o menos real (nada de un simple baño de chapa y pintura), pretenda afrontar una transformación ágil, la gestión de los egos vuelve a ser un tema fundamental. Ya no se trata simplemente de la gestión de los escépticos. Un posible innovador o visionario (que por lo tanto debería ser un aliado de la transformación) con el ego herido o amenazado, puede ser un problema más dificil de superar que el mayor reto técnico que se nos pueda ocurrir.

En este tipo de transformaciones, el empoderamiento de los equipos puede ser una amenaza para el midle management y para determinadas áreas de negocio. Los equipos multidisciplinares cambian el paradigma de los departamentos estaco monofunción, que deben adaptarse, por ejemplo, a un modelo de comunidades, cambiando el control total por la definición de reglas del juego a seguir en cada equipo.

¿Y cómo hacemos para gestionar estas situaciones? Creo que la respuesta es igual de clara que complicada: haz que las personas clave se sientan involucradas en la transformación. De alguna manera. Seguro que hay alguna.

¿Y dónde ponemos el límite en la identificación de las personas clave? ¿Cómo hacemos para que todas ellas se sientan involucradas sin que el tema se convierta en algo ingobernable? Nadie dijo que fuera a ser fácil.

IMG_1592 (1)

«Haz que las personas clave se sientan involucradas en la transformación».

Recelos existirán siempre. Y gente en contra, dispuesta a hacer fracasar el cambio, también. Es por ello que es tan importante la fase de análisis de «a quién necesitamos a bordo para que nos ayude«, bien sea porque pueda ser un entusiasta, o bien porque el cambio le vaya a afectar tanto (e igual no del todo a su gusto) que sea muy aconsejable que por lo menos sienta que está ayudando y que está siendo informado de lo que está pasando y en lo que se va a transformar su área, departamento, empresa, etc…

Y en ese punto, tanto para los que podamos involucrar como para los que sea imposible hacerlo, recordad que los conceptos de transparencia y de métricas accesibles son fundamentales. Vamos a dejar que quien quiera se informe de lo que estamos haciendo y de lo que queremos hacer. Y vamos a medir nuestros avances de forma clara y objetiva lo antes que sea posible, para que los números hablen por nosotros y, esperemos, nos ayuden a convencer a quien haga falta de que vamos por el buen camino.