Cuidado con las sacudidas en el tren a DevOps

Eduardo Méndez Polo    24 julio, 2018

En una ocasión, mientras impartía una conferencia sobre DevOps para grandes organizaciones, uno de los asistentes no paraba de interrumpirme con sus preguntas. Es uno de los riesgos de permitir a la audiencia que te detenga sobre cualquier cuestión cuando lo considere oportuno. Es cierto que los españoles somos poco dados a hacerlo pero aquella vez me tocó la excepción… Y debo reconocer que ese día me costó cierto esfuerzo ser capaz de contestar las dudas de aquella persona sin perder el hilo de la conferencia pero esa situación hizo que me planteara el tema de los obstáculos en DevOps, que también afecta a muchas otras olas de innovación:

¿Qué ocurre cuando no se obtienen los resultados esperados con la implantación de DevOps? ¿Qué sucede si los plazos de desarrollo son superiores a los de los equipos convencionales? ¿Cómo reaccionar si surgen incidentes en producción que exigen un sobreesfuerzo continuado al equipo? Ésta es la pesadilla que acosa cada noche a cualquier director de proyecto. Porque cuando avanzan según las previsiones es maravilloso, pero si el proyecto empieza a torcerse ¿qué hay que hacer? ¿Se debe volver a la operativa convencional?

Es el mismo dilema que se le presenta a Gary Cooper en “El hombre del oeste” (Man of the West, Anthony Mann, 1958), en la que interpreta a Link Jones, un granjero que viaja en tren a Texas con la misión de contratar a una maestra para el pueblo. El tren es asaltado y al poco descubrimos que Jones fue anteriormente miembro de esa misma banda de salteadores, aunque pensaba que ya había dejado esa vida atrás. Cuando su seguridad y la de otros dos pasajeros está en juego ¿defenderá su redención a toda costa arriesgando su vida y la de los demás o volverá a su vida de malhechor y echará, así, a perder su proceso de redención de los últimos años?

Es cierto que si ante el primer obstáculo en un proyecto DevOps se toma la decisión de dar marcha atrás en su implantación refleja un escaso compromiso con los objetivos propuestos y graves carencias en la realización de los assessment (análisis previos a la puesta en marcha). Pero, por el contrario, si el proyecto de implantación se va encontrando con un obstáculo tras otro sin que se obtengan ninguno de los objetivos previstos tampoco tiene sentido mantenerse contra viento y marea, cegados por las ventajas del modelo DevOps.

¿Cómo resolver el dilema entonces? En primer lugar, es necesario adelantarse a la aparición del problema. La fase de evaluación de los proyectos en los que se tenga intención de aplicar el modelo DevOps debe ser realmente rigurosa. Dedicarle tiempo a conocer a fondo los proyectos y tener claras las necesidades del equipo, la demanda de herramientas e infraestructura que deberán utilizarse y establecer las operativas, métricas y el modelo de gobierno será una inversión en tiempo y esfuerzo que no tardará en dar sus frutos en forma de resultados. Y, sin duda, servirá para esquivar algunos de los obstáculos que aparecen con frecuencia. Cualquier problema es mucho más fácil de resolver si ha sido abordado antes de que surja.

Pero ¿cómo hay que reaccionar cuando no se ha sido capaz de realizar la evaluación con todo el rigor necesario? O ¿y si, a pesar de toda la previsión posible, aparecen obstáculos que ponen en riesgo el resultado de la iniciativa? Vaya por delante que no existen soluciones fáciles. Avanzar hasta el punto en que aparece el problema habrá supuesto un trabajo intenso y salir de ese problema tampoco resultará una tarea sencilla.

La tentación (fácil y frecuente) es buscar una vía intermedia de ejecución entre el modelo DevOps y el modelo convencional, encontrar una especie de compromiso entre las dos formas de ejecutar proyectos. Pero esto es un error estratégico. Lo que inicialmente pueda parecer que remueve obstáculos para avanzar en el proyecto terminará consumiendo la capacidad de decisión de los equipos, la agilidad en los despliegues o la unidad de acción entre los roles de desarrollo y explotación.

Lo correcto es, en cambio, volver a realizar la evaluación del proyecto y hacer un análisis comparativo entre el resultado actual y el que se obtuvo antes de arrancar su ejecución. A la luz de las diferencias identificadas deberá ser posible analizar las causas de los problemas que hayan surgido. Pero, más importante todavía, ese ejercicio debe ofrecer información para tomar las decisiones necesarias para recuperar el ritmo y la senda de los resultados. Dichas decisiones serán generalmente duras y con frecuencia llevarán a realizar modificaciones en el proyecto: en el ámbito y objetivos, en las herramientas utilizadas, en la metodología y, en ocasiones, en el equipo que lo ejecuta. Y, no importa el tipo de cambio que sea necesario ejecutar en una o varias de las dimensiones del proyecto, todos ellos serán dolorosos. Pero nuevamente, si se ha realizado el análisis de forma sosegada y reconociendo las virtudes y defectos de la ejecución llevada a cabo, también supondrán soltar un lastre que permitirá comenzar a obtener los primeros resultados parciales. También hay que tener en cuenta que lo que se recorta en este punto se podrá recuperar en una fase posterior una vez que la iniciativa deje de estar sometida a tensiones o cuando los resultados muestren una madurez en el modelo de aplicación. Y no hay que olvidar que, en un modelo de trabajo operativo, no hay por qué aplicar todos los cambios de una vez. Es más, lo idóneo es introducir primero los que supongan un mayor impacto, para ir valorando otros en sucesivas iteraciones.

En fin, no existen los caminos fáciles para recuperarse de los obstáculos. Link Jones, de hecho, debe aplicar toda su inteligencia y valor para salvar su vida y la de sus compañeros de infortunio. Se verá empujado a volver a matar y otras personas saldrán mal paradas de la situación. Pero al final consigue recuperar el camino de redención que había tomado y comprende que el pasado podrá volver a cruzarse en su camino de forma dolorosa.

Imagen: Cartel de la película “El hombre del oeste” (Man of the West, Anthony Mann, 1958)

Comentarios

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *