Организации проектируют системы, которые копируют структуру коммуникаций в этой организации
Еще в 1967м году программист Мелвин Конвей сформулировал эту идею, которую впоследствии не раз и не два подтверждали. На той же Википедии есть ссылки на исследования MIT и Гарварда, подтверждающие это явление.
Что это значит для мира ПО?
Сначала стоит вспомнить о том, что есть еще и такое явление как оптимальный размер команды. Группы людей выше 10-15 человек тяготеют к разбиению - формальному или не очень, но это в итоге заканчивается в ограниченных зонах ответственности.
Именно поэтому небольшие стартапы с разделением по функциям - разработка, маркетинг, продажи - так эффективны. Еще есть фактор "тяжелого наследия", но примеры "корпоративных стартапов" говорят о том, что этот фактор в действительности преувеличен.
Любая новая функциональность программного продукта - это вещь, которую нужно поддерживать и обслуживать.
И либо это падает на плечи изначальной команды, либо выделяется в отдельную команду, которая тут же обрастает барьерами. Интересно, что с точки зрения психологии это делается даже не из каких-то лучших побуждений в сторону продукта, а для сплочения самой команды. "Мы-то знаем, как надо" делается не потому что люди хотят сделать, как лучше, а ради того, чтобы это "мы", собственно, и появилось. Строгая типизация в Java появилась столько не для того, чтобы точно понимать, чем оперируют люди, а для того, чтобы эти люди могли быстрее общаться друг с другом. Именно поэтому ее система типов так избыточно выразительна - да, этот код писать медленнее, потому что объективно там много букв, но это линейная сложность, а взаимодействие с другими командами, которые будут использовать этот код - это сложность O(n), и каждая новая команда, которая приходит смотреть код, замедляет оригинальную. Настолько, что рано или поздно проще сделать новый продукт, потому что местячковые решения в предыдущем сделали скорость фактической разработки нулевой.
Есть технологические решения, которые позволяют это обойти - тот же Go изначально создавался для того, чтобы можно было бесконечно горизонтально масштабировать разработку. Тысяча человек могла делать отдельные компоненты системы, и результатом их деятельности становились сущности настолько простые, что интегрировать их можно было почти не включая мозг. Потом, конечно, все влюбились в язык за простоту, и споткнулись о нее же, но это совсем другая история.
Барьеры, которые появляются - не только идейные, но еще и программные. Интерфейсы для коммуникации между отдельными частями, архитектура, логика для валидации этого всего... Даже если считать, что поддержание этого всего стоит 3-5% времени команды - со временем количество связанных проектов растет настолько, что команды вынуждены большую часть времени обслуживать собственные убеждения и границы, а не делать что-то в рамках собственных целей.
Микросервисный (да и микрофронтэндный) подход появился именно поэтому - чтобы уменьшить эти проценты на взаимодействие между командами, чтобы на отстаивание личных границ тратилось не 60%, а 20-30% всего времени. Kubernetes, AWS, Azure - это, как ни странно, средства оптимизации не тулинга для деплоя и процессов, а взаимодействия между командами. "системы следуют за организационной структурой", и Google, создавая k8s, делала это не из-за запроса на легкое и быстрое масштабирование продуктов - для этого было уже много решений, таких как Ansible, Chef, и даже OpenStack, нет. Она пыталась сделать барьеры между командами шаблонными, teamwork-as-a-code.
Конечно, это нигде особо не заявлялось, и не факт что даже понималось всеми, кто проектировал эту систему, но в действительности эффектом от этих инструментов в первую очередь был этот.
Что же это значит на практике?
Есть разные программные решения. Одни направлены на коллективную работу, и в них уже заложены механизмы, позволяющие физически работать с большим уровнем автономии, а другие - наоборот, нацелены на индивидуалистов. Первые медленные, потому что заставляют делать решения "на будущее" и писать избыточно, выражая не конечные мысли, а сам процесс мышления - чтобы другой человек, придя работать с проектом, не был озадачен. Да, в программном коде есть решения, которые позволяют компенсировать закон Конвея. Вторые этим не обременены, и для большинства ощущаются как "глоток свежего воздуха". Но чем больше людей начинают этот продукт любить - тем больше он вынужден под их же запросами внедрять этой "защиты от Конвея".
Люди, которые занимались фронтэндом последние лет 5, могли наглядно увидеть этот эффект: после Angular с кучей навязанных правил и жесткой структуры React казался глотком свежего воздуха, потому что не навязывал правил. Вокруг React выросло сообщество и набор правил для работы между людьми. Потом был vue, который в третьей версии тоже слегка забюрократился, теперь - svelte.
Так а что делать-то?
В целом - это открытый вопрос, но явные практики становятся видны.
Те же самые изначальные паттерны программирования от Gang of Four служили именно для того, чтобы границы имели определенные правила и были оптимальны с точки зрения работы с ними.
Отдельные инфраструктурные и платформенные подразделения в компаниях снимают головную боль с отдельных команд, позволяя отдельной "структурной единице" делать больше.
Однозначного ответа нет, но неосознанно почти любой engineering manager начинает в какой-то момент заниматься именно этими границами, проектированием будущего и вещами, которые отдельным людям в команде могут казаться бесполезными - если не вредными.