The Phoenix Project: Una novela acerca de TI, DevOps y como contribuir al triunfo del negocio.

El libro es muy ameno, al principio pensé que era un libro técnico, pero no, es más bien una novela, la elección del formato es afortunada ya que lo hace muy fácil de leer. Puedo decir sin temor que si has trabajo en el area de sistemas de cualquier empresa, muchas cosas te resultarán familiares y empezaras a imaginar escenarios y poner nombres de ex compañeros.

Portada del Libro, The Phoenix Project. (Las imágenes pueden estar sujetas a derechos de autor).

El libro, narra las aventuras de Bill, cuando a raíz de su ascenso a la vicepresidencia del departamento de operaciones de TI, en una compañía de autopartes completamente disfuncional, se ve inmediatamente envuelto en el caos de un proyecto de suprema importancia para la empresa, el cual esta muy atrasado, por encima del presupuesto, mal construido y sin pruebas ¿les suena familiar?. Muchos hemos estado en situaciones semejantes a uno (o más) de los personajes en algún punto de nuestras carreras por lo cual es fácil tener empatía con Bill y la mayoría de su equipo.

A raíz del encuentro con un misterioso personaje llamado Erik Reid, miembro de la junta directiva, se deja entrever la idea de que el departamento de TI es como una planta de manufactura, la cual va cobrando sentido a medida que se avanza en el libro, como cuando Jorge Castaneda hace sus primeras visitas al brujo Don Juan, al principio todo era confuso.

Porta del libro — Las enseñanzas de don Juan — escrito por Carlos Castaneda.

En los 80´s la planta fue rediseñada y mejorada por tres importantes tendencias gerenciales, la teoría de las limitaciones (Theory of Constraints), lean production o producción ajustada (Toyota Production System) y manejo total de calidad (Total Quality Management), aunque las tres se dieron en diferentes lugares las tres concuerdan en una cosa, WIP (Work in Progress por sus siglas en inglés) es el asesino silencioso. Así que uno me los mecanismo más críticos en el manejo de la planta es la liberación de materiales y el trabajo, sin este ¿ como se podría controlar el WIP ?

Dr.Eliyahu M. Goldratt, who created the Theory of Constraints, showed us how any improvements made anywhere besides the bottleneck are an illusion.

Pero ¿como llevas esto al departamento de TI ? Bueno primero habría que identificar los 4 tipos de trabajo, el WIP (Work in progress) en general o completo podríamos decir, nuestro amigo Bill ya tenia uno muy claro, los proyectos del negocio, pero no es hasta el capitulo 10 que entiende que los cambios y/o actualizaciones son otro tipo de trabajo, y hasta el capitulo 15 finalmente, llega a tener la claridad para identificar los tres primeros tipos de trabajo, proyectos del negocio, proyectos internos y cambios. ¿Pero y el cuarto tipo de trabajo — y tal vez el más importante, por que puede ser muy destructivo ? Súbitamente y como por arte de magia: ¡apagar incendios! ¿ qué puede perjudicar todo lo planeado? lo no planeado.

Muy ilustrativo.

La implementación de un sistema de manejo de cambios efectivo, acorde a las necesidades de la empresa y lo más importante, no solo un hermoso procedimiento en papel si no que util a los usuarios, se describe como toda una experiencia de mucho aprendizaje.

On my walk over to Brent´s cube in Building 7, I remind myself that my goal is to observe and seek understand.

Esto es uno de los párrafos que en mi opinión muchos gerentes o directors deberían subrayar, y que por supuesto no es fácil de hacer — buscar entender.

Para concluir puedo decir que el libro no es solo acerca de hacer las cosas de forma más rápida en TI o por menos dinero, es una reflexión acerca de lo que el negocio necesita y como puede TI hacer lo que se necesita de manera mucho más efectiva. No es suficiente optimizar, tenemos que optimizar las cosas adecuadas en el momento adecuado. Esta es la lección más importante del Proyecto Fenix: como identificar correctamente que necesita ser corregido y luego corregirlo con las herramientas y tecnologías adecuadas. Con la posibilidad de que estas herramientas no sean digitales o basadas en un sistema informático, sino pueden ser solo plumones y papel.

Cualquier interesado en aprender sobre DevOps debería comenzar por este libro.

Acá andamos, saludos.

Alex

Cheerleader in chief for KMMX, RPA Enthusiast, DevOps, Technical Writer & International Speaker, Dad & 2 cats.

Cheerleader in chief for KMMX, RPA Enthusiast, DevOps, Technical Writer & International Speaker, Dad & 2 cats.