Fonte: "Lei de Conway"

Nota do autor 42 anos após a publicação:

Talvez mais notavelmente neste artigo, ele foi publicado devido à declaração descrita no terceiro parágrafo do final. Para aliviar a dificuldade de superar os 45 parágrafos anteriores, vou expressá-lo de forma livre agora:

Qualquer organização que cria um sistema (interpretado aqui mais do que apenas um sistema de informação) inevitavelmente criará um modelo que repetirá a estrutura de comunicação da própria organização.

Acontece que esse princípio é observado não apenas no desenvolvimento de software, no contexto ao qual é frequentemente referido.

Sugiro que você se familiarize com o material e, em seguida, procure em outras áreas.

Atualmente, meu exemplo favorito é o complexo de questões sociais relacionadas à pobreza na América: acesso ao mercado de trabalho, moradia, educação e saúde. Depois de ler o artigo, considere como as estruturas de nossos vários governos influenciam sua atitude em relação a essas questões.

Como os comitês criam novos?

Melvin E. Conway
PDF original .

A atividade intelectual, como resultado da criação de um todo a partir de partes díspares, pode ser chamada de design do sistema. Seja a preparação de um grande complexo militar, recomendações para resolver problemas sociais ou uma lista de programas de computador. Um objetivo típico de uma organização de design é preparar um documento contendo uma quantidade de informações coerentemente estruturada. Chamamos essas informações de modelo do sistema. Normalmente, o iniciador é um cliente que deseja usar o modelo para fornecer qualquer ação adicional. Por exemplo, um estadista pretende propor um projeto de lei para evitar a recorrência de um desastre recente, para isso ele contrata uma equipe para descobrir as causas do desastre. Ou o fabricante precisa de um novo produto e ele designa pessoas responsáveis ​​para determinar o novo produto e planejar seu lançamento.

A organização de design pode ou não estar envolvida na implementação do sistema projetado. Muitas vezes, nos esforços do governo, existem normas que impedem o grupo de agir de acordo com suas próprias recomendações, enquanto a situação inversa prevalece no setor privado. Será razoável supor que essa condição afetará o processo de design do sistema, juntamente com outras idéias do desenvolvedor sobre seu próprio futuro. Como veremos mais adiante, os incentivos existentes em um ambiente gerencial tradicional podem ser contrários aos objetivos do cliente. [1]

Etapas do projeto

A fase inicial do projeto refere-se mais à estruturação do processo em si do que ao desenvolvimento do sistema [2]. O desenvolvimento completo é precedido por certas ações preliminares, a saber:

1. Definir os limites das atividades do projeto e o resultado final estabelecido pelo cliente e as realidades existentes.
2. Avaliação inicial da estrutura do sistema com o objetivo de formação equilibrada de equipes de desenvolvimento.

No futuro, explicaremos em detalhes que a estrutura organizacional da equipe já afeta a implementação do projeto, direta ou indiretamente. Assim, mesmo a incapacidade de proporcionar condições ideais para a busca de funcionários, a formação da equipe não será realizada de maneira absolutamente objetiva. E após a formação da equipe, as responsabilidades serão delegadas em subgrupos, estreitando o escopo da pesquisa, o que reduzirá simultaneamente o número de opções para o desenvolvimento do sistema.

Tendo atribuídas responsabilidades, os gerentes enfrentam o problema de coordenação no nível dos grupos de trabalho, o que afeta negativamente a consolidação dos esforços de cada grupo, a fim de criar um sistema uniforme. Apesar da possível diminuição desse papel de indivíduo.

O processo de design do sistema possui os seguintes estágios:

1. Definindo limites de acordo com as regras básicas.
2. Desenvolvimento de um conceito preliminar de sistema.
3. Organização do trabalho de design e delegação de tarefas de acordo com o conceito.
4. Coordenação ao nível das tarefas delegadas.
5. Combinando subsistemas em um sistema.

Em um único trabalho de design, nem todos os estágios podem ser rastreados. Pode acontecer que, no processo, seja encontrado um novo conceito de projeto mais perfeito. É claro que este não é um momento muito favorável, pois a subsequente interrupção do trabalho será dolorosa e cara. Obviamente, do ponto de vista do historiador, tudo se repete.

