Закон Конвея. Невероятно часто цитируемый закон. Но при этом, похоже, статья в которой он появился, так и не была переведена на русский (к слову, сделать понятный перевод этой статьи оказывается совсем не просто). Так как статья – не художественное произведение, да еще и написана в далеком 1968 году, ее перевод может (да, наверное, и должен) восприниматься как весьма косноязычный и местами непонятный, но так уж излагали мысли ученые в 68-м. Посчитал, что для научной статьи адаптивный перевод может привести к потере смыслов (хотя и понимаю, что на русском языке смысл может исказиться). Всячески рекомендую оригинал (ссылка в конце статьи), а переводом пользоваться только в том случае, если недостаточно знаний английского.
How Do Committees Invent?
Вид интеллектуальной деятельности, который создает полезное целое из своих различных частей, можно назвать проектированием системы. Вне зависимости от того, является ли конкретная деятельность созданием спецификаций для системы основных видов вооружения, формированием рекомендации для решения социальной задачи или программированием компьютера, основная деятельность по большей части одинакова.
Как правило, целью организации выполняющей проектирование является создание и сборка документа, содержащего связно структурированный массив информации. Эту информацию можно назвать дизайном системы. Обычно он создается для спонсора, желающего выполнить какую-либо деятельность, руководствуясь дизайном системы. Допустим, государственное должностное лицо хочет предложить закон, нацеленный на предотвращение повторения недавней катастрофы, и в связи с этим назначает группу для объяснения причин катастрофы. Или производителю необходим новый продукт, и он определяет деятельность по планированию производства продукта, чтобы выяснить, какой продукт следует представить.
Организация, выполняющая проектирование может участвовать или не участвовать в построении системы, которую она проектирует. Часто в общественно-политической деятельности придерживаются политики, которая препятствует тому, чтобы группа действовала в соответствии со своими собственными рекомендациями, тогда как в частном секторе преобладает прямо противоположная ситуация.
Кажется разумным предположить, что знание того, что кому-то придется выполнять свои собственные рекомендации или что эта задача будет возложена на других, вероятно, влияет на некоторые варианты дизайна, которые приходится делать отдельному проектировщику. Большая часть проектирования требует постоянного выбора. Часто такой выбор может быть чем-то большим, чем решения в рамках проектирования; он может быть личным решением проектировщика относительно своего будущего. Как мы увидим позже, стимулы, существующие в традиционной среде, могут побуждать к выбору, подрывающему намерение спонсора.
Этапы проектирования
Начальные этапы проектирования больше связаны со структурированием деятельности по проектированию, чем с самой системой. Невозможно перейти к полномасштабному проектированию до тех пор, пока не будут пройдены определенные предварительные этапы. К ним относится:
- Понимание границ как процесса проектирования, так и проектируемой системы, установленных спонсором и мировыми реалиями.
- Достижение предварительного представления об организации системы, чтобы можно было осмысленно назначать группы задач проектирования.
Позднее мы в подробностях увидим, что сама организация группы проектирования означает, что определенные решения явным или иным образом уже приняты. При любой организации группы проектирования существует класс вариантов решений, которые не могут быть эффективно реализованы такой организацией, поскольку не существует необходимых каналов связи. Таким образом, не существует такого явления, как группа проектирования, которая одновременно была бы организованной и беспристрастной.
После того, как для проектирования выбрана организация, можно делегировать задачи подгруппам организации. Каждый раз, когда осуществляется делегирование и сужается чья-то область исследования, также сужается и класс вариантов решений по проектированию, которые могут быть эффективно реализованы.
Как только определены сферы деятельности, возникает проблема координации. Координация между рабочими группами, хотя и снижает продуктивность отдельных сотрудников в небольшой группе, обеспечивает единственную возможность того, что отдельные рабочие группы смогут объединить свои усилия в единую систему.
Таким образом, жизненный цикл проектирования системы проходит через следующие общие этапы:
- Определение границ в соответствии с основными правилами.
- Выбор предварительной концепции системы.
- Организация процесса проектирования и делегирование задач в соответствии с выбранной концепцией.
- Координация делегированных задач.
- Объединение подпроектов в один проект.
Есть вероятность что конкретный процесс проектирования будет проходить не четко по этому списку. Предположительно, она может быть реорганизована при обнаружении новой и явно более совершенной концепции дизайна; однако возникновение такой неопределенности довольно неприятно, да и сам факт добровольного отказа от того, что уже создано болезненный и затратный. Конечно, с точки зрения историка, процесс постоянно повторяется. Эта точка зрения привела к выводу, что никогда не бывает достаточно времени, чтобы сделать что-то правильно, но всегда есть достаточно времени, чтобы сделать это заново.
https://businesswomanguide.org/capstone/kbs-world-essay-competition/22/ essay profile sample college board 2004 ap english literature essay prompts what is viagra super active plus https://ardelyx.com/news-releases/which-is-stronger-20mg-cialis-or-100mg-viagra/197/ see es bueno el viagra natural https://revivemedicalny.com/citrate/expired-saw-palmetto/8/ https://completecompetentcare.com/5275-is-viagra-bad-for-diabetes/ pieces of april movie essay viagra bao nhieu 1 vien zebeta side effects to kamagra https://iaace.com/annual/help-for-low-income-college-students/92/ my family essay 200 words https://assessmentcentertraining.org/exercises/cooking-is-an-art-essay/58/ dissertation topics in survey https://albionfoundation.org/perpill/novo-pramil-sildenafil-50mg/63/ https://willcoxwinecountry.org/linkedin/help-me-focus-on-my-essay/47/ forum viagra kaufen ohne rezept https://vivianschilling.com/film/essay-on-i-love-my-post-office/61/ can get pregnant viagra https://mswwdb.org/report/free-coursework-info/96/ essay on our environment in india thesis support essay topics https://laralafayette.org/classes/another-word-for-assignment/91/ get link go here sildenafil citrate and alcohol enter site buy viagra at pharmacy in bangkok Спроектированная система
Любая система строится из связанных между собой более мелких подсистем. Описание системы, если оно предназначено для описания того, что происходит внутри этой системы, должно характеризовать связи системы с внешним миром, а также в общих чертах изображать каждую из подсистем и то, как они взаимосвязаны. Спустившись на один уровень вниз, мы можем сказать то же самое о каждой из подсистем, рассматривая ее как систему. Такое сокращение масштаба может продолжаться до тех пор, пока мы не придем к системе, достаточно простой, чтобы ее можно было понять без дальнейшего разделения.
Примеры. Трансконтинентальная система общественного транспорта состоит из автобусов, поездов, самолетов, различных типов трасс, автостоянок, такси, терминалов и т. д. Эта система очень неоднородна; то есть ее подсистемы весьма разнообразны. Спустимся на один уровень ниже. Самолет, допустим, может иметь подсистемы для конструкции, движения, распределения энергии, связи и компоновки полезной нагрузки. Двигательная подсистема состоит из топливной подсистемы, подсистемы зажигания и пусковой подсистемы, и это лишь часть от общего их числа.
Возможно, менее очевидно, что теория так же является системой. Она относится к внешнему миру наблюдаемых событий, где должна объяснять их или, по крайней мере, не противоречить им. Она состоит из подтеорий, которые должны одинаковым образом соотноситься друг с другом. Например, при расследовании авиакатастрофы предпринимается попытка создать теорию, объясняющую сложное событие. Она может состоять из подтеорий, описывающих траекторию полета самолета, радиосвязь, характер повреждений и его связь с близлежащими объектами во время события. Каждый из них этих элементов, в свою очередь, сам по себе представляет собой историю, которую можно далее разбить на более мелкие детали вплоть до уровня отдельных единиц факта.
Линейные графы. Рис. 1 иллюстрирует это представление системы в виде линейного графа с ребрами (линии) и узлами (круги). Каждый узел представляет собой подсистему, которая по ребрам сообщается с другими подсистемами. В свою очередь, каждая подсистема может содержать структуру, которую можно изобразить аналогичным образом. Термин интерфейс, который становится популярным среди системщиков, относится к пути или ответвлению связи между подсистемами, представленному ребром на Рис. 1. В качестве альтернативы интерфейс представляет собой вставку или выступ, с помощью которого путь, выходящий из одного узла, соединяется с путем, выходящим из другого узла.
Relating the two
Изображение линейного графа полезно тем, что оно обеспечивает абстракцию, имеющую одинаковую форму для двух рассматриваемых нами сущностей: организации и проектируемой ею системы. Это можно представить на Рис. 1, заменив следующие слова:
- «Система» на «комитет».
- «Подсистема» на «подкомитет».
- «Интерфейс» на «координатор».
Как и в случае с системами, мы находим, что группы можно рассматривать на нескольких уровнях сложности. Федеральное правительство, к слову, является прекрасным примером организации, осуществляющей проектирование, сложность которой удовлетворит любого системного инженера. Это особо примечательный пример, показывающий сходство двух изучаемых здесь концепций в виду того, что Федеральное правительство является как проектирующей организацией (разрабатывающей законы, конвенции и политику), так и спроектированной системой (Конституция является основным предварительным документов дизайна).
Базовые отношения. Теперь мы можем ответить на основополагающий вопрос данной статьи: Существует ли предсказуемая взаимосвязь между графовой структурой проектирующей организации и графовой структурой разрабатываемой ею системы? Ответ: Да, взаимосвязь настолько проста, что в некоторых случаях эти два понятия тождественны. Рассмотрим следующее «доказательство»:
Выберем произвольно некоторую систему и спроектировавшую ее организацию, а затем столь же произвольно выберем некоторый уровень сложности проектируемой системы, для которого мы можем построить граф. (Мотивация такой нашей самовольности состоит в том, что, если нам удастся продемонстрировать что-то интересное, это будет справедливо для любой организации, выполняющей проектирование и любого уровня сложности.) На Рис. 2 (стр. 30) в качестве условного примера показана структура, к которой могут быть отнесены следующие утверждения.
Для любого узла x в системе мы можем определить группу организации, разработавшую x; назовем ее Х. Таким образом, обобщая данный процесс, для каждого узла системы мы имеем правило нахождения соответствующего узла организации. Обратите внимание, что это правило не обязательно должно иметь соотношение один к одному; то есть две подсистемы могут быть разработаны одной группой.
Интересно, что мы можем сделать аналогичное утверждение о ребрах. Возьмем любые два узла x и y системы. Они либо соединены ребром, либо нет. (То есть они либо взаимодействуют друг с другом каким-то образом, имеющим значение для работы системы, либо нет.) Если ребро есть, то две (не обязательно разные) группы X и Y, спроектировавшие два узла, должны согласовать и утвердить спецификацию интерфейса, чтобы разрешить связь между двумя соответствующими узлами организации. С другой стороны, если между z и y ребра нет, то подсистемы не взаимодействуют друг с другом, двум соответствующим группам не о чем договариваться, и, следовательно, между X и У нет ребра.
Что мы только что показали? Грубо говоря, мы показали, что существует очень тесная связь между структурой системы и структурой организации, которая ее спроектировала. Во многих случаях, когда у каждой подсистемы была своя отдельная группа, мы обнаруживаем, что структуры (т. е. линейные графы) группы и системы идентичны. В случае, когда некая группа разработала более одной подсистемы, мы обнаружим, что структура организации представляет собой свернутую версию структуры системы, при этом подсистемы, имеющие одну и ту же группу, сворачиваются в один узел, представляющий эту группу.
Такой вид сохраняющей структуру связи между двумя множествами вещей называется гомоморфизмом. С точки зрения математики можно сказать, что существует гомоморфизм от линейного графа системы к линейному графу проектировавшей ее организации.
Системы повторяют структуру проектировавших их групп
Среди опытных проектировщиков систем существует убеждение, что при любой конструкции системы кто-нибудь когда-нибудь найдет лучшую ее версию для той же работы. Другими словами, было бы неправильно говорить о конкретном дизайне, если это не понимается в контексте пространства, времени, знаний и технологий. Смиренность, которую эта вера должна навязывать проектировщикам систем, является единственно подходящей позицией для тех, кто читает историю или обращается к своим воспоминаниям.
Показательным примером является прогресс в разработке компьютерных трансляторов языков программирования, таких как FORTRAN и COBOL. В середине 50-х годов, когда появились прообразы этих языков, их компиляторы представляли собой еще более громоздкие объекты, чем гигантские (по тем временам) компьютеры, которые требовались для их выполнения. Сегодня эти трансляторы представляют собой лишь исторические диковинки, не имеющие ничего общего по дизайну с сегодняшними компиляторами. (Следует особо отметить тот факт, что качественные скачки в прогрессе проектирования компиляторов были связаны с появлением новых групп людей на территории, которую ранее топтали в основном лишь производители компьютеров, — сначала это был сплоченный небольшой университетский исследовательский коллектив, за которым последовали независимая компания по разработке программного обеспечения.)
Если, таким образом, разумно предположить, что для любого системного требования существует семейство системных проектов, удовлетворяющих этому требованию, нам необходимо также выяснить, влияет ли выбор организации на процесс выбора дизайна системы из этого семейства. Если мы верим в наш гомоморфизм, то должны согласиться с тем, что влияет. В той мере, в какой организация не является полностью гибкой в своей коммуникационной структуре, эта организация будет выштамповывать свой образ в каждом дизайне, который она производит. Чем крупнее организация, тем меньше у нее гибкости и тем более выражен этот феномен.
Примеры. В контрактной исследовательской организации было восемь человек, которые должны были создать компилятор COBOL и ALGOL. После некоторой первоначальной оценки сложности и времени, пять человек были назначены на работу с COBOL, трое с ALGOL. Получившийся компилятор COBOL выполнялся в пять этапов, ALGOL — в три.
Главнокомандующий поручил двум военным службам разработать общую систему вооружения для удовлетворения соответствующих потребностей. Приложив большие усилия, они создали копию своей организационной структуры. (См. Рис. 3а)
Рассмотрим операционную систему. На высоком уровне она состоит из трех частей: аппаратного обеспечения, системного программного обеспечения и прикладной программы. (См. Рис. 3b) Этим подсистемам сопоставлены соответствующие разработчики: инженеры производителя компьютеров, системные программисты и прикладные программисты пользователя. (Те редкие случаи, когда системное аппаратное и программное обеспечение имеют тенденцию к взаимодействию, а не просто терпят друг друга, связаны с производителями, программисты и инженеры которых имеют аналогичные отношения.)
Управление системой
Структуры больших систем имеют тенденцию дезинтегрироваться в процессе развития качественно больше, чем малые системы. Это наблюдение поразительно очевидно применительно к крупным военным информационным системам последних десятилетий; это одни из самых сложных объектов, созданных человеческим разумом. Деятельность под названием «управление системой» возникла частично в ответ на эту тенденцию систем к дезинтеграции. Давайте рассмотрим полезность концепций, которые мы разработали, для управления системой.
Почему большие системы дезинтегрируются? Процесс, судя по всему, происходит в три этапа, первые два из которых поддаются контролю, а третий является прямым результатом гомоморфизма.
Во-первых, осознание первоначальными проектировщиками того, что система будет большой, вместе с определенным давлением в организации делает непреодолимым искушение назначить для разработки дизайна слишком много людей.
Во-вторых, применение общепринятых догм менеджмента к крупной организации приводит к дезинтеграции ее коммуникационной структуры.
В-третьих, гомоморфизм гарантирует, что структура системы будет отражать дезинтеграцию, произошедшую в организации.
Для начала давайте рассмотрим тенденцию к «перенаселению» работ по проектированию. Это естественное искушение первого проектировщика — того, чьи предварительные концепции дизайна влияют на организацию проектирования — делегировать задачи, когда кажущаяся сложность системы приближается к граням его понимания. Это поворотный момент в ходе проектирования. Либо он изо всех сил пытается свести систему к понятности и побеждает, либо теряет над ней контроль. Если в распоряжении есть график и бюджет, то результат почти предсказуем.
Менеджер знает, что его могут обвинить в неумелом управлении, если он не выполнит план, не задействовав все свои ресурсы. Это знание создает сильное давление на первоначального проектировщика, который может предпочесть бороться с дизайном, а не фрагментировать его посредством делегирования. Однако это же знание заставляет его чувствовать, что цена риска слишком высока, чтобы рисковать. Поэтому он вынужден делегировать полномочия, чтобы задействовать больше ресурсов.
Следующий случай иллюстрирует другой родственный способ, которым окружение менеджера может конфликтовать с целостностью разрабатываемой системы.
Менеджер должен отдать в субподряд важную и сложную задачу по проектированию. Он выбирает между двумя подрядчиками: небольшой новой организацией, которая предлагает интуитивно привлекательный подход за гораздо меньшие, чем заложено в бюджете, деньги, и давно зарекомендовавшей себя, но традиционной организацией, которая требует более «реалистичную» плату. Он знает, что, если яркая молодая организация не сможет добиться достаточных результатов, его обвинят в неумелом управлении, а если потерпит неудачу проверенная организация, это будет доказательством того, что проблема действительно сложна.
В чем тут сложность? Большая ее часть относится к рассуждениям об измерении ресурсов, вытекающим из традиционной теории бухгалтерского учета. Согласно этой теории, единицей ресурса является доллар, и все ресурсы должны измеряться с использованием единиц измерения, конвертируемых в доллары. Если ресурсом является человеческий труд, единицей измерения является количество часов, отработанных каждым человеком, умноженное на его почасовую ставку, суммированные для всей рабочей силы.
Одним из заблуждений, лежащих в основе этого расчета, является свойство линейности, согласно которому два человека, работающие в течение года, или сто человек, работающие в течение недели (при одинаковых почасовых ставках на человека), являются ресурсами равной ценности. Если предположить, что два человека и сто человек не могут работать в одной и той же организационной структуре (это интуитивно очевидно и будет обсуждаться ниже), наш гомоморфизм говорит, что они не будут проектировать подобные системы; поэтому ценность их усилий может быть даже несопоставимой. По опыту мы знаем, что два человека, если они правильно подобраны и имеют нужный опыт, дадут нам лучшую систему. Предположения, которые могут быть достаточными для чистки картошки и возведения кирпичных стен, не годятся для проектирования систем.
В переназначении работ по проектированию важную роль играет закон Паркинсона. Пока престиж и власть менеджера связаны с размером его бюджета, он будет мотивирован расширять свою организацию. Это неуместный мотив в управлении проектированием. Раз организация существует, конечно, она будет использоваться. Вероятно, самым большим общим фактором, лежащим в основе многих плохо спроектированных систем, существующих в настоящее время, является наличие организации выполняющей проектирование, нуждающейся в работе.
Второй шаг в дезинтеграции дизайна системы — фрагментация коммуникационной структуры организации выполняющей проектирование — начинается, как только начинается делегирование. Элементарная теория вероятностей говорит нам, что количество возможных каналов связи в организации примерно равно половине квадрата числа людей в организации. Даже в умеренно небольшой организации возникает необходимость ограничить общение, чтобы люди могли выполнить какую-то «работу». Исследования, которые ведут к методам, обеспечивающим более эффективную коммуникацию между проектировщиками, будут играть чрезвычайно важную роль в технологии системного управления.
Общепринятая практика управления накладывает определенные количественные ограничения на сложность линейного графа, который представляет административную структуру армейских организаций. В частности, каждый человек должен иметь не более одного начальника и не более семи подчиненных. В той мере, в какой организационный протокол ограничивает общение по порядкам подчиненности, коммуникационная структура организации будет напоминать ее административную структуру. Это одна из причин, почему армейские организации разрабатывают системы, которые выглядят как их организационные схемы.
Заключение (а вот тут и сформулирован Закон Конвея, прим. пер.)
Основной тезис этой статьи состоит в том, что организация, проектирующая систему (в принятом здесь широком смысле), производит дизайн, являющийся копией коммуникационных структур этой организации. Мы заметили, что этот факт имеет важное значение для управления дизайном систем. Прежде всего, мы нашли критерий структурирования проектирующих организаций: проектирование должно быть организовано в соответствии с потребностью в коммуникации.
Этот критерий создает проблемы, поскольку потребность в коммуникации в любое время зависит от действующей в это время концепции системы. Поскольку дизайн, который возникает первым, почти никогда не бывает самым лучшим, возможно, потребуется изменить преобладающую концепцию системы. Следовательно, для эффективного проектирования важна гибкость организации.
Необходимо найти способы вознаграждать руководителей за то, что их организации остаются компактными и гибкими. Необходима философия управления дизайном систем, которая не основывается на предположении, что простое добавление рабочей силы повышает производительность. Развитие такой философии обещает раскрыть базовые вопросы о ценности ресурсов и методов коммуникации, на которые необходимо будет ответить, прежде чем наша технология построения систем сможет уверенно двигаться вперед.
Ссылки:
Оригинал статьи: https://www.melconway.com/Home/Committees_Paper.html
Основные идеи из книги «Сотрудничество в DevOps-культуре» раскрывает идеи сотрудничества и коммуникации в современных реалиях.
