Реорганизация разработки часто начинается с мысли: «Сейчас пересоберём команды и поедем быстрее». Но стоит копнуть глубже и несколько раз задать вопрос «зачем?», как выясняется, что нужна вовсе не реорганизация, а быстрый результат — довести что‑то до продакшена, снять ограничения, вернуть управляемость.

В инженерных оргсистемах редко бывает одна универсальная проблема и почти всегда своя комбинация сложностей. Как в «задаче трёх тел» Лю Цысиня: если в гравитационном взаимодействии появляется третий объект, точного аналитического решения больше не существует. Пересборка команд — такая же задача многих тел, в которой задействованы сами команды, новые роли, стейкхолдеры, ожидания бизнеса, накопленные конфликты. У всех свои интересы и влияние на систему.

Меня зовут Александр Колесников, я технический директор направления «Управление персоналом» Х5 Tech. Десять лет разработчик и десять лет менеджер. В этой статье разбираю четыре кейса из разных проектов. Это обобщённые истории, не привязанные к конкретным людям и командам, но с сохранённой управленческой логикой. Каждый кейс показывает, какой ограничитель мешал ускорить поставку результата, и какие инструменты оказались рабочими.

Кейс 1: «Много тел, много дел»

У нас была большая команда, около ста человек, и сложный продукт с длинным релизным циклом до полутора лет. В некоторых специфичных отраслях такая продолжительность считается нормой, но в нашем случае за это время поменялся рынок и требования. В результате к моменту релиза не было понятно, что именно сделала команда и насколько это всё ещё нужно бизнесу.

На уровне ощущений казалось, что команда слишком большая и медленная. Внутри проекта было четыре группы разработки, четыре группы тестирования, перепутанные зоны ответственности и отсутствие фокуса. В такой конфигурации сложно сопоставить базу тестирования с конкретными командами разработки, и нужен был более чёткий фокус.

Инструмент: фокус на чём-то одном

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

Команды ядра поддерживают большие, сложные и критичные системы, как правило, специфичные для компании. Это те самые mission-critical системы, про которые принято говорить: «Солнце встаёт на востоке и заходит на западе? Всё работает? Не трогай!». Они не приносят прямой бизнес-ценности, но если их работа ломается, всё останавливается.

Платформенные команды создают инструменты: инфраструктуру, фреймворки, нотации, дизайн-системы. Они тоже не дают бизнес-результат напрямую, но делают оснастку, на основе которой эта ценность создаётся другими.

Enabler-команды — это группы сильных экспертов, которые решают сложные технологические задачи и дают другим командам новые возможности. Они приходят, закрывают узкое место и переходят к следующей проблеме.

Продуктовые или проектные команды составляют 80-90% всех команд, концентрируются на конкретных продуктах и поставляют бизнес-ценность.

Что сделали и что получили

Ключевой принцип в основе решения: одна команда — один фокус. Разные продукты и направления должны фокусироваться на своей зоне ответственности и делать это достаточно хорошо, чтобы снизить когнитивную нагрузку и избежать расфокуса. Бизнес-ценность поставляют одни команды, а большие, сложные, технические системы поддерживают другие. Вот что мы для этого сделали:

1. Сформировали несколько кросс-функциональных команд со сквозными зонами ответственности за доставку бизнес-ценности.

2. Отдельно выделили одну платформенную команду и одну Enabler, как техническую опору для остальных.

3. Развели зоны ответственности между командами. Чётко прописали, кто за что отвечает.

4. Сверху добавили классический Scrum для команд и некоторые элементы SAFe, в частности, PI-планирование для синхронизации приоритетов.

В итоге релизный цикл сократился с полутора лет до шести месяцев. Для конкретной отрасли это была адекватная частота: при более частых релизах партнёры и клиенты сами просили замедлиться.

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

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

По сути, ускорение произошло за счёт того, что у каждой команды появился чёткий фокус и понятная зона ответственности за результат.

