На початку

  • Ваша програмна архітектура не «спроектована» командою розробників — вона «зростає» зі структури вашої організації. Цей закон, сформульований у 1968 році, постійно підтверджується в епоху ШІ.
  • Емпіричні дослідження Гарвардської школи бізнесу доводять: відстань між командами краще передбачає частоту багів, ніж складність коду. Те, що ви називаєте «технічним боргом», насправді може бути «організаційним боргом».
  • Імперія мікросервісів Amazon, модель малих команд Spotify, криза Siri в Apple — три трильйонні компанії, що продемонстрували різні долі, але одну й ту саму закономірність.
  • ШІ-агенти ввійшли в організаційні схеми. Коли «вузли» в команді більше не є лише людьми, закон Конвей буде переписаний так, як ви навіть не уявили.

У 1968 році невідомий програміст написав статтю, яку «Harvard Business Review» відхилив, назвавши її «не доведеною». 56 років потому центральна ідея цієї статті стала загальноприйнятим законом у всій індустрії програмного забезпечення — а в 2026 році, коли ШІ перебудовує все, він важливіший, ніж будь-коли.

I. Як одна відхилена стаття стала «законом всесвітнього тяжіння» програмної інженерії

Пророк, відхилений HBR

У квітні 1968 року Мелвін Конвей опублікував у журналі Datamation статтю зі скромною назвою: «How Do Committees Invent?» (Як комітети винаходять?).
Основний тезис цієї статті — одна речення, яке здатне змусити будь-якого CTO не спати всю ніч:

“Організації, що проектують системи, не уникнуть створення проектів, які є копіями їхніх комунікаційних структур.”
Простими словами: організаційна діаграма вашої компанії — це просто відображення вашої архітектури програмного забезпечення.

Конвей у своїй статті навів досконалий приклад. Компанія призначила вісім осіб на розробку двох компіляторів, розділивши їх на дві групи: п’ятьох і трьох. Що вийшло? Група з п’яти осіб створила п’ятиетапний компілятор, а група з трьох — триетапний. Не тому, що технічно це було необхідно, а тому, що кожен бажав “володіти” власним блоком роботи.

Конвей описав цю залежність мовою математики як “гомоморфізм” (homomorphism) — структурно збережене відображення між організаційною структурою та проектом системи. Це не випадковість, не випадок — це майже математично необхідна закономірність.

Саркастично, але Conway спочатку надіслав цю статтю до «Harvard Business Review», але редактор відхилив її, заявивши, що «аргумент не доведено». Сім років потому Fred Brooks у класичній книзі «The Mythical Man-Month» серйозно посилався на цю ідею і офіційно назвав її «законом Конвея» (Conway’s Law).
З того часу спостереження, відхилене провідними комерційними журналами, стало одним із найчастіше цитованих законів у сфері програмної інженерії. 信息图——康威定律的"前世今生"时间线 ## «Остаточний вердикт» Мартіна Фаулерa Якщо Конвей — це Копернік, що сформулював гіпотезу, то емпіричні дослідження останніх двадцяти років — це телескоп. У 2022 році головний науковець ThoughtWorks Мартін Фаулер написав фразу, яка швидко поширилася серед професіоналів: «Якщо в області програмної архітектури є єдиний закон, з яким згодні всі практики, то це закон Конвея. Він настільки важливий, що вплинув на кожну систему, яку я бачив; він настільки потужний, що будь-хто, хто намагається йому протистояти, обов’язково зазнає невдачі».
Це не теоретичні міркування вченого в слоновій кістці. Фаулер у своїй консультативній практиці з сотнями компаній по всьому світу неодноразово спостерігав одне й те саме явище: організаційна структура — це тінь архітектури програмного забезпечення, незалежно від того, чи усвідомлюють це менеджери.

Тут є тонкий, але ключовий нюанс, який багато хто пропускає: Фаулер мав на увазі, що «будь-хто, хто намагається заперечити його, обречений на невдачу», а не «будь-хто, хто намагається використати його». У чому різниця? Заперечення закону Конвей означає нав’язування змін у архітектурі без зміни організаційної структури; а використання його — це спочатку перебудувати організацію, щоб архітектура «розвивалася природно».

Ця різниця визначає успіх чи провал проектів цифрової трансформації. Ми детально розглянемо ключову стратегію «зворотного закону Конвей» (Inverse Conway Maneuver) у наступній другій статті про Team Topologies — суть її полягає саме у використанні, а не запереченні цього закону.

Друга частина: Від лабораторії до поля бою — три дослідження підтверджують цей закон 三项研究的核心发现对比表格