Nesse caso, por que sempre não há tempo suficiente para fazer tudo certo, mas sempre há tempo suficiente para refazer algo?

Projeto do sistema

Qualquer sistema serial consiste em subsistemas interconectados. A descrição da estrutura interna do sistema deve refletir seu relacionamento com o ambiente externo e o relacionamento de seus subsistemas. Ao descer para um nível mais baixo, podemos dizer o mesmo sobre o subsistema, considerando-o como um sistema. E assim por diante, até esse subsistema, que será extremamente simples e indivisível.

Exemplos

O sistema de transporte transcontinental do estado consiste em ônibus, trens, aviões, táxis, estacionamentos, terminais, etc. Este é um sistema muito heterogêneo, o que significa que seus subsistemas são bastante diversos. Ao descer para um nível mais baixo, por exemplo, veremos seus subsistemas: quadro, mecanismo, distribuição de energia, comunicação, carga útil. O sistema do motor inclui subsistemas como combustível, ignição etc.

Não é tão óbvio, mas a teoria também é um sistema. Refere-se ao ambiente externo, aos eventos observados, os quais devem explicar ou pelo menos não contradizê-los. Consiste em teorias de partes que se relacionam de maneira semelhante. Por exemplo, durante a investigação de acidente, foi criada uma teoria que descreve a trajetória da aeronave, suas comunicações, danos e interação com outros objetos durante o acidente. Cada um desses itens em si é uma história separada e também pode ser dividida em subitens, até unidades de informação individuais.

Esquemas

Na Fig. 1, o sistema é representado na forma de um diagrama - como um chocalho - com conexões (ramificações) na forma de linhas e nós principais (nós) na forma de círculos. Cada nó simboliza um subsistema que se comunica com outros subsistemas, que podem ser representados de maneira semelhante. O termo interface, que está ganhando popularidade entre os desenvolvedores, refere-se à interação de subsistemas, indicada por linhas.



A imagem gráfica demonstra claramente a forma idêntica dos dois conceitos que estamos considerando: o sistema e a organização que o projeta. Tente substituir:

1. "Sistema" para "comitê"
2. "Subsistema" para o "subcomitê"
3. "Interface" para "coordenador"

Como no caso de sistemas, vemos que as organizações de design podem ser consideradas levando em consideração vários níveis de complexidade. O governo federal é um ótimo exemplo de organização de design com um nível de complexidade que pode satisfazer qualquer engenheiro. Este é um exemplo particularmente interessante, mostrando a semelhança dos dois conceitos que estamos considerando, porque o Governo Federal é uma organização de design (desenvolve leis, tratados, políticas) e uma organização de design (com a Constituição como a principal documentação de design).

Interação primária

Agora estamos prontos para a edição principal deste artigo. Existe uma relação previsível entre a estrutura da organização de design e o sistema que ela projeta? A resposta correta é sim, e essa conexão é tão simples que geralmente é constante. Considere a seguinte "evidência".

Vamos escolher arbitrariamente o sistema e a organização que o desenvolveu e selecionar aleatoriamente o nível de complexidade do sistema projetado, esboçá-lo (nossa escolha é arbitrária, porque se observarmos relacionamentos interessantes, podemos estendê-los a qualquer organização de design e nível de complexidade). Na Fig. A Figura 2 mostra (para maior clareza) uma estrutura para a qual a afirmação abaixo é verdadeira.



Para qualquer nó x no sistema, podemos identificar o grupo de trabalho da organização de design que o desenvolveu (denotá-lo por X). Desta maneira

Resumindo esse processo, para qualquer nó do sistema, temos uma regra para encontrar o grupo de trabalho apropriado. Observe que a proporção 1: 1, ou seja, dois subsistemas podem ser projetados pela mesma organização de design.