Кейс № 2: «Блуждания»

Давайте представим другую ситуацию. У нас сто сотрудников, разделённых на десять-двенадцать продуктовых команд. И классический продуктовый подход: есть кросс‑функциональные команды, есть фокус и каждый понимает, чем нужно заниматься. Процессы тоже есть. А результата нет.

Команды как будто «бегают по кругу». Это похоже на бесконечное блуждание в тёмном космосе, как в повести «Блуждающая Земля» Лю Цысиня, когда цель путешествия где‑то далеко и кажется недостижимой.

Внутри слишком много реформ

Чтобы разобраться, почему всё работает именно так, посмотрим, как устроена предметная область именно этой команды:

• много заказчиков — не четыре, как в предыдущем кейсе, а около двенадцати;

• компания часто меняет курс: примерно раз в полтора месяца меняется направление и фокус, в среднем до восьми пересборок в год;

• бэклог постоянно перекраивается, и команды не успевают доводить задачи до результата;

• слишком маленькие команды: сто человек, разделённые на команды, по шесть-восемь человек в каждой. Стоит одному заболеть, второму уйти в отпуск или уволиться, и команда теряет половину мощности.

Как следствие, разработка не успевает за частотой изменений. Команды бросают недоделанные задачи и бегут к следующей инициативе. Люди выгорают и злятся: «Мы полгода работали, но ничего не сделали».

Инструмент: стабильная оргструктура для частых изменений

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

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

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

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

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

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

Проектная структура с проектным или продуктовым офисом снимает часть напряжения (функциональные руководители превращаются в руководителей ресурсных пулов: в основном нанимают, увольняют, мотивируют), но увеличивает управленческую сложность и число ролей. В нашей ситуации её пришлось бы слишком часто пересобирать, а это разрушило бы устойчивость системы.

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

Иногда компании приходят к ней через гибридные формы, когда в разных частях бизнеса функционируют разные модели. Со временем эволюция замыкается на кросс-функциональных командах с административным руководителем — тимлидом, менеджером проекта или продукта. В подчинении у него оказываются люди разных ролей. Разница остаётся только между монофункциональной и кросс-функциональной командой.

Иногда в роли руководителя бэкендеров и тестировщиков оказывается фронтендер или кто-то из продукта. Возможно, этот человек и не эксперт во всём, но он учится, а команда ему помогает. И если нет конфликта интересов, эта схема нормально работает.

Инструмент: скорректировать ответственность команд

Чтобы разобраться с ответственностью, мы смотрели на две вещи: размер команды (T) и размер продукта (P). Важно не количество людей, а то, как они соотносятся между собой.

Т = P — идеальный, можно сказать, «книжный» случай, когда размер команды равен размеру продукта. Одна команда отвечает за один продукт.

Т < Р — более сложный случай, когда размер команды меньше размера продукта. Тогда над одним продуктом вынуждены работать несколько команд. Типичный пример, маркетплейс.

Т > Р — обратная ситуация, когда команда больше продукта или сервиса. Чаще всего это задачи поддержки или мелкий багфикс. Такая команда напоминает гроздь винограда: висит красиво, но если заиграться с расширением зоны ответственности, легко свалиться в сценарий из кейса № 1, когда все делают всё и теряется фокус.

Что сделали и что получили

1. Мы осознанно ушли от продуктовой структуры в матрицу.

Сначала посмотрели на соотношение размеров команд и продуктов и увидели, что в разных частях системы разная картина: где-то T < P, а где-то T > P. В этих условиях классическая продуктовая структура перестала выдерживать частые изменения, требуя относительной стабильности в зоне ответственности и понятного вектора развития продукта. Проектная модель тоже не подходила, так как предполагала чёткое начало и окончание проекта.

Дополнительной проблемой были слишком маленькие команды: уход одного человека фактически останавливал работу. Так мы вышли на сбалансированную матрицу.

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

