Baby Steps: Pasos a producción y cambio cultural

Autor: Óscar Bustamante (Principal Software Engineer, Datos)

Cambio cultural, un concepto tan cliché como vago, es una frase recurrente donde sea que vaya y con quien quiera que hable. Al escucharlo me imagino un problema que todos saben que existe, pero nadie sabe cómo solucionar. Entonces se me viene a la cabeza la pregunta ¿cómo impulsar algo tan vago desde la vereda de lo técnico? Mi primera impresión, al acercarme a un problema cuya solución implica un cambio cultural, es que con mi sombrero de programador no hay mucho que pueda hacer. Sin embargo, en el lejano y pre-pandémico 2016, terminé involucrado en un proceso que me demostró todo lo contrario.

El Problema

En todo el tiempo que llevo desarrollando software, me he encontrado con pocas situaciones que impliquen un choque cultural más estrepitoso que los pasos a producción. A menudo he visto este proceso desarrollarse como una pelea entre el equipo de desarrollo y el responsable de producción, donde a la larga no hay un ganador; los primeros dándose de cara una y otra vez con un muro de procesos y validaciones, mientras los segundos gastan tiempo revisando procedimientos incompletos y checklists que ni siquiera miraron.

Ante estas situaciones solemos hablar de una cultura sin “rayar la cancha”, sin embargo, es probable que no estemos refieriéndonos a lo mismo. Cultura es un concepto polisémico, es decir, tiene diversos significados. Es por eso que me voy a referir a cultura como el conjunto de costumbres, hábitos o prácticas propias de un equipo. Y es precisamente en este aspecto práctico de la cultura en lo que me quiero enfocar.

La Historia

Corría el año 2016, estaba buceando en la documentación del web service de nuestra plataforma de service desk, el objetivo era obtener la información asociada a los tickets de incidentes que se creaban. Después de bastante tiempo intentando entender la estructura del modelo y posteriormente desarrollar las piezas que realizaban la integración, me entró la curiosidad y profundicé más, revisando la documentación de los distintos métodos, hasta que di con los documentos sobre la creación de tickets. En ese momento decidí hacer la prueba y crear una solicitud. Todo anduvo bien y automatizamos algunos procesos usando esta nueva herramienta.

Tiempo después se concretó un proyecto que migró la administración de las solicitudes de paso a producción (SPP) a la misma plataforma de service desk, por supuesto empecé nuevamente con las pruebas y logré crear un ticket de SPP utilizando los métodos del web service. La capacidad técnica estaba, pero faltaban todas las conversaciones de las áreas involucradas para que se pudieran crear esos SPPs automáticamente. Esto se tornó en una discusión que parecía ir hacia ninguna parte.

Uno de los puntos más difíciles de conciliar era el de las aprobaciones. Desde el punto de vista del proceso, todo cambio en producción debe cumplir con un listado de requisitos que aseguren que la modificación esté cubierta en todas sus dimensiones, pero en pocas ocasiones esto se hace automáticamente, por lo que era muy habitual que este paso implicara mucho trabajo manual. Eventualmente se logró llegar a un acuerdo donde se podrían crear ciertas solicitudes dentro de un contexto muy acotado de sistemas involucrados, tipos de cambios y equipos que podían utilizar este mecanismo dentro de sus pipelines de despliegue automatizado. Pasó algún tiempo antes de que todo este proceso comenzara a evolucionar, pero cuando lo hizo fue un cambio del cielo a la tierra.

En Tiendas por Departamento, alrededor del 2019, comenzaba a gestarse una estrategia bastante ambiciosa que apuntaba a la infraestructura como código y pipelines de despliegue completamente automatizados; fue entonces cuando les mostré las pruebas de concepto que habíamos hecho hacía mucho tiempo al equipo que comenzaba a definir los workflows de desarrollo. Las integraciones que hasta ese momento incluían a GitLab, Jira y AWS sumaron a un nuevo actor, la plataforma de service desk. Muchas horas de trabajo después, entre reuniones para acordar toda la información y reglas con que los SPP debían cumplir, y los desarrollos para hacer realidad esta integración, se logró pasar a producción el primer cambio completamente automatizado y que incluía toda la trazabilidad impulsada por compliance.

Luego vino Cencommerce y muchas de las prácticas que se desarrollaron en ese entonces, pasaron a ser parte del ADN de esta nueva área, entre ellos los SPP automáticos. Hoy en día, apostaría a que la gran mayoría de los devs que trabajan en Cencommerce ni siquiera ha escuchado hablar de los SPP. Todo este proceso que duró años, realizado en muchas etapas y por personas que en algunos casos ni siquiera llegaron a conocerse, tuvo como resultado uno de los cambios más radicales que he visto en Cencosud: un procedimiento que en el mejor de los casos podía reducirse a un día, con la colaboración de varios equipos y personas, se convirtió en un stage que tarda veinticinco segundos, cuando kubernetes tarda en aprovisionar el pod, dentro de un pipeline.

El Aprendizaje

Lo que aprendí de esta situación fue que, para catalizar el cambio cultural desde el mundo técnico, en este caso desde el desarrollo de software, no es tan importante centrarse en el proceso mismo sino en los hábitos que conviven con él. Recordando una de las conversaciones más satisfactorias que he tenido en mucho tiempo, donde después de mucho analizar el tema cultural concluimos que apuntar a cambiar algo tan vago e intangible como la cultura no debe ser el objetivo, dicho cambio es solo el resultado de otra cosa, la solución de un problema que subyace a la cultura; es a los hábitos que conforman esa amalgama hacia donde debemos dirigir los esfuerzos. Todos conocemos las costumbres, que para bien o mal, están asociadas a los procesos de nuestra organización, y si logramos sistematizar estas instancias de cambio, creo que podemos dar con una solución al intangible problema del cambio cultural.

Si tomamos las tareas rutinarias que solo le quitan tiempo a las personas que las realizan y encontramos la manera de automatizarlas, el hábito se ve afectado y se puede empezar a gestar una transformación de la cultura. El truco está en proponer una solución que esté en el medio de dos posturas distintas frente a un mismo tema, dejando en evidencia que ambas se pueden beneficiar con dicha propuesta al tiempo que aparece la instancia que las libera de sus sesgos. A través de estos pequeños cambios, Baby steps, podremos lograr los cambios profundos que nuestras organizaciones necesitan.

¿Qué mejor oportunidad para cambiar un hábito que el encuentro de dos visiones diametralmente opuestas?

Ayúdanos evaluando este artículo -> Formulario
Trabaja con nosotros! -> Sway