Curiosamente, podemos fazer uma declaração semelhante em relação às filiais. Pegue quaisquer dois nós do mesmo sistema, x e y. Eles podem ou não estar conectados (ou seja, eles interagem entre si de alguma forma importante para o funcionamento do sistema ou não). Se houver uma conexão entre eles, os dois grupos de trabalho X e U, que desenvolveram dois nós de dados, tiveram que concordar com os recursos da interface para perceber a possibilidade de comunicação entre os nós. Se não houver conexão entre x e y, os subsistemas não se comunicam entre si, o que significa que os grupos de trabalho não interagiram entre si (já que não há conexão entre X e Y). [3]

O que acabamos de mostrar? Em palavras simples, demonstramos que há uma conexão estreita entre a estrutura do sistema e a estrutura da organização envolvida em seu design. Quando cada subsistema tem seu próprio grupo de trabalho separado, podemos observar que as estruturas (esquemas) do grupo de trabalho e do subsistema são idênticas. No caso em que vários grupos de trabalho desenvolvem um subsistema, a estrutura da organização de design se parece com uma estrutura do sistema, mas com menos subsistemas (nós no diagrama).

Um relacionamento semelhante de preservação de estrutura entre dois objetos é chamado de homomorfismo. Na linguagem matemática, existe um homomorfismo entre o diagrama do sistema e o diagrama de projeto da organização.

O sistema é um reflexo da organização que o projetou

Muitos projetistas de sistemas experientes acreditam que qualquer um pode fazer melhor qualquer projeto de sistema. Em outras palavras, é incorreto e incorreto falar sobre a tarefa de design, exceto no contexto de local, tempo, nível de conhecimento e tecnologia. Isso deve ser lembrado por quem lê a história do trabalho de projetar um objeto ou lembra e analisa seu trabalho.

O desenvolvimento de tradutores de computador de linguagens de programação como FORTRAN e COBOL é um excelente exemplo. Em meados da década de 1950, quando surgiram protótipos dessas linguagens, seus compiladores eram ainda mais pesados ​​que os próprios computadores, gigantescos naqueles dias que deveriam executar comandos. Hoje, esses tradutores são apenas maravilhas históricas que não têm nada em comum com os compiladores modernos. (Vale ressaltar que uma enorme inovação no desenvolvimento de compiladores foi associada ao surgimento de novos grupos de pessoas na área anteriormente consideradas patrimônio dos fabricantes de computadores - este foi inicialmente um pequeno grupo universitário de pesquisadores coesos, seguido por desenvolvedores de software independentes).

Se assumirmos que, para qualquer requisito de sistema, existem vários projetos de sistema que atenderão a esse requisito, também devemos perguntar se a escolha da organização de design afeta o processo de escolha de um projeto de sistema desta série. Se acreditarmos em nosso homomorfismo, concordaremos com o que influencia. Dado que a organização não possui uma estrutura de comunicação flexível, esta organização carimbará uma cópia de si mesma em qualquer produto do projeto. Quanto maior a organização, menos flexível ela é e mais essa propriedade se manifesta.

Exemplos

Em uma organização de pesquisa, havia oito pessoas que deveriam fazer os compiladores COBOL e ALGOL. Após uma avaliação inicial da complexidade e dos possíveis prazos, cinco deles foram determinados a trabalhar com o COBOL e três foram designados para trabalhar com o ALGOL. Como resultado, o compilador COBOL trabalhou em cinco passagens e o compilador ALGOL em três passagens.

Dois serviços militares, sob a liderança de seus comandantes em chefe, desenvolveram um sistema de armas para suas necessidades. Depois disso, não sem esforço, eles fizeram uma cópia de sua estrutura organizacional (ver Fig. 3a)



Preste atenção ao sistema operacional do computador envolvido nesta tarefa. Depois de estudá-lo em detalhes, vemos que ele consiste em três partes: hardware, software e aplicativos (veja a Fig. 3b). Seus desenvolvedores correspondem a esses subsistemas: engenheiros do fabricante do computador, programadores de sistemas e desenvolvedores de aplicativos personalizados (esse caso raro em que especialistas em hardware e software colaboram, e não apenas se suportam com dificuldade).

Gerenciamento do sistema

