El Proyecto Fénix

La falta de confianza en una organización es realmente costosa. No puedes etiquetar a otros como villanos si conoces a sus hijos. — Anónimo.

En la organización en la que trabajo, el área de Aseguramiento de Calidad (QA) decidió adoptar una estrategia DevOps; para los novatos de este término, es una filosofía en la que las áreas de desarrollo, calidad, seguridad y operaciones de la empresa colaboran tan estrechamente, que el proceso de entrega o delivery se simplifica y es automático. Como resultado, podríamos tener en teoría varias liberaciones a producción diariamente, con todos los beneficios que esto implica: ciclos de liberación rápidos, corto plazo de comercialización y entregables con un nivel de calidad y seguridad que no necesitarán que toda la organización se encuentre «apagando incendios» cuando se necesiten nuevas actualizaciones y requerimientos. Aquellos que han seguido este camino anteriormente, saben que tal estrategia no es fácil o rápida de implementar, y que se materializará después de varios meses o años de cambio organizacional.

Así, recientemente, terminé de leer The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win de Gene Kim, Kevin Behr y George Spafford. Esta es una lectura amena, en la que seguimos las aventuras de Bill Palmer, un ex gerente de operaciones que ha sido promovido al puesto de vicepresidente de operaciones de TI en «Parts Unlimited», una empresa de manufactura automotriz y ventas al menudeo. Escrito como una obra de ficción, nos adentramos en el funcionamiento interno de Parts Unlimited y cómo gracias a los esfuerzos de Bill, evoluciona poco a poco desde un infierno de TI donde todas las áreas de negocios y de TI se desprecian, cada lanzamiento es una marcha de la muerte llena de heroísmos y todo en producción se mantiene de pie con «alambritos», a una empresa madura donde TI y negocio comparten los mismos objetivos, y aunque en el libro nunca lo mencionan sino hasta el final, DevOps y ágil han sido ampliamente adoptados, todas las versiones forman parte de una línea de despliegue continuo y todo es hermoso, tanto que Bill está listo para enfrentar el próximo desafío en su carrera laboral.

Cuando finalmente llego a casa, es después de la medianoche. Después de un largo día de desilusiones, estoy agotado. Hay globos en el piso y una botella de vino medio vacía se asienta en la mesa de la cocina. En la pared hay un cartel dibujado con crayones que dice: «¡Felicidades, papá!» Cuando llamé a mi esposa, Paige, esta tarde para contarle sobre mi promoción, ella estaba mucho más feliz que yo. Ella insistió en invitar a los vecinos a tener una pequeña celebración. Al volver a casa tan tarde, me perdí mi propia fiesta. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. Gene Kim, Kevin Behr & George Spafford. (IT Revolution Press, 2015).

La historia comienza cuando Bill es elegido por el CEO de la compañía, Steve Masters, para arreglar todos los problemas que sus predecesores dejaron antes de que fueran despedidos; de especial interés es el titular Proyecto Fénix, que es la plataforma de venta minorista / comercio electrónico que pronto será lanzada a producción. Desafortunadamente para Bill, después de pasar varios años en la cómoda silla de administración de sistemas de rango medio, ahora se ve inmerso en las operaciones diarias de TI de toda la compañía, apagando incendios todo el tiempo, con la ayuda de sus dos directores, Wes Davis y Patty McKee, así como la ayuda (o estorbo) de muchos otros personajes como el Director de Seguridad, John Pesche, o la principal antagonista de la historia, la Vicepresidenta de Operaciones Comerciales, Sarah Moulton. Finalmente, a la distancia, hay un personaje clave que funciona como mentor de nuestro héroe, el excéntrico candidato a la mesa directiva, Erik Reid.

Sin revelar la trama principal, los personajes y situaciones son bastante estereotipados. Por ejemplo, todos conocemos a un «Brent», uno de los ingenieros de la historia que parece estar en todas partes: conoce todos los sistemas, todos los pormenores de la empresa, y todos lo solicitan para trabajar en sus proyectos, ya sea por las buenas o por las malas. Con respecto a las situaciones, hay muchas que los veteranos de TI hemos experimentado en nuestras vidas, que tan dolorosas como lo fueron cuando sucedieron, ahora es divertido revivirlas en el contexto de la historia:

Sospechando que puedo estar perdiendo a Steve, empiezo de nuevo. «Por la forma caótica en que trabajamos actualmente, Brent tiene que arreglar los agujeros en el casco casi todos los días. Sin embargo, estoy bastante seguro de que Brent es una de las principales razones por las que el casco está perforado en primer lugar. No es malicioso, por supuesto, pero es solo un efecto secundario de la forma en que trabajamos y solucionamos los problemas aquí». Hay una pausa. Luego él dice lenta y decididamente: «Me alegra que estés siendo tan catedrático al respecto, pero tenemos un incendio incontrolable. Hasta ahora, lo hemos hecho a tu manera. Y ahora vamos a hacerlo a mi manera. Quiero que llames a Brent, y quiero que se arremangue y ayude a solucionar esta caída. Y no solo Brent. Quiero todos los ojos en las pantallas y todas las manos en los teclados. Soy el Capitán Kirk. Tú eres Scotty. Y necesito velocidad warp, ¡así que levanta a tus perezosos ingenieros de sus traseros! ¿Me entiendes?» Steve grita tan fuerte ahora que estoy sosteniendo el teléfono lejos de mi oído. De repente, estoy furioso. Steve va a arruinar esto de nuevo. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. Gene Kim, Kevin Behr & George Spafford. (IT Revolution Press, 2015).

