Меня зовут Игорь Гранщиков, я руководитель разработки Авито Недвижимости. Эта статья о паттернах организационного дизайна основана на моём докладе на Saint TeamLead Conf 2025. Там, где что-то взято из книги, фреймворка или методологии, будут явные ссылки. Всё остальное — моё личное мнение, основанное на опыте. Каждый из этих паттернов я так или иначе пробовал в разное время и в разных компаниях: что-то приживалось надолго, а от чего-то приходилось довольно быстро отказываться.
Что в статье:
Что такое оргдизайн и зачем им заниматься
Организационный дизайн — это проектирование структуры команд, их зон ответственности и способов взаимодействия между ними. По сути оргдизайн — это кто за что отвечает, кто с кем общается и как принимаются решения.
Технические решения создают люди. В процессе создания этих решений люди общаются, и, если организационная структура не совпадает со структурой коммуникаций, люди начинают «протаптывать тропы» в обход формальной организации.
Почему это важно?
По теории когнитивной нагрузки Джона Суэллера, существует три типа когнитивной нагрузки:
Внутренняя (intrinsic) — вызвана сложностью самой задачи. На неё нельзя никак повлиять.
Полезная (germane) — связана с обучением и построением ментальных моделей. Учиться необходимо.
Внешняя (extraneous) — возникает из-за избыточных коммуникаций и переключения контекста.
Поскольку когнитивные способности людей ограничены, задача организационного дизайна — минимизировать именно внешнюю когнитивную нагрузку. На масштабе это может означать перенаправление сотен и тысяч человеко-часов с напрасного расходования на прямое создание ценности.
Это хорошая модель, и Team Topologies Скелтона и Паиса, пожалуй, самая актуальная на сегодня книга, которая на ней построена. Но она описывает идеальный мир: продукт понятен и стабильно развивается, ресурсов достаточно, и единственное, о чём нужно думать — это архитектура коммуникаций. В реальности при проектировании организации приходится учитывать ещё как минимум два фактора.
Состояние продукта. Одно дело — масштабировать стабильный продукт с понятной архитектурой. Другое — когда product-market fit ещё не найден и направление меняется каждый спринт. В первом случае мы можем позволить себе проектировать команды под архитектуру. Во втором — любая фиксация команд по компонентам создаст очереди и станет тормозом.
Ограничения бизнеса. Иногда компания растёт и нанимает — и задача в том, чтобы новые команды давали пропорциональный прирост. А иногда нужно делать больше с тем, что есть — do more with less — и тогда платформенная команда на каждый домен становится роскошью, которую мы не можем себе позволить.
1. Обратный манёвр Конвея
Закон Конвея, сформулированный Мелвином Конвеем ещё в 1960-х годах, гласит: организации производят системы, архитектура которых копирует структуру коммуникаций в организации. Проще говоря — архитектура повторяет оргструктуру.
Обратный манёвр Конвея (Inverse Conway Maneuver) переворачивает эту зависимость: мы сначала проектируем целевую архитектуру, а затем выстраиваем организационную структуру так, чтобы она ей соответствовала. Термин был предложен Джонни Леруа и Мэттом Саймонсом из ThoughtWorks в 2010 году.
Как это работает на практике
Допустим, у вас есть одна техническая система и три команды, которые в неё контрибьютят. Каждая команда вынуждена координировать действия с двумя другими — количество коммуникаций растёт нелинейно. Архитектура, следуя закону Конвея, скопирует этот хаос — получится монолит или распределённый монолит.
Применяя обратный манёвр Конвея, вы начинаете с архитектуры: разбиваете систему на три изолированных домена, а затем назначаете по одной автономной команде на каждый домен. Так реализуются сразу два важных принципа: loose coupling/high cohesion (слабая связанность/высокая связность) и single responsibility (единая ответственность).
Важно: проектирование оргструктуры при этом подходе очень напоминает проектирование микросервисной архитектуры. Если у вас хорошая архитектура и вы придерживаетесь обратного манёвра Конвея, оргструктура тоже получится красивой. «Доменами» здесь могут быть не только сервисы, но и пакеты, экраны или любые другие изолируемые компоненты систем.
Когда применять
Бизнес настроен на рост, продукт стабилен и нужно масштабировать команды.
Вы чувствуете, что добавление новых команд не даёт пропорционального роста производительности.
Архитектура и оргструктура давно не пересматривались совместно.
Примеры из практики
Amazon в начале 2000-х столкнулся с тем, что монолитная архитектура и функциональные силосы тормозят инновации. Джефф Безос издал знаменитый «API mandate» — все команды обязаны предоставлять свои данные и функциональность через сервисные интерфейсы, а других форм межпроцессного взаимодействия быть не должно. Это радикальное архитектурное решение повлекло за собой реструктуризацию в маленькие автономные «two-pizza teams».
Netflix при создании единой платформы для обсервабилити провёл реорганизацию команд до начала технической реализации. Руководство осознало, что текущая структура, где отдельные команды поддерживали отдельные инструменты (логи, метрики, трейсинг), не позволяет создать единый интегрированный продукт. Команды реорганизовали по слоям нового продукта — и только потом начали строить архитектуру.
Что почитать
Martin Fowler — Conway's Law — классическое описание закона и обратного маневра.
Matthew Skelton, Manuel Pais — «Team Topologies» (2019) — must-read по теме организационного дизайна. Книга на английском языке.
Хабр — Закон Конвея — обзор на русском языке.
2. Платформенные решения (X-as-a-Service)
Бывают случаи, когда какой-то сервис или домен нужен сразу нескольким командам. Если позволить всем командам вносить правки в чужой домен, мы получим тот самый нелинейный рост коммуникаций и разрушение границ ответственности.
Решение: по принципам чистой архитектуры добавление новых фич должно происходить через расширение, а не через переписывание. Общий домен закрывается фасадом (например, API), и команда, которая за него отвечает, объявляется платформенной командой. Остальные команды работают с этим доменом как с сервисом — x-as-a-Service.
Типы команд
Компонентные (продуктовые) команды — доставляют конечную пользовательскую ценность. В терминологии Team Topologies называются stream-aligned teams.
Платформенные команды — предоставляют свои решения другим командам as-a-Service, скрывая сложность за контрактом (API, SDK, инфраструктура).
Ключевое: взаимодействие между командами идёт не через личные коммуникации, а через технический контракт. Это кардинально снижает внешнюю когнитивную нагрузку.
Когда применять
Несколько команд вынуждены работать с одним и тем же доменом или компонентом.
Вы хотите дать командам автономию, но есть shared-зависимости.
При масштабировании, когда количество команд растёт и нужно контролировать точки взаимодействия.
Примеры из практики
Spotify использует концепцию платформенных команд для предоставления инфраструктуры (Backstage — их внутренний портал для разработчиков — вырос в open-source проект).
Что почитать
Matthew Skelton, Manuel Pais — «Team Topologies» (2019) — детальное описание четырёх типов команд и трёх режимов взаимодействия.
Team Topologies — сайт проекта — статьи, видео, шаблоны.
3. Компактные команды
При прочих равных, компактные команды (3—5 человек) более производительны, чем большие (8—12 человек). Это объясняется эффектом Рингельмана — тенденцией к снижению индивидуальной продуктивности по мере роста численности группы.
Этот эффект был обнаружен ещё в начале XX века в экспериментах по перетягиванию каната: когда в команде 8 человек, каждый прикладывает примерно половину от своего максимального усилия. В командах разработки действует та же закономерность — чем компактнее команда, тем выше вклад каждого.
Поэтому если у вас команда из 9 человек, её может быть эффективнее разделить на 3 команды по 3 человека — суммарная производительность будет выше.
Нюанс: откуда взять менеджеров
Если на одну команду из 9 человек нужен один менеджер, то на три команды по 3 — формально нужны три менеджера. Это не оптимизация, а наоборот. Поэтому компактные команды работают только в связке с распределённым менеджментом (см. следующий паттерн).
Когда применять
Бизнес в режиме «оптимизации» — нужно делать больше с теми же ресурсами.
Команды из 7—10 человек можно безболезненно разделить.
Есть возможность делегировать менеджерские функции в команды.
Примеры из практики
Amazon формализовал этот подход в знаменитом правиле «двух пицц» — команда не должна быть больше, чем можно накормить двумя пиццами (5—10 человек). Но дело не только в размере: каждая такая команда обладает полной автономией и отвечает за свой компонент от идеи до эксплуатации.
Что почитать
Martin Fowler — Two Pizza Team — о концепции и её ограничениях.
AWS Executive Insights — Amazon's Two-Pizza Teams — как это работает в Amazon.
Хабр — Эффект Рингельмана — подробный разбор на русском языке.
4. Shared-функции (гибридные команды)
Если полностью функциональные команды (где все поделены по специальностям: бэкенд, фронтенд, iOS, QA, DevOps) — это скорее жест отчаяния, то вынос некоторых функций в shared-команды — это разумный компромисс.
Идея: основа команд остаётся привязанной к доменам (принцип единой ответственности сохраняется), но отдельные функции выносятся в сервисные команды, которые обслуживают несколько продуктовых команд.
Какие функции чаще всего выносят
DevOps — самый распространённый вариант. Команда предоставляет CI/CD as-a-Service, а продуктовые команды пользуются этим как сервисом. Отлично сочетается с компонентными командами.
QA — частая практика. Помимо оптимизации, создаётся quality gate — своеобразный противовес разработке. QA-команда может обслуживать несколько продуктовых команд, обеспечивая единые стандарты качества.
Мобильная разработка — встречается реже. Обоснование: у мобильных разработчиков своя кодовая база, свой релизный цикл, и они стыкуются с остальной разработкой через API. Команда при этом становится сервисной, выполняя заказы продуктовых команд.
Когда применять
Бизнес в режиме оптимизации — нет возможности нанять специалиста в каждую команду.
Продукт стабильный, и можно предсказуемо планировать загрузку shared-функций.
Важно сохранить компонентную структуру, но при этом экономить на дублировании ролей.
Что почитать
Henrik Kniberg, Anders Ivarsson — Scaling Agile @ Spotify — оригинальный whitepaper о модели Spotify.
Atlassian — The Spotify Model — обзор модели и адаптация.
5. Распределённый менеджмент
Когда вы делаете компактные команды, возникает вопрос: откуда взять менеджеров? Ответ — делегировать функции менеджера в команды. Я назвал этот подход распределённый менеджмент.
У менеджера можно выделить четыре основные зоны ответственности:
Люди — пипл-менеджмент, развитие, мотивация.
Домен — бизнес-экспертиза, понимание продукта.
Техника и архитектура — технические решения, архитектурное видение.
-
Деливери — процессы, планирование, обеспечение потока.
Распределённый менеджмент
Каждую из этих зон можно делегировать: домен — в продакта или бизнес-аналитика, процессы — в Agile Coach или Scrum Master, технику — в архитектора или Head of (QA, Mobile, Backend и т.д.). Что точно не получится просто так делегировать — это управление людьми.
Делегирование может происходить одним из двух способов:
Неформальное — опора на лидеров внутри команд. Это создаёт возможности для роста людей: получая дополнительную ответственность, они прокачиваются и двигаются по грейдам. Грейдинг «на вырост» ещё и дешевле, что актуально при оптимизации.
Формальное — выделение специальных ролей (архитектор, Agile Coach), которые работают с несколькими командами. Такие роли формируют тягу к стандартизации — им удобнее, когда все команды устроены одинаково.
Дополнительный эффект делегирования можно достигнуть при помощи стандартизации процессов в командах. Однако, следует помнить, что стандартизация ограничивает нестандартные решения людей, через которые они могут проявлять свой профессионализм, тем самым создавая “навес” над возможностями роста. Например, архитектор забирает у инженеров возможность поархитектурить.
Стандартизация хорошо подходит для стабильной среды с низкой неопределённостью, но чем выше уровень неопределенности, тем больше ставку нужно делать на профессионализм. Он отлично подходит, когда нужны креативные решения и важно максимально использовать талант людей. Но требует более высокого уровня зрелости команды.
Когда применять
У вас компактные команды и не хватает менеджеров на каждую.
Нужно «растянуть» менеджера на большее число людей без потери качества управления.
Осознанно выбираете баланс между стандартизацией и автономией.
Ограничения: число Данбара
Менеджеры тоже люди, и их когнитивные способности точно так же ограничены. Числа социальных связей, которые стоит держать в голове при выборе размера команд и количества подчиненных у менеджера:
5 — лучшие друзья (ближайший круг доверия).
15 — сильное доверие.
50 — взаимное доверие. Это реальный верхний предел подчинённых у менеджера, если он занимается только пипл-менеджментом.
150 — число Данбара. Можем запомнить способности — но это уже фактическое отсутствие полноценного управления.
В западных Big Tech компаниях, где менеджеры отвечают только за people management, размер команды одного менеджера обычно 35—40 человек.
Что почитать
Henry Mintzberg — «Structure in Fives: Designing Effective Organizations» (2019) — классика по организационному дизайну.
Thomas Schmidt — A review of Structure in Fives; Designing Effective Organizations — краткое содержание основных мыслей книги.
Хабр — Карьерный рост из senior: кто такой staff-инженер — про старшие грейды в разработке.
6. Feature Teams
Компонентные команды хорошо работают, когда направление стабильно. Но если продукт ещё ищет свой product-market fit и направление меняется каждый спринт, привязка к компонентам создаёт очереди: самая загруженная команда становится бутылочным горлышком для всех.
Feature teams — команды, которые универсальны в квалификации и могут работать с любыми компонентами системы. Вместо того, чтобы каждая команда отвечала за свой компонент, все команды работают над единым бэклогом, забирая самые приоритетные задачи.
Компромисс: мы жертвуем когнитивной нагрузкой от переключения между компонентами и принципом единой ответственности. Зато получаем максимальную гибкость и скорость доставки.
Starmap и Heatmap для проектирования команд
Чтобы собрать эффективные feature teams, полезно использовать инструменты starmap и heatmap из фреймворка LeSS. Starmap показывает, какие компетенции есть в команде, а heatmap — какие компетенции нужны для достижения целей. Их «дифф» показывает, что нужно нарастить.
Визуально заполненный Starmap + Heatmap могут выглядеть примерно так:
У меня в канале есть чуть более подробный пост с шаблоном инструмента – если захочется глубже погрузиться в тему.
Когда применять
Стартап или новый продукт, который часто меняет направление.
Несколько команд работают над одним продуктом без устоявшейся архитектуры.
Product-market fit пока не найден.
Нужно максимально быстро проверять гипотезы.
Переход к компонентным командам
Важный момент: feature teams — это не навсегда. Когда product-market fit найден и динамика среды стабилизировалась, команды можно «зафиксировать» — просто закрепив за каждой определённый компонент. Так feature teams трансформируются в компонентные команды.
Примеры из практики
Slack начинался как игровой стартап, разрабатывавший MMORPG. Когда стало ясно, что игра не взлетит, команда перефокусировалась на внутренний инструмент общения — так родился самый популярный корпоративный мессенджер в мире. В условиях такого пивота фиксированные компонентные команды были бы слишком инертны.
Что почитать
LeSS — Feature Teams — подробное описание на сайте фреймворка.
LeSS — Introduction — обзор фреймворка Large Scale Scrum на русском языке.
TechCrunch — The Slack Origin Story — история пивота Slack.
7. Управление Span of Control
Span of Control — количество подчинённых у одного менеджера. Есть два основных подхода:
Широкий — менеджеру подчинено много людей. Плюс: проще перераспределять работу, меньше уровней иерархии, управляющие сигналы доходят быстрее. Минус: менее глубокая работа с каждым человеком.
Узкий — менеджеру подчинено мало людей. Плюс: можно сильнее работать с людьми, лучше подходит для высокой неопределённости. Минус: нужны дополнительные уровни менеджмента, которые порождают инерционность управления (управляющие сигналы сверху-вниз медленее доходят до линии выполнения).
Когда какой выбирать
В условиях частой смены направления (пивот) предпочтительнее выглядит широкий span of control — чтобы управляющие сигналы доходили без задержек. При необходимости его можно усилить распределённым менеджментом (Agile Coach, архитектор).
В условиях стабильности более подходит узкий span of control — он позволяет глубже работать с людьми и лучше понимать контекст каждой команды.
8. Изоляция нового от старого
Когда внутри большой компании со сложившейся системой появляется новый продукт, который взаимодействует со старой системой, есть риск, что старое «задушит» новое. Команды начнут коммуницировать, системы срастутся, и новый продукт едва появившись станет частью легаси.
Решение: провести водораздел между новым и старым на уровне архитектуры и оргструктуры. Старая система закрывается фасадом (API), который поддерживает границу между мирами. Новые команды и системы взаимодействуют только с этим фасадом.
По мере выноса компонентов из «старого мира» в «новый», команды тоже переходят на другую сторону API. Старая система постепенно уменьшается, а новая растёт.
Этот подход имеет прямой аналог в микросервисной архитектуре — паттерн Strangler Fig (инжир-душитель). Он описывает постепенную замену монолита через создание фасада, за которым старые компоненты один за другим заменяются новыми.
Когда применять
Компания запускает новый продукт, который зависит от старой системы.
Распиливание монолита — нужно изолировать новые микросервисы от легаси.
Post-merger integration — объединение технических систем после слияния/поглощения компаний.
Любая ситуация, когда «новое» и «старое» вынуждены сосуществовать.
Примеры из практики
Классический пример Strangler Fig — множество компаний, распиливавших монолиты: постепенно вынося функциональность за API-фасад и заменяя компоненты один за другим. Uber описывает подобный подход в своём блоге о переходе на микросервисную архитектуру.
Что почитать
Martin Fowler — Strangler Fig Application — описание паттерна.
Uber Engineering — Domain Oriented Microservice Architecture — опыт Uber.
9. Повторение структуры бизнеса
Бывает так, что при проектировании будущей архитектуры недостаточно данных — «туман войны». В этом случае можно начать с самого простого: выделить домены на основании того, как устроен бизнес, и от этого проектировать команды разработки.
Если есть финансовый отдел, отдел продаж и логистика — делаете 3 домена и 3 команды. Структура бизнеса — это уже готовая эвристика для первого приближения.
Когда применять
Новый бизнес или трансформация, когда непонятно, какой будет целевая архитектура.
Нужно быстро начать работу несколькими командами.
Как «шаг ноль» перед более осмысленным проектированием.
Важно
Это именно отправная точка, а не финальное решение. После того как команды начнут работать и появится понимание архитектуры, структуру нужно пересмотреть, применив более точные паттерны — обратный маневр Конвея, платформенные решения и т.д.
Что почитать
Vaughn Vernon — «Implementing Domain-Driven Design» (2013) — практические аспекты DDD.
Как всё это сочетается
Описанные паттерны — не взаимоисключающие. В одной компании одновременно могут существовать разные состояния бизнеса, а значит и разные комбинации паттернов. Вот несколько типичных комбинаций:
Рост + стабильный продукт (масштабирование): обратный манёвр Конвея + платформенные решения + Team Topologies.
Фиксированные ресурсы + стабильный продукт (оптимизация): shared-функции + компактные команды + распределённый менеджмент + стандартизация (осторожно).
Фиксированные ресурсы + частая смена направления (пивот): feature teams + широкий span of control + LeSS.
Рост + изменчивая среда (трансформация): изоляция нового от старого + повторение структуры бизнеса.
Вместо заключения
В начале статьи я сказал, что в идеальном мире достаточно думать только о когнитивной нагрузке. Но в реальном мире есть продукт, который может быть стабильным или меняться каждый спринт, и есть бизнес, который может расти или требовать делать больше с тем, что есть. Именно поэтому здесь нет одного правильного паттерна — есть набор компромиссов.
Причём эти факторы не статичны. За оптимизацией рано или поздно наступает рост. Пивот находит свой product-market fit и переходит в масштабирование. Больше того, в одной компании одновременно могут сосуществовать разные состояния: один продукт стабильно масштабируется, а рядом команда пилотирует новое направление. Паттерны, которые работают для первого, будут мешать второму.
Поэтому к паттернам правильнее относиться как к ящику с инструментами. Достали один, попробовали. Заработало — оставили. Не заработало — доставать следующий, не жалея признать эксперимент неудачным. Единственное, о чём стоит помнить при любом выборе — какое состояние будет следующим, и не создаёте ли вы структуру, которую потом придётся героически переделывать.
За время работы с разными командами я убедился в одном: не существует оргструктуры, которая будет правильной навсегда. Но существует навык — замечать момент, когда текущая структура начинает мешать, и иметь под рукой инструменты, чтобы это починить. Надеюсь, эта статья добавит вам несколько таких инструментов.