2. Проекты стали запускаться по мере завершения предыдущих, через сквозной бэклог.

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

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

3. Когда фаза активного роста закончилась и скорость изменений упала, мы вернулись к проектно‑продуктовой структуре, но уже с другим пониманием размеров команд и границ ответственности. Бизнес меняться не перестал, но делал это гораздо медленнее.

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

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

Кейс 3: «В лесу потемнело»

Вселенная — это «тёмный лес», в котором каждая цивилизация подобна затаившемуся охотнику. Поэтому, если раскроешься, будешь уничтожен из-за недоверия и борьбы за ресурсы. Отсылка к «тёмному лесу» из «Задачи трёх тел» здесь не случайна. Ситуация в кейсе была похожей: все боятся всего.

В разработке участвовало около двухсот человек. Компания агрессивно росла, прибавляя по сто человек в квартал, и так несколько кварталов подряд. Внутри были ресурсные пулы и деление на продукты, снаружи всё выглядело знакомо. Работы много — результата мало.

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

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

Инструмент: ответ на вопрос «Кто и за что отвечает?»

Проблема ответственности оказалась не новой, в такой команде мне уже доводилось работать раньше. Логичный шаг в таких ситуациях — использовать какую-нибудь рамку, например матрицу RACI: responsible, accountable, consult, inform. Но в ситуации, где уже идёт менеджерская война, это плохой инструмент. Объяснять долго, можно неправильно понять, и конфликт только усилится.

Мы пошли другим путём и сформулировали ответы на четыре вопроса:

• Что делаем?

• На какой технологии?

• Как организуем работу?

• Кто именно делает?

И договорились о границах:

• Если разговор идёт про «что делаем», то есть какие фичи, в каком порядке и зачем они бизнесу, — это зона ответственности продукта и бизнеса.

Когда кто-то из разработки начинал решать этот вопрос самостоятельно, его сразу отправляли в бизнес. Иначе он неизбежно наступит кому-то на хвост, и конфликт только усилится.

• Если обсуждали вопрос «на какой технологии», то это зона ответственности техлидов или архитекторов.

• Вопрос «как организовать работу», а именно процессы, договорённости, сроки, отнесли к проектным менеджерам.

• А ответы на вопрос «кто делает» — распределение задач внутри команды — отдали на откуп самой команде (тимлиду вместе с людьми).

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

Второе измерение: когда всё сложнее, чем кажется

Разложить ответственность по вопросам на одной плоскости оказалось мало. На одни и те же вопросы можно отвечать как с точки зрения техники, так и с точки зрения бизнеса. Поэтому мы добавили второе измерение — «техника/бизнес».

Если отвечаем на вопрос «как» с технической стороны — какие технологии, какая архитектура, — это зона ответственности техлида. Если на тот же вопрос, но уже с точки зрения бизнеса — как организуем работу, сроки, согласования, — это зона project‑/product‑менеджера.

Вопрос «что делаем» на бизнес‑уровне — зона продукта. Вопрос «кто делает» — какие именно люди и команды берут задачу — зона команды и тимлида.

Дальше мы стали пробовать комбинации: переопределяли роли, зоны ответственности и смотрели, как ведёт себя система. Таблица «как/что/кто» по осям «техника/бизнес» сразу подсветила типовые перегрузы.

Например, Technical Project Manager (TPM) — человек, который одновременно отвечает и за технику, и за организацию. Он может и проектом управлять, и код писать. Отличный специалист, но либо очень дорогой, либо хронически не высыпается.

На схеме ниже он занимает сразу две клетки по оси «как»: техническую (TechLead) и бизнесовую (Project Manager).

Или другой слой, в котором добавляются бизнес-, системные, дата- и продуктовые аналитики. Формально экспертизы становится больше, разные виды аналитики накладываются друг на друга, но процесс не движется. Потому что аналитик пытается ответить на бизнес-вопросы на уровне команды, а это в основном ограниченная перспектива. Так возникают дополнительные сложности, особенно если сам бизнес не до конца понимает, чего хочет.

