Ваша организационная структура уже определила судьбу вашего программного обеспечения — Закон Конвей: недооценённый 56 лет управленческий закон

Перед началом

• Ваша архитектура программного обеспечения не «спроектирована» вашей технической командой — она «выросла» из вашей организационной структуры. Этот закон, сформулированный в 1968 году, снова и снова подтверждается в эпоху ИИ.
• Эмпирические исследования Гарвардской школы бизнеса доказали: организационные расстояния лучше предсказывают частоту дефектов ПО, чем сложность кода. То, что вы называете «техническим долгом», по сути, может быть «организационным долгом».
• Империя микросервисов Amazon, модель команд Spotify, кризис Siri от Apple — три триллионные компании, используя совершенно разные судьбы, иллюстрируют одну и ту же закономерность.
• ИИ-агенты входят в организационные схемы. Когда «узлы» в вашей команде перестают быть исключительно людьми, закон Конвей будет переписан способом, которого вы не ожидаете.

В 1968 году неизвестный программист написал статью, которую «Harvard Business Review» отклонил, сославшись на «недоказанность тезиса». Через 56 лет основная идея этой статьи стала общепризнанным законом всей индустрии ПО — а в 2026 году, когда ИИ перестраивает всё, он важнее, чем когда-либо.

1. Как статья, отклонённая редакцией, стала «законом всемирного тяготения» программной инженерии

Пророк, отвергнутый HBR

В апреле 1968 года Мелвин Конвей опубликовал в журнале Datamation статью с скромным названием «How Do Committees Invent?» (Как комитеты изобретают?).
Основной тезис этой статьи — всего одно предложение — способен лишить сна любого CTO:

«Организации, создающие системы, неизбежно порождают дизайны, которые являются копией их коммуникационных структур.»
Проще говоря: организационная структура вашей компании — это точная копия вашей архитектуры программного обеспечения.
Конвей в статье приводит изящный пример: компания назначила восемь человек разделиться на две группы для создания двух компиляторов — одна группа из пяти человек, другая — из трёх. Что произошло? Группа из пяти человек создала пятиэтапный компилятор, группа из трёх — трёхэтапный. Не потому, что технически требовалось именно такое разделение на этапы, а потому, что каждый хотел «владеть» собственной частью работы.
Конвей описал эту зависимость на математическом языке как «гомоморфизм» (homomorphism) — структурное отображение между организационной структурой и дизайном системы, сохраняющее их форму. Это не совпадение, не случайность — это закон, почти математически неизбежный.

Ирония в том, что Конвей первоначально отправил эту статью в «Harvard Business Review», но редакция отклонила её, сославшись на «недостаточное доказательство тезиса». Семь лет спустя Фред Брукс в классической книге «Мифический человеко-месяц» серьёзно цитировал эту идею и официально назвал её «законом Конвея» (Conway’s Law).
С тех пор наблюдение, отвергнутое ведущим коммерческим журналом, стало одним из самых часто цитируемых законов в области программной инженерии.
## «Финальное суждение» Мартина Фаулерa
Если Конвей — Коперник, выдвинувший гипотезу, то последние двадцать лет эмпирических исследований — это телескоп.
В 2022 году главный научный сотрудник ThoughtWorks Мартин Фаулер написал фразу, которая широко распространилась в индустрии: «Если в области программной архитектуры существует одно правило, с которым согласны все практики, то это закон Конвея. Он настолько важен, что повлиял на каждую систему, которую я видел; он настолько мощен, что любой, кто пытается ему противостоять, обречён на поражение».
Это не теоретические рассуждения учёного в башне из слоновой кости. Фаулер на практике, консультируя сотни компаний по всему миру, неоднократно наблюдал одно и то же явление: организационная структура — это тень архитектурного плана программной системы, независимо от того, осознаёт ли это руководство.

