Fuente: "Ley de Conway"

Nota del autor 42 años después de la publicación:

Quizás lo más notable en este artículo, fue publicado debido a la declaración descrita en el tercer párrafo desde el final. Para aliviar la dificultad de superar los 45 párrafos anteriores, lo expresaré en forma gratuita ahora:

Cualquier organización que diseñe un sistema (interpretado aquí más que un simple sistema de información) inevitablemente creará un modelo que repetirá la estructura de comunicación de la organización misma.

Resulta que este principio se observa no solo en el desarrollo de software, en el contexto al que a menudo se hace referencia.

Le sugiero que se familiarice con el material, y luego mire a su alrededor y búsquelo en otras áreas.

Actualmente, mi ejemplo favorito es el complejo de problemas sociales relacionados con la pobreza en Estados Unidos: acceso al mercado laboral, vivienda, educación y atención médica. Después de leer el artículo, considere cómo las estructuras de nuestros diversos gobiernos influyen en su actitud ante tales problemas.

¿Cómo crean los comités nuevos?

Melvin E. Conway
PDF original

La actividad intelectual, como resultado de la cual se crea un todo a partir de partes dispares, se puede llamar diseño del sistema. Ya sea la preparación de un gran complejo militar, recomendaciones para resolver problemas sociales o una lista de programas de computadora. Un objetivo típico de una organización de diseño es preparar un documento que contenga una cantidad de información coherentemente estructurada. Llamamos a esta información el modelo del sistema. Por lo general, el iniciador es un cliente que quiere usar el modelo para proporcionar cualquier otra acción. Por ejemplo, un estadista tiene la intención de proponer un proyecto de ley para evitar la recurrencia de un desastre reciente, para esto contrata a un equipo para averiguar las causas del desastre. O el fabricante necesita un nuevo producto y designa personas responsables para determinar el nuevo producto y planificar su lanzamiento.

La organización de diseño puede o no estar involucrada en la implementación del sistema diseñado. A menudo, en los esfuerzos del gobierno, existen normas que impiden que el grupo actúe de acuerdo con sus propias recomendaciones, mientras que la situación inversa prevalece en el sector privado. Será razonable suponer que esta condición afectará el proceso de diseño del sistema, junto con otras ideas del desarrollador sobre su propio futuro. Como veremos más adelante, los incentivos que existen en un entorno administrativo tradicional pueden ser contrarios a los objetivos del cliente. [1]

Etapas de diseño

La fase de diseño inicial se relaciona más con la estructuración del proceso en sí que con el desarrollo del sistema [2]. El desarrollo completo está precedido por ciertas acciones preliminares, a saber:

1. Definir los límites de las actividades del proyecto y el resultado final establecido por el cliente y las realidades existentes.
2. Evaluación inicial de la estructura del sistema con el objetivo de una formación equilibrada de equipos de desarrollo.

En el futuro, explicaremos en detalle que la estructura organizativa del equipo ya afecta la implementación del proyecto, directa o indirectamente. Entonces, incluso la incapacidad de proporcionar las condiciones ideales para la búsqueda de empleados, la formación del equipo no se llevará a cabo de manera absolutamente objetiva. Y después de la formación del equipo, las responsabilidades se delegarán en subgrupos, reduciendo el alcance de la investigación, lo que reducirá simultáneamente el número de opciones para el desarrollo del sistema.

Una vez asignadas las responsabilidades, los gerentes enfrentan el problema de la coordinación a nivel de los grupos de trabajo, lo que afecta negativamente la consolidación de los esfuerzos de cada grupo para crear un sistema uniforme. A pesar de la posible disminución en este papel de un individuo.

El proceso de diseño del sistema tiene las siguientes etapas:

1. Definir límites de acuerdo con las reglas básicas.
2. Desarrollo de un concepto de sistema preliminar.
3. Organización del trabajo de diseño y delegación de tareas de acuerdo con el concepto.
4. Coordinación a nivel de tareas delegadas.
5. Combinando subsistemas en un sistema.

En un trabajo de diseño único, no se pueden rastrear todas las etapas. Puede suceder que en el proceso se encuentre un nuevo concepto de proyecto más perfecto. Este, por supuesto, no es un momento muy favorable, ya que el cese posterior del trabajo será doloroso y costoso. Por supuesto, desde el punto de vista del historiador, todo se repite.

En este caso, ¿por qué no siempre hay tiempo suficiente para hacer todo bien, pero siempre hay tiempo suficiente para rehacer algo?

Diseño del sistema

Cualquier sistema en serie consta de subsistemas interconectados. La descripción de la estructura interna del sistema debe reflejar su relación con el entorno externo y la relación de sus subsistemas. Bajando a un nivel inferior, podemos decir lo mismo sobre el subsistema, considerándolo como un sistema. Y así sucesivamente, hasta ese subsistema, que será extremadamente simple e indivisible.

Ejemplos

El sistema de transporte transcontinental del estado consiste en autobuses, trenes, aviones, taxis, estacionamientos, terminales, etc. Este es un sistema muy heterogéneo, lo que significa que sus subsistemas son bastante diversos. Bajando a un nivel inferior, por ejemplo, veremos sus subsistemas: marco, motor, distribución de energía, comunicación, carga útil. El sistema del motor incluye subsistemas como combustible, ignición, etc.

No es tan obvio, pero la teoría también es un sistema. Se refiere al entorno externo, a los eventos observados, que debería explicar o al menos no contradecirlos. Consiste en teorías de partes que se relacionan entre sí de manera similar. Por ejemplo, en el curso de la investigación del choque, se creó una teoría que describe la trayectoria de la aeronave, sus comunicaciones, daños e interacción con otros objetos durante el accidente. Cada uno de estos elementos en sí mismo es una historia separada y también se puede dividir en subelementos, hasta unidades individuales de información.

Esquemas

En la fig. 1, el sistema se representa en forma de diagrama, como un sonajero, con conexiones (ramas) en forma de líneas y nodos principales (nodos) en forma de círculos. Cada nodo simboliza un subsistema que se comunica con otros subsistemas, que pueden representarse de manera similar. El término interfaz, que está ganando popularidad entre los desarrolladores, se refiere a la interacción de subsistemas, indicada por líneas.



La imagen gráfica demuestra claramente la forma idéntica de los dos conceptos que estamos considerando: el sistema y la organización que lo diseña. Intenta reemplazar:

1. "Sistema" a "comité"
2. "Subsistema" al "subcomité"
3. "Interfaz" a "coordinador"

Como en el caso de los sistemas, vemos que las organizaciones de diseño pueden considerarse teniendo en cuenta varios niveles de complejidad. El gobierno federal es un gran ejemplo de una organización de diseño con un nivel de complejidad que puede satisfacer a cualquier ingeniero. Este es un ejemplo particularmente interesante, que muestra la similitud de los dos conceptos que estamos considerando, porque el Gobierno Federal es una organización de diseño (desarrolla leyes, tratados, políticas) y una organización de diseño (con la Constitución como la documentación principal del diseño).

Interacción primaria

Ahora estamos listos para el tema principal de este artículo. ¿Existe una relación predecible entre la estructura de la organización de diseño y el sistema que diseña? La respuesta correcta es sí, y esta conexión es tan simple que a menudo es constante. Considere la siguiente "evidencia".

Elija arbitrariamente el sistema y la organización que lo desarrolló y seleccione al azar el nivel de complejidad del sistema diseñado, esbocemos (nuestra elección es arbitraria, porque si observamos relaciones interesantes, podemos extenderlas a cualquier organización de proyecto y nivel de complejidad). En la fig. La Figura 2 muestra (para mayor claridad) una estructura para la cual la siguiente afirmación es verdadera.



Para cualquier nodo x en el sistema, podemos identificar el grupo de trabajo de la organización de diseño que lo desarrolló (denotarlo por X). De esta manera

resumiendo este proceso, para cualquier nodo en el sistema tenemos una regla para encontrar el grupo de trabajo apropiado. Tenga en cuenta que la relación 1: 1, es decir dos subsistemas pueden ser diseñados por la misma organización de diseño.

Curiosamente, podemos hacer una declaración similar con respecto a las sucursales. Tome dos nodos del mismo sistema, x e y. Pueden o no estar conectados (es decir, interactúan entre sí de alguna manera importante para el funcionamiento del sistema o no). Si hay una conexión entre ellos, entonces los dos grupos de trabajo X y U, que desarrollaron dos nodos de datos, tuvieron que ponerse de acuerdo sobre las características de la interfaz para darse cuenta de la posibilidad de comunicación entre nodos. Si no hay conexión entre x e y, entonces los subsistemas no se comunican entre sí, lo que significa que los grupos de trabajo no interactuaron entre sí (ya que no hay conexión entre X e Y). [3]

¿Qué acabamos de mostrar? En palabras simples, hemos demostrado que existe una estrecha conexión entre la estructura del sistema y la estructura de la organización que participa en su diseño. Cuando cada subsistema tiene su propio grupo de trabajo separado, podemos observar que las estructuras (esquemas) del grupo de trabajo y el subsistema son idénticas. En el caso de que varios grupos de trabajo desarrollen un subsistema, la estructura de la organización de diseño parece una estructura de sistema, pero con menos subsistemas (nodos en el diagrama).

Una relación similar de preservación de la estructura entre dos objetos se llama homomorfismo. En lenguaje matemático, existe un homomorfismo entre el diagrama del sistema y el diagrama de proyección de la organización.

El sistema es un reflejo de la organización que lo diseña.

Muchos diseñadores de sistemas experimentados creen que cualquiera puede mejorar el diseño de cualquier sistema. En otras palabras, es erróneo e incorrecto hablar sobre la tarea de diseño, excepto en el contexto del lugar, el tiempo, el nivel de conocimiento y la tecnología. Esto debe ser recordado por aquellos que leen la historia del trabajo de diseño de un objeto o recuerdan y analizan su trabajo.

El desarrollo de traductores informáticos de lenguajes de programación como FORTRAN y COBOL es un excelente ejemplo. A mediados de la década de 1950, cuando aparecieron los prototipos de estos lenguajes, sus compiladores eran aún más engorrosos que las computadoras mismas, gigantes en aquellos días que se suponía que ejecutaban comandos. Hoy, estos traductores son solo maravillas históricas que no tienen nada en común con los compiladores modernos. (Vale la pena señalar que un gran avance en el desarrollo de compiladores se asoció con la aparición de nuevos grupos de personas en el área que anteriormente se consideraba patrimonio de los fabricantes de computadoras; al principio, este era un pequeño grupo de investigadores universitarios cohesivo, seguido de desarrolladores de software independientes).

Si suponemos que para cualquier requisito del sistema hay una serie de proyectos del sistema que cumplirán con este requisito, también debemos preguntarnos si la elección de la organización de diseño afecta el proceso de elegir un proyecto de sistema de esta serie. Si creemos en nuestro homomorfismo, entonces estaremos de acuerdo con las influencias. Dado que la organización no tiene una estructura de comunicación flexible, estampará una copia de sí misma en cualquier producto del proyecto. Cuanto más grande es la organización, menos flexible es y más se manifiesta esta propiedad.

Ejemplos

En una organización de investigación, se suponía que ocho personas debían fabricar los compiladores COBOL y ALGOL. Después de una evaluación inicial de la complejidad y posibles plazos, cinco de ellos fueron determinados a trabajar con COBOL, y tres fueron asignados a trabajar con ALGOL. Como resultado, el compilador COBOL trabajó en cinco pases, y el compilador ALGOL en tres pases.

Dos servicios militares bajo el liderazgo de sus comandantes en jefe han desarrollado un sistema de armas para sus necesidades. Después de eso, no sin esfuerzo, hicieron una copia de su estructura organizacional (ver Fig. 3a)



Presta atención al sistema operativo de la computadora involucrado en esta tarea. Después de estudiarlo en detalle, vemos que consta de tres partes: hardware, software y aplicaciones (ver Fig. 3b). Sus desarrolladores corresponden a estos subsistemas: ingenieros del fabricante de la computadora, sus programadores de sistemas y desarrolladores de aplicaciones personalizadas (ese caso raro cuando los especialistas en hardware y software colaboran, y no solo se soportan entre sí con dificultad).

Gestión del sistema

La estructura de los sistemas grandes tiende a deteriorarse a medida que se desarrollan. Esta observación es especialmente evidente cuando se consideran los grandes sistemas de información militar de los últimos diez años. Son los objetos más complejos de todos los creados previamente por el hombre. Ha surgido una actividad llamada "gestión del sistema", incluso debido a la tendencia de los sistemas a separarse en sus elementos constitutivos. Veamos la practicidad de la gestión de sistemas en el contexto de la idea principal de este artículo.

¿Por qué se desmoronan los sistemas grandes? Este proceso pasa por tres etapas, las dos primeras son controlables, y la tercera etapa es una consecuencia directa de nuestro homomorfismo.

1. En primer lugar, los desarrolladores, habiéndose dado cuenta del tamaño del sistema proyectado, no pueden resistir la tentación de contratar a tantas personas como sea posible para crearlo.
2. En segundo lugar, cuando se aplica el modelo de gestión habitual para la implementación de un proyecto a gran escala, su estructura de comunicación se divide en partes separadas.
3. En tercer lugar, los procesos de desintegración que ocurren en la estructura del diseñador de la organización ocurren en la estructura del sistema, de acuerdo con el fenómeno del homomorfismo.

Para comenzar, considere la situación de "sobrepoblación". El deseo natural del desarrollador de delegar tareas es bastante comprensible cuando el nivel de complejidad del sistema se acerca a los límites de su comprensión. Este es un punto de inflexión en el proceso de desarrollo. O lucha para simplificar el sistema y gana, o pierde el control sobre él. El resultado es casi predecible, dada la presión del marco de tiempo y el presupuesto.

Si se pierde el plazo, el gerente tendrá la culpa exacta si no utilizó todos los recursos para evitarlo. Por lo tanto, intentará influir en el desarrollador, quien, tal vez, preferiría lidiar con la complejidad del sistema y no delegar tareas a otros. Como resultado, aumentará la cantidad de recursos involucrados.

O otro ejemplo, que demuestra un caso similar de conflicto del administrador y la integridad del sistema diseñado. El gerente debe entregar la parte crítica y compleja del trabajo para la implementación. Puede elegir uno de los dos artistas: una nueva empresa pequeña, que se distingue por un enfoque creativo y bajos salarios, o una oficina de buena reputación que se ha establecido, que tiene precios más "realistas". Él sabe que si una empresa joven y brillante no hace frente a la tarea, será culpable de interrumpir el proyecto. Si falla una organización conocida, esto solo indicará que la tarea es realmente difícil.

¿Cuál es el truco aquí? Básicamente, en el método de evaluación y asignación de recursos, que se usa tradicionalmente. Entonces, la unidad del recurso es el dólar, por lo que todos los recursos se expresan en términos de dólares. Si el recurso es mano de obra humana, la unidad de medida será el costo de una hora de trabajo multiplicado por el número de trabajadores.

La falacia de este enfoque es que el trabajo de dos personas durante el año se evalúa de la misma manera que el trabajo de cientos de personas durante la semana. Pero dado que la estructura organizativa del trabajo de doscientos será diferente, dado el homomorfismo, se puede argumentar que crearán sistemas diferentes, por lo que no debe comparar el costo de su trabajo. Por experiencia, sabemos que dos personas seleccionadas correctamente, si se las arreglan, mostrarán el mejor resultado. Las suposiciones que pueden ser ciertas para pelar papas o colocar ladrillos son erróneas en el diseño del sistema.

La Ley de Parkinson [4] es de gran importancia en la redistribución de los recursos laborales en las actividades del proyecto. Mientras la reputación del gerente dependa del tamaño del presupuesto, estará interesado en expandir su organización. Esta no es una motivación adecuada para resolver problemas de desarrollo de sistemas. Una vez que existe una organización, entonces, por supuesto, se utilizará. Quizás la razón más convincente para la existencia de tantos sistemas mal diseñados en la actualidad radica en la presencia de organizaciones de diseño que buscan trabajo.

En segundo lugar, la razón del colapso del proceso de diseño del sistema (fragmentación de la estructura de comunicación de la organización de diseño) comienza a manifestarse con el comienzo de la delegación de tareas. Según la teoría de la probabilidad elemental, el número de comunicaciones posibles es igual a la mitad del cuadrado del número de empleados de la organización. , . .

. , . . , .

Conclusión

— , ( ) , . , . : , , . , . , , , , , - , .

, . , , . . .

[1] . « » (John Kenneth Galbraith's The New Industrial State). VI, «».

[2] C. « » (.J. Middleton, «How to Set Up a Project Organization,» 1967, . 73).

[3] . , . , , .

[4] .. « » (C. Northcote Parkinson, Parkinson's Law and Other Studies in Administration, 1957)

:

Más

• «How do Committees Invent?»
• Exploring the Duality between Product and Organizational Architectures: A Test of the «Mirroring» Hypothesis
• Does Conway's Law apply to Linux?
• Conway's Law [Framework of the Day]
• One-on-one with Mel Conway and Mike Amundsen

«»

«Augmenting Human Intellect:
A Conceptual Framework» , .

«» — « », «» , , () .

— ( , ! , .) — , , , , , , , , WikiPedia, Web Archive, Knol, Quora, Cybersyn, Xanadu, DARPA, IARPA.

— 50 . La madre de todas las demos.

Si realmente quieres entender NLS, debes olvidar la realidad de hoy. Olvida todo lo que sabes sobre computadoras. Imagina que todavía no sabes qué es una computadora. Regreso a 1962. Y luego lee lo que tiene en mente .
- Bret Victor, algunas palabras sobre Douglas Engelbart