Un interesante post "Luck has nothing to do with it" de Marcus Hammarberg autor de Kanban in Action me hizo recordar el libro de Alex Rovira La Buena Suerte en el que a través de la fábula de los Caballeros Sid y Nott nos desvela las claves de la Buena Suerte (con mayúsculas) frente a la suerte (con minúsculas) que puedes encontrar pero que además de ser escasa tiende a irse igual que llega. Intentaré resumir la fábula en un párrafo:
Trébol. Imagen bajo licencia Creative Commons tomada de Flickr.com
Merlín reune a todos los caballeros del reino y les reta a encontrar el Trébol de la Buena Suerte que crecerá en el Bosque Encantado en siete noches. Ninguno, excepto dos caballeros, acepta el reto. Nott, el primero de ellos, se pasa los días dando vueltas por el bosque interrogando a sus habitantes y enfadándose porque nadie quiere ayudarle en la imposible tarea. El caballero Sid por su parte, decide crear las condiciones necesaria para que, por primera vez, crezca un trébol en el Bosque Encantado: prepara una tierra nueva, desvía un arroyo para mantenerla húmeda, poda los árboles para que penetre el sol... Si finalmente crece un trébol dentro de siete noches lo más probable es que crezca en la tierra que he preparado - se convence a sí mismo Sid.
Puedes imaginar quien encuentra el trébol. Te recomiendo el libro y aunque está clasificado como narrativa empresarial también lo recomendaría para los pequeños de la casa (si los hay :).
Volviendo al post de Marcus, la suerte no tiene nada que ver con que un músico no desafine, un portero de hockey se encuentre con frecuencia con los postes, o más cercano a nuestro entorno, que un departamento de TI consiga mantener estable sus sistemas.
Como en el cuento de Alex Rovira, la suerte poco hará para ayudarte en tales circunstancias... Sí, podemos tener suerte (con minúsculas) de vez en cuando pero en situaciones complejas en las que se juntan tantísimas variables como en los sistemas software rara vez aparece.... Como nos indicaba Fred Brooks en su archiconocido "No Silver Bullet" la complejidad de los sistemas software es una característica esencial de los mismos. El enorme número de estados que maneja el sistema en sí, más los estados de los servidores en los que se ejecutan sumado a la complejidad añadida de los sistemas operativos e infraestructura de red de los que dependen, hacen que sea más fácil tener la suerte de acertar una quiniela que controlar el número de estados que implica un despliegue trimestral de nuevas versiones de software.
No, como apuntaba Marcus, la suerte no tiene nada que ver... en el siguiente despliegue dicha organización, aun corrigiendo los supuestos problemas de planificación, volverá a tener mala suerte porque: alguien decidió cambiar determinada infraestructura física, o algún usuario decidió cambiar las especificaciones al darse cuenta que no era exactamente lo que necesitaba, o se descubrió determinado "efecto colateral" en otro sistema una vez en producción. No, eso no es mala suerte, está asociado al enorme número de variables que entran en juego y la única forma de evitar esa "mala suerte" es crear Buena Suerte (con mayúsculas) al igual que hizo el Caballero Sid: preparar el entorno para reducir la probabilidad e impacto de dichos cambios.
Echando la vista atrás, me doy cuenta de que la suerte no tiene nada que ver con que un equipo de mantenimiento de aplicaciones (responsable de más de 20 sistemas muy heterogéneos) mantenga el número de peticiones en espera por debajo de 10 (y sin estrés) cuando lo normal era estar en la franja de 20-30, tampoco tiene nada que ver en que reduzcan drásticamente sus tiempos de entrega...
No, no es suerte, como en el caso del Caballero Sid es el resultado de llevar a cabo las acciones necesarias para crear la Buena Suerte: limitar el trabajo en curso del equipo (WIP), dividir al máximo las peticiones y ponerlas a disposición de los usuarios ASAP, probar la funcionalidad por alguien diferente del desarrollador antes de subir a producción (sí, puedes releer esto último...), compartir proyectos/código, prohibir las subidas a producción desde los entornos de desarrollo, compilar todas las noches todos los proyectos y ejecutar pruebas automáticas, implementar un Sistema de Alerta Temprana (SAT) que informe de incidencias en producción (en datos o aplicaciones) antes de que se entere el usuario, permitiendo resolver el problema antes de generar efectos secundarios que en ocasiones son más costosos de corregir que la incidencia inicial... estas son algunas de las acciones que los Caballeros del Grupo de Gestión llevaron a cabo para encontrar su trébol... puede ser que no compartas una o ninguna de estas acciones, da igual, elige tu propia lista de acciones... pero te aseguro que pasearte de despacho en despacho buscando culpables por los cambios no planificados de operaciones o de los usuarios o de agentes externos... no te va a traer la Buena Suerte, si aun así prefieres esperar "a ver si toca"... ¡Te deseo suerte!
En el mundo de la TI la "suerte" es el resultado de las acciones que están fuera de tu control, habitualmente de otros participantes implicados. El resto, todo aquello sobre lo que se puede actuar, saldrá bien si, como dices, se trabaja. El problema es que las organizaciones tienen procesos tan complejos, en los que están involucrados tantos actores, que muchas más veces de lo que sería deseable, el resultado se ve demasiado afectado por "lo ajeno" que suele ser un mundo lleno de "Notts"... (Curiosos los nombres, SId para el positivo y NOtt para el negativo..., no?)
ResponderEliminar;-)