«Гіпотеза дзеркала» Гарвардської школи бізнесу

У 2012 році МакКормак та його колеги з Гарвардської школи бізнесу опублікували важливе дослідження, яке в академічному середовищі отримало назву «гіпотеза дзеркала» (Mirroring Hypothesis).

Методологія була дуже витонченою: вони порівняли комерційне програмне забезпечення та відкрите програмне забезпечення, які виконували однакові функції. Комерційне ПЗ розроблялося ієрархічними корпоративними командами, а відкрите — розсіяними спільнотами.

Результати збіглися з передбаченням закону Конвей: продукти, розроблені організаціями зі слабким зв’язком, значно більш модулярні. Щиро намагаючись досягти модулярного дизайну, команди з щільним зв’язком у кінцевому підсумку створюють системи, що відображають їхню організаційну структуру — з щільним зв’язком.

Організаційна структура діє як «гравітаційне поле» — ви можете тимчасово протистояти їй, але з часом архітектура системи неодмінно повертається до форми, що збігається з організаційною структурою.

Який справжній висновок для керівників підприємств? Коли ваша технічна команда постійно каже: «Нам потрібно рефакторити», справжнім об’єктом рефакторингу, можливо, є не код, а організація. Але як визначити, чи це «технічний борг» чи «організаційний борг»? Потрібна системна діагностична методика — повну оціночну модель ми надамо у 12-й статті «Каркас прийняття рішень щодо впровадження інструментів AI у підприємствах».

«Експеримент з Windows Vista» від Microsoft Research

У 2008 році Nagappan та його колеги з Microsoft Research провели масштабне кількісне дослідження проекту Windows Vista. Вони намагалися відповісти на ключове питання: який фактор найкраще передбачає наявність дефектів (багів) у програмному забезпеченні?

Кандидати на роль ключового фактора включали: складність коду, кількість рядків коду, частоту змін коду, досвід розробників… і одну змінну, що здавалася не пов’язаною з «технікою» — організаційна відстань (тобто відстань між командами, що розробляють відповідні модулі, в організаційній структурі).

Висновки дослідження викликали занепокоєння серед технократів: відстань між організаціями краще передбачає частоту дефектів у програмному забезпеченні, ніж складність коду. 组织距离 vs 代码复杂度 Іншими словами, модуль, розроблений двома командами, які “далеко” розташовані на організаційній діаграмі, схильніший до багів, ніж надзвичайно складний модуль, що підтримується тісно співпрацюючою командою. Ви думаєте, що баги виникають через поганий код — але справа може бути саме в погано спроектованій організаційній структурі.

Це відкриття має набагато глибші корпоративні наслідки, ніж здається на перший погляд. Воно означає — ваша стратегія QA повинна відповідати організаційній структурі, а не складності коду. Модулі, що розробляються кількома командами, потребують більш строгого покриття тестами та процесів рев’ю, навіть якщо сам код виглядає простим. У епоху експоненційного зростання коду, згенерованого ШІ (Copilot зараз генерує 46% коду, написаного користувачами), цей принцип стає ще важливішим — ми детально розглянемо це на прикладі Coinbase у 8-й статті, коли обговорюватимемо «парадокс продуктивності».

«Прискорення» та «приховані загрози» дослідження DORA

Команда DevOps Research and Assessment (DORA), що належить Google та очолюється Nicole Forsgren, Jez Humble та Gene Kim, опублікувала найбільше на сьогодні дослідження ефективності доставки програмного забезпечення.

Основні висновки збігаються з законом Конвей: «Якщо ми реалізуємо архітектуру з низьким зв’язуванням та добре інкапсульованою структурою, супроводжувану відповідною організаційною структурою, ми можемо підвищити швидкість та стабільність доставки, зберігаючи лінійний або навіть суперлінійний ріст продуктивності навіть при значному збільшенні інженерних команд». Але звіт DORA 2022 року також виявив цікавий побічний ефект: хоча архітектура з низьким зв’язуванням підвищує ефективність доставки, вона може збільшувати вигорання команд. Причина може полягати в тому, що коли команди є високо автономними та ізольованими один від одного, учасники втрачають усвідомлення загального сенсу, відчуваючи себе «лише шестеренками».

Це важливе нагадування — відповідність архітектури та організації не є срібною кулею: вона вирішує проблеми ефективності, але може створювати проблеми культури. Глибокий висновок: якщо архітектура з низьким зв’язуванням + організація з низьким зв’язуванням вже роблять людей-розробників відчутними ізоляції, що відбудеться, коли до команди додадуть AI-агентів? AI не «відчуває ізоляції», але люди стануть ще більш ізольованими. Цей аспект майже не обговорюється, але в наших джерелах звіт BCG за 2025 рік згадує «проблему координації середніх менеджерів» — це саме ключова тема нашої 11-ї статті.

