Закон Конвея (Conway's law)
Закон Конвея (Conway's law) - це вислів, який стверджує, що організації проектують системи, які відображають їхню власну комунікаційну структуру. Він названий на честь програміста Мелвіна Конвея, який представив цю ідею в 1967 р.[1]
Доктор Конвей був керівником відділу досліджень периферійних систем у Sperry Rand's Univac Div., де він працює над розпізнаванням безперервного мовлення. Раніше він був науковим співробітником в Університеті Кейс Вестерн Резерв і консультантом з програмного забезпечення. Має ступінь магістра фізики від CaiTech та ступінь доктора філософії з математики від Case.
Його оригінальне формулювання було таким:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.[2] [3]
— Melvin E. Conway
Закон ґрунтується на міркуванні, що для того, щоб продукт функціонував, автори і дизайнери його складових частин повинні спілкуватися один з одним, щоб забезпечити сумісність між компонентами. Отже, технічна структура системи відображатиме соціальні кордони організацій, які її створили, через які комунікація ускладнюється.
Розмовною мовою це означає, що складні продукти зрештою "формуються" під організаційну структуру, в якій вони розроблені або для якої призначені. Закон застосовується насамперед у сфері архітектури програмного забезпечення, хоча Конвей розглядав його ширше, і його припущення та висновки можна застосувати до більшості технічних галузей.
Варіації закону Конвея
Ерік С. Реймонд, прихильник відкритого програмного забезпечення, переформулював закон Конвея в "Новому словнику хакера", довіднику, заснованому на "Файлі жаргону". За його словами, організація програмного забезпечення та організація команди розробників програмного забезпечення будуть конгруентними. Підсумовуючи приклад з роботи Конвея, Реймонд написав:
Якщо над компілятором працюють чотири групи, ви отримаєте 4-прохідний компілятор.
Далі Реймонд представляє поправку Тома Читема до закону Конвея, сформульовану наступним чином:
Якщо група з N осіб реалізує компілятор COBOL, то буде виконано N-1 проходів. Хтось з групи повинен бути менеджером.
Юрдон і Константін у своїй книзі 1979 року про структурований дизайн представили більш чітко сформульовану варіацію закону Конвея:
Якщо частини організації (наприклад, команди, відділи або підрозділи) не дуже точно відображають основні частини продукту, або якщо відносини між організаціями не відображають відносини між частинами продукту, то проект буде в біді ... Тому: Переконайтеся, що організація сумісна з архітектурою продукту.
Нещодавні коментатори відзначили наслідок - для програмних проектів з тривалим терміном використання коду, таких як Microsoft Windows, структура коду відображає не лише комунікаційну структуру організації, яка створила останню версію, але й комунікаційні структури кожної попередньої команди, яка працювала над цим кодом.
Інтерпретації закону Конвея
Закон, у строгому сенсі, стосується лише відповідності; він не стверджує, що структура комунікації є причиною структури системи, а лише описує зв'язок. Різні коментатори займають різні позиції щодо напрямку причинно-наслідкового зв'язку: що технічний дизайн змушує організацію реструктуруватися, щоб відповідати йому, що організаційна структура диктує технічний дизайн, або і те, і інше.
Закон Конвея спочатку був задуманий як соціологічне спостереження, але можливо багато інших інтерпретацій. У Новому хакерському словнику він використовується переважно в гумористичному контексті, тоді як учасники Національного симпозіуму з модульного програмування 1968 року вважали його достатньо серйозним і універсальним, щоб назвати його "законом Конвея".
Думки також різняться щодо бажаності цього явища; дехто вважає, що дзеркальне відображення є корисною особливістю таких систем, тоді як інші інтерпретації кажуть, що це небажаний результат організаційної упередженості. Середні позиції описують його як необхідну ознаку компромісу, небажану в абстрактному сенсі, але необхідну для подолання людських обмежень.
Підтверджуючі докази
Приклад впливу закону Конвея можна знайти в дизайні деяких веб-сайтів організацій. Найджел Беван у своїй статті 1997 року щодо проблем юзабіліті веб-сайтів зазначив: "Організації часто створюють веб-сайти з контентом і структурою, які відображають внутрішні проблеми організації, а не потреби користувачів сайту".
Докази на підтримку закону Конвея були опубліковані групою дослідників Массачусетського технологічного інституту (MIT) і Гарвардської бізнес-школи, які, використовуючи "гіпотезу віддзеркалення" як еквівалент закону Конвея, знайшли "вагомі докази на підтримку гіпотези віддзеркалення", а також того, що "продукт, розроблений слабко пов'язаною організацією, є значно більш модульним, ніж продукт від тісно пов'язаної організації". Автори підкреслюють вплив "організаційних проектних рішень на технічну структуру артефактів, які ці організації згодом розробляють".[4]
Додаткові тематичні дослідження закону Конвея були проведені Нагаппаном, Мерфі та Базілі в Університеті Меріленда у співпраці з Microsoft, а також Саїдом та Хаммудою в Технологічному університеті Тампере (Фінляндія), які також підтримують закон Конвея.
[3] How do committees invent? (April 1968)
Критерії організаційного дизайну (design organization criteria)
Цей вид інтелектуальної діяльності, який створює корисне ціле з різних частин, можна назвати проектуванням системи. Незалежно від того, чи це конкретна діяльність - створення специфікацій для основної системи озброєння, формування рекомендацій для вирішення соціальної проблеми або програмування комп'ютера, загальна діяльність в основному однакова.
Як правило, метою проектної організації є створення і складання документа, що містить послідовно структурований масив інформації. Ми можемо назвати цю інформацію дизайном системи. Вона зазвичай створюється для спонсора, який, як правило, бажає здійснювати певну діяльність, керуючись планом системи.
Наприклад, державний чиновник хоче запропонувати законодавство, щоб запобігти повторенню висхідних катастроф, тому він призначає групу для пояснення катастрофи. Або виробник потребує нового продукту і призначає діяльність з планування продукту, щоб визначити, що саме має бути впроваджено.
Проектна організація може бути залучена, а може і не бути залученою до побудови системи, яку вона проектує. Часто в державному секторі існує політика, яка не сприяє тому, щоб група діяла за власними рекомендаціями, тоді як у приватному бізнесі часто переважає протилежна ситуація.
Можна припустити, що усвідомлення того, що доведеться виконувати власні рекомендації або що це завдання буде покладено на інших, ймовірно, впливає на деякі проектні рішення, які доводиться приймати індивідуальному дизайнеру. Більшість видів проектної діяльності вимагає постійного вибору.
Багато з цих виборів можуть бути не просто проектними рішеннями; вони також можуть бути особистими рішеннями автора щодо його власного майбутнього. Як ми побачимо пізніше, стимули, що існують у звичайному управлінському середовищі, можуть мотивувати вибір, який підриває наміри спонсора.
Eтапи проектування (stages of design)
Початкові етапи проектування пов'язані більше зі структуруванням проектної діяльності, ніж з самою системою. Повноцінне проектування не може тривати доти, доки не будуть пройдені певні попередні етапи. До них відносяться:
- Розуміння меж, як для проектної діяльності, так і для системи, що проектується, встановлених спонсором та світовими реаліями.
- Досягнення попереднього уявлення про організацію системи, щоб можна було осмислено призначити проектні групи.
Пізніше ми побачимо детальніше, що сам факт організації команди проектувальників означає, що певні проектні рішення вже вже прийняті, явно чи ні. За будь-якої організації проектної групи, існує клас проектних альтернатив, які не можуть бути ефективно реалізовані такою організація не може ефективно реалізувати, тому що не існує необхідних шляхів комунікації не існує. Тому не існує такого поняття, як проектна група, яка була б одночасно і організованою, і неупередженою.
Після того, як обрано організацію проектної групи, можна делегувати діяльність підгрупам організації. Кожного разу, коли відбувається делегування повноважень і звужується сфера діяльності певного органу, звужується і клас проектних альтернатив, які можуть бути ефективно використані.
Після визначення сфер діяльності виникає проблема координації. Координація між робочими групами, хоча і знижує продуктивність роботи кожного члена малої групи, є єдиною можливістю для окремих робочих груп об'єднати свої зусилля в єдиний проект системи.
Таким чином, життєвий цикл проектування системи проходить через наступні загальні етапи:
- Визначення меж відповідно до основних правил.
- Вибір попередньої концепції системи.
- Організація проектної діяльності та делегування завдань відповідно до цієї концепції.
- Координація між делегованими завданнями.
- Консолідація субдизайнів в єдиний дизайн.
Цілком можливо, що певна проектна діяльність не піде прямо за цим списком. Можливо, вона реорганізується після відкриття нової, очевидно, кращої концепції дизайну; але така видимість невизначеності не прикрашає, а сам акт добровільної відмови від творіння є болісним і дорогим. Звісно, з точки зору історика, цей процес постійно повторюється. З цієї точки зору виникає спостереження, що ніколи не вистачає часу, щоб зробити щось правильно, але завжди є достатньо часу, щоб зробити це заново.
Запроектована система (The designed system)
Будь-яка система наслідків складається з менших підсистем, які пов'язані між собою. Опис системи, якщо він має на меті описати те, що відбувається всередині цієї системи, повинен описувати зв'язки системи із зовнішнім світом, а також окреслювати кожну з підсистем і те, як вони пов'язані між собою.
Опустившись на один рівень нижче, ми можемо сказати те ж саме про кожну з підсистем, розглядаючи її як систему. Таке зменшення обсягу може тривати доти, доки ми не дійдемо до системи, яка є достатньо простою, щоб її можна було зрозуміти без подальшого поділу.
Приклади. Трансконтинентальна система громадського транспорту складається з автобусів, поїздів, літаків, різних типів смуг відводу, парковок, таксі, терміналів тощо. Це дуже гетерогенна система, тобто підсистеми досить різноманітні. Якщо опуститися на один рівень нижче, то літак, наприклад, може мати підсистеми структури, рушія, розподілу енергії, зв'язку та пакування корисного вантажу. Підсистема рушія має паливну, запалювальну та пускову підсистеми, якщо назвати лише деякі з них.
Те, що теорія є системою в тому ж сенсі, може бути менш очевидним. Вона пов'язана із зовнішнім світом спостережуваних подій, де вона повинна пояснювати або, принаймні, не суперечити їм. Вона складається з підтеорій, які мають так само співвідноситися одна з одною. Наприклад, при розслідуванні авіакатастрофи робиться спроба створити теорію, що пояснює складну подію.
Вона може складатися з підтеорій, що описують траєкторію польоту літака, його радіозв'язок, характер пошкоджень і його взаємозв'язок з навколишніми об'єктами під час події. Кожна з них, у свою чергу, сама по собі є історією, яка може бути розбита на більш дрібні деталі аж до рівня окремих одиниць доказів.
Лінійні графи (Linear graphs). Рис. 1 ілюструє цей погляд на систему як на лінійний граф - конструкцію з гілок (branches - лінії) та вузлів (circles - кружечки). Кожен вузол є підсистемою, яка взаємодіє з іншими підсистемами по гілках. У свою чергу, кожна підсистема може містити структуру, яку можна зобразити аналогічно.
Термін інтерфейс (interface), який стає популярним серед системників, позначає міжпідсистемний комунікаційний шлях або гілку, зображену лінією на рис. 1. Альтернативно, інтерфейс - це роз'єм або фланець, за допомогою якого шлях, що виходить з одного вузла, з'єднується з шляхом, що виходить з іншого вузла.
Зв'язок між ними (Relating the two)
Лінійно-графова нотація корисна тим, що вона забезпечує абстракцію, яка має однакову форму для двох сутностей, які ми розглядаємо: проект організації та система, яку вона проектує.
Це можна проілюструвати на рис. 1, замінивши наступні слова:
- Замініть "систему" на "комітет".
- Замініть "підсистема" на "підкомітет".
- Замінити "інтерфейс" на "координатор".
Як і у випадку з системами, ми бачимо, що проектні групи можна розглядати на декількох рівнях складності. Федеральний уряд, наприклад, є чудовим прикладом проектної організації з достатньою складністю, щоб задовольнити будь-якого системного інженера.
Це особливо цікавий приклад для демонстрації схожості двох концепцій, які ми тут вивчаємо, оскільки Федеральний уряд є одночасно і проектною організацією (розробляє закони, договори і політику), і проектованою системою (Конституція є основним попереднім проектним документом) .
Базовий взаємозв'язок (basic relationship). Тепер ми можемо відповісти на фундаментальне питання цієї статті: Чи існує якийсь передбачуваний зв'язок між графовою структурою дизайн-організації та графовою структурою системи, яку вона проектує? Відповідь: так, цей зв'язок настільки простий, що в деяких випадках він є тотожним. Розглянемо наступний "доказ":
Виберемо довільно деяку систему та організацію, яка її розробила, а потім так само довільно виберемо деякий рівень складності розробленої системи, для якого можна намалювати графік. (Ми мотивуємо цю довільність тим, що якщо нам вдасться продемонструвати щось цікаве, то це буде справедливо для будь-якої організації та рівня складності). На рис. 2 показано структуру, до якої можна віднести наступні твердження, лише з метою ілюстрації.
Для будь-якого вузла x в системі ми можемо визначити проектну групу проектної організації, яка підписала x; назвемо її X. Таким чином, узагальнюючи цей процес, для кожного вузла системи ми маємо правило для знаходження відповідного вузла проектної організації. Зауважте, що це правило не обов'язково є один-до-одного; тобто дві підсистеми могли бути були спроектовані однією проектною групою.
Цікаво, що ми можемо зробити аналогічне твердження про гілки. Візьмемо будь-які дві вершини x та y системи. Або вони з'єднані гілкою, або ні. (Тобто, або вони взаємодіють між собою якимось чином, значущим для роботи системи, або ні). Якщо є відгалуження, то дві (не обов'язково різні) проектні групи X і Y, які розробляли ці два вузли, повинні були провести переговори і узгодити специфікацію інтерфейсу, щоб дозволити комунікацію між двома відповідними вузлами проектної організації. Якщо, з іншого боку, між x і y немає гілки, то підсистеми не спілкуються одна з одною, двом відповідним проектним групам не було про що домовлятися, і, отже, між X і Y немає гілки. *
Що ми щойно показали? Грубо кажучи, ми продемонстрували, що існує дуже тісний зв'язок між структурою системи та структурою організації, яка її розробила. У звичайному випадку, коли кожна підсистема мала свою окрему проектну групу, ми бачимо, що структури (тобто лінійні графіки) проектної групи і системи ідентичні. У випадку, коли якась група розробляла більше однієї підсистеми, ми бачимо, що структура проектної організації є згорнутою версією структури системи, де підсистеми, що мають одну проектну групу, згорнуті в один вузол, що представляє цю групу.
Такий тип відношення, що зберігає структуру між двома множинами речей, називається гомоморфізмом. Говорячи мовою математиків, ми б сказали, що існує гомоморфізм від лінійного графу системи до лінійного графу її проектної організації.
Системи зображують свої проектні групи (Systems image their design groups)
Досвідчені системні проектувальники вірять, що, маючи будь-який дизайн системи, хтось колись знайде кращий для виконання тієї ж роботи. Іншими словами, оманливо і неправильно говорити про дизайн для конкретної роботи, якщо це не розуміти в контексті простору, часу, знань і технологій.
Смирення, яке це переконання повинно накласти на системних дизайнерів, є єдиною правильною позицією для тих, хто читає історію або звертається до своїх спогадів.
Прикладом може слугувати прогрес у розробці комп'ютерних перекладачів таких мов програмування, як FORTRAN і COBOL. У середині п'ятдесятих років, коли з'явилися прототипи цих мов, їхні компілятори були ще більш громіздкими об'єктами, ніж гігантські (як на той час) комп'ютери, які були потрібні для їхнього виконання.
Сьогодні ці транслятори є лише історичним курйозом, не маючи жодної схожості в дизайні з сучасними компіляторами. (Слід особливо відзначити той факт, що квантові стрибки у розвитку компіляторів були пов'язані з появою нових груп людей на території, яку раніше топтали переважно виробники комп'ютерів - спочатку це була маленька університетська дослідницька група, а потім незалежна компанія, що займалася розробкою програмного забезпечення)
Якщо розумно припустити, що для будь-якої системної вимоги існує сім'я системних проектів, які задовольняють цю вимогу, ми повинні також запитати, чи впливає вибір структури проектування на процес вибору системного проекту з цієї сім'ї. Якщо ми віримо в наш гомоморфізм, то мусимо погодитися, що впливає. Якщо організація не є повністю гнучкою у своїй комунікаційній структурі, вона буде штампувати свій образ у кожному проекті, який вона виробляє. Чим більшою є організація, тим меншою є її гнучкість і тим більш вираженим є це явище.
Приклади. Дослідницька організація, що працює за контрактом, мала вісім осіб, які повинні були написати компілятор на COBOL та ALGOL. Після деяких початкових оцінок складності та часу, п'ять осіб було призначено для роботи на мові COBOL і три - на мові ALGOL. В результаті компілятор для COBOL виконувався у п'ять етапів, а компілятор для ALGOL - у три.
Розглянемо операційну комп'ютерну систему, яка використовується для розв'язування задачі. На високому рівні розгляду вона складається з трьох частин: апаратного забезпечення, системного програмного забезпечення та прикладної програми. (Див. рис. 3б.) Цим підсистемам відповідають відповідні розробники: інженери виробника комп'ютера, його системні програмісти і прикладні програмісти користувача. (Ті рідкісні випадки, коли апаратне та програмне забезпечення системи мають тенденцію співпрацювати, а не просто терпіти одне одного, пов'язані з виробниками, чиї програмісти та інженери мають подібні стосунки. )
Керування системою (System management)
Структури великих систем мають тенденцію до дезінтеграції під час розвитку, причому якісно більшою мірою, ніж у випадку малих систем. Це спостереження стає особливо очевидним, якщо застосувати його до великих військових інформаційних систем останнього десятиліття; це одні з найскладніших об'єктів, створених людським розумом.
Діяльність під назвою "системний менеджмент" виникла частково у відповідь на цю тенденцію до розпаду систем. Давайте розглянемо, наскільки корисними для системного менеджменту є концепції, які ми тут розробили.
Чому великі системи розпадаються? Здається, процес відбувається у три етапи, перші два з яких можна контролювати, а третій є прямим наслідком нашого гомоморфізму.
По-перше, усвідомлення початковими розробниками того, що система буде великою, разом з певним тиском в їхній організації, робить непереборною спокусу залучити до проектування занадто багато людей.
По-друге, застосування традиційної управлінської мудрості до великої проектної організації призводить до розпаду її комунікаційної структури.
По-третє, гомоморфізм гарантує, що структура системи відображатиме дезінтеграцію, яка відбулася в проекті організації.
Давайте спочатку розглянемо тенденцію до перенаселення проектних зусиль. Це природна спокуса для початкового дизайнера - того, чиї попередні концепції дизайну впливають на організацію проектних зусиль - делегувати завдання, коли видима складність системи наближається до меж його розуміння.
Це переломний момент у процесі проектування. Або він намагається звести систему до зрозумілості і перемагає, або втрачає контроль над нею. Результат майже передбачуваний, якщо є тиск графіка і бюджет, яким потрібно управляти.
Керівник знає, що він буде вразливий до звинувачень у неефективному управлінні, якщо не встигне за графіком, не задіявши всі свої ресурси. Це знання створює сильний тиск на початкового дизайнера, який, можливо, волів би боротися з проектом, а не фрагментувати його шляхом делегування, але він відчуває, що ціна ризику надто висока, щоб ризикувати. Тому він змушений делегувати повноваження, щоб залучити більше ресурсів.
Наступний випадок ілюструє інший, але споріднений спосіб, у який оточення менеджера може конфліктувати з цілісністю системи, що проектується.
Менеджер повинен віддати на субпідряд важливе і складне завдання з проектування. У нього є вибір між двома підрядниками: невеликою новою організацією, яка пропонує інтуїтивно привабливий підхід за набагато менші гроші, ніж передбачено бюджетом, і усталеною, але традиційною фірмою, яка просить більш "реалістичний" гонорар.
Він знає, що якщо яскрава молода організація не зможе досягти належних результатів, його звинуватять у неефективному управлінні, тоді як невдача усталеної організації буде свідченням того, що проблема справді є складною.
У чому тут полягає складність? Значною мірою вона пов'язана з типом міркувань щодо вимірювання ресурсів, які випливають з традиційної теорії бухгалтерського обліку. Згідно з цією теорією, одиницею виміру ресурсів є долар, і всі ресурси повинні вимірюватися в одиницях виміру, які конвертуються в долар.
Якщо ресурсом є людська праця, то одиницею виміру є кількість годин, відпрацьованих кожною людиною, помножена на її погодинну вартість, підсумовану для всієї робочої сили.
Однією з помилок цього розрахунку є властивість лінійності, яка говорить, що двоє чоловіків, які працюють протягом року, або сто чоловіків, які працюють протягом тижня (при однаковій погодинній вартості на людину), є ресурсами однакової цінності.
Припускаючи, що два чоловіки і сто чоловік не можуть працювати в одній організаційній структурі (це інтуїтивно зрозуміло і буде розглянуто нижче), наш гомоморфізм говорить, що вони не будуть проектувати схожі системи; тому цінність їхніх зусиль може бути навіть не порівнянною.
З досвіду ми знаємо, що ці двоє людей, якщо вони добре підібрані і витримають випробування, дадуть нам кращу систему. Припущення, які можуть бути адекватними для чищення картоплі та зведення цегляних стін, не підходять для проектування систем.
Закон Паркінсона відіграє важливу роль у надмірному розподілі проектних зусиль. Поки престиж і влада керівника прив'язані до розміру його бюджету, він буде зацікавлений у розширенні своєї організації. Це неприйнятний мотив в управлінні діяльністю з системного проектування. Якщо організація існує, звичайно, вона буде використовуватися.
Ймовірно, найбільшим спільним фактором багатьох погано спроектованих систем, що існують зараз, є потреба в проектуванні організації, яка потребує роботи.
Другий крок у розпаді системного дизайну - фрагментація комунікаційної структури проєктувальної організації - починається, щойно розпочинається делегування повноважень. Елементарна теорія ймовірності говорить нам, що кількість можливих шляхів комунікації в організації дорівнює приблизно половині квадрата кількості людей в організації.
Навіть у помірно невеликій організації виникає необхідність обмежити комунікацію, щоб люди могли виконати певну "роботу". Дослідження, які приведуть до методів, що дозволяють більш ефективно спілкуватися між проектантами, відіграватимуть надзвичайно важливу роль у технології управління системами.
Загальноприйнята практика управління накладає певні числові обмеження на складність лінійного графа, який представляє адміністративну структуру організації військового типу. Зокрема, кожна особа повинна мати щонайбільше одного керівника і щонайбільше приблизно сім підлеглих.
Наскільки організаційний протокол обмежує комунікацію вздовж ліній підпорядкування, настільки комунікаційна структура організації буде нагадувати її адміністративну структуру. Це одна з причин, чому організації військового типу розробляють системи, які виглядають як їхні організаційні схеми.
Висновок (Conclusion)
Основна теза цієї статті полягає в тому, що організації, які проектують системи (в широкому розумінні), змушені створювати проекти, які є копіями комунікаційних структур цих організацій. Ми побачили, що цей факт має важливі наслідки для управління системним дизайном. Перш за все, ми знайшли критерій для структурування проектних організацій: проектні зусилля повинні бути організовані відповідно до потреби в комунікації.
Цей критерій створює проблеми, оскільки потреба в комунікації в будь-який момент часу залежить від системної концепції, що діє на той момент. Оскільки проект, який з'являється першим, майже ніколи не є найкращим з можливих, може виникнути потреба у зміні домінуючої системної концепції. Тому гнучкість організації є важливою для ефективного проектування.
Необхідно знайти способи винагородити проектних менеджерів за те, що їхні організації залишаються ощадливими та гнучкими. Існує потреба у філософії управління системним дизайном, яка не ґрунтується на припущенні, що додавання людських ресурсів просто підвищує продуктивність.
Розвиток такої філософії обіцяє розкрити основні питання про цінність ресурсів і методів комунікації, на які необхідно буде відповісти, перш ніж наша технологія побудови систем зможе впевнено розвиватися.
Джерела:
- Conway, Melvin. "Conway's Law". Mel Conway's Home Page. http://www.melconway.com/Home/Conways_Law.html
- Conway, Melvin E. (April 1968). "How do Committees Invent?". Datamation.
- Conway, Melvin (1968). "How do committees invent"(PDF). Datamation: 28–31.
- MacCormack, Alan; Rusnak, John; Baldwin, Carliss Y. (2011). "Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis" (PDF).
Якщо стаття була для вас корисна підпишіться на розсилку або на мій телеграм канал.