Здесь скрытый, но ключевой нюанс, который многие упускают: Фаулер говорил о том, что «любой, кто пытается противостоять ему, обречён на провал», а не «любой, кто пытается использовать его». В чём разница? Противостоять закону Конвей означает навязывать архитектурные изменения без изменения структуры организации; а использовать его — значит сначала перестроить организацию, чтобы архитектура «естественно развивалась».
Это различие определяет успех или провал проектов цифровой трансформации. Мы подробно рассмотрим ключевую стратегию «обратного действия Конвей» (Inverse Conway Maneuver) во второй части серии, посвящённой Team Topologies — по сути, это и есть использование, а не противодействие этому закону.

II. От лаборатории к полю боя: три исследования подтвердили этот закон

«Гипотеза зеркального отражения» Гарвардской школы бизнеса

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

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

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

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

Какой же реальный вывод для руководителей компаний? Когда ваша техническая команда постоянно говорит: «Нам нужно рефакторить», — возможно, рефакторинга требует не код, а сама организация. Но как отличить «технический долг» от «организационного долга»? Требуется систематический метод диагностики — полную оценочную модель мы представим в 12-й статье «Каркас принятия решений по внедрению инструментов ИИ в корпоративной разработке».

«Эксперимент с Windows Vista» от Microsoft Research

В 2008 году исследователи из Microsoft Research, включая Нагаппана, провели масштабное количественное исследование проекта Windows Vista. Их целью было ответить на ключевой вопрос: какие факторы наиболее точно предсказывают наличие дефектов (багов) в программном обеспечении?

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

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

Это открытие имеет гораздо более глубокий корпоративный смысл, чем кажется на первый взгляд. Оно означает — ваша стратегия QA должна следовать организационной структуре, а не сложности кода. Модули, разрабатываемые несколькими командами, требуют более строгого покрытия тестами и более тщательных процессов ревью, даже если сам код выглядит простым. Сегодня, когда объем кода, генерируемого ИИ (Copilot уже создает 46% кода, написанного пользователями), резко возрастает, этот принцип становится еще более критичным — мы подробно разберем пример Coinbase в 8-й статье, когда будем обсуждать «парадокс производительности».

«Ускорение» и «скрытые угрозы» исследования DORA

Команда DevOps Research and Assessment (DORA), входящая в Google и возглавляемая Николь Форсгрен, Джезом Хамблом и Джином Кимом, опубликовала самое масштабное на сегодня исследование эффективности доставки ПО.

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

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

Три «момента Конвея» у компаний с капитализацией в триллионы

Amazon: письмо CEO, изменившее всё

Вокруг 2002 года Джефф Безос отправил внутри Amazon знаменитое письмо «API Mandate» — все команды обязаны общаться исключительно через интерфейсы сервисов (API), и никакие команды не могут напрямую обращаться к хранилищам данных других команд.
Последний пункт этого письма, как утверждают, гласил: «Сотрудники, не соблюдающие эти правила, будут уволены».
Многие считают микросервисную архитектуру Amazon техническим решением. Но с точки зрения закона Конвей, Безос принял организационное решение: он сначала административно перекрыл «обходные пути» общения между командами, и только потом программная архитектура естественным образом трансформировалась в изолированные сервисы.
Так появилась концепция «команды из двух пицц» (Two-Pizza Team) — размер каждой команды не превышает числа людей, которых можно накормить двумя пиццами (обычно 5–8 человек); каждая команда владеет собственным сервисом, развертывает его независимо и взаимодействует с внешним миром исключительно через API.
Империя микросервисов Amazon не была спроектирована архитекторами — она выросла из организационной структуры. Это один из самых классических положительных примеров закона Конвей.

Но здесь есть аспект, который многие статьи не упоминают: успех Amazon обусловлен не только тем, что Безос понял закон Конвей, но и тем, что он одновременно решил проблему «выравнивания стимулов». Каждая «команда из двух пицц» имеет свой P&L (отчет о прибылях и убытках), и они автономны не только в техническом, но и в коммерческом плане. Это означает, что у команд есть внутренняя мотивация поддерживать четкие границы сервисов — потому что нечеткие границы ведут к нечеткости ответственности, а нечеткость ответственности означает нечеткость оценки. Треугольник: организационная структура + система стимулов + техническая архитектура —这才是 Amazon-модель в полном объеме. Компании, которые копируют только организационную структуру, но игнорируют проектирование стимулов, зачастую улавливают только форму, но не суть.