Три «моменти Конвей» у компаніях з трильйонною оцінкою

Amazon: лист CEO, що змінив усе

Близько 2002 року Джефф Безос усередині Amazon розіслав той найвідоміший «API Mandate» — усі команди мали зобов’язання спілкуватися виключно через інтерфейси сервісів (API), заборонялося будь-яке прямі доступи до сховищ даних інших команд.
Останній пункт цієї листівки, як стверджують, гласив: «Порушників цих правил буде звільнено».
Багато хто сприймає мікросервісну архітектуру Amazon як технічне рішення. Але з погляду закону Конвей, Безос зробив саме організаційне рішення: він спочатку за допомогою управлінських заходів перекрив «короткі шляхи» спілкування між командами — і вже після цього програмна архітектура природно трансформувалася в ізольовані сервісні модулі.
Amazon 的"因果链"示意图
Це й стало основою для пізнішого концепту «команди з двох піц» (Two-Pizza Team) — розмір кожної команди не перевищував кількості людей, яких можна накормити двома піцами (зазвичай 5–8 осіб); кожна команда володіла власним сервісом, здійснювала незалежне розгортання та взаємодіяла ззовні через API.
Мікросервісна імперія Amazon не була намальована архітекторами — вона виростала з організаційної структури. Це найкласичніший позитивний приклад закону Конвей.

Але тут є один аспект, про який багато статей не згадують: успіх Amazon пояснюється не лише тим, що Безос зрозумів закон Конвей, а й тим, що він одночасно вирішив проблему “відповідності стимулів”. Кожен “командний піца” володіє власним P&L (звітом про фінансові результати), і вони не лише технічно автономні, а й комерційно автономні. Це означає, що команди мають внутрішній стимул підтримувати чіткі межі сервісів — бо розмиті межі означають розмиту відповідальність, а розмита відповідальність — розмите оцінювання. Трикутник: організаційна структура + система стимулів + технічна архітектура — ось повна картина моделі Amazon. Компанії, що копіюють лише організаційну структуру, а не дизайн стимулів, зазвичай отримують лише форму, а не суть.

Spotify: ідеальна модель зіткнулася з реальністю “зростання ентропії”

Модель “Squad” Spotify колись вважалася біблією організаційного дизайну в Сіліконовій долині: автономні команди з 5–8 осіб (Squad), кілька команд об’єднуються в племена (Tribe), технічні експерти з різних племен утворюють розділи (Chapter), а спільноти за інтересами — гільдії (Guild).

Spotify 组织模型的经典四层示意图

Ця модель була глибоко узгоджена з законом Конвей — через структуру невеликих, автономних команд вона стимулювала створення невеликих, автономних програмних сервісів.

Але сама Spotify пізніше визнала, що реальність набагато складніша за модель. Коли бізнес досягає певного розміру, залежності між командами неухильно зростають, і чиста автономність починає породжувати витрати на координацію. Це розкриває один із рідко згадуваних висновків закону Конвейя: організаційна структура — це не те, що можна спроектувати один раз і забути про неї; вона, як і програмне забезпечення, має тенденцію до зростання ентропії. Зі зростанням складності бізнесу межі організації поступово розмиваються, шляхи комунікації стають довшими, а архітектура системи деградує. Відмінні технічні організації — це не ті, що “спроектували гарну архітектуру”, а ті, що створили здатність постійно підлаштовувати відповідність між організацією та архітектурою. Цю здатність ми детально розглянемо у другій статті про Team Topologies — вона пропонує більш систематичний і практичніший фреймворк, ніж модель Spotify. ## Apple: чому Siri була “знищена” ChatGPT У 2024–2025 роках план оновлення штучного інтелекту Siri в Apple майже став “антиприкладом” закону Конвейя.

Проблема не в технології. Apple має світово відомих фахівців з ШІ та достатньо фінансування. Але розробка Siri стикається зі структурним розривом між двома командами: командою досліджень ШІ (під керівництвом Джона Джіаннандреа) та командою розробки продукту (під керівництвом Крейга Федерігі).

Ці дві команди мають різні пріоритети, різний темп роботи та різні критерії успіху. Команда досліджень ШІ прагне до проривів на передовій здатності моделей, тоді як команда продукту прагне до стабільного надання досвіду користувача. Коли структура комунікації між цими двома організаційними “вузлами” розривна, результатуюча система також буде розривною.

