Ley de Conway

La Ley de Conway, también conocida como la Ley del software, es un principio fundamental en el desarrollo de programas informáticos que tiene una gran relevancia en el mundo digital actual. Esta ley, propuesta por el científico británico Melvin Conway en 1968, establece que la estructura de un sistema de software refleja la estructura de comunicación de las personas que lo diseñaron. En otras palabras, la forma en que un equipo de desarrolladores se organiza y se comunica entre sí se refleja en el producto final que crean. En este artículo, exploraremos más en detalle esta interesante ley y cómo puede influir en el éxito o fracaso de un proyecto de desarrollo de software.

Origen

Hace muchos años, Melvin Conway observó que la forma en que se estructuran las organizaciones impacta cualquier sistema que creen. en su articulo [1]el escribio:

Cualquier organización que diseñe un sistema (definido aquí de manera más amplia que simplemente sistemas de información) inevitablemente producirá un diseño cuya estructura es una copia de la estructura de comunicación de la organización.

En ese momento, Harvard Business Review rechazó su artículo original porque no había probado su hipótesis. El artículo se publicó en abril de 1968 en Datamation, la principal revista de TI de la época. La ley se hizo conocida después Fred Brooks citó el artículo y la idea en su libro clásico. El mes del hombre míticollamándolo Ley de Conway. El nombre se quedó y se extendió, especialmente entre los desarrolladores de software.

La ley de Conway no pretendía ser una broma o un koan zen, sino una observación sociológica válida. Es una consecuencia del hecho de que dos módulos de software A y B no pueden interactuar correctamente entre sí a menos que el diseñador e implementador de A se comunique con el diseñador e implementador de B. Por lo tanto, la estructura de interfaz de un sistema de software necesariamente mostrará una congruencia con la estructura social de la organización que lo produjo.

Brooks reconoció que la ley tiene importantes corolarios en la teoría de la gestión:

Debido a que el diseño que ocurre primero casi nunca es el mejor posible, es posible que sea necesario cambiar el concepto de sistema predominante. Por lo tanto, la flexibilidad de la organización es importante para un diseño eficaz.

A pesar de la observación del autor (de aplicar esto no sólo a los sistemas de información), muchas investigaciones que validaron este principio provinieron de desarrolladores de software.[2]incluido el propio hipertexto de Satya Nadella y la transformación en Microsoft[3]:

Para obtener realmente el mejor impacto de nuestros esfuerzos, tendremos que esforzarnos por trascender la ley de Conway.

En muchos sentidos, la ley afirma y valida que el software es el producto de la estructura de comunicación de una organización.

La Escuela de Negocios de Harvard realizó un estudio[4] de diferentes bases de código para ver si podía probar la hipótesis original de Conway aplicada a los sistemas de software. En él, tomaron múltiples ejemplos de software creado para resolver el mismo propósito (por ejemplo, software de procesamiento de textos, gestión financiera y bases de datos) y compararon las bases de código creadas por equipos de código abierto poco acoplados y aquellas creadas por equipos estrechamente acoplados. .

Su estudio encontró que los equipos de productos enfocados y a menudo ubicados juntos creaban software que tendía más hacia bases de código monolíticas y estrechamente acopladas. Mientras que los proyectos de código abierto dieron como resultado bases de código más modulares y descompuestas.

Un buen ejemplo de la Ley de Conway lo encontró en 1999 el experto en UX Nigel Bevan mientras estudiaba diseños de sitios web corporativos. Bevan descubrió que los usuarios finales a menudo se sentían frustrados con los sitios web de las empresas porque eran lentos y difíciles de usar, ya que la navegación, el diseño de la página y la estructura del contenido a menudo reflejaban las preocupaciones internas de una organización, en lugar de satisfacer primero las necesidades del usuario previsto.

Esto ha llevado a muchas organizaciones a experimentar con metodologías ágiles de equipos más distribuidos. Pero al mismo tiempo, todavía existe la consideración de que un grupo de programadores desconectados podría infundir en su trabajo sus prejuicios individuales.

Conceptos

Homomorfismo

También llamada isomorfismo, esta ley subyace a la ley de Conway:

El homomorfismo es un mapa que preserva la estructura entre 2 estructuras.

El homomorfismo es el poder de un sistema o estructura de manifestarse en otro sistema. La fuerza crea la misma estructura. Las estructuras se copian entre sí. Conserva la estructura. En términos más simples, un sistema replica elementos reconocibles de la organización que lo desarrolló. En términos más simples, este es el Efecto espejopor el cual un sistema produce una imagen especular de la organización que lo creó.

Ley de Conway inversa

El paradigma anterior conduce a lo que Allan Kelly definió como el Inverso de la ley de Conway:

Las organizaciones con sistemas de larga duración adoptarán una estructura modelada según el sistema. El diseño organizacional es el diseño de sistemas. Diseñar la organización para diseñar el sistema.

Desde hace unos años, las organizaciones han comprendido este vínculo entre la estructura organizativa y el software que crean. En consecuencia, han estado adoptando nuevas estructuras para lograr el resultado que desean.

Por ejemplo, Netflix y Amazon se estructuran en torno a múltiples equipos pequeños, cada uno de los cuales es responsable de una pequeña parte del sistema general. Estos equipos independientes pueden poseer todo el ciclo de vida de los servicios que crean, lo que les brinda un mayor grado de autonomía que el que es posible para equipos más grandes con bases de código más monolíticas. Estos servicios, con sus preocupaciones independientes, pueden cambiar y evolucionar por separado unos de otros, lo que da como resultado la capacidad de realizar cambios en la producción más rápidamente. Si estas organizaciones hubieran adoptado equipos de mayor tamaño, los sistemas monolíticos más grandes que habrían surgido no les habrían dado la misma capacidad para experimentar, adaptarse y, en última instancia, mantener contentos a sus clientes.

Por el momento, basta decir que múltiples investigadores han validado estos principios en diversos campos, no sólo en el diseño de software.

Importancia

Una vez que nos alejamos de los productos de software hacia algo más amplio, podemos descubrir varias relaciones con casos concretos:

  • Ya hemos visto cómo un accidente aéreo masivo fue el resultado de una estructura de comunicación defectuosa en una organización en teoría diseñada para centrarse enteramente en la seguridad y la importancia de la ingeniería.
  • Varios grandes escándalos en las organizaciones (pensemos en Enron) han sido el resultado de decisiones organizativas conscientes que, en última instancia, reflejaron el fracaso de todo un sistema.

La ley de Conway es cada vez más relevante hoy porque la aceleración aspecto de VUCA y incomprensible de BANI hace más visibles todos estos aspectos.

Estudio de caso: comercio minorista

Las tiendas físicas y los sitios de comercio electrónico reflejan profundamente cómo están estructuradas las organizaciones y su estructura de comunicación.[5]. Pensemos en la indumentaria: pocos casos vienen inmediatamente a la mente.

Las tiendas de ropa están organizadas principalmente según diferenciaciones de género (hombres/mujeres) y grupos de edad (niños/adultos). En la mayoría de los casos, esto refleja una distinción que está profundamente arraigada en la organización, desde el estilo hasta el desarrollo de productos, pasando por la comercialización y el abastecimiento. Esta distinción crea inmediatamente problemas en el momento en que la moda sin género entra en juego y limita la confusión: tallas pequeñas, otra área agrupada bajo niñosaunque los adultos también los compren.

Así llamado omnicanal servicios. ¿Alguna vez has intentado comprar online y devolver algo en la tienda? Estoy seguro de que todos ustedes han experimentado al menos un par de ojos en blanco junto a la silla al solicitar este servicio. El problema es que la mayoría de las organizaciones todavía están organizadas por canal; por lo tanto, regresar a una tienda física significa que algo vendido en línea terminará en el recuento de existencias de una tienda física. En la mayoría de los casos, los mecanismos de control empresarial, la asignación de recursos y los incentivos siguen siendo por canal, a pesar de la promesa de una experiencia omnicanal.

Todos estos ejemplos reflejan cuán amplias son las implicaciones de la Ley de Conway, especialmente si pretendemos que el concepto de sistema en su sentido más enorme posible, precisamente como pretendía el propio Conway.

Corolario de la ley de Conway

Para comprender mejor la ley de Conway, debemos evaluar todos los aspectos y resultados críticos que produce una organización y la experiencia que brinda a sus clientes. La calidad de la experiencia del cliente brindada por una organización será inevitablemente producto de su diseño organizacional.

Hace unos años, en su libro Cómo funciona GoogleEric Schmidt (Schmidt, 2014) se refirió casualmente a los resultados de la Ley de Conway:

Nunca debería poder realizar ingeniería inversa en el organigrama de una empresa a partir del diseño de su producto.

Causas fundamentales comunes

En realidad, el software suele ser un tema muy complejo y producir software es un desafío increíble que requiere comprensión de la psicología, el arte, el diseño, la lógica digital, las relaciones de datos, los sistemas, las herramientas, el liderazgo, el trabajo en equipo y mucho más. Al menos una persona dentro de una empresa encargada de crear software debe tener un mapa claro de qué es este software, qué será, cómo funciona y cómo hacer que funcione mejor. Esta persona suele ser el director ejecutivo, el director de tecnología, el vicepresidente de ingeniería o alguna otra persona con autoridad de alto nivel, y debe hacer un trabajo claro al comunicar los requisitos y otros datos importantes al resto de la organización.Los problemas comunes que resultan de una mala comunicación entre los miembros de un equipo de software incluyen[6]:

  • Retardo de propagación: La información tarda mucho más de lo esperado en viajar desde quienes la tienen hasta quienes la necesitan. A veces, una información ya no es relevante cuando llega al destinatario previsto. Esto resulta en un desperdicio de esfuerzo y puede prolongar tareas y proyectos simples durante períodos de tiempo indefinidos.
  • Liderazgo ciego: Cuando los líderes tardan en escuchar y responden rápido, se pierden comentarios críticos de los miembros del equipo, los clientes y otras personas con conocimientos que ellos no tienen. No hay forma de que una persona pueda ver, escuchar o analizar más información que un equipo completo de personas, independientemente de cuán inteligente pueda ser esa persona. No escuchar el feedback es arrogante y generalmente tiene un impacto muy negativo en el equipo y por tanto en el producto (o productos) final en su conjunto.
  • Elitismo: No compartir información de manera útil entre los miembros de un equipo puede resultar en una distribución muy unilateral de la información en todo el equipo, lo que significa que un individuo o grupo puede tener más información de la que necesita mientras que otro se las arregla sin alguna pieza crítica de información. información que podría obtenerse fácilmente de otra parte del grupo. Esto puede resultar en una nosotros contra ellos Escenario en el que un grupo tiene todas las cartas y obviamente es malo para todo, desde la moral hasta la calidad general del producto.
  • Confusión: La mala comunicación obviamente conduce a confusión, que a menudo desemboca en una falta de comprensión generalizada y masiva, en la que diferentes personas tienen diferentes ideas sobre cómo se supone que se debe hacer algo. Se vuelve mucho más fácil para las personas culparse o convertirse en chivos expiatorios entre sí, o para los malos gerentes ocultar sus deficiencias detrás de los miembros del equipo (o culpar al cliente/cliente/perro mascota/cualquier otra persona)
  • Objetivo equivocado: Dar en el blanco equivocado es un problema común en el campo del desarrollo de software y es uno de los eventos más devastadores que uno puede experimentar en su carrera. No hay nada como aprovechar la emoción de crear un gran producto durante semanas o meses solo para descubrir que creaste algo completamente equivocado y tienes que empezar de nuevo.

Contras de la ley de Conway

Empresas de todos los tamaños y en todos los sectores han utilizado y tenido éxito al adoptar la Ley de Conway y han comenzado a utilizar pequeños equipos ágiles en sus diseños de sistemas. Desde Google hasta el sector financiero, empresas de todos los sectores han adoptado la Ley de Conway como forma de estimular la innovación. Básicamente, dedicas un pequeño equipo de personas muy unidas a un solo proyecto, les dejas iterar y obtendrás las soluciones más creativas. La noción ha sido a menudo que El número de Dunbar Se aplica tanto a las relaciones laborales como a las personales: hay un límite superior de 150 personas que pueden colaborar eficazmente en una organización. Más que eso y la comunicación se rompe.

Sin embargo, al mismo tiempo, este concepto también se está ganando sus propios detractores.

Un artículo de Forbes[7] de 2017 señaló que existen posibles inconvenientes al dejar que la ley de Conway guíe la estructura de su organización. El pensamiento es que:

Una vez que se consolidan equipos pequeños de esta manera, su respeto y lealtad hacia ese equipo a menudo superan su lealtad hacia la organización en su conjunto… Los equipos en ubicaciones dispares terminan formando identidades fuertes pero exclusivas como departamentos individuales.

Es bueno que los equipos formen vínculos fuertes, pero esos vínculos no deben volverse excluyentes ni camarillas; de lo contrario, la organización pierde su cohesión interna. Como se cita en el artículo:

El resultado es algo así como la película. Chicas malas, donde cada uno está en su propio grupo y puede mirar con sorna a quienes no forman parte de él. McKenty llamó a esta mentalidad miope Síndrome de no inventado aquí, y ofreció tres formas en que aparece en las empresas: a través de barreras geográficas, límites organizacionales y con respecto a la experiencia en el dominio. Los equipos en ubicaciones dispares terminan formando identidades fuertes pero exclusivas como departamentos individuales. Y luego, incluso en el nivel micro dentro de los equipos, puede tener experiencia en el dominio que mantiene a las personas separadas, y las personas no pueden comunicarse de manera efectiva porque uno es un DBA y el otro es un desarrollador.

Como ocurre con la mayoría de las cosas, la respuesta al diseño de un equipo no es tan clara como aplicar una observación popular hecha hace más de cinco décadas. Hay empresas que han ampliado los límites de lo que es posible mediante el uso de pequeños equipos independientes para crear cambios rápidos, pero incluso estos equipos más pequeños aún pueden sufrir sus propias neurosis internas y desafíos de comunicación.

Una vez que cosas como la inseguridad, la desconfianza y el miedo comienzan a infiltrarse en la mentalidad de un equipo, es la ley de Conway la que nos recuerda que esos mismos rasgos se filtrarán en los sistemas que crean estos equipos. Una vez que esto sucede, tenemos que controlar estas características negativas adoptando una comunicación adecuada dentro de un equipo u organización y al mismo tiempo animando a otros a hacerlo sin importar el tamaño del equipo.

Think Insights (25 de septiembre de 2023) Ley de Conway. Obtenido de https://thinkinsights.net/strategy/conways-law/.
Ley de Conway.” Think Insights – 25 de septiembre de 2023, https://thinkinsights.net/strategy/conways-law/
Think Insights 9 de abril de 2022 Ley de Conway.visto el 25 de septiembre de 2023,<https://thinkinsights.net/strategy/conways-law/>
Piensa en ideas – Ley de Conway. [Internet]. [Accessed September 25, 2023]. Disponible de: https://thinkinsights.net/strategy/conways-law/
Ley de Conway.” Think Insights – Consultado el 25 de septiembre de 2023. https://thinkinsights.net/strategy/conways-law/
Ley de Conway.” Piensa en ideas [Online]. Disponible: https://thinkinsights.net/strategy/conways-law/. [Accessed: September 25, 2023]

Error 403 The request cannot be completed because you have exceeded your quota. : quotaExceeded



Ley de Conway – Preguntas frecuentes

Ley de Conway – Preguntas frecuentes

¿Qué es la Ley de Conway?

La Ley de Conway, también conocida como la Ley de las Organizaciones que Diseñan Sistemas, es un principio en
el ámbito de la ingeniería de software propuesto por Melvin Conway en 1967. Esta ley establece que “las
organizaciones que diseñan sistemas producirán diseños que son copias de la estructura de comunicación de
dicha organización”. En pocas palabras, esto significa que la estructura de comunicación y organización de una
empresa se reflejará en el diseño de los sistemas de software que produce.

¿Cuál es la importancia de la Ley de Conway?

La Ley de Conway es relevante en el desarrollo y diseño de software, ya que destaca la influencia que tienen las
relaciones y la comunicación interna de una organización en el resultado final de los sistemas que se crean. Esto
implica que para lograr diseños de software eficientes, es esencial entender y mejorar la estructura organizativa
y las interacciones entre los equipos de trabajo.

¿Cómo se aplica la Ley de Conway en el desarrollo de software?

La aplicación de esta ley implica que el diseño de un sistema de software estará condicionado por la estructura
de comunicación que existe entre los diferentes equipos y departamentos involucrados en su desarrollo. En
otras palabras, si una organización tiene equipos de trabajo aislados y con poca comunicación entre ellos, es
probable que el sistema resultante presente una arquitectura compleja y poco cohesionada.

¿Existen excepciones a la Ley de Conway?

Aunque la Ley de Conway es ampliamente aceptada en la industria del software, existen casos en los que se
pueden observar excepciones. Por ejemplo, cuando una organización ha implementado una estructura de
comunicación eficiente y flexible, se pueden lograr resultados más óptimos en términos de diseño de software,
incluso si la estructura organizativa no es tradicional.

¿Cómo se puede utilizar la Ley de Conway de manera efectiva?

Para utilizar la Ley de Conway de manera efectiva, las organizaciones pueden:

  1. Promover una comunicación efectiva y transparente entre los equipos de trabajo.
  2. Fomentar la colaboración y el intercambio de conocimientos entre los miembros de los diferentes
    departamentos.
  3. Reevaluar y ajustar la estructura organizativa según las necesidades del proyecto de desarrollo de
    software.
  4. Priorizar el diseño y la arquitectura adecuada para promover una estructura de software coherente con la
    organización.

Referencias Externas

Si deseas obtener más información sobre la Ley de Conway, te recomendamos visitar los siguientes enlaces:

Deja un comentario