В 1967 году программист Мелвин Конвей сформулировал наблюдение, которое навсегда изменило подход к управлению разработкой. Он заявил, что организации, проектирующие системы, неизбежно создают архитектуры, которые являются точной копией их внутренних структур коммуникации. Проще говоря, если вы поручите создание компилятора четырем разным командам, вы гарантированно получите четырехпроходный компилятор.
Долгое время это высказывание считалось профессиональной шуткой, пока исследования ведущих университетов не подтвердили его абсолютную правоту. Закон Конвея объясняет, почему технические проблемы часто невозможно решить техническими же средствами. Если архитектура вашего продукта запутана, полна костылей и постоянно ломается на стыках модулей, проблема кроется не в плохом коде. Проблема кроется в том, как ваши люди общаются между собой.
Суть закона и влияние на разработку
Закон Конвея работает как гравитация. Вы можете его игнорировать, но он все равно будет тянуть ваш продукт в определенную сторону. Архитектура программного обеспечения всегда подстраивается под границы между отделами.
Если в вашей компании есть отдел фронтенда, отдел бэкенда и отдел тестирования, ваш продукт будет разделен на соответствующие слои. Разработчики баз данных будут писать логику так, чтобы минимизировать общение с фронтендерами, потому что согласование интерфейсов через менеджеров занимает слишком много времени. В результате вместо единого удобного продукта вы получаете набор изолированных кусков кода, которые с трудом склеиваются вместе перед релизом.
Сравнение организационных структур и архитектуры
| Тип организационной структуры | Характер внутренних коммуникаций | Итоговая архитектура продукта |
|---|---|---|
| Функциональные колодцы (Frontend, Backend, QA) | Общение через передачу ТЗ, тикеты и менеджеров | Монолитная система с жесткими слоями и частыми багами на стыках технологий |
| Кросс-функциональные продуктовые команды | Постоянное живое общение внутри команды ради общей цели | Модульная или микросервисная архитектура с независимыми компонентами |
| Изолированные департаменты без общих целей | Отсутствие общения, конкуренция за ресурсы | Разрозненный продукт с разным дизайном, дублированием логики и плохим UX |
Глубокое погружение: Обратный маневр Конвея
Осознание закона Конвея привело к появлению мощной управленческой практики, которая называется Обратный маневр Конвея (Inverse Conway Maneuver). Суть этого подхода предельно прагматична. Вместо того чтобы пытаться натянуть желаемую архитектуру на существующую структуру компании, вам нужно сначала изменить структуру компании под ту архитектуру, которую вы хотите получить.
Если бизнес хочет перейти от тяжелого монолита к быстрым и независимым микросервисам, нанимать дорогих архитекторов бесполезно, пока вы сохраняете старые отделы. Сначала вам нужно разрушить функциональные колодцы. Вы создаете небольшие автономные команды, каждая из которых владеет конкретным бизнес-доменом от начала и до конца. Вы даете им независимость в принятии решений. И только тогда, естественным образом, их код начнет разбиваться на такие же независимые микросервисы.
Именно на этом законе базируется фундаментальное требование Scrum о создании кросс-функциональных команд. Разработчики в Scrum объединяют специалистов всех необходимых профилей в единую ячейку. Убирая барьеры между аналитикой, написанием кода и тестированием, Scrum устраняет барьеры внутри самого продукта. Команда начинает создавать целостный Инкремент, потому что внутри нее больше нет коммуникационных разрывов.
Резюме: Архитектура это отражение культуры
Закон Конвея доказывает, что дизайн системы не рождается на доске архитектора. Он рождается в переговорных комнатах, в чатах и в кулуарах офиса.
Ключевой вывод состоит в том, что технические лидеры и менеджеры должны проектировать организацию с тем же вниманием, с каким они проектируют программное обеспечение. Если вы хотите получить гибкий, масштабируемый и удобный продукт, вам придется построить гибкую, масштабируемую и открытую к общению компанию.
Часто задаваемые вопросы (FAQ)
Да. Изначально это было эмпирическое наблюдение, но позже исследователи из Гарвардской школы бизнеса и MIT провели масштабные исследования. Они проанализировали кодовые базы коммерческих и open-source проектов и математически доказали сильную корреляцию между структурой команды разработчиков и структурой исходного кода.
Если пользователь видит, что разные разделы приложения выглядят по-разному, требуют отдельной авторизации или имеют разную логику навигации, это прямое следствие закона Конвея. Это означает, что эти разделы делали разные команды, которые не общались между собой и не имели единого Владельца продукта.
Абсолютно. Закон Конвея применим к проектированию любых сложных систем. Например, при проектировании самолета или автомобиля структура инженерных бюро неизбежно отразится на компоновке деталей и узлов транспортного средства.
Компании пытаются внедрить микросервисную архитектуру, сохраняя при этом матричную систему управления и жесткие функциональные отделы. Из-за закона Конвея разработчики в такой среде физически не могут создать по-настоящему независимые сервисы. В итоге компания получает распределенный монолит, который поддерживать еще сложнее и дороже.
Скрам мастер работает как разрушитель коммуникационных барьеров. Его задача выявлять ситуации, когда команда изолируется от остальной организации или от клиентов. Налаживая прозрачные связи и устраняя внешние препятствия, Скрам мастер напрямую влияет на то, чтобы архитектура продукта оставалась чистой и ориентированной на ценность.