Para ayudar a establecer el contexto de estos puntos de partida, primero debo intentar definir "DevOps" y el objetivo que persigue. La palabra "DevOps" es un acrónimo de "Development" (desarrollo) y "Operations" (operaciones). Se formó a partir de la constatación de que los "desarrolladores" y las "operaciones", aunque normalmente separados, necesitaban colaborar más estrechamente para aumentar el valor que proporcionaban al resto de la empresa. Para lograr esta colaboración más estrecha, se aplicaron con gran éxito muchos de los principios fundamentales de la fabricación física. Esto condujo a un cambio de paradigma, ya que el valor empresarial se entregaba de forma constante a un ritmo cada vez mayor, lo que permitió a las empresas que integraron los principios y prácticas de DevOps en su trabajo diario "ganar en el mercado".
Dar pasos de bebé para cada parte de la organización típica llevaría fácilmente a un artículo demasiado largo y saldría rápidamente de mi ámbito de experiencia. Para evitar esto, he identificado tres personas típicas con las que he trabajado y daré los puntos de partida para cada una. Estos personajes son el colaborador individual, el jefe de equipo y el directivo.
Las personas
El colaborador individual es la persona cuyo trabajo diario aporta el valor real a la empresa. Puede ser un desarrollador de software, un administrador de sistemas o un evaluador de calidad. Para esta persona, recomendaría empezar automatizando su entorno de desarrollo. Asegúrate de que se puede configurar de forma coherente, repetida y que imita el entorno de producción. Preste atención a lo que hace que la configuración del entorno sea dolorosa y genere trabajo no planificado. Ese dolor es una señal de las mejoras que podrían introducirse en el producto y en el proceso de desarrollo del producto. A menudo, estas mejoras ayudan a garantizar que su trabajo cumple el ideal de localidad y simplicidad, lo que lleva al equipo a ser más feliz y productivo.
El jefe de equipo es la persona cuyo trabajo diario consiste en proporcionar orientación técnica a los colaboradores individuales del equipo. Para esta persona, yo recomendaría empezar por trazar los pasos necesarios para que el código pase del commit al uso por parte de los clientes, cuánto tiempo lleva cada paso y cuántas personas son necesarias para llevarlo a cabo. Esto ayuda a garantizar que el equipo sea siempre consciente de las oportunidades de mejorar el trabajo diario, y de comunicar a los gestores cuándo el equipo está a punto de toparse con un obstáculo para poder eliminarlo antes de llegar a él, lo que permite el flujo continuo de valor para el cliente y un estrechamiento constante del bucle de retroalimentación.
El gestor es la persona cuyo trabajo diario consiste en coordinar la dirección de varios equipos y mantenerlos alineados. Para esta persona, recomendaría examinar uno de los productos de su cartera con el objetivo de comunicar y aclarar el impacto que tendría una transformación DevOps en las personas que trabajan en el producto. Cuando esta comunicación se hace bien, los equipos comprenderán cómo los objetivos de la transformación DevOps se alinean con los objetivos del producto y cuándo señalar que se han encontrado con un impedimento para alcanzar esos objetivos que necesitan ayuda del gerente para resolver. Esto crea una seguridad psicológica que es increíblemente importante (aunque no suficiente) para garantizar que los miembros de cada equipo estén satisfechos con los productos que están entregando. Esto tiene un efecto secundario de deleitar a los clientes a través de la entrega cada vez más rápida de valor.
Estos pasos por sí solos no provocarán una transformación DevOps, pero iniciarán el camino y es de esperar que proporcionen algunas victorias rápidas. Sin embargo, debo hacer una advertencia, que creo que podría ilustrarse mejor con una historia.
Aprender una nueva habilidad es difícil
A mi mujer y a mí nos gusta llevar a nuestras hijas al parque. Una de ellas, cuando era pequeña, se negaba a andar completamente sola. Al mismo tiempo, le encantaba tirarse por los toboganes, sobre todo cuando yo la esperaba abajo. Aterrizaba de pie y levantaba los brazos esperando que yo la levantara. Después de hacerlo unas cuantas veces, tuve una repentina intuición, retrocedí un paso o dos desde el fondo del tobogán y extendí los brazos. Bajó y cayó de pie. Entonces empezó a caminar hacia mí mientras yo retrocedía con las manos extendidas. Unos 5 pasos después se paró y empezó a llorar, no porque pensara que me estaba escapando de ella, sino porque de repente se dio cuenta de que estaba haciendo lo que creía que no estaba preparada para hacer. Después de unas cuantas salidas más al parque esa semana, por fin tuvo la confianza y la voluntad suficientes para caminar sola.
Esto también ocurre en DevOps. Durante el empuje inicial, el equipo empezará a rendir y luego chocará contra un muro porque todavía no son buenos en ello o se toparán con vientos políticos en contra y tendrán que reducir la velocidad para hacerles frente. Esta frustración puede llevar a que DevOps se perciba como otra moda pasajera que no cambia nada. A veces hay que superar la frustración y reconocer que el beneficio para todos merece el tiempo y el esfuerzo que supone aprender a hacerlo bien, tanto en el equipo como en la organización.
Una nota final
Cada viaje DevOps se trata de racionalizar la entrega de valor al cliente de una manera que beneficie a todos los que están involucrados en el proceso. Para que todos se beneficien, tenemos que asegurarnos de que siempre estamos aprendiendo no sólo sobre la necesidad, sino sobre las fuentes de esa necesidad para que la empresa esté manejando el problema real en lugar del aparente. No hay nada más desmoralizador que descubrir que un viaje nunca terminará porque no se están abordando los problemas reales. Cuando se satisface la necesidad de un cliente y la necesidad desaparece, entonces el viaje para satisfacer más eficazmente esa necesidad ha terminado. Aprendiendo continuamente del cliente y racionalizando para satisfacer la necesidad del cliente, la empresa podrá pivotar y cambiar para satisfacer nuevas necesidades, de lo contrario desaparecerá junto con la antigua necesidad. Un giro de este tipo sólo puede producirse cuando la empresa tiene un propósito más elevado que simplemente ganar dinero satisfaciendo las necesidades del cliente. Este propósito superior no sólo impulsa al colaborador individual, al jefe de equipo y al directivo a alcanzar mayores niveles de excelencia. También puede impulsar la dirección que siguen los clientes en su propio viaje y en el que estamos todos. Sin embargo, el debate sobre este viaje más amplio queda fuera del ámbito de este artículo. Buena suerte y que Dios le acompañe al comenzar su viaje DevOps. Si necesita ayuda o más información, ponte en contacto¡! Improving puede ayudarte a empezar con estos pequeños pasos.
*Muchas gracias a los autores de DevOps Handbook, Project to Product y Sooner, Safer, Happier. Sin ellos, no habría tenido el vocabulario necesario para escribir este artículo.