Що отримує користувач у вигляді Siri? “Плоский асистент зі збірки функцій” — окремі модулі виглядають прийнятно, але разом вони не створюють єдиного інтелектуального досвіду. Саме це й передбачав закон Конвей: розриви в системі відображають розриви в організації.

Випадок Apple особливо важливий для керівників китайських компаній. Багато компаній переживають саме таку ж проблему — команди ШІ та бізнес-команди підпорядковані різним віцепрезидентам, і проекти впровадження ШІ перетворюються на “політичну гру між двома відділами”, а не на “спільну розробку продукту”.

Якщо ваша компанія активно продвігає впровадження ШІ, зверніть увагу на свою організаційну структуру: здатності ШІ існують як окремий відділ чи вбудовані в бізнес-команди? Відповідь на це питання може вирішувати успіх проекту навіть більше, ніж вибір моделі ШІ.

Чотири: Ера ШІ — Закон Конві переписується

Коли «організаційні вузли» більше не лише люди

2026 року закон Конві стикається з найглибшою перевіркою з 1968 року.
Конві, формулюючи цей закон, передбачав прихований постулат: кожен «вузол» у організації — це людина. Комунікаційні структури — це взаємодія між людьми.

Але сьогодні ШІ-агенти входять до організаційних схем. Claude Code може самостійно виконувати багатокрокові завдання розробки, система Minions від Stripe щотижня генерує понад 1000 злитих PR, Cursor змінив спосіб роботи 100% інженерів NVIDIA. За звітом Gartner, запити на консультації щодо багатоагентного керування ШІ у бізнесі у 2025 році зросли на 1445%.

Що відбувається з законом Конві, коли деякі вузли організації більше не є людьми?
传统组织架构图 vs AI 时代组织架构图

Ця проблема буде розгорнута в другій частині нашого серіалу — у статті 10 про феномен «одинокого унікорна», у статті 11 про «закон Конвей та AI-агенти», у статті 14 про «Агентний інжиніринг» — але ось три початкові тези, щоб сформувати вашу мислительну рамку:

Перше, структура комунікації перетвориться на структуру стратегії. Людська комунікація ґрунтується на культурі, взаємному розумінні та неформальних взаємодіях. Але між людиною та AI-агентом немає «взаємного розуміння» — ви повинні чітко визначити межі взаємодії за допомогою стратегій, правил та прав доступу. Здатність до управління замінить здатність до комунікації як ключовий параметр організаційного дизайну.

Друге, організаційна діаграма перетвориться на діаграму прав доступу. Традиційні організаційні діаграми описують лінії підпорядкування та функціональне розподілення. «Діаграма» епохи AI схожа на орієнтований ациклічний граф (DAG), який визначає здібності та обмеження: який агент може отримувати доступ до яких даних, виконувати які операції та за яких умов вимагати людського схвалення.

Третє, інституційні знання перейдуть від людей до стратегій. Раніше «коли старий співробітник пішов — знання втекли» було болем кожної компанії. У майбутньому ключові знання будуть закодовані в стратегіях та контексті AI-агентів — це й можливість (знання більше не втрачаються), й ризик (помилки в стратегіях можуть системно посилюватися).

Кожне твердження ґрунтується на величезній кількості галузевих практик і даних. Наприклад, третє твердження про «перенесення інституційних знань» — це драматичний приклад з Klarna: після звільнення 40% співробітників вони зрозуміли, що AI-система не може замінити неявні знання, які відійшли разом із звільненими, і їм довелося знову наймати людей. Цю історію ми детально розглянемо у 9-й статті «Уроки Klarna».

Перше й друге твердження — це не лише наша думка. У подкасті a16z «Software in the Age of Agents» в липні 2026 року партнер команди a16z Seema Amble та колишній генеральний директор Windows у Microsoft Steven Sinofsky, опираючись на свої спостереження з першої лінії інвестування, прийшли до абсолютно збіжних висновків. Steven одним реченням вказав на суть першого твердження: «Найбільший мережевий ефект у корпоративному програмному забезпеченні відбувається всередині компанії» (The biggest network effect in enterprise software is inside of a company): саме мережа, що складається з людських зв’язків, процесів і систем всередині організації, є справжнім джерелом лояльності. Agent не може під’єднатися до цієї мережі за допомогою «неписаної згоди» — він може це зробити лише через чіткі стратегії та дозволи — саме це й є реальним стимулом, що перетворює структуру спілкування на структуру стратегії. Seema підтвердила друге твердження з точки зору доступу agent до корпоративних систем: коли agent має «виконати» дію (наприклад, записати дані в систему або змінити фінансові записи), він одразу зіштовхується з цілою системою питань: ідентичність, облікові дані, ліцензійні місця, права на схвалення — організаційна діаграма перетворюється на карту дозволів: «Хто має доступ до чого? Хто може авторизувати що?». Ці два твердження — не прогнози, а те, що вже відбувається в проектах, в які інвестують інвестори на передовій. (Гості — партнери a16z / колишні високопосадовці Microsoft, позиція VC.)