A estrutura dos grandes sistemas tende a decair à medida que se desenvolvem. Essa observação é especialmente evidente ao considerar os grandes sistemas de informação militar dos últimos dez anos. Eles são os objetos mais complexos de todos os criados anteriormente pelo homem. Surgiu uma atividade chamada "gerenciamento de sistemas", inclusive devido à tendência dos sistemas de se separarem em seus elementos constituintes. Vejamos a praticidade do gerenciamento de sistemas no contexto da idéia principal deste artigo.

Por que grandes sistemas desmoronam? Esse processo passa por três estágios, os dois primeiros controláveis, e o terceiro é uma conseqüência direta do nosso homomorfismo.

1. Em primeiro lugar, os desenvolvedores, tendo percebido o tamanho do sistema projetado, não conseguem resistir à tentação de contratar o maior número possível de pessoas para criá-lo.
2. Em segundo lugar, ao aplicar o modelo gerencial usual para a implementação de um projeto de larga escala, sua estrutura de comunicação se divide em partes separadas.
3. Terceiro, os processos de desintegração que ocorrem na estrutura do organizador-projetista ocorrem na estrutura do sistema, de acordo com o fenômeno do homomorfismo.

Para começar, considere a situação com "superpopulação". O desejo natural do desenvolvedor de delegar tarefas é bastante compreensível quando o nível de complexidade do sistema se aproxima dos limites de seu entendimento. Este é um ponto de virada no processo de desenvolvimento. Ou ele luta para simplificar o sistema e vence, ou perde o controle sobre ele. O resultado é quase previsível, dada a pressão do prazo e do orçamento.

Se o prazo for perdido, o gerente será exatamente o culpado se ele não usar todos os recursos para evitar isso. Portanto, ele tentará influenciar o desenvolvedor, que talvez prefira lidar com a complexidade do sistema e não delegar tarefas a outros. Como resultado, o número de recursos envolvidos aumentará.

Ou outro exemplo, demonstrando um caso semelhante de conflito do gerente e a integridade do sistema projetado. O gerente deve fornecer a parte crítica e complexa do trabalho para implementação. Ele pode escolher um dos dois artistas: uma nova pequena empresa, que se distingue por uma abordagem criativa e com baixos salários, ou um escritório respeitável que se estabeleceu, com preços mais "realistas". Ele sabe que se uma empresa jovem e brilhante não lidar com a tarefa, ele será culpado de interromper o projeto. Se uma organização conhecida falhar, isso indicará apenas que a tarefa é realmente difícil.

Qual é o problema aqui? Basicamente, no método de avaliação e alocação de recursos, que é tradicionalmente usado. Portanto, a unidade do recurso é o dólar, portanto todos os recursos são expressos em termos de dólar. Se o recurso for mão-de-obra humana, a unidade de medida será o custo de uma hora de trabalho multiplicado pelo número de trabalhadores.

A falácia dessa abordagem é que o trabalho de duas pessoas durante o ano é avaliado da mesma maneira que o trabalho de centenas de pessoas durante a semana. Mas como a estrutura organizacional do trabalho de duzentos e cinquenta será diferente, dado o homomorfismo, pode-se argumentar que eles criarão sistemas diferentes, portanto você não deve comparar o custo do trabalho deles. Por experiência, sabemos que duas pessoas selecionadas corretamente, se lidarem, mostrarão o melhor resultado. Pressupostos que podem ser verdadeiros para descascar batatas ou colocar tijolos são errôneos no design do sistema.

A Lei de Parkinson [4] é de grande importância na redistribuição de recursos trabalhistas nas atividades do projeto. Desde que a reputação do gerente dependa do tamanho do orçamento, ele estará interessado em expandir sua organização. Essa não é uma motivação adequada para resolver problemas de desenvolvimento de sistemas. , , , . , -, .

— — . . , . .

. , . . , .

Conclusão

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

, . , , . . .

[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)

:

Mais

• «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 . A mãe de todas as demos

Se você realmente quer entender o NLS, deve esquecer a realidade de hoje. Esqueça tudo o que você sabe sobre computadores. Imagine que você ainda não sabe o que é um computador. Retorno a 1962. E então leia o que ele tem em mente .
- Bret Victor, Algumas palavras sobre Douglas Engelbart