Hace algún tiempo leí el libro The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, una novela muy inspiradora al respecto del uso de las técnicas Lean en el mundo de las operaciones IT y su fuerte relación con el mundo del desarrollo y DevOps. Como novela es entretenida, explica y ejemplifica los conceptos fundamentales y es un cuento de hadas, donde todo va de acuerdo a lo que el guionista ha pensado y desemboca en un fantástico final feliz. Desde luego, no creo que sea necesario recordarles a los lectores que lo que pasa en esos mundos imaginarios no siempre se parece a la realidad y al contrario que en el mundo de Fantasía, a este otro lado a veces las cosas no son tan maravillosas. (Nadie piensa que los lobos hablan después de leer Caperucita, verdad??)
En un momento del libro, el protagonista está reflexionando al respecto de cómo acelerar el ritmo de pasos a producción en el equipo de desarrollo (se han puesto el objetivo de conseguir diez –si, 10- despliegues al día) justamente para seguir los consejos que daba el equipo de Flickr en su conferencia de 2009. Parte de esa reflexión le lleva a decir la frase
Until code is in production, no value is actually beign generated, because it is merely WIP stuck in the system
o sea… hasta que el código no está en producción no se está generando realmente valor porque es únicamente WIP atascado en el sistema
Claro, el paralelismo con el libro de Service Operations de ITIL® y el sentido de que no es hasta este momento cuando realmente se entrega valor al usuario del servicio es directo… pero mi reflexión posterior me llevó un poco más adelante: recordé aquel post que había escrito al respecto de que en realidad el valor de un servicio no es como dice ITIL® el equivalente a Utilidad x Garantía, sino que debemos incorporarle un factor más: el uso.
Así, pues, y siguiendo con la reflexión, tanto da que seamos capaces de hacer 1, 10 ó 100 despliegues al día, que si el usuario no es consciente de lo que pasamos a producción y no es capaz de usar las nuevas funcionalidades que estamos incorporando, en realidad IT habrá generado su parte de valor pero si damos un paso atrás e intentamos encontrar dónde está el valor aportado/generado por el negocio no lo encontraremos: así, mi propuesta de modificación a la frase es
Until code is properly USED to GENERATE the EXPECTED VALUE, it still will be WIP stuck at any other point of the system
o sea.. hasta que el codigo no sea USADO de forma adecuada para GENERAR el VALOR ESPERADO, seguirá siendo WIP atascado en cualquier otra parte del sistema.
Intenté contactar con Gene Kim, el autor del libro, a ver qué opinaba del tema, pero es un hombre ocupado y no he conseguido llamar su atención… pero sí que hubo otra persona que dio su punto de vista: Byron Miller opinó al respecto diciendo que en el fondo todo lo relacionado con formación, cambios culturales y modificación de procesos debe ser también considerado WIP.
Vamos a ver si soy capaz de explicar hasta qué punto es importante esto: dentro de las metodologías ágiles (Scrum, XP, etc.) hay un aspecto que es fundamental y es lo que llaman la definición de “HECHO”. Sin esta definición no funciona nada… y es algo que está aquí para arreglar gran parte de los problemas que tenemos en las TIC.
Es necesario que todo el equipo que participa en la cadena de valor del servicio llegue a un consenso al respecto de qué significa decir que una petición del cliente esté HECHA. Históricamente, cada uno de los diferentes silos que participan en la entrega de esta petición ha interpretado como HECHO el momento en que lo da por terminado (según su visión especializada de las cosas) y lo pasa al siguiente elemento en la cadena. Así, el analista da por hecho el análisis cuando lo pasa a desarrollo, el desarrollador da por hecho el código cuando lo pasa a QA Testing y toda la división de desarrollo da por hecho el programa cuando lo entrega a producción.
Pero la cosa no debe de ser así. Todo el equipo, completo, debe tener una definición común de hecho. ¿Cuándo está hecho el evolutivo? ¿Cuando entrego a Ops? ¿Cuando lo despliego? ¿o cuando he conseguido que los usuarios lo usen adecuadamente?
Desde el punto de vista del negocio, claramente el evolutivo está hecho cuando entrega el valor prometido y eso sólo se hace mediante el USO, por lo tanto HECHO incluye también la formación, el cambio cultural, la modificación de los procesos de negocio, etc etc etc.
Así que, desde luego, todo ese aspecto soft de la entrega de servicios forma parte del WIP.
Ahora vamos a darle otra vuelta de tuerca a todo esto. Si pensamos en la teoría de las limitaciones, la propuesta de Goldratt dice en parte que dado un sistema, siempre existirá un cuello de botella. Es más, resulta que cualquier mejora que pretendamos aplicar al sistema debe de ser directamente sobre el cuello de botella, ya que si actuamos antes el resultado será un atasco monumental a la entrada del cuello de botella; y si actuamos después nos encontraremos con que no servirá de gran cosa puesto que será la limitación actual del sistema la que no esté entregando suficiente “ritmo” a las piezas que se encuentran detrás de ella. Así, cualquier mejora introducida en el sistema si no es en el cuello de botella, o bien no tiene efecto o bien contribuye a empeorar el rendimiento global del sistema.
Ufff… esto es complicado, pero va cogiendo sentido!
¿Qué pasa cuando agilizamos el desarrollo y no agilizamos los pasos a producción? Pues que se produce un atasco monumental en los PaP, y eso provoca… que la gestión de cambios es “el malo”, el que no deja pasar las cosas a producción, el que es un freno para la organización. Y qué pasa cuando agilizamos también el paso a producción? Que nadie se explica cómo puede ser que no se usen las nuevas funcionalidades de las aplicaciones y que cuando se usan el equipo de soporte y apoyo funcional no da abasto (hemos movido el atasco a otro sitio).
Si juntamos una definición de HECHO con visión completa, en la que el evolutivo está hecho cuando se está usando y está generando valor a la organización, con la “prisa” por adoptar metodologías DevOps que nos permitan hacer diez despliegues al día, nos encontraremos con que ahora el cuello de botella es el usuario, que no es capaz de absorber tanto cambio de forma continuada o la organización no permite que el usuario dedique el tiempo necesario a formación para ser capaz de absorber los diez despliegues al día. 
En mi opinión, el ejemplo más claro de esta situación es el mundo de las Apps, en las que se despliegan (no 10 veces al día, pero hay algunos que despliegan al menos una vez al mes) nuevas funcionalidades que son documentadas en un pequeño “Read-Me” o similar que nadie se lee. El resultado? Pilas de nuevas funcionalidades que nadie usa… waste por todas partes porque no se está entregando valor con ese código desplegado, pero un equipo de desarrollo orgulloso de haber conseguido los hitos previstos.
De esa forma, todo vuelve a girar alrededor del “activo más importante de las empresas”: las personas. Las personas son la pieza sobre la que no tenemos capacidad de automatización y por lo tanto será el elemento que siempre será nuestro cuello de botella y sobre el que debemos trabajar en primera instancia, porque de lo contrario lo único que estaremos haciendo será cambiar el atasco de sitio (práctica muy habitual en las organizaciones estructuradas por silos, donde no hay una visión de conjunto: “yo ya he hecho mi parte… el resto no es cosa mía” y donde, además, se ponen objetivos por cumplimientos parciales)
En fin, todo esto ha sido una reflexión provocada por un párrafo en una novela… así que es probable que esté profundamente equivocado. ¿Tienes experiencias al respecto? ¿Trabajas en una empresa DevOps y nos quieres contar cómo transmites todo el cambio a la comunidad de usuarios?
¡Usa los comentarios, por favor!
Postdata: Ops! Por cierto… si somos capaces de hacer diez despliegues al día de correctivos, adelante!!! La comunidad de usuarios y los equipos de soporte lo están deseando! Es decir, todo este discurso es válido cuando el cuello de botella es el usuario por su ritmo de adoptar/asimilar/aprender las nuevas funcionalidades que estamos desplegando. Pero si hablamos de demanda fallo, el discurso es completamente distinto!
¿Cómo puede ser que no haya escrito nada aquí? Otros medios se han llevado mi atención, algún que otro foro especializado y alejado del sector ITSM, una que otra presentación y lo más importante: un trabajo frenético hasta conseguir sacar adelante el 223 de Novática.