П’ять: Самоперевірка: яку «помилку Конві» допускає ваша організація?

Якщо ви дійшли сюди й все ще вважаєте: «Ці ідеї мені відомі», то хочу запропонувати вам вправу.

Нижче наведено п’ять поширених шаблонів «розриву між організацією та архітектурою», виведених нами на основі закону Конві та його подальших досліджень. Зіставте їх із вашою компанією — скільки пунктів ви впізнаєте?

五种"组织-架构错位"模式的诊断卡片

  • ❶ Поверхневі мікросервіси: код розбито, але 50 осіб все ще суперечать у одному чаті.
  • ❷ Ілюзія платформи: платформа перетворилася на точку зупинки для всіх бізнес-ліній.
  • ❸ AI-острови: моделі, розроблені AI-командою, не можуть бути інтегровані в бізнес, бо організаційно вони «не на тій дорозі».
  • ❹ Деградація віддаленої співпраці: фізична ізоляція призводить до непотрібного розриву систем.
  • ❺ Погане засвоєння поглинань: несумісність організаційних культур призводить до невдачі технічної інтеграції.

Наступний крок

Це перша з 15 статей серії «Зміни в програмній інженерії в епоху AI». Ми виходили з закону Конві й сформували базове розуміння: організаційна архітектура визначає системну архітектуру — це не метафора, а емпірично підтверджена причинно-наслідкова залежність.

Але знання цього закону — лише початок. Справжнє питання: чи можемо ми використати його навпаки? Шляхом свідомого проектування організаційної структури для спрямування бажаної архітектури системи — ось суть «зворотного закону Конвей» (Inverse Conway Maneuver). У наступній статті «Team Topologies — методологія організаційного дизайну в епоху після Agile» ми глибоко розглянемо, як Метью Скелтон та Мануель Пайс перетворили цю ідею на повну, практичну методологію, що включає чотири базових типи команд, три моделі взаємодії та концепцію «когнітивного навантаження», яка серйозно недооцінюється. Практичні приклади з Netflix, Adidas, Accenture продемонструють: за яких умов зворотний закон Конвей працює, а за яких — зазнає невдачі. — > Примітка до серії: Ця серія буде відстежувати останні тенденції в галузі AI-інструментів для програмування, організаційних структур та програмних парадигм, зокрема нові зміни закону Конвей в епоху AI-агентів у 2026 році, ступінь зрілості новітніх інструментальних екосистем тощо. Підпишіться на цю серію, щоб отримувати актуальні інсайти. # Про цю серію

«Зміни в програмній інженерії в епоху ШІ» — це глибокий дослідницький серіал для технічних рішень підприємств, що складається з 15 статей. На основі систематичного аналізу 200+ академічних статей та галузевих звітів, ми надаємо рішення з позначенням рівня доказів. Більше матеріалів — у майбутньому.

Джерела:

  • Conway, M. (1968). How Do Committees Invent? Datamation, 14 (4), 28–31.
  • Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
  • MacCormack, A., et al. (2012). Exploring the Duality between Product and Organizational Architectures: A Comparative Study of Commercial and Open Source Software. Harvard Business School Working Paper.
  • Nagappan, N., et al. (2008). The Influence of Organizational Structure on Software Quality. ICSE ‘08 Proceedings.
  • Forsgren, N., et al. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
  • Fowler, M. (2022). Conway’s Law. Martinfowler.com/bliki/ConwaysLaw.html.
  • Gartner (2025/26). Predicts 2026: AI Agents in Software Engineering.
  • a16z (2026). Software in the Age of Agents. The a16z Podcast. (Steven: «The biggest network effect in enterprise software is inside of a company» + Seema Amble про те, як агенти зіштовхуються з правами доступу, обліковими даними та ліцензіями при підключенні до корпоративних систем — підтверджують твердження 1 і 2 у розділі 4; первинне джерело — аудіозапис подкасту. Позиція: партнер a16z / колишній високопосадовець Microsoft, позиція VC. Гості підтверджено: Seema Amble, партнер a16z Enterprise, Steven Sinofsky, колишній президент Windows у Microsoft (board partner), Elena Burger, автор a16z; випуск вийшов у липні 2026 року.)