Comparte:
Transformación Digital
13 de febrero de 2018

Gestión de objetivos y motivación en proyectos DevOps

Gestión de objetivos y motivación en proyectos DevOps

Gestión de objetivos y motivación en proyectos DevOps

Escrito por , 13/02/2018

Todos hemos oído hablar de organizaciones en las que se arrancan proyectos que no llegan a buen puerto, se quedan a medias de los objetivos propuestos o han tenido que reducir el alcance original. Seguro que no nos ha pasado a ninguno… En estas ocasiones uno suele tener un amigo que le cuenta estas cosas.

Cuando nos planteamos un proyecto de gran calado o una transformación, como  el despliegue de un modelo de trabajo DevOps, no podemos permitirnos cometer este tipo de errores. Pero ¿cómo evitarlos?

Una vez más, el cine del oeste nos permite ilustrar este tipo de situaciones. En “Incidente en Ox-Bow” (The Ox-Bow incident, William A. Wellman, 1943) se nos cuenta la historia de un pueblo que sufre el acoso de una banda de cuatreros, ladrones de ganado, que han llegado incluso a asesinar a un granjero. Como consecuencia, se organiza la clásica partida de búsqueda y captura para cazar a los forajidos y darles su merecido. El sheriff local ha dado la instrucción clara de que los delincuentes deben ser encarcelados y juzgados. Pero… ¿cumplirá la partida su misión o las circunstancias y el día a día terminarán alterando los objetivos?

Respecto a la transformación operativa siempre se dice que debemos centrarnos en tres claves: personas, procesos y herramientas, y que la más importante es la primera. Pero muchas veces, con las presiones y urgencias de la vida diaria, se nos olvida que las personas no son artilugios mecánicos a los que basta con darles una orden para que la ejecuten. Las personas tienen (tenemos) expectativas, necesidades, sentimientos, cambios de humor y comportamientos variables dependiendo de las circunstancias.

En cualquier proyecto, pero aún más en los de transformación, debemos distinguir tres papeles principales:

  • El patrocinador
  • Los gerentes
  • Los técnicos

El patrocinador

No es baladí que éste sea el único rol para el que utilizo el singular. Patrocinador hay uno. Si hay más de uno será que o bien no hay ninguno o que entre los dos (o más) quedan zonas grises. Y ninguna de las dos cosas es buena.

El patrocinador es el mecenas del proyecto. Quien lleve el día el día de la puesta en marcha de una iniciativa de transformación en torno a DevOps deberá asegurarse de que esta figura presida la reunión de lanzamiento (kick-off) del proyecto, aunque esa participación se limite tan solo a unos minutos. Su presencia es fundamental para que cualquier unidad implicada en el proyecto perciba con claridad que éste no es un proyecto más, sino que hay que prestarle atención. Y, lo que es mucho más importante para su viabilidad, dotarlo de medios.

Pero existe un riesgo inmenso con el patrocinador, y es que su interés por el proyecto se enfríe con el tiempo. Si empezamos a sufrir crisis, dicho interés se mantendrá por sí solo, pero éste es precisamente el escenario del que debemos huir. La única manera de mantener su atención a lo largo de la duración del proyecto requiere un esfuerzo importante del director de proyecto e implica principalmente dos actividades:

  1. Realizar un seguimiento quincenal o semanal con el patrocinador en forma de cuadro de mando, de manera que, en pocos minutos, y de forma visual, pueda obtener una imagen clara de la situación, percibir los avances y conocer los principales resultados que se puedan ir obteniendo.
  2. Planificar quick wins que permitan dar a conocer  los hitos más relevantes de la transformación ejecutados y de los productos que resulten de los equipos de trabajo. Estas presentaciones de resultados, que deberán ser breves como en el punto anterior, permitirán seguir mostrando el empuje del patrocinador sobre el proyecto al resto de miembros del comité ejecutivo.

Los gerentes

Los mandos intermedios suelen ver su participación en proyectos extraordinarios con una mezcla de suspicacia y oportunidad. Suspicacia porque para sus equipos significan una sobrecarga respecto a la actividad que deben atender regularmente. Pero también como una oportunidad que les permite dar mayor visibilidad a su aportación a la organización, lo cual les interesará tanto para su propia trayectoria profesional como para obtener apoyos en la defensa de otros proyectos que sean relevantes para ellos.

La clave para que la balanza de cada uno de los gerentes se decante por nuestro proyecto dependerá precisamente de que su participación tenga visibilidad en los cuadros de mando presentados al patrocinador, y a los que me he referido en el punto anterior. Cualquier mando que perciba que el director de proyecto le considera como una parte fundamental, y que vea que su participación en los resultados llega al comité ejecutivo, se convertirá en un motor de esta iniciativa de transformación, incluso aquéllos que en un principio pudieran mostrar mayores resistencias.

El equipo técnico

La gestión de la motivación del equipo técnico es, desde mi punto de vista, la que mayores satisfacciones podrá dar al director del proyecto de transformación.

El equipo técnico debe ser seleccionado, como hemos explicado en ocasiones anteriores, por su actitud mucho antes que por su aptitud técnica. Y para sostener e impulsar esa actitud y su implicación con el proyecto y sus resultados, deberemos cumplir con la promesa de que los miembros del equipo son realmente quienes toman las decisiones técnicas y de planificación para cumplir con los objetivos. Es decir, motivar a un equipo DevOps consiste simplemente en cumplir que sea un equipo DevOps.

La gestión de la motivación por parte de los actores participantes en un proyecto debe ser constante, y el director de proyecto deberá marcarlo en su agenda con la misma prioridad con que lo hace para cualquier otra actividad técnica o de gestión. Dar por supuesto que las personas traemos la motivación “en la mochila” puede convertirse en un error que termine minando el proyecto, sus plazos y sus objetivos.

En “Incidente en Ox-Bow”, el sheriff no tuvo en cuenta que podría surgir un grupo de exaltados que hiciera perder el objetivo de la misión y, dejándose llevar por apreciaciones incorrectas, terminar cometiendo fatalidades que les costarían un alto precio. Nuestros proyectos no tendrán, afortunadamente, un final tan dramático como el de esta película pero podemos aprender de ella para que no caigamos en nuestros proyectos en los mismos errores.

Imagen: Cartel de la película “The Ox-Bow Incident”(William A. Wellman, 1943.

Sobre el autor

Eduardo Méndez Polo

Eduardo Méndez Polo

Llevo 26 años en este mundo de las TI, con lo que me ha dado tiempo a conocer una gran variedad de tecnologías, metodologías operativas y buenas prácticas. Por suerte (y por ganas) he podido también realizar casi todo tipo de funciones: desarrollo software, gestión de la calidad, despliegues, operaciones, infraestructura, planes técnicos y estratégicos… Los temas más recientes en los que me he visto envuelto han sido cloud computing y DevOps. En mi tiempo libre formo parte del Coro Gospel de Boadilla del Monte, y he dado unos primeros pasos en el complejo mundo del modelismo espacial…
Ver todos sus artículos »