paquete

Decía el bueno de San Ambrosio que de las cenizas del ave fénix salía un gusanico que se colaba en un huevo para convertirse, al salir de él, en águila celeste. Dejando a un lado la posible evidencia científica del hecho (y la evidente simbología con la resurrección cristiana), la simbología de un renacer tras un fracaso es común a varias culturas.

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win (El Proyecto Fénix, una novela sobre iT, DevOps y ayudar a triunfar a tu empresa) es una novela que me pasó Pablo. A pesar de haber asistido a reuniones con programadores, ingenieros, técnicos, managers y líderes de todo tipo, no acababa de entender su mundo ni su manera de pensar. Mis creencias limitantes no ayudaban en exceso, más bien al revés. Me creía un forastero en el Salvaje Oeste de IT. Un “ventas”, perdón, un puto comercial que iba a ser baleado en el saloon por algún técnico. Perdón, por algún puto informático.

Esta novela, escrita por Gene Kim, Kevin Behr y George Spafford, no la podía tener en papel, claro.

Cuenta la historia de Parts Unlimited, empresa ficticia fabricante de piezas de automóvil que está a punto de hundirse. Steve Masters, director general, asciende a Bill Palmer como vicepresidente de IT. Y le encomienda una misión suicida, tratar de ayudar a la empresa a recuperar la rentabilidad perdida.El Proyecto Phoenix era la última oportunidad de la empresa. El tiempo vuela, el barco se hunde sin remisión. Sin estar muy entusiasmado, Bill acepta. El director de sistemas y la directora de soporte serán sus aliados en esta encomienda.

Bill, antiguo marine, entiende la organización como un ejército. Pronto el día a día comienza a ser un caos y cada día va a peor. Cuando todo está cerca de explosionar, aparece el doctor Erik Reíd, personaje central de la novela. Un nuevo miembro de la Junta Directiva que comparte su conocimiento y experiencia con Bill, ayudándole a pensar mejor. Pronto le saca de uno de sus errores: el ejército y una empresa no necesariamente funcionan igual. Erik lleva a Bill a una de las fábricas de la empresa y le muestra cómo las políticas que lleva esa fabricación de piezas son trasladables a IT.

Sin hacer spoilers porque no quiero destripar una historia entretenida, la novela muestra los 3 principios fundamentales de las DevOps, los 4 tipos de trabajo en IT, la definición de “cambio” (cualquier cosa física o virtual en software o hardware que afectara al servicio prestado), la manera en la que evitar el “fuego amigo” y muchas cosas más. Erik también le sugiere a Bill la lectura de La meta, del físico y Doctor Eli Goldratt, que describe la Teoría de las Restricciones (un caramelo para los que nos entusiasman las aportaciones de la ciencia a la mejora de las organizaciones). Leyéndomela, al margen de la novela, entendí mejor esos “cuellos de botella” de los que hablaban en IT y los problemas de comunicación entre Operaciones y Desarrollo.

Cuando acabé de leer la novela sentí un gran alivio, casi con la emoción de Champollion al traducir la Piedra de Rosetta. Así, sin exagerar. Ya no me sentía incapaz de sostener conversaciones y hacer las preguntas adecuadas. Que, al fin y al cabo, era mi trabajo. Nadie me pedía saber sumergirme en códigos y lenguajes de programación. Sólo entender los escenarios deseados que dibujaban las empresas con las que hablábamos, incluyendo pilares como el trabajo colaborativo, experimentos de bajo riesgo o la cultura del aprendizaje.