Destacado

Mi pirámide de prioridades

En una semana dejo la empresa donde he trabajado los últimos 14 años. Ha sido una etapa irrepetible que me ha dado, entre otras cosas, lo más importante de mi vida. Pero cómo aún queda una semana, dejo para más adelante la despedida.

El caso es que, hace ya más de un mes, comenté con mi jefe mi intención de abandonar la empresa para emprender una nueva aventura. Desde aquel día todo ha sido muy raro, una locura. Además del traspaso, he hecho muchas más cosas de lo que se suponía previsible para este periodo de transición que, a priori, pintaba tranquilo.

El caso es que, como a mitad de ese periodo y por circunstancias que no vienen al caso, una mañana me levanté muerto después de haber dormido muy pocas horas durante demasiados días. Mil planes, mil proyectos, mil ideas, largas noches… y pocas horas de sueño. Aquel día me arrastré como pude pero recuerdo que el ánimo, las ganas y la energía de días anteriores se esfumó.

Ese día me di cuenta de lo acostumbrado que estoy a trabajar por cuenta ajena. Y digo simplemente esto comparándolo con la vida que entiendo que deben llevar alguno de mis amigos que son freelance trabajando para lo que les sale, en varios clientes a la vez y con incertidumbre constante.

Que conste que la mayor parte de mi vida profesional ha sido bastante mala a nivel de horarios (siempre he estado vinculado al mantenimiento o desarrollo de sistemas que tenían que estar up & running 7×24, y eso da muy muy mala vida… ), pero al fin y al cabo, desde siempre he tenido un trabajo del cual, cuando podía, desconectaba y punto. Y probablemente me ha dado siempre una falsa sensación de seguridad. Y una nómina a fin de mes.

El caso es que llevaba menos de 15 días cerrando ese trabajo por cuenta ajena de los últimos años, comenzando a hacer los primeros pinitos con una iniciativa propia que me hace mucha ilusión mientras espero que, en un par de semanas, comience, además, mi nuevo trabajo por cuenta ajena.

Habían sido solo 15 días de experimentar, y creo que «de lejos», lo que se debe sentir cuando de lo que hagas directamente tú, de lo que aceptes o no, de lo que plantees o no, etc… depende a lo que te dediques y el dinero que entre en casa. Y en esos 15 días ya me había desestabilizado bastante. Cero momentos de salir a correr, nada de otro tipo de deporte, horarios raros hasta para fijar una hora para comer y, lo comentado al principio: una media de 4 horas dormidas en los últimos días (bastantes…).

Fue así como me di cuenta que no sé si serviría para trabajar de esa manera. Es decir, que creo que en esa situación me desestabilizaría rápidamente. Y eso que habían sido solo 15 días!!

Comentando el tema con mi psicóloga (aprovechando, un off topic: ¿vamos normalizando que hay gente que vamos cada semana a charlar un rato con un@ profesional porque nos va bien y lo necesitamos?… pues venga yo doy el primer pasito… dejo para otro día el tema ansiedad) me dijo que creía que tenía que pensar en cual era mi pirámide de prioridades. Es decir, una lista de no más de 5 elementos que reflejaran, por orden, cuales quería que fueran siempre mis prioridades en la vida (a ver, quien dice siempre, dice ahora y durante un tiempo razonable… :P). Me dijo que la hiciera y que, en los momentos que sintiera que la vida se me desestabilizaba (como acababa de pasar) la revisara y la tuviera presente, cogiéndola como guía para comprobar si la desestabilización estaba poniendo en peligro dicha lista de prioridades.

Pues ayer me senté un rato y dibujé la mía. Que es esta:

Y vamos rápidamente con una explicación que quizás sea lo menos interesante en general, pero es lo primordial para mí:

  1. Me: porque si yo no estoy, o no estoy bien, o ando distraído, nada de las otras cuatro cosas va a poder funcionar bien. Y son las cuatro cosas prioritarias en mi vida, así que no me puedo permitir que no vayan bien. Así que efectivamente, el burro delante. Pero no por egoísmo, es un tema más de que este primer punto es un habilitador del resto.
  2. MAM: Miriam, Abril y Marc. Porque por ellos es por lo único que pondría en jaque al punto 1, aunque suene un poco contradictorio.
  3. Family: porque somos pocos, pero somos muy guays :P. He tenido muuucha suerte, tanto con la directa como con la política. Y porque muchos de ellos (la mayoría) podrían ser los primeros en la lista del siguiente punto.
  4. Friends and Work: Hala, lo que ha dicho!… amigos igual de importante que el curro? Pues va a ser que sí. La verdad es que tengo muchos amigos y dos o tres muy buenos amigos. Pero también es verdad que si el trabajo que haces no te gusta se pone en riesgo el punto 1… y el 2… y el 3… Y además es que mis amigos, los que fundamentalmente llenan los ratos de los días de la semana que no llena el trabajo, tiran mucho. Es decir, que además de gustarte el curro, tiene que dar pagar la hipoteca, los coles, las facturas, un nivel de vida normal (ya sinceramente es lo que aspiro a mantener) y además… aguantarles el ritmo a los amigos!! (es medio coña… pero vamos…). Así que sí señores. Pasamos muuuchas horas en el curro a lo largo de la vida. Así que el curro es importante, y los amigos también.
  5. Side projects: pues esto debería ser como la salsa para aderezar todo lo demás. Si no hay ninguno no pasa nada, pero yo es que, en serio, me apetece tener siempre alguno vivo. Y ojo, que pueden ser fuente de frustración también si tienes ganas de empujar alguno y no puedes por el motivo que sea. Aquí meto parte de mi nueva aventura, pero también el grupillo con el que ensayamos cada vez que podemos, mis canciones a medio acabar en mi piano, mis videos y ese libro que estoy comenzando a escribir desde hace un año :P. No puede ser todo a la vez, por que, de nuevo, se pondría en riesgo el punto 1… y entonces el 2, y el 3… pero puede ser cada uno en una época, según te apetezca. O es así, por lo menos, como yo lo veo.

Y hasta aquí el ejercicio. Ahora se trata de tenerlo presente siempre. E intentar que sirva de guía cuando las cosas se tuerzan (que se torcerán), para intentar ser coherente y rectificar. Y si hay que cambiar algo de orden, porque es otro momento, se cambia. Pero sin perder la perspectiva, e intentando siempre ser un buen tipo.

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.