El libro es bastante intrigante por la forma en que está estructurado, ya que terminamos preocupándonos por el equipo de Bill y cómo él y sus compañeros comienzan desde abajo, siendo despreciados por casi todos, hasta convertirse finalmente en superestrellas recompensadas ​​por la alta gerencia al final de la novela; ya saben, una historia que termina bien. Solo una nota de precaución: mientras que el viaje de Bill a DevOps es bastante sencillo, en el mundo real tal esfuerzo es tortuoso y puede tomar años, sucesivos equipos de gestión y una gran cantidad de daños colaterales. Por ejemplo, Bill tiene dos personas clave en quienes puede depender, sin las cuales, el viaje habría terminado abruptamente dentro de las primeras diez páginas de la novela: la primera es Patty McKee, directora de soporte de servicio de TI y brazo derecho de Bill. En la novela, ella es la SME que crea varios procesos e iniciativas, tales como Change Advisory Boards (CAB), tableros scrumban y «magia de TI», como optimización de procesos, análisis forenses y documentación de posibles fallas del sistema. Según mi experiencia, ese administrador hands-on simplemente no existe, porque la mayoría de los ejecutivos son técnicos o administrativos; ella es una directora cuyas habilidades suenan a una mezcla entre Sheryl Sandberg y Anita Borg. El otro personaje que mantiene el flujo de la historia es Erik Raid, un hombre misterioso que le enseña al protagonista todos los conceptos utilizados a lo largo del libro, resolviendo problemas aparentemente irresolubles de manera repentina e inesperada. En esencia, él es el sensei de Bill, y al igual que el Sr. Miyagi en Karate Kid (1984), ha salvado el pellejo del protagonista en más de una ocasión. Una vez más, esta puede ser una figura literaria, pero en el mundo real de perro-come-perro, como inversionista, Erik estaría más preocupado por el aumento de sus ingresos mediante la posible partición de la compañía, o como un genio técnico, estaría más interesado en escribir un libro y pasar el resto de su vida impartiendo conferencias, o bien, escribiendo artículos sobre DevOps y Lean.

Ahora, en el lado más técnico de las cosas. El libro destaca varios temas encontrados en la literatura de operaciones de TI, lean y ágil: la ​​relación disfuncional entre negocios y TI, trabajo en progreso («Work In Progress» – WIP), kanban, «Simian Army» y «Chaos Monkey» (éstos últimos, descaradamente copiados del conjunto de herramientas creadas en Netflix), así como muchos otros conceptos que todo militante de DevOps debería conocer.

Tu trabajo consiste en garantizar un flujo rápido, predecible e ininterrumpido de trabajo planificado que genere valor para el negocio, mientras minimiza el impacto y la interrupción del trabajo no planificado, para que puedas proporcionar un servicio de TI estable, predecible y seguro. (Source: TatvaSoft)

El libro nos introduce al concepto de los Tres Caminos, que describen las claves para la adopción exitosa de DevOps. En resumen, éstos serían los siguientes:

1. Crear un «flujo de trabajo rápido» a través de las operaciones. Esto significa que las operaciones se encuentran entre lo que el negocio quiere y el dinero ingresado. Por lo tanto, el trabajo número uno es hacer que las operaciones se realicen lo más rápido posible haciendo visible el trabajo, reduciendo los bloques e intervalos de trabajo, aumentando la calidad evitando que los defectos pasen a los centros de trabajo más adelante en el flujo (es decir, Desarrollo -> Operaciones -> Clientes), optimizando constantemente los objetivos globales.

2. Evitar el trabajo innecesario, creando ciclos de retroalimentación y visualizando el desperdicio, viendo los problemas a medida que ocurren, trabajando en conjunto hasta que se implementen contramedidas efectivas. En el libro, los tableros kanban ayudan a los gerentes a visualizar todo tipo de trabajo: proyectos comerciales, proyectos de TI, cambios / nuevos requisitos e incidentes, para que puedan ver cuándo el trabajo empieza a acumularse. Una interpretación interesante que se encuentra en el libro es que detener el trabajo innecesario a menudo es más importante que hacer más cosas (es decir, congelar todas las liberaciones en producción y enfocarse solo en el proyecto crítico de mayor valor agregado).

3. Finalmente, la organización debe alentar la mejora al permitir que los equipos practiquen, experimenten y fallen, transformando los descubrimientos locales en mejoras globales. De acuerdo a esta filosofía, la repetición de experimentos con buenas métricas permitirá que los equipos mejoren rápidamente. Si no están mejorando, es probable que su desempeño ya esté empeorando.

Una de las principales ideas de este libro es que DevOps se trata de centrarse en las relaciones en lugar de las herramientas; entregables de trabajo en lugar de documentación interminable; colaboración organizacional en lugar de obligaciones contractuales y respuesta de cambio rápida en lugar de seguir ciegamente un plan. Oh, ¿ven eso? Es casi como si necesitáramos ser ágiles si queremos implementar DevOps correctamente.

Conclusiones

El Proyecto Phoenix es un excelente primer paso en el largo viaje hacia DevOps. Para aquellos que nunca han escuchado hablar de él, realmente recomiendo que lo lean, ya que no toma mucho tiempo terminarlo. Una vez que sinteticemos las ideas y necesitemos un manual en lugar de una novela, será necesario recurrir a otra bibliografía, pero como introducción a este mundo, vale la pena leerlo. Claro que, es necesario tomarlo con cautela, porque este libro NO es una bala de plata, los personajes son la versión de TI de The Avengers de Marvel y lamentablemente, la mayoría de iniciativas como ésta están llenas de trampas mortales, política y personas dejando la organización, porque… la vida no es una película. Los chicos buenos pierden, todos mienten, y el amor… no lo conquista todo.