Spotify: идеальная модель против реальности «роста энтропии»

Модель «Squad» Spotify一度 считалась в Силиконовой долине библией организационного дизайна: автономные команды из 5–8 человек (Squad), несколько команд объединяются в племена (Tribe), технические эксперты из разных племен формируют главы (Chapter), а сообщества по интересам — гильдии (Guild).

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

Но сам Spotify позже признал, что реальность намного сложнее модели. Когда бизнес достигает определённого масштаба, межкомандные зависимости неизбежно растут, и чистая автономия начинает порождать координационные издержки. Это раскрывает часто упускаемый из виду вывод из закона Конвэя: организационная структура — это не что-то, что можно спроектировать один раз и забыть; она, как и программное обеспечение, обладает тенденцией к росту энтропии. По мере роста сложности бизнеса границы организаций постепенно размываются, каналы коммуникации удлиняются, а архитектура системы деградирует. Отличные технические организации — это не те, что «спроектировали хорошую архитектуру», а те, что создали способность постоянно корректировать согласованность между организацией и архитектурой. Эту способность мы подробно рассмотрим во второй статье о Team Topologies — она предлагает более систематическую и практичную рамку, чем модель Spotify. ## Apple: Почему Siri проиграла ChatGPT В 2024–2025 годах план обновления ИИ Siri от Apple почти стал «антипримером» закона Конвэя.

Проблема не в технологии. Apple обладает мировым уровнем специалистов по ИИ и щедрыми финансовыми ресурсами. Но разработка Siri затрагивает две команды, между которыми существует структурный разрыв в организационной архитектуре: команда исследований ИИ (возглавляемая Джоном Джаннандреа) и команда разработки продукта (возглавляемая Крейгом Федериги).

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

Что в итоге получает пользователь? Siri — «пошитый из фрагментов посредственный помощник»: отдельные модули выглядят прилично, но в совокупности они не создают единой интеллектуальной экспертизы. Именно это и предсказывала закон Конвей: трещины в системе отражают трещины в организации.

Кейс Apple особенно важен для китайских руководителей. Многие компании сейчас сталкиваются с абсолютно теми же проблемами — команды ИИ и бизнес-команды подчиняются разным вице-президентам, а внедрение ИИ-проектов превращается в «политическую борьбу между двумя отделами», а не в «совместную доставку одного продукта».

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

Четыре: Эра ИИ — Закон Конвей переписывается

Когда «организационные узлы» перестают быть исключительно людьми

В 2026 году Закон Конвей сталкивается с самым глубоким вызовом со времён его формулировки в 1968 году. Когда Конвей формулировал этот закон, он предполагал скрытый постулат: каждый «узел» в организации — это человек. Структура коммуникаций — это коммуникации между людьми.

Но сегодня ИИ-агенты проникают в организационные схемы. Claude Code может самостоятельно выполнять многошаговые задачи разработки, система Minions от Stripe еженедельно генерирует более 1000 объединённых запросов на слияние, Cursor изменил способ работы 100% инженеров NVIDIA. Согласно отчёту Gartner, запросы на консультации по оркестрации многопроцессных ИИ-агентов в корпоративной среде выросли на 1445% в 2025 году.

Что происходит с Законом Конвей, когда некоторые узлы в организации перестают быть людьми?

Этот вопрос будет рассматриваться в течение второй половины нашей серии — в статье 10 о феномене «один человек — уникорн», в статье 11 о «законе Конвея и AI-агенты», в статье 14 о «Agentic Engineering» — но здесь мы сразу дадим три предварительных суждения, чтобы помочь вам сформировать мысленную рамку:

Первое: структура коммуникации станет структурой стратегии.
Человеческое общение опирается на культуру, взаимопонимание и неформальные каналы. Но между человеком и AI-агентом нет «взаимопонимания» — вы должны явно определять границы взаимодействия через стратегии, правила и права доступа. Способность к управлению заменит способность к коммуникации как ключевой переменный фактор в проектировании организаций.

Второе: организационные схемы превратятся в схемы прав доступа.
Традиционные организационные схемы описывают отношения подчинения и функциональное разделение труда. «Схема» эпохи AI скорее напоминает направленный ациклический граф (DAG), определяющий возможности и ограничения: какой агент может получить доступ к каким данным, выполнять какие операции и при каких условиях требовать одобрения человека.

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

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

Первое и второе утверждения — это не только наша точка зрения. В подкасте a16z «Software in the Age of Agents» от июля 2026 года партнёр команды a16z по корпоративным инвестициям Сима Амбл и бывший президент Windows в Microsoft Стивен Синовски, опираясь на наблюдения с передовой, пришли к совершенно совпадающим выводам. Стивен одним предложением раскрыл суть первого утверждения: «Самый большой сетевой эффект в корпоративном ПО существует внутри компании» (The biggest network effect in enterprise software is inside of a company): именно сеть, сплетённая из человеческих связей, процессов и систем внутри организации, и есть настоящий источник лояльности. Agent не может подключиться к этой сети «по наитию» — он может это сделать только через чёткие стратегии и права доступа — именно это и является реальной движущей силой, превращающей структуру коммуникаций в структуру стратегий. Сима подтвердила второе утверждение с точки зрения доступа agent к корпоративным системам: когда agent должен «выполнить» действие (записать в систему, изменить бухгалтерские данные), он немедленно сталкивается с целым комплексом вопросов — идентификация, учётные данные, лицензионные места, права на утверждение — организационная структура постепенно трансформируется в карту прав: «Кто имеет доступ к чему? Кто уполномочен что делать?». Эти два утверждения — не прогнозы, а то, что уже происходит в проектах, в которые инвестируют венчурные инвесторы на передовой. (Гости — партнёры a16z / бывшие топ-менеджеры Microsoft, позиция VC.)

Пять: Самопроверка: какую «ошибку Конвей» допускает ваша организация?

Если вы дочитали до этого места и всё ещё думаете: «Я и так всё это знаю», — предлагаю вам выполнить упражнение.

Ниже приведены пять распространённых паттернов несоответствия между организацией и архитектурой, выявленных нами на основе закона Конвей и последующих исследований. Сопоставьте их с вашей компанией и посмотрите, сколько пунктов вам подходят:

• ❶ Внешние микросервисы: Код разбит, но 50 человек всё ещё спорят в одном чате.
• ❷ Иллюзия централизованной платформы: Централизованная платформа превратилась в узкое место для коммуникации между всеми бизнес-линиями.
• ❸ AI-острова: Модели, созданные командой ИИ, не могут быть интегрированы в бизнес-процессы, потому что в организации они «на разных дорогах».
• ❹ Деградация удалённой координации: Физическая изоляция привела к ненужному расколу систем.
• ❺ Непереваренная акквизиция: Несовместимость корпоративных культур привела к провалу технической интеграции.

Следующий шаг

Это первая из 15 статей цикла «Преобразования программной инженерии в эпоху ИИ». Исходя из закона Конвей, мы сформировали базовое понимание: организационная структура определяет системную архитектуру — это не метафора, а эмпирически подтверждённая причинно-следственная связь.

Но знание этого закона — лишь начало. Настоящий вопрос в другом: можем ли мы использовать его в обратном направлении? Сознательно проектируя организационную структуру, чтобы направлять желаемую архитектуру системы — именно в этом суть «обратной операции Конвей» (Inverse Conway Maneuver).
В следующей статье «Team Topologies — методология организационного проектирования в пост-агильную эпоху» мы подробно рассмотрим, как Мэттью Скелтон и Мануэль Пайс превратили эту идею в полную и практичную методологию, включающую четыре базовых типа команд, три модели взаимодействия и концепцию «когнитивной нагрузки», которая долгое время недооценивалась. Практические кейсы 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. Верификация гостей: Seema Amble, партнер команды a16z по корпоративным технологиям; Steven Sinofsky, бывший президент Windows, партнер совета директоров a16z; Elena Burger, автор a16z; выпуск от июля 2026 г.)