The Phoenix Project, tus problemas de IT no son tan unicos

Hace un par de años me recomendaron leer The Phoenix Project, no lo hice, en parte porque tenía otros temas, pero principalmente porque mi dominio del idioma Inglés no me lo permitia. Ahora, hace un par de dias, me lo volvieron a recomendar y esta vez si lo pude leer. Es una novela, si, pero refleja tan bien lo que es trabajar en un proyecto de software que ahora no paro de recomendarlo a todo el mundo.

The Phoenix Project nos cuenta la historia de Bill, un DevOps devenido en manager, que queda a cargo de todo el equipo de operaciones de un gran compañia donde sistemas es tomado como área de soporte del core de negocio que es el de producir partes para autos. A lo largo de las páginas lo acompañamos en algunos éxitos y varios fracasos relacionados a tener un sistema productivo.

Los autores, muy sabiamente, van introduciendo muchos conceptos y promoviendo prácticas que creen que son beneficiosas para proyectos de IT. Lo hacen de forma tal que uno acompaña a Bill a lo largo de camino de aprendizaje. A su vez nos encontramos con algunos personajes entrañables y con algunos otros que nos generan rechazo. Me vi constantemente haciendo paralelismos entre los personajes y personas de mi día a día.

Ya en las primeras páginas arranca con un outage general causado, en parte, por Bill dejándose convencer de deployar a producción un proyecto sumamente riesgoso. Luego de eso, y de noches sin dormir, Bill comienza a entender que cosas causaron esa caída y cómo solucionarlas. En esencia toda la primer parte cuenta el típico camino del héroe, en este caso con una historia de IT por detrás.

Uno de los conceptos que introduce el libro es el definir el trabajo. ¿Que es trabajo en IT? Responder esa pregunta te habilita pensar tus procesos como cualquier otra actividad productiva. Hacer software es ingeniería no es arte y se tiene que abordar con un punto de vista ingenieril. Eso me gusta. Al final llegan a la conclusión de que el trabajo es:

  • Proyectos del negocio.
  • Proyectos internos.
  • Cambios.
  • Trabajo no planeado.

Donde el trabajo no planeado es lo peor que nos puede pasar.

El paso siguiente es pensar el desarrollo de software como un todo. Usando el concepto de las tres vías. Concepto que se trabaja en otros libros y sobre el que se puede profundizar pero que se puede resumir en:

  • Primera via: El trabajo fluye en una sola dirección… Entonces buscamos evitar el retrabajo y nos esforzamos en hacer que ese fluir sea el mejor posible. Para ellos tenemos que encontrar los cuellos de botella y accionar de forma tal que aumentemos nuestro throughput.
  • Segunda via: Ciclos de retroalimentación (feedback) cortos y amplificados. Muy de Lean, fail fast y esas cosas. En vez de desarrollar durante 12 meses para deployar algo que ya está obsoleto hacerlo de forma tal que uno pueda salir a producción 10 veces por dia.
  • Tercera via: Experimentacion continua, para aprender de los errores y lograr la maestría. Es como dicen, la practica hace al maestro. Y practicar implica equivocarse y aprender de ello.
La primera via Dev -> Ops. La segunda via el feedback, Ops -> Dev. La tercera vía todo lo que pasa en el medio con ciclos cortos que nos permitan aprender.

Es importante que sepamos que es una novela. No es un manual, no es una guia y mucho menos es un libro que nos pretende vender una forma de trabajo. De todas formas al leerlo, si son del mundo de IT, van a notar que lo que les duele a los protagonistas son las mismas cosas que nos duelen a nosotros en nuestro día a día.

Al final nos damos cuenta que nuestros retos no son tan únicos como nos parecen cuando nos encontramos con ellos por primera vez. Que los retos que se enfrentan los roles más cercanos a management son muy similares en en todos los rubros y que el éxito viene de lograr que todas las partes trabajen en conjunto.

Un gran complemento a este libro, mucho mas tecnico, es The DevOps Handbook, que recorre las tres vías con sumo detalle. A su vez hace un par de meses (Noviembre de 2019) publicaron The Unicorn Project, donde se abarca esta misma temática pero desde el punto de vista de los desarrolladores.

En The Unicorn Project se presentan los 5 ideales:

  • Localidad y Simplicidad
  • Foco, Flujo y Alegría
  • Mejora del trabajo diario
  • Seguridad psicológica
  • Foco en el cliente

Estoy deseoso de leer este libro, me parece un buen complemento a The Phoenix Project. Ambos libros creo que tienen por detrás un montón de conceptos e ideales que no son tan explícitos pero que hablan de una nueva de trabajar. Conceptos muy relacionados con el agilismo y que está bueno incorporar.

Deja un comentario