Закон Конвея и структура организации
В 1968 году учёный и инженер Мелвин Конвей опубликовал статью со странным названием «Как комитеты создают новое?» («How Do Committees Invent?»), которая так бы может и осталась незамеченной, если бы айтишники не подняли на знамёна фразу, которая была написана в самом конце статьи:
Любые организации, проектирующие системы …, обречены создавать такие архитектуры, которые копируют коммуникационную структуру этих организаций.
В оригинале:
Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
Более современная (и более на мой взгляд понятная) формулировка того, что впоследствии стало известно как «закон Конвея» звучит так:
«Если архитектура системы и архитектура организации противоречат друг другу, победу одерживает архитектура организации.»
С момента публикации прошло больше полувека и за это время закон многократно эмпирически подтверждался (говорят у него есть и строго научное доказательство, но так как я его не понимаю в силу скудоумия, то и приводить не буду).
Всё, с матчастью закончили. Теперь я постараюсь объяснить, что это всё значит, и почему это важно.
Вот есть в вашей организации какая-то структура: бухгалтерия, продажи, производство, продуктовики и так далее. И они как-то между собой общаются: производство с продажами, маркетинг с PR’ом, эти с теми, а те — с этими. Т.е. у вашей организации есть какая-то архитектура: узлы (ваши отделы) и связи между ними (коммуникации).
Так вот:
Любой продукт (или услуга), созданные вашей компанией, будут повторять модель работы самой компании.
Ну это как раз и так понятно, верно? В конце концов компания и создавалась под реализацию этого продукта или услуги. Но вот то, что обратное утверждение тоже верно, понятно почему-то далеко не всегда:
Ваша компания в текущем виде не способна создать продукт или услугу, механика работы которых принципиально отличаются от того, что вы уже производите.
Я сейчас не говорю, что ткацкая фабрика не может вдруг начать строить самолёты, вы же понимаете. Давайте на примерах. Начнём с IT, так проще.
- Если у вас есть команды фронтендеров и бэкендеров, то любой ваш софт будет состоять из фронта и бэка, что бы вы там ни хотели сделать.
- Если вы задумали микросервисы, но при этом сервисные команды общаются только через CPO, который всё лично контролирует, будьте уверены — вы напишете монолит.
- Если клиентский фидбек до продуктовой команды доносит отдел продаж, то фичи в продукте будут такими, какие нужны продавцам, а не клиентам.
- Если вы хотите начать R&D работу и быстро проверять гипотезы, но не собрали под это отдельную команду, «оторвав» людей с корнями из их текущих отделов и функциональных единиц — затея обречена. Сколько бы вы ни запускали проектов, люди на тех же местах будут делать новую работу так же, как они привыкли делать старую.
Ну и так далее.
Но я вам обещал примеры не из IT.
- Вам никогда не казалось, что в автомобилях разные приборы управления сонастроены таким образом, словно их разработчики никогда друг с другом не общались? Ужас последних лет (последних десяти лет?) с повсеместным внедрением мультимедийных экранов хорошо это иллюстрирует.
- Apple даёт пользователям бесшовный опыт между разными своими устройствами в том числе и потому, что команды там собраны по функциональному принципу. Грубо доворя, за весь дизайн отвечает департамент дизайна.
- Штатовский пример из одной из статей, но всё же: законопроекты, подготовленные различными группами авторов, как правило имеют структуру, зависящую от того, представители какого количества партий или иных комитетов в них входили. Сколько комитетов — столько разных разделов в документе.
Уверен, если вы посмотрите вокруг, то сами удивитесь тому, как много можно рассказать об организации на основе того, как устроены её продукт или услуга.
Ну хорошо, допустим, а делать-то что? Вот у вас есть уже какая-то организация, с какой-то структурой. А вам хочется изменений. Как «продать» эти изменений компании? Хитрые айтишники и тут нашли рецепт. Называется «обратный манёвр Конвея». Вместо того, чтобы впихивать новые инициативы в существующие команды, перестройте команды так, каким хотите видеть новый продукт. И тогда архитектура нового продукта автоматически повторит структуру команд.
Понятно, что на деле всё не так гладко. Это только на бумаге людей туда-сюда двигать — просто. Но в целом подход-то правильный. Начинать надо с конца:
- Есть новая идея? Представьте, как должна быть устроена организация, которая идеально воплотит её в жизнь.
- Нарисуйте структуру этой организации: сколько там будет команд, какие, как они будут взаимодействовать.
- Проведите мысленный эксперимент: представьте, что нанимаете людей в новую компанию, а ваши текущие сотрудники — соискатели на эти вакансии. Кого и куда вы бы взяли? Распишите это.
- Остались ли сотрудники, которые не получили оффер в новую компанию по итогам эксперимента? Ну вот и не берите их туда. Оставьте там, где они уже приносят пользу, не мучайте людей.
- Остались ли в новой компании не закрытые позиции? Этих людей надо будет найти на рынке (несколько наблюдений про найм вам в помощь).
- Не забудьте поговорить с текущими сотрудниками, которые получили оффер в будущее, и предложить им эту работу не в мечтах, а в реальности. Надо ж ещё, чтобы они согласились с вами в это будущее идти ;)
Думаете, в больших структурах это не реально? Ещё как реально. Вот вам для вдохновения анимация структурных изменений в компании Autodesk (восемь тысяч сотрудников, более сотни разных продуктов) за четыре года (с 2007 по 2011). Кружочек — сотрудник. Связь — функциональное подчинение. Тот что ближе к центру — менеджер. Чем больше кружочек — тем больше подчинённых. Одна секунда видео — примерно одна неделя. У меня такое ощущение, что они только и делали, что менялись. А вы говорите, не реально..
Меня зовут Евгения Самойлов, я занимаюсь бизнес-трекингом стартапов, зрелых бизнесов и корпоративных команд. Контакт для связи:
я не до конца понял очем пост - если есть проблемы в организации производства продукта - есть различные метедологии и способы производства которые улучшают его производство - Например Scrum в IT сфере и не только
Очень крутой разбор — точно лайк