Если не получилось разложить ответственность «по горизонтали» (например, из-за возможного конфликта ролей или людей, которые за эти роли отвечали), можно попробовать «по вертикали».

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

А если взять правый столбец — получается связка project + product. Роль, в целом, рабочая, но такой человек вынужден отвечать одновременно и за discovery (понимать, что делать), и за delivery (организовывать, как делать).

Дальше возникает соблазн позвать agile-коуча или скрам-мастера: «Они нам точно всё настроят».

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

Что сделали и что получили

Мы остановились на простом принципе: минимальный набор ролей должен закрывать весь «квадрат ответственности» (или его аналог, который вы нарисуете для своей компании). В итоге собрали кросс-функциональные команды с чёткими ограничениями. Для этого хватило набора ролей, состоящего из техлидов и владельцев продуктов. Остальное оказалось лишним.

Когда ответственность разложили по ролям, нашли ещё одну проблему, уже продуктовую. Раньше продукты пытались решать одни и те же задачи, из-за чего функциональность пересекалась. И с размытыми зонами ответственности это было неочевидно. Поэтому мы пересобрали несколько продуктов так, чтобы они работали на единую программу.

Кейс 4: «Всё вместе»

В разработке было около 80 человек и ещё более агрессивный рост: плюс 50 человек в месяц, то есть примерно 150 новых сотрудников в квартал. Новые люди приходили волнами, процессы и онбординг не успевали за ростом.

Внутри существовало несколько слабо связанных между собой команд специалистов. Фронтендеры отдельно, бэкендеры отдельно, тестировщики отдельно. Между ними метались менеджеры, пытаясь свести инициативы воедино. Левая рука не знала, что делает правая: команды параллельно решали похожие задачи, часто дублировали работу и мешали друг другу. Все делали всё и людей постоянно перекидывали между инициативами.

В этих условиях накопилось много легаси и неочевидных зависимостей. Любое изменение требовало долгих согласований и затрагивало несколько команд. Релизный цикл растягивался, результат получался размытым, а общее ощущение — «всё сложно».

По сути, здесь сошлись проблемы из трёх предыдущих кейсов. Как в первом — громоздкая оргструктура. Как во втором — пересекающиеся зоны ответственности. Как в третьем — раздробленность команд, внутренняя война и всё сопутствующее. Плюс к этому — высокий bus‑фактор и «тяжёлое» наследие.

При этом люди старались, много работали, куда‑то постоянно бежали. Важно зафиксировать: команда была умной и мотивированной. Проблема была не в людях, а в том, как организована система.

Инструмент: понять издержки легаси

Чтобы с этим кейсом можно было что-то сделать, сначала пришлось договориться о понятиях: что мы называем «легаси» и во что оно нам обходится.

Объясню через график, где по горизонтали — время, по вертикали — капасити команды.

Это потенциальная работа, которую может выполнить команда в идеальных условиях (ничего не мешало, никто не отвлекал). Как понимаете, в реальности так не бывает.

Сначала появляются транзакционные издержки из-за необходимости постоянно переключаться. Позвонил менеджер, кто-то написал в чат, потом ещё полчаса уходит, чтобы вспомнить, на чём остановились. Пусть эти издержки будут на графике в начале и в конце работы, но это идеальный случай.

Дальше появляются координационные издержки. Так как мы живём не в вакууме, нужно договариваться и синхронизироваться с другими командами. Созвон на 10 человек, потом на 20, потом на 30. Мы их неправильно поняли, они нас неправильно поняли. Поругались, помирились, выяснили, что всё равно с этим надо что-то делать, и забрали на эту активность часть рабочего поля.

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

Остаётся 20–30% на работу. Причём чем выше уровень роли — team lead, CTO — тем меньше у них этой зелёной зоны и больше остальных забот.

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

Инструмент: управление размером и конфигурацией команд

Когда стало видно, куда утекает капасити, встал следующий вопрос: как организовать команды так, чтобы при всех этих издержках они всё равно могли что‑то успевать?

На рабочий ресурс команды влияет её размер. Для оптимизации размера есть интуитивное правило 7 ± 2, Scrum Guide с рекомендацией до девяти человек или two‑pizza team, как у Безоса. Но то, что сработало у Безоса, в реальности часто не работает. Если один заболел, второй ушёл в отпуск, а третий уволился — команда уменьшилась вдвое, а работать всё равно надо.

Есть ещё один фактор, который часто игнорируют, — социальные ограничения. Здесь вспоминаем числа Данбара: 5, 15, 50, 150. Это не про менеджмент, а про то, как люди вообще способны выстраивать отношения.

Пять человек — это самый близкий круг. По сути, те же 7 ± 2. Иногда работа или стартап подменяют этот круг. Люди живут проектом, горят делом, работают днём и ночью. Но такой режим не вечен и почти всегда заканчивается выгоранием. Это следствие слишком маленьких, перегретых команд.

Следующий уровень — чуть большая социальная группа: близкие друзья, знакомые, коллеги. Эмпирически наиболее устойчивый размер группы или команды в больших компаниях — 10-15 человек, оптимально около 12. Если меньше, не хватает рук, особенно если много легаси. Если больше, резко растут издержки на коммуникацию и координацию.

Понятно, что все 12 человек не могут эффективно работать со всеми. Поэтому внутри такой команды условно «два кулака»: две небольшие фича-команды по 6-9 человек, работающие над одной предметной областью. Сегодня одна команда разгребает легаси, завтра — другая. В сложных системах такой подход у меня всегда давал результат лучше, чем в случае небольших команд по 6-7 человек.

Что сделали и что получили

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

В результате система начала развиваться в два-три раза быстрее. Где-то это было видно сразу, где-то сначала только на бумаге.

Отдельно мы сформулировали критерии, по которым считаем реформу успешной, и начали сознательно на них опираться:

• Есть чётко выделенные люди, отвечающие за продуктовую часть и за техническую — два крыла, которые дают баланс. Понятно, кто отвечает за «что», а кто за «как», и эти зоны ответственности не конкурируют между собой. 

• Есть защищённый продуктовый бэклог, по которому понятно, что и зачем мы делаем.

• Размер команд адекватен задаче — не слишком маленький и не слишком большой. И внутри — именно инженеры. Если аналитиков снова становится слишком много, значит, мы опять переплели роли.

• Команды понимают основы продуктовой работы: как принимаются решения, как проверяются гипотезы, где заканчивается их зона влияния и начинается бизнес.

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

Из этого кейса уносим рабочую комбинацию решений:

• чёткое разделение команд по типам: enabler, продуктовые, платформенные, команды ядра;

• понимание оптимальных размеров команд в зависимости от контекста;

• выбор оргструктуры под фазу бизнеса;

• набор ролей и их сочетания, без попытки закрыть всё одним человеком.

Выводы

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

Ниже несколько общих наблюдений, которые повторялись из кейса в кейс:

1. Сроки изменений. Изменения в инженерных оргсистемах занимают от трёх до десяти месяцев. Быстрее можно только при удачном стечении обстоятельств и при условии, что все участники действительно хотят меняться, а не просто пережить реформу.

2. Размер команд. Слишком маленькие команды почти всегда приводят к высокому bus-фактору и перегреву. В энтерпрайзе со временем всё равно выходят на команды порядка 10–15 человек — это устойчивый компромисс между гибкостью и надёжностью.

3. Фуллстеки — не панацея. Идея «набрать фуллстеков, и всё заработает» на практике упирается в то, что фуллстеков мало и они дорогие. Например, мы вполне можем работать с обычными инженерами. Я и сам такой.

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

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