Cuando me leí “The Mythical Man Month” de Fred Brooks, un clásico sobre gestión de proyectos que siempre recomendamos en el blog, la llamada “Ley de Conway” fue una de las cosas que me llamó la atención. Tanto, que empecé a buscar experiencias propias que corroboraran o no esa teoría: en proyectos, mentoring, en experiencias en conferencias, hablando con la gente…
Antes de explicarte de qué trata, me gustaría que reflexionaras un poco. ¿Has llegado a vivir proyectos en los que a nivel cultural la empresa tenía problemas, había barreras de comunicación entre equipos (peleas, riñas, cabezonerías)? Tal vez, ¿cierta necesidad por ocultar cierta información al resto de compañeros?
Y por otro lado, ¿conoces empresas con equipos de personas que se llevan bien, trabajan con un objetivo en común, o en las que la transferencia de conocimiento es algo asumido en la propia cultura?
Si es así, ¿notas alguna relación entre dichos aspectos y la forma en la que el software está diseñado, la arquitectura, las dependencias entre componentes?
En mi experiencia sí que he encontrado cierta relación:
– He visto equipos con muy buena comunicación que son capaces de gestionar una arquitectura de microservicios sin problemas.
– Empresas tan orgullosas de su código, tan animadas a difundir el conocimiento y colaborar entre sí, que liberan ciertas partes de sus frameworks en Github (desgraciadamente, he visto menos ejemplos de este tipo).
– También empresas muy ocultistas de información entre compañeros, en las que preguntas y nadie sabe como funcionan ciertas partes de la aplicación, y como consecuencia aparecen problemas a la hora de integrar componentes de software.
– O empresas cuya aplicación es muy enrevesada, con muchos parches, y en las que luego te das cuenta de que su cultura es ir rápido como sea, “como pollos sin cabeza***”, sin parase a pensar ante ciertos problemas.
– ¿Y lo complicado que es coordinar equipos de software distribuidos con una aplicación monolítica?
Por poner algunos ejemplos.
Qué dice la Ley De Conway
Todo lo dicho anteriormente tiene una base sociológica, que Melvin Conway reflejó en 1968 en How Do Committees Invent? de la siguiente manera:
“Cualquier organización que diseñe un sistema producirá un diseño que copia la estructura de comunicación de dicha organización.”
Conway no dijo esta afirmación como una broma, sino con una justificación real por detrás. Este hecho es causado porque dos componentes software (p.e A y B), no pueden conectarse correctamente a menos que quien diseña y quien implementa el módulo A se comunique con quien diseñe e implemente el módulo B. Así, este problema en la forma de comunicación de la empresa se refleja en el software, ya que el desarrollo es una actividad intelectual que depende mucho de las propias personas que lo desarrollan.
Para que te des cuenta de forma más visual de esta teoría, Manu Cornet en su web creó las siguientes ilustraciones, donde se muestran las estructuras de comunicación, la forma de organización de empresas como Google, Facebook, Amazon, Microsoft…
Si no te hubiera dicho que son estructuras de comunicación de dichas empresas, ¿hubieras pensado que esos diagramas podrían corresponder a bocetos muy generales de las arquitecturas del software que desarrollan? Yo sí. (Y por cierto, me encanta el diagrama de Microsoft)
¿Y las empresas software aplican esto en su día a día?
¡Sí! ¡Hay empresas como Spotify, Netflix, Amazon que sí se aprovechan de esta teoría para hacer las cosas mejor! Y por mi parte, muchas veces sin darme cuenta, a la hora de ver cómo escalar agilidad en una empresa, ¡doy recomendaciones en las que por detrás se aplica la Ley de Conway!
Netflix, Amazon y Spotify, se organizan con varios equipos pequeños, donde cada uno de ellos es responsable de una pequeña parte de todo el sistema.
Estos equipos son ágiles, autónomos y multifuncionales, con la suficiente independencia como para poder desarrollar funcionalidades en dicho componente de principio a fin, y desplegar versiones de código más rápido, sin afectar a ningún otro equipo.
Probablemente, con una comunicación más procedimental y equipos con más personas, no hubieran llegado a evolucionar su arquitectura hacia tener pequeños componentes independientes.
Y Github por ejemplo, al tener un espíritu open source, con gente de distintos países, distintas zonas horarias, que no están en la misma sala, tiene una arquitectura distribuida.
Concluyendo…
Por lo tanto, el truco está en ir cambiando y evolucionando las estructuras organizativas para que cuadren con la arquitectura de software que quieres llevar a cabo. Así, poco a poco, los distintos equipos irán evolucionando la arquitectura y el diseño del software, reflejando la forma en la que están organizados.
Sencillo, ¿verdad? *Ironía*. Ya en serio, hay que tener ganas y realmente ver que el cambio vale la pena, para poder ir mejorando.
—–
*** Por si no conoces qué significa esta frase, es una expresión española, cuyo significado es ir corriendo por todos lados frenéticamente, como hacen las gallinas cuando les cortan la cabeza…(si estás interesado en el tema, hay vídeos en youtube que no pongo por evitar herir tu sensibilidad). Se usa para decir que se está avanzando sin saber a dónde, ni para qué, por no tener cerebro. También, se emplea para sugerir que alguien no sabe lo que hace.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Muy interesante tu articulo .
Es todo tal cual lo decís. Justamente ahora vivimos algo como lo de los «pollos sin cabeza» en nuestra organización
Muy interesante y aqui el lenguaje una pequeña palabra lenguaje ubicuo tiene mas sentido aún.