[Перевод] Первоисточник: «закон Конвея»13.12.2018 01:05

Примечание автора спустя 42 года после публикации:

Возможно, наиболее примечательно в данной статье то, что она была опубликована благодаря утверждению, описанному в третьем абзаце с конца. Для облегчения трудности преодоления предшествующих 45 абзацев я озвучу его в свободной форме сейчас:

Любая организация, проектирующая систему (трактуется здесь шире, чем просто информационная система), неизбежно создаст такую модель, которая будет повторять коммуникационную структуру самой организации.

Оказывается, этот принцип наблюдается не только в разработке программного обеспечения, в контексте которого его часто упоминают.

Предлагаю вам ознакомиться с материалом, а потом оглянуться и поискать его в других сферах.

В настоящее время моим любимым примером является комплекс социальных вопросов, касающихся бедности в Америке: доступ к рынку труда, жилищному обеспечению, образованию и здравоохранению. После прочтения статьи подумайте над тем, как структуры наших различных правительств влияют на их отношение к подобным вопросам.

Как комитеты создают новое?

Мелвин Конвей (Melvin E. Conway)
Оригинал PDF.
Интеллектуальную деятельность, в результате которой создается целое из разрозненных частей, можно назвать проектированием системы. Будь то подготовка крупного военного комплекса, рекомендаций по решению социальных проблем или перечня компьютерных программ. Типичная цель проектной организации — подготовка документа, содержащего когерентно структурированный объем информации. Назовем эту информацию моделью системы. Обычно инициатором является заказчик, который хочет использовать модель для обеспечения каких-либо дальнейших действий. Например, государственный деятель намерен предложить законопроект по предотвращению повторения недавнего бедствия, для этого он нанимает команду для выяснения причин катастрофы. Или производителю требуется новый продукт, и он назначает ответственных лиц для определения новой продукции и планирования ее выпуска.

Проектная организация может быть или не быть задействована в воплощении в жизнь спроектированной системы. Зачастую в государственных начинаниях существуют нормы, препятствующие группе действовать в соответствии с собственными рекомендациями, в то время как в частном секторе преобладает обратная ситуация. Будет резонно предположить, что это условие будет влиять на процесс проектировки системы, наравне с другими мыслями разработчика о собственном будущем. Как мы увидим далее, существующие в традиционной управленческой среде побудительные мотивы могут противоречить целям заказчика. [1]

Этапы проектирования

Первоначальный этап проектирования относится скорее к структурированию самого процесса, чем к разработке системы [2]. Полноценной разработке предшествуют определенные предварительные действия, а именно:

1. Определение границ проектной деятельности и итогового результата, установленных заказчиком и существующими реалиями.
2. Первичная оценка структуры системы с целью взвешенного формирования групп разработчиков.

В дальнейшем мы подробно объясним, что организационная структура команды уже влияет на реализацию проекта, явно или косвенно. Так, даже невозможность обеспечить идеальные условия поиска сотрудников, формирование команды будет выполнено не абсолютно объективно. А после формирования команды обязанности будут делегироваться подгруппам, сужая область исследования, что одновременно уменьшит количество вариантов развития системы.

Распределив обязанности, управляющие сталкиваются с проблемой координации на уровне рабочих групп, что отрицательно сказывается на консолидации усилий каждой группы в целях создания единообразной системы. Несмотря на возможное снижение при этом роли отдельного индивидуума.

Процессу проектирования системы присущи следующие стадии:

1. Определение границ в соответствии с базовыми правилами.
2. Выработка предварительной концепции системы.
3. Организация проектировочной работы и делегирование заданий в соответствии с концепцией.
4. Координация на уровне делегированных заданий.
5. Объединение подсистем в систему.

В отдельно взятой работе по проектированию могут не прослеживаться все стадии. Может так случится, что в процессе работы будет найдена новая, более совершенная концепция проекта. Это, конечно, не совсем благоприятный момент, так как последующее прекращение работы будет болезненным и дорогостоящим. Безусловно, с точки зрения историка все повторяется.

В таком случае, почему вечно не хватает времени сделать все правильно, однако всегда хватает времени что-то переделывать?

Проектирование системы

Любая последовательная система состоит из взаимосвязанных подсистем. Описание внутреннего устройства системы должно отображать ее связи с внешней средой и взаимосвязь ее подсистем. Спускаясь на уровень ниже, можно то же самое сказать о подсистеме, рассматривая ее как систему. И так далее, вплоть до такой подсистемы, которая будет предельно проста и неделима.

Примеры

Государственная трансконтинентальная транспортная система состоит из автобусов, поездов, самолетов, такси, парковок, терминалов и т.д. Это очень разнородная система, что значит, ее подсистемы довольно разнообразны. Спускаясь на уровень ниже, на уровень самолета, например, мы увидим его подсистемы: каркас, двигатель, распределение мощности, связь, полезная нагрузка. К системе двигателя относятся такие подсистемы как топливо, зажигание и пр.

Не так очевидно, но теория является тоже системой. Она относится к внешней среде, к наблюдаемым событиям, которые она должна объяснять или, по меньшей мере, не противоречить им. Она состоит из частей-теорий, которые соотносятся между собой подобным образом. Например, в ходе расследования авиакатастрофы создана теория, описывающая траекторию самолета, его сообщения, повреждения, взаимодействие с другими объектами во время происшествия. Каждый из этих пунктов сам по себе является отдельной историей и может быть также разделен на подпункты, до отдельных единиц информации.

Схемы

На Рис. 1 система изображена в виде схемы — похожей на погремушку — со связями (branches) в виде линий и основными узлами (nodes) в виде окружностей. Каждый узел символизирует подсистему, которая сообщается с другими подсистемами, которые могут быть изображены аналогичным образом. Термин интерфейс (interface), который набирает популярность среди разработчиков, относится к взаимодействию подсистем, обозначенному линиями.

Графическое изображение наглядно демонстрирует одинаковую форму двух понятий, которые мы рассматриваем: системы и организации, которая ее проектирует. Попробуйте заменить:

1. «систему» на «комитет»
2. «подсистему» на «подкомитет»
3. «интерфейс» на «координатор»

Также как в случае с системами мы видим, что проектные организации могут быть рассмотрены с учетом нескольких уровней сложности. Федеральное правительство являет собой прекрасный пример проектной организации с таким уровнем сложности, который может удовлетворить любого инженера. Это особенно интересный пример, показывающий схожесть двух рассматриваемых нами концепций, потому что Федеральное правительство является одновременно и проектной организацией (разрабатывает законы, договоры, политику) и проектируемой организацией (с Конституцией в качестве первичной проектной документации).

Основное взаимодействие

Сейчас мы готовы для основного вопроса данной статьи. Существует ли предсказуемая взаимосвязь между структурой проектной организации и проектируемой ею системой? Правильный ответ: да, и эта связь настолько проста, что зачастую постоянна. Рассмотрите следующее «доказательство».

Давайте произвольно выберем систему и разработавшую ее организацию и выберем случайным образом уровень сложности спроектированной системы, изобразим его схематично (наш выбор произволен, потому что в случае наблюдения интересных взаимосвязей, мы сможем распространить их на любую проектную организацию и уровень сложности). На Рис. 2 изображена (для наглядности) структура, для которой нижеуказанное утверждение верно.

Для любого узла х в системе мы можем идентифицировать рабочую группу проектной организации, которая его разработала (обозначим ее Х). Таким образом,

обобщая этот процесс, для любого узла системы у нас есть правило по поиску соответствующей рабочей группы. Обратите внимание, что здесь не обязательно сохраняется пропорция 1:1, т.е. две подсистемы могут быть спроектированы одной и той же проектной организацией.

Занимательно, что мы можем сделать похожее утверждение относительно связей (branches). Возьмите два любых узла одной системы, х и у. Они могут быть связаны, а могут и не быть (т.е. либо они взаимодействуют друг с другом каким-либо важным для функционирования системы образом, либо нет). Если между ними есть связь, тогда две рабочих группы Х и У, которые разработали два данных узла, должны были договориться об особенностях интерфейса для реализации возможности связи между узлами. Если же между х и у нет связи, то подсистемы не сообщаются между собой, а значит и рабочие группы не взаимодействовали друг с другом (т.к. между Х и У нет связи). [3]

Что мы только что показали? Говоря простыми словами, мы продемонстрировали, что есть тесная связь между структурой системы и структурой организации, которая занимается ее проектировкой. Когда у каждой подсистемы есть своя отдельная рабочая группа, мы можем наблюдать что структуры (схемы) рабочей группы и подсистемы идентичны. В случае, когда несколько рабочих групп разрабатывают одну подсистему, структура проектной организации выглядит как структура системы, но с меньшим количеством подсистем (узлов на схеме).

Подобная сохраняющая структуру взаимосвязь между двумя объектами называется гомоморфизм. Говоря математическим языком, наблюдается гомоморфизм между схемой системы и схемой проектирующей ее организации.

Система является отражением проектирующей ее организации

Многие опытные разработчики систем верят, что любой проект системы когда-нибудь кто-нибудь сможет сделать лучше. Другими словами, ошибочно и не корректно говорить о проектировочном задании кроме как в контексте места, времени, уровня знаний и технологий. Об этом должны помнить те, кто читает историю о работе по проектированию какого-либо объекта или вспоминает и анализирует свою работу.

Ход разработки компьютерных переводчиков таких языков программирования, как FORTRAN и COBOL отличный тому пример. В середине 50-х годов, когда появились прототипы этих языков, их компиляторы были еще более громоздкими, чем сами компьютеры, гигантские в те времена, которые должны были выполнять команды. Сегодня эти переводчики лишь исторические диковины, которые не имеют ничего схожего с современными компиляторами. (Стоит отметить, что огромный рывок в разработке компиляторов ассоциировался с появлением новых групп людей в области, ранее считавшейся вотчиной производителей компьютеров, — это была сначала небольшая сплоченная университетская группа исследователей, вслед за которой потянулись независимые разработчики программного обеспечения).

Если мы допускаем, что для любого системного требования есть ряд системных проектов, которые будут отвечать данному требованию, мы также должны задастся вопросом, влияет ли выбор организации-проектировщика на процесс выбора системного проекта из этого ряда. Если мы верим в наш гомоморфизм, то мы согласимся с тем, что влияет. Учитывая, что в организации не гибкая коммуникационная структура, эта организация будет штамповать копию себя в любом проектном продукте. Чем больше организация, тем менее она гибкая и тем сильнее проявляется это свойство.

Примеры

В одной исследовательской организации было восемь человек, которые должны были сделать компиляторы COBOL и ALGOL. После первичной оценки сложности и возможных сроков, пять из них были определены на работу с COBOL, а трое были назначены работать с ALGOL. В результате компилятор COBOL работал в пяти проходах, а компилятор ALGOL — в трех.

Две военные службы под руководством своих главнокомандующих разработали систему вооружений для своих нужд. После, не без усилий, они сделали копию своей организационной структуры (см. Рис. 3а)

Обратите внимание на операционную систему компьютера, задействованную в решении этой задачи. Детально ее изучив, видим, что она состоит из трех частей: оборудование, программное обеспечение и приложения (см. Рис. 3b). Этим подсистемам соответствуют их разработчики: инженеры производителя компьютеров, его системные программисты и разработчики пользовательских приложений (тот редкий случай, когда специалисты оборудования и программного обеспечения сотрудничают, а не просто с трудом терпят друг друга).

Управление системой

Структура больших систем имеет тенденцию распадаться по мере развития. Это наблюдение особенно очевидно при рассмотрении крупных военных информационных систем последних десяти лет. Они являются самыми сложными объектами из всех ранее созданных человеком. Деятельность под названием «управление системой» возникла, в том числе по причине тенденции систем разделяться на составные элементы. Давайте рассмотрим практичность управления системами в разрезе основной идеи данной статьи.

Почему крупные системы распадаются на составные части? Данный процесс проходит три стадии, первые две из которых контролируемы, а третья стадия является прямым следствием нашего гомоморфизма.

1. Во-первых, разработчики, осознав размер проектируемой системы, не могут противостоять соблазну нанять как можно больше людей для ее создания.
2. Во-вторых, при применении привычной управленческой модели для реализации столь масштабного проекта распадается на отдельные части ее коммуникационная структура.
3. В-третьих, дезинтеграционные процессы, происходящие в структуре организации-проектировщике, происходят и в структуре системы, в соответствии с явлением гомоморфизма.

Для начала рассмотрим ситуацию с «перенаселением». Вполне понятно естественное стремление разработчика делегировать задания, когда уровень сложности системы приближается к границам его понимания. Это поворотный момент в процессе разработки. Либо он борется за упрощение системы и побеждает, либо он теряет контроль над ней. Итог почти предсказуем, учитывая давление временных рамок и бюджета.

При срыве сроков управляющий будет точно виноват, если он не использовал все ресурсы для предотвращения этого. Поэтому он постарается повлиять на разработчика, который, может быть, и предпочел бы побороться со сложностью системы, а не делегировать задачи другим. В итоге количество задействованных ресурсов увеличится.

Или другой пример, демонстрирующий схожий случай конфликта управляющего и целостности проектируемой системы. Управляющий должен отдать на реализацию критичную и сложную часть работы. Выбрать он может одного из двух исполнителей: новая маленькая компания, которая отличается творческим подходом и низкой оплатой, либо зарекомендовавшая себя уважаемая контора, у которой более «реалистичные» расценки. Он знает, что если светлая молодая компания не справится с заданием, он будет виновен в срыве проекта. Если же известная организация не справится, то это будет лишь свидетельствовать о том, что задача и вправду трудная.

В чем же здесь загвоздка? В основном, в способе оценки и распределении ресурсов, который традиционно используется. Так, единицей ресурса выступает доллар, поэтому все ресурсы выражаются в долларовом выражении. Если ресурсом является человеческий труд, единицей измерения будет стоимость одного часа работы помноженная на количество работников.

Ошибочность подобного подхода в том, что работа двух человек в течение года оценивается так же, как работа сотни людей в течение недели. Но так как организационная структура работы двоих и ста будет разной, учитывая гомоморфизм, можно утверждать, что они создадут различные системы, поэтому не следует сравнивать стоимость их работы. По опыту мы знаем, что двое правильно подобранных людей, если они справятся, покажут лучший результат. Предположения, которые могут быть верными для чистки картошки или укладки кирпича, ошибочны при разработке систем.

Закон Паркинсона [4] имеет большое значение при перераспределении трудовых ресурсов в проектной деятельности. До тех пор, пока репутация управляющего зависит от размера бюджета, он будет заинтересован в расширении своей организации. Это не подходящая мотивация при решении задач по разработке систем. Раз организация существует, то, конечно, она будет использоваться. Возможно, наиболее веская причина существования сегодня такого количества плохо проработанных систем кроется в наличии организаций-проектировщиков, ищущих работу.

На втором месте причина развала процесса проектирования системы — фрагментация коммуникационной структуры проектной организации — начинает проявляться с началом делегирования задач. По теории элементарной вероятности число возможных коммуникационных связей равняется половине квадрата числа сотрудников организации. Даже в маленьких организациях приходится ограничивать общение, чтобы люди могли закончить работу. Исследование в области усовершенствования технологий общения между разработчиками оказало бы сильное влияние на управление системой.

В организациях военного типа обычно используются количественные ограничения административной структуры. Так, у каждого должен быть вышестоящий начальник и около семи подчиненных. Коммуникация осуществляется в соответствии с принципом субординации. Поэтому подобные организации разрабатывают системы, своей структурой напоминающие их собственную организационную структуру.

Заключение

Основной тезис данной статьи — организации, занимающиеся разработкой и проектированием систем (здесь трактуется в широком смысле) обречены создавать проекты, которые копируют их коммуникационную структуру. Мы увидели, что данное свойство оказывает серьезное влияние на управление процессом проектирования. Мы определили важный критерий организационной структуры проектных организаций: ресурсы, направленных на решение задачи, следует увеличивать только в соответствии с коммуникационными возможностями структуры организации. Этот критерий создает трудности, так как потребности в коммуникации зависят от концепции системы в определенное время. В связи с тем, что оценка задачи на начальном этапе никогда не бывает оптимальной, концепция системы может потребовать изменений, что, в свою очередь, напоминает о таком важном для компании-проектировщика качестве, как гибкость.

Необходимо найти такие способы вознаграждения управляющих процессом разработки, чтобы они были заинтересованы в экономичности и гибкости своих компаний. Нужна новая философия разработки и проектирования систем, которая не будет основана на допущении, что дополнительная рабочая сила увеличивает производительность. Развитие в этом направлении привлечет внимание к необходимости решения базовых вопросов о стоимости ресурсов и способах коммуникации. Без этого невозможно представить себе прогресс в области разработки систем.

Примечания

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

Перевод: Сергей Даньшин

Ещё

О проекте «Энгельбарт»

Гуглдок с хабрапереводом «Augmenting Human Intellect:
A Conceptual Framework» тут, можно дополнять.

Невозможная задача для проекта «Энгельбарт» — «перезагрузить матрицу», «пересобрать» всю область информационных технологий, интернета и компьютерного железа, учитывая все ошибки первой (нынешней) версии.

Ближайшие действия — переводы и сбор в одном месте ключевых концептуальных документов и поиск единомышленников (проснись, Нео! То что ты ищешь, тоже ищет тебя.) Под прицелом — Ванневар Буш, Джозеф Ликлайдер, Пол Отлет, Алан Кей, Дуглас Энгельбарт, Глушков, Лебедев, Ершов, WikiPedia, Web Archive, Knol, Quora, Cybersyn, Xanadu, DARPA, IARPA.

подробнее — 50 лет спустя. The Mother of All Demos

Если вы действительно хотите понять NLS, вы должны забыть сегодняшнюю реальность. Забудьте всё, что знаете о компьютерах. Представьте, что вы ещё не знаете, что такое компьютер. Вернитесь в 1962 год. А затем прочитайте, что он задумал.
— Брет Виктор, Несколько слов о Дугласе Энгельбарте

© Habrahabr.ru