Сначала команды, потом код: как оргдизайн меняет архитектуру

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

Возьмём классический пример. Есть команды клиентской разработки (фронтенд и мобильная) и бэкенд. В такой оргструктуре зона ответственности между ними делится по границе бэкенд-API и клиентских SDK. Клиентские команды, стремясь минимизировать свои зависимости и ускорить TTM, делают себе собственные прокси и «лёгкие» бэкенды. А бэкенд-команды, не имея контроля над клиентским кодом, стараются управлять всем со своего слоя. В результате возникает дублирование логики и размытие зон ответственности: каждая команда «делает своё», а итоговая система становится «слоистой» и перегруженной.

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

В итоге, если мы хотим сделать действительно крутую архитектуру, важно посмотреть на то, как устроены наши команды. И начать стоит не с нового стека технологий, а с «обратного манёвра Конвея».