El muro de la confusión

Últimamente he estado reflexionando mucho sobre este concepto, ya que tengo un par de semanas preparando un curso sobre DevOps para IEBS (si te interesa conocer más puedes preguntarme directamente), además de que ayer lo comentaba con unas compañeras que están realizando una propuesta para implementar DevOps en una organización. El Muro de la confusión nos ayuda a explicar metafóricamente los problemas de comunicación que viven las organizaciones que mantienen una estructura basada en silos.

Este muro no existe sólo de forma organizativa, si no que también de una manera muy personal, que hace que las personas se encierren en una burbuja donde limitan su responsabilidad a esta burbuja, su equipo. En esos casos pareciera que no están conscientes de que su trabajo como parte de una empresa, es afectado y afecta a otros y que su equipo forman parte de una gran cadena de valor.

Una de las razones principales por lo que sucede esto es que cada unidad establece sus propios objetivos que intentan cumplir para quedar bien y muchas veces intentando que los otros queden mal (llevarse ellos el crédito de un "buen  trabajo"). En muchas ocasiones esos objetivos individuales no van realmente alineados con la razón de existir de la organización, "Ofrecer valor a sus clientes".

Pero, ¿Qué es el muro de la confusión?

Más seguido de lo que nos gustaría, nos encontramos organizaciones donde no existe colaboración, donde el sistema pareciera estar roto, donde no han entendido que son parte de una cadena de producción y más bien parece que tienen establecido un laberinto de producción del cuál es cada vez más difícil salir (producir valor). En estas organizaciones, los resultados están muy lejos de lo que podrían ser, si se aprovechan tanto el potencial, como la inteligencia colectiva con la que cuenta la organización.

En DevOps al fenómeno que impide esa colaboración, se le conoce como “El muro de la confusión”.

Este muro existe cuando un grupo que forma parte de una cadena de valor, considera que ha terminado su trabajo cuando se lo pasa al siguiente grupo en la cadena sin considerar los problemas que estos puedan tener y la ayuda que podrían necesitar de ellos para resolverlos.

Por ejemplo, imagina un equipo de Desarrollo que pasa al equipo de Operaciones una versión de software que solo ha sido probado en un entorno de desarrollo, que por sus características, está a kilómetros de diferencia del entorno en producción, es decir ni de chance está en un estado "deployable", es decir que puede ponerse en producción, como cuando encajas la última pieza en un rompecabezas.

Esto lo que hace es que el equipo de operaciones tenga dificultades para implementar el software en el entorno de producción, provocando retrasos significativos en las nuevas versiones, actualizaciones, correcciones de errores y aumentando el riesgo de defectos y otros problemas más críticos que pueden afectar a los clientes y por ende a la reputación del negocio en el mercado.

Una situación como esta que se repita constantemente hace que equipos como Desarrollo y Operaciones, cuyo trabajo y responsabilidad están estrechamente relacionados, se conviertan en casi adversarios, donde constantemente libran batallas a muerte (metafóricamente hablando) intentando cada uno cumplir sus propios objetivos pero llevándose al otro equipo por delante, a pesar que pertenecen a la misma organización y que lo que se espera es que combinen su trabajo para poder llegar a los cliente con productos innovadores y de calidad.

Más allá de Dev y Ops

Pero el problema no termina ahí. El fenómeno del muro de la confusión, se puede ver en toda la cadena de valor de la organización, y aplica para todos los problemas de comunicación que pueden existir entre otras áreas del negocio, UX, QA, Marketing, Ventas incluso Recursos Humanos.

A pesar de que, es en DevOps que este concepto se hace famoso y llega a nuestra atención, no es la adopción de DevOps (o tu framework, método o metodología favorita) la que provocará que puedas derribar ese muro. Si bien DevOps nos señala el problema, somos nosotros, las personas, quienes decidimos si nos comunicamos o no, somos nosotros quienes debemos marcar la diferencia cuando es realmente necesario. Mantener una actitud de “nosotros vs. ellos" no es marcar esa diferencia y seguro que ninguna metodología va a arreglar eso.

Al final es una decisión muy personal el cómo queremos realizar nuestro trabajo y trabajar con los demás, y sí, toca trabajar con los demás porque nos necesitamos los unos a los otros.

En el ejemplo que comenté antes, Dev y Ops se necesitaban para completar el trabajo (lo que el cliente estaba esperando), sólo que no lo reconocían. Los servidores, las redes, los sistemas de monitoreo no son nada si no hay una aplicación que necesite ser desplegada en esos servidores, conectada por esas redes o ser monitoreada constantemente. Lo mismo ocurre para una aplicación creada por el equipo de desarrollo.

Si existe un muro de confusión en nuestra organización, es porque como organización y como personas permitimos que exista.

Debemos derribar el muro de la confusión, eliminando los silos y las separaciones entre departamentos. Pertenecemos a la misma empresa, si la empresa cae, también nosotros.

Debemos enfocar nuestros esfuerzos en lograr "lo que la empresa y nuestros clientes necesitan", que trabajemos juntos para entregar software estable y de calidad de manera continua, no lo que yo como Negocio, Desarrollo, Operaciones o ___________ (llena el espacio con el nombre de tu área) necesito cumplir para quedar bien y verme mejor que los demás.

Si puedes, la próxima vez, que alguien te diga que está haciendo Agile o DevOps pregúntale ¿Cómo derribaste el muro de la confusión?, a ver que te responde y si no sabe qué es, le puedes invitar a leer este artículo, si lo haces, te agradecería si me dejas tus comentarios al respecto en la sección abajo.

Espero que hayas disfrutado el artículo, gracias por leerme.

¡Un abrazo!