На масштабе скорость чаще всего теряется не из‑за технологий, а из‑за размытых зон ответственности.

TL;DR

Если вы чувствуете, что раньше катили быстро, а теперь всё через согласования, чаще всего проблема не в том, что люди стали хуже.

Проблема в том, что:

  • команда отвечает за часть оргструктуры, а не за часть ценности;
  • границы ответственности размыты, а значит решения «не имеют владельца»;
  • зависимости множатся, и скорость уходит на передачи ответственности между командами;
  • RACI есть, но права на принятие решений — нет;
  • менеджеры расширяют команды, но не расширяют автономию в них.

Как это связано с законом Конвея. Архитектура и продуктовые стыки неизбежно повторяют структуру коммуникаций. Если команды людей собраны по функциям, система начинает «распадаться» на границы между ними: больше передач ответственности, больше согласований, больше интеграционной боли. Команды миссий (по потокам ценности) обычно делают обратное: подтягивают коммуникации и границы сервисов ближе к реальному value stream — и поэтому ускоряют процесс разработки.

Ниже — критерии, когда нужны команды миссий, и плейбук, как закреплять ответственность по доменам так, чтобы не вырастить бюрократию.

Две модели, которые часто путают

Команды людей — это когда структура строится вокруг функций, руководителей или навыков.

«Фронтенд-команда», «мобильная команда», «команда интеграций», «команда тестирования», «команда поддержки».

Это удобно для найма и развития экспертизы. Но у этой модели есть предсказуемая цена: скорость продукта начинает зависеть от количества стыков.

Команды миссий — это когда структура строится вокруг потока ценности и результата.

«Онбординг клиента», «платёжный поток», «доставка», «поиск и подбор», «партнёрские интеграции», «антифрод».

Это удобно для скорости и ответственности. Но у этой модели тоже есть цена: сложнее управлять экспертизой и стандартизацией.

На масштабе выигрывает не «правильная» модель, а модель, где ответственность закреплена однозначно, а стыки минимальны и прозрачны.

Где именно утекает скорость

Когда компания людей растёт, скорость чаще всего теряется в четырёх местах.

1. Дырявая зона ответственности

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

2. Решения не имеют права собственности

Никто не говорит «это моё решение и моя ответственность». Все говорят: «нужно согласовать». Согласования — это не зло. Зло — когда согласование заменяет ответственность.

3. Передача ответственности растет быстрее команды

Вы нанимаете людей, но вместе с этим растёт число стыков между командами — мест, где работу нужно передать, согласовать и дождаться очереди.

4. Количество взаимодействий растёт быстрее, чем численность.

На определённом размере вы внезапно обнаруживаете, что производительность команд — это среднее между ними, а не сумма их мощностей.

5. Метрики измеряют активность, а не поток

Команды начинают оптимизировать локальную эффективность. «Мы закрыли много задач», «мы всё сделали в срок». А поток ценности всё равно медленный, потому что самое дорогое — между командами.

Критерии: когда вам нужны команды миссий

Я не считаю, что нужно «всех перевести на продуктовые команды». Но есть критерии, при которых команды миссий дают системный выигрыш.

Вот простой набор (можно использовать как диагностику):

  1. Стоимость задержки высока — если неделя промедления стоит денег, клиентов или репутации — вам нужен владелец потока.
  2. Изменения регулярно пересекают 3+ команд — если почти любая фича — это «пингани ещё вот этих» — структура уже проигрывает.
  3. Сложно назвать одного человека, отвечающего за результат — если outcome размазан — скорость будет размазана тоже.
  4. Карта зависимостей плотнее, чем карта продукта — если архитектура и оргструктура разъехались — скорость утекает в синхронизацию.
  5. Много конфликтов при приоритизации — это часто не конфликт людей, а конфликт владельцев стримов.
  6. Онбординг новых людей долгий и болезненный — когда границы не ясны, новичок вынужден «узнавать систему через людей». А это масштабируется плохо.

Если у вас совпадают 3+ пункта — команды миссий стоит рассматривать всерьёз.

Пример из моего опыта

Было: фича отправка бизнес уведомлений требовала создание сервиса по отправке, доработку интеграционной платформы, клиентов, API и подключение поддержки. Между владельцами сервиса рассылки и платформой — пропасть: разные цели, собственный бэклог и приоритеты.

Стало: value stream команда с миссией по партнерской интеграции получила право владеть квотой на доработку необходимых систем и внедрять требуемые изменения без согласования, подключая партнеров через чёткие контракты и SLO.

Плейбук: как перейти к командам миссий без бюрократии

Важно: это не «реорганизация ради реорганизации». Это переупаковка ответственности вокруг ценности.

Шаг 0. Нарисуйте карту value streams

Не оргсхему. И не архитектурную схему. А карту потоков ценности: от события/потребности пользователя до измеримого результата.

Примеры:

  • «Регистрация → активация → первая ценность»
  • «Оплата → подтверждение → закрытие обязательств»
  • «Интеграция партнёра → тест → запуск → поддержка»

На этом шаге вы обычно видите две вещи:

  • где ваши реальные «продуктовые связи»;
  • где именно происходят самые дорогие передачи ответственности.

Артефакт: карта value streams.

Шаг 1. Определите домены владения потоками ценностей (а не команды)

Что такое домен. Домен — это устойчивая «зона ответственности» в продукте/платформе: набор правил, данных и решений, за которые отвечает один владелец (обычно команда). У домена есть границы: что входит внутрь, а что считается внешней зависимостью.

На карте потоков выделите домены, которые:

  • имеют относительно стабильные границы;
  • могут быть измерены outcome-метрикой;
  • допускают автономное принятие решений;
  • имеют понятные интерфейсы к соседям.

Что такое поток ценности. Поток ценности — это путь от потребности пользователя до измеримого результата. Это последовательность шагов, которые вместе дают ценность. Почти всегда поток проходит через несколько доменов.

Ключевое отличие: поток ценности отвечает на вопрос «как рождается ценность», а домен — «кто и за какую часть системы отвечает».

Поток ценности «Покупка в интернет‑магазине» выглядит так:

поиск товара → карточка → корзина → оформление → оплата → подтверждение → доставка → уведомления.

Этот один поток проходит через несколько доменов, например: каталог, корзина и оформление платежи, доставка и уведомления.

И обратная сторона: один домен (например, Платежи) участвует сразу в нескольких потоках ценности — покупка, возврат, подписка.

Суть: сначала домены, потом — команды. Иначе вы будете подгонять домен под текущих людей.

Артефакт: ownership-карта доменов.

Шаг 2. Зафиксируйте права на принятие решений простым способом

Большая ошибка — начинать с того, что всем надо написать RACI на всё.

Правильнее — ограничиться тем, что реально тормозит:

  • приоритизация изменений;
  • изменения в интерфейсах;
  • инциденты и SLO;
  • архитектурные решения, влияющие на другие команды.

Вам нужен не «комитет». Вам нужен минимальный набор правил:

  • что команда решает сама;
  • что согласует;
  • что эскалирует;
  • и по каким триггерам.

Артефакт: владелец/RACI только для стыков.

Шаг 3. Соберите команды вокруг миссий и результата

Теперь можно «пересаживать людей».

Принцип простой:

  • команда должна владеть основным потоком end-to-end настолько, насколько это реалистично;
  • зависимости — допустимы, но должны быть явно перечислены;
  • «кто принимает решение» и «кто отвечает за результат» — один и тот же контур.

Здесь полезно держать правило:

Если команда не может выпустить ценность без двух внешних очередей — это не владение доменом. Это координация.

Результат обычно выражается в сокращении: времени на интеграцию, количества повторных согласований, числа инцидентов в зоне между командами.

Шаг 4. Сверьте количество людей под управлением с нормой

Скорость часто теряется не потому, что мало менеджеров, а потому что вырос управленческий охват, а автономия — нет.

Если руководитель ведёт 12–15 человек, но решения принимаются всё равно наверху — система начинает буксовать.

Проверьте:

  • где руководитель является «шлюзом» решений;
  • где команда ждёт «подтверждения»;
  • где нет понятного владельца приоритета.

Артефакт: карта подчиненных (по доменам, а не по отделам).

Шаг 5. Введите простые метрики оргскорости

Оргдизайн не проверяется лозунгами. Он проверяется метриками. Вот минимальный набор из 5 метрик, которые можно начать измерять уже завтра без сложных систем:

  • время от идеи до выпуска — сколько проходит от решения начинать делать до результата в продукте;
  • время выполнения задачи внутри команды — сколько задача нахолится в работе;
  • доля инициатив, где нужно 3+ команд — чем выше, тем больше трения;
  • инциденты на стыках, где неясно, кто отвечает» и их доля;
  • время восстановления в инцидентах, где задействованы несколько доменов.

Замерьте «до», проведите изменения, замерьте «после». Обычно достаточно окна 2–3 недели. Если метрики не улучшились — не надо героически защищать реорганизацию. Нужно пересобрать границы ответственности и правила взаимодействия на стыках.

Типовые ошибки (почти всегда повторяются)

  1. Пересобрали команды, но не выделили ответственных. Теперь это команда миссии, но приоритеты всё равно задают другие люди.
  2. Сделали RACI, чтобы было. Оформили RACI в вики в качестве документа, но ответственность за домен — это поведение. Если принятие решений не изменилось, документ не ускорит.
  3. Увеличили автономию без контрактов. Автономия без интерфейсов превращается в хаос. Нужны API/события, SLO и правила изменения контрактов.
  4. Нарезали миссий слишком мелко. Получились микрокоманды, которые снова зависят от всех.
  5. Не решили вопрос кто владеет платформенными слоями. Команды миссий ускоряют продукт. Но если платформенный слой не имеет ясного владельца и плана развития — скорость упирается в него.
  6. Смешали роли и уровни ответственности. Если у вас владельцы без права говорить нет — это не владельцы.

Финальный вывод

Команды миссий — это не про модное словосочетание. Это про то, чтобы скорость была свойством системы, а не героизмом отдельных людей.

Вопрос к вам: как вы закрепляете ответственность по доменам, чтобы не выросла бюрократия?

Денисов Денис | Мой телеграмм канал