Блог Agile Организации

Кейс проектирования продуктовой группы

В этой статье я описываю универсальный алгоритм проектирования продуктовой группы, который был применён и проверен на практике в рамках реального кейса с одним из моих клиентов, и опирается на идеи, изложенные в книгах Creating Agile Organizations и "Дизайн Agile-организаций".

Продуктовая группа

В этой секции мы вводим два ключевых понятия, на которых строится дальнейший организационный дизайн: продуктовая группа и продуктовая семья.
Продуктовая группа представляет собой формальную организационную единицу, которая отвечает за создание, развитие и финансовый результат продуктовой семьи.
Продуктовая семья — это группа взаимосвязанных продуктов, объединённых общей архитектурой и/или общими функциональными элементами и развиваемых на основе единой продуктовой платформы для удовлетворения схожих потребностей клиентов или рыночных сегментов.
Концепция продуктовой группы опирается на многомерный организационный дизайн Р. Акоффа (Re-Creating the Corporation). В многомерной организации на каждом уровне структуры присутствуют три типа юнитов:
  • input units — обеспечивают другие подразделения ресурсами;
  • output units — создают продукт;
  • market units — работают с клиентами и рынком.
При этом значимость каждого юнита определяется стратегическим фокусом.
Структура продуктовой группы включает:
  • кросс-функциональные команды как output-юниты, создающие продукт end-to-end;
  • общие market- и input-функции внутри группы, например маркетинг, digital-продажи или платформенные сервисы;
  • Product Group Leadership — Владельца Продукта и лидеров юнита, определяющих направление развития и создающих условия для работы группы.

Прототип продуктовой группы

Таким образом, продуктовая группа — это полуавтономный многомерный юнит, объединяющий функции создания продукта, рыночного взаимодействия и внутренних сервисов. Это позволяет оптимизировать принятие решений, снизить транзакционные издержки и ускорить поток ценности end-to-end.

Принципы проектирования

При проектировании структуры продуктовой группы мы будем опираться на следующие принципы:
  • Дизайн, основанный на способностях. Организационный дизайн строится от необходимых способностей: сначала определяем, что организация должна уметь, а затем создаём структуру, роли и процессы, которые делают эти способности реальными и устойчивыми.
  • От целого к частям. Организационный дизайн начинается с целой системы, её миссии и роли в бизнесе, а не с отдельных функций. Сначала — замысел и архитектура целого, затем — наполнение элементами.
  • Баланс масштаба и гибкости. Организационный дизайн должен сочетать преимущества децентрализации (скорость, адаптивность) и централизации (стандарты, эффективность, масштаб). Задача лидеров — найти точку равновесия между автономией продуктовых групп и общесистемными эффектами масштаба.
  • Минимизация транзакционных расходов. Структура должна снижать издержки взаимодействия — координации, переключения, согласований и адаптации. Хороший дизайн размещает функции там, где стоимость их взаимодействия минимальна, а поток ценности наиболее устойчив.

Алгоритм проектирования продуктовой группы

Представленный алгоритм проектирования продуктовой группы следует принципам, описанным выше и для выполнения алгоритма нам нужно ответить на ряд вопросов.
Следуя принципу «от целого к частям», всё начинается с формирования миссии юнита (его предназначения) и описания его основных частей. Основные части — это необходимый и достаточный набор элементов системы, который позволяет выполнять ее функцию. Но не все основные части системы стоит включать в юнит по умолчанию: некоторые из них могут оставаться корпоративными централизованными функциями ради экономии на масштабе. Особенно это важно в операционно-центричной стратегии.
Поэтому следующие шаги помогают ответить на вопрос: что из основных частей остаётся внутри и является специфичным для продуктовой семьи, а что стоит централизовать и оставить за пределами продуктовой группы.
Шаги алгоритма:
  1. Какая миссия юнита и какие основные части нужны для её выполнения?
  2. Какие способности нужно сохранить и развить?
  3. Какие самые частотные / специфичные компоненты и функции?
  4. Какие операционные зависимости между элементами?
  5. Какие поддерживающие функции стоит включить, учитывая цену задержки (CoD) и критичность / неопределённость?
  6. Какая модель продуктового и линейного менеджмента?
  7. Какой организационный дизайн имеет минимальную функциональную связанность?
  8. Какие области ценности (Value Areas) и какие составы команд?
На первом шаге мы, следуя принципу «от целого к частям», наполняем продуктовую группу максимально широким набором элементов. Дальше, шаг за шагом, начинаем отсекать лишнее, следуя принципу баланса гибкости и масштаба.
Далее я покажу, как работает алгоритм, на примере большой финансовой организации.

Какая миссия юнита и какие основные части нужны для ее выполнения?

Миссия проясняет причину существования продуктовой группы как отдельного подразделения внутри компании, а также указывает на клиентов и результат, который они получат. Менеджмент сформулировал миссию продуктовой группы «Ежедневный Банкинг» так:

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

Миссия и основные части будущей продуктовой группы

Для выполнения миссии менеджмент выделил следующие основные части:
  • Карты
  • Бонусы
  • Транзакции
  • Sales (digital)
  • Маркетинг (реклама)
  • Call-центр
  • Sales (ЗП-клиенты)
  • Sales (розница в филиалах)

Какие способности нужно сохранить и развить?

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

Какие самые частотные / специфичные функции?

На этом шаге алгоритма мы определяем, какие функции и компоненты должны находиться внутри продуктовой группы «Ежедневный банкинг». Базовым инструментом анализа остается Heat Map частотности взаимодействий, показывающая, как часто каждая функция участвует в реализации продуктовых фич.
Однако частотность сама по себе не определяет границы продуктовой группы. Для принятия структурных решений мы дополняем её вторым аналитическим измерением — специфичностью (specificity), заимствованной из теории транзакционных издержек (Transaction Cost Economics, TCE), представленной в работах Рональда Коуза и Оливера Уильямсона.
Специфичность отражает степень зависимости функции от уникального продуктового контекста, доменной экспертизы и архитектуры. В логике TCE высокоспецифичные функции целесообразно удерживать внутри юнита, поскольку их вынесение за пределы продуктовой группы приводит к росту транзакционных издержек — издержек координации, согласований и адаптации. Низкоспецифичные функции, напротив, могут быть централизованы без существенных экономических потерь.
Мы используем следующую шкалу специфичности:
  • 0 — низкая: стандартизируемая, повторяемая, универсальная функция;
  • 1 — умеренная: требует доменного контекста, но легко переиспользуется;
  • 2 — высокая: зависит от продукта, требует глубокой предметной экспертизы;
  • 3 — очень высокая: критична для ключевых сценариев и архитектурно связана с ядром продукта.
Для оценки специфичности в контексте «Ежедневного банкинга» мы отвечали на следующие вопросы:
  • Насколько функция зависит от уникального продуктового или доменного контекста?
  • Может ли она обслуживать несколько продуктовых групп без изменений?
  • Насколько глубоко она встроена в архитектуру продукта?
Комбинация частотности и специфичности позволяет определить экономическую границу продуктовой группы. Чтобы сфокусироваться на основном объёме работы, мы применили правило Парето. В рамках анализа были рассмотрены 14 ключевых фич, поэтому в дальнейший анализ были включены функции, встречающиеся более чем в трех фичах.

Тепловая карта, построенная по частотности и специфичности

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

Матрица принятия решений по частотности / специфичности

Исходя исключительно из анализа частотности и специфичности, на данном этапе CRM, ABS, DBMS, Call-center и Sales (branches) не соответствуют критериям автоматического включения в продуктовую группу. Частотность их взаимодействия носит эпизодический характер, а специфичность остается умеренной, что помещает эти функции в зону “consider” матрицы принятия решений. С точки зрения теории транзакционных издержек (Transaction Cost Economics, TCE) это означает, что централизованное размещение остаётся экономически оправданным, однако решение не является окончательным.
В то же время ряд функций однозначно соответствует критериям включения. Backend, Web, iOS и Android сочетают высокую или очень высокую специфичность с частым взаимодействием, что делает их внутреннее размещение экономически обоснованным и критически важным.
Одновременно с этим Marketing и Sales (digital) также попадают в зону “consider”. Несмотря на относительно высокую частотность их участия, их специфичность остается умеренной, что не дает достаточных экономических оснований для автоматического включения в продуктовую группу на данном этапе.
Чтобы учесть операционную реальность и издержки координации, на следующем шаге мы вводим дополнительную перспективу — тип операционных зависимостей.

Какие операционные зависимости между элементами?

Анализ частотности и специфичности позволяет определить экономическую границу продуктовой группы и выделить набор функций, находящихся в зоне неопределенности. Чтобы принять окончательное решение по их размещению, необходимо учесть операционную реальность — то, каким образом функции и компоненты зависят друг от друга в процессе создания ценности. Для этого мы используем классификацию операционных зависимостей Дж. Томпсона (Organizations in Action).
Томпсон выделяет три типа операционных зависимостей:
  • Pooled (общие) — элементы используют общие ресурсы, но могут работать относительно независимо;
  • Sequential (последовательные) — результат работы одного элемента является входом для другого;
  • Reciprocal (взаимные) — элементы взаимно зависят от результатов работы друг друга и требуют постоянной координации.
С точки зрения организационного дизайна именно взаимные (reciprocal) зависимости создают наибольшие издержки координации и являются самым сильным аргументом в пользу организационной близости. Последовательные зависимости, как правило, могут быть управляемы через интерфейсы и процессы, а общие — через централизованные механизмы.
После проведения воркшопа с представителями функций мы проанализировали типы операционных зависимостей между компонентами, выявленными на предыдущем шаге, и сгруппировали их в устойчивые кластеры.
Анализ операционных зависимостей и формирование кластеров
Digital Core. Web, Backend, iOS и Android должны входить в состав кросс-функциональных команд, поскольку это самые высокочастотные и взаимозависимые функции цифрового продукта. Изменения в Backend требуют синхронизации с Web и мобильными платформами, а доработки интерфейсов влияют на серверную логику.
Integration Cluster. ABS, DBMS и CRM демонстрируют взаимные зависимости не только между собой, но и с Backend. На уровне данных и бизнес-логики изменения в Digital Core регулярно требуют синхронных изменений в интеграционных компонентах, и наоборот — доработки в ABS, базах данных и CRM часто инициируют изменения в Backend. Таким образом формируется цепочка взаимных зависимостей, охватывающая цифровое ядро и интеграционный слой.
Хотя по результатам анализа частотности и специфичности эти компоненты находились в зоне consider, их механическое исключение привело бы к вынесению тесно связанных взаимодействий за пределы продуктовой группы и существенному росту издержек координации и интеграции. Поэтому ABS, DBMS и CRM были объединены в отдельный интеграционный кластер — второй тип кросс-функциональных команд, дополняющий Digital Core и обеспечивающий непрерывный поток создания ценности.
При этом рассматривался и альтернативный вариант — объединение Digital Core и интеграционного слоя в единый кластер. Теоретически такой подход позволил бы реализовывать изменения полностью end-to-end без зависимостей. Однако он был отвергнут из-за недостаточной частотности такого укрупненного кластера, ограниченности ресурсов и чрезмерного роста размера и специализации команд.
Marketing & Sales. Marketing и Sales (digital) демонстрируют смешанный характер зависимостей. Digital Sales имеет последовательные зависимости с Backend и взаимные зависимости с Marketing. Это означает, что изменения в продукте и изменения в маркетингово-коммерческих активностях требуют регулярной синхронизации.
Именно анализ операционных зависимостей снимает неопределенность, оставшуюся после шага частотности и специфичности. Несмотря на умеренную специфичность, Marketing и Digital Sales включаются в продуктовую группу как shared capability, хотя и не входят в состав кросс-функциональных команд. Такое размещение снижает издержки координации и предотвращает регулярные согласования между юнитами при реализации фич end-to-end.
Не включаются в продуктовую группу. Call-center и Sales (branches) не включаются в продуктовую группу, поскольку они имеют низкую частотность и низкую специфичность, а их связи с продуктом являются последовательными, а не взаимными.

Какие поддерживающие функции стоит включить, учитывая цену задержки (CoD) и критичность / неопределенность?

Возвращаясь к концепции продуктовой группы и многомерной организации, внутри продуктовой группы могут присутствовать input-функции — например, HR — которые сами по себе не входят в основную value-chain. Традиционно такие функции централизуются на уровне корпоративных сервисов. Однако при чрезмерной централизации они могут превращаться в бутылочные горлышки, создавая высокую цену задержки (Cost of Delay). В таких случаях Владельцу Продукта может быть экономически выгоднее «оплатить» эту функцию и включить её внутрь продуктовой группы.
Любую функцию за пределами продуктовой группы стоит оценить по двум факторам:
  • Критичность — насколько функция влияет на бизнес-результаты продуктовой группы (например, NPS или P&L). Оценка от 1 до 10, где 10 — максимально критичная.
  • Неопределенность — насколько централизованное исполнение данной функции мешает предсказуемой и надежной поставке. Оценка от 1 до 10, где 10 — максимальная непредсказуемость.
Функции, которые получают высокие оценки (выше 5) по обоим факторам, целесообразно включать в периметр продуктовой группы.
Итак, после воркшопа мы оценили корпоративные функции, которые остаются за периметром продуктовой группы и не относятся к её основным частям:
  • IT Security — (7, 7)
  • HR — (2, 2)
  • Finance — (4, 2)
  • Legal — (2, 7)
Анализ по двум критериям — критичности и неопределенности — показывает, что единственным потенциальным кандидатом на включение в продуктовую группу является IT Security.

Концепт продуктовой группы на данном этапе проектирования

На этом этапе концепт нашей продуктовой группы может выглядеть следующим образом:
  • Output-юниты: кластеры Digital Core и Integration Cluster;
  • Input-юнит: информационная безопасность (IT Security);
  • Market-юнит: маркетинг и продажи (Marketing & Sales).

Какая модель линейного и продуктового лидерства?

В Creating Agile Organizations подчеркивалась необходимость разделения продуктового и линейного менеджмента. В крупных организациях на Владельца Продукта ложится значительная продуктовая нагрузка: стратегия, видение, взаимодействие с рынком, определение ценности, управление Бэклогом Продукта. Одновременно заниматься развитием организационной системы — людьми, компетенциями, процессами, оценками эффективности, наймом, вознаграждениями — практически невозможно без потери качества. Поэтому в гибких организациях продуктовый и линейный управленческие контуры разводятся. Кроме того, если этого не сделать, то возможен конфликт интересов между линейным и продуктовым менеджментом.
Существует три основных варианта распределения лидерства внутри продуктовой группы.
1. Dual Leadership. Владелец Продукта отвечает за стратегию и ценность, а Unit Leader — за людей, процессы и организационную среду. Это простая, понятная и универсальная модель, хотя по мере роста продуктовой группы нагрузка на Unit Leader начинает увеличиваться. В этой логике Unit Leader становится общим кросс-функциональным менеджером для всех юнитов в продуктовой группе.

Модель Dual Leadership

2. Triad Leadership. Подходит для разнородных продуктовых групп. Здесь Владелец Продукта остаётся стратегическим лидером, тогда как линейный менеджмент распределяется между:
  • Output Lead (отвечает за кросс-функциональные команды двух типов);
  • Market Lead (отвечает за маркетинг и digital sales);
  • Input Lead (отвечает за функцию безопасности).

Модель Triad Leadership

3. Head of Product Group (GM) + PO Team. Эта модель встречается, когда продуктовая группа фактически становится мини-бизнесом. В этом случае появляется Head of Product Group (GM), отвечающий за организационную систему, ресурсы, бюджеты и бизнес-контур, а Владелец Продукта руководит продуктовой стратегией и Product Owner Team. Модель подходит только крупным продуктовым семьям — тем, которые по масштабу, автономии и сложности функционируют как мини-бизнес-юнит (потенциально отделяемая организация). Она требует развитой управленческой архитектуры, нескольких юнитов разных типов, существенного бюджета и стратегической самостоятельности. Для небольших и средних продуктовых групп такая конструкция создает избыточные организационные издержки.

Модель Head of Product Group + PO Team

Возможны и гибридные конструкции, которые комбинируют элементы всех трех подходов.
В нашем кейсе модель Triad Leadership показалась наиболее адекватной. Менеджмент посчитал нереалистичным, что один линейный лидер сможет одинаково эффективно развивать как технические команды (Web, Backend, Mobile, Integration), так и маркетингово-коммерческие функции (Marketing, Digital Sales). Эти юниты требуют принципиально разной экспертизы, разных подходов к развитию компетенций, разных метрик эффективности и разных операционных моделей. Разделение лидерства на Output Lead и Market Lead позволяет обеспечить качественное управление каждым направлением и избежать перегрузки одного руководителя, что критично для устойчивого развития продуктовой группы.

Какой организационный дизайн имеет минимальную функциональную связанность?

В Creating Agile Organizations мы сформулировали гайдлайн Decouple Unit Functions: при проектировании организационных юнитов важно стремиться к тому, чтобы функции внутри юнита были максимально независимы.
Чтобы формально оценить степень такой независимости, мы используем подход аксиоматического дизайна. Он предлагает описывать организацию через два набора:
  • функциональные требования (FR) — что юнит должен обеспечивать;
  • дизайн-параметры (DP) — структурные элементы, которые эти требования реализуют.
Хороший дизайн стремится к минимальной функциональной связанности, то есть каждый FR должен зависеть преимущественно от одного DP. Когда один DP начинает влиять сразу на несколько ключевых требований, возникает нежелательная взаимозависимость и риск конфликтов интересов.
На воркшопе менеджмент сформировал таблицу FR–DP, присвоив каждому юниту внутри продуктовой группы функциональные требования. Первоначально IT Security рассматривалась как кандидат на включение в состав продуктовой группы — на основе двух критериев: критичности и неопределенности, которые действительно оказались высокими.

Потенциальный конфликт интересов между Владельцем Продукта и функцией безопасности

Анализ функциональной связанности подсветил важную проблему: между Product Owner и IT Security возникает структурный конфликт интересов. Продуктовые цели (ценность, скорость, приоритеты) могут оказывать давление на контрольные функции безопасности, что приводит к функциональной связанности и снижению независимости IT Security.
Поэтому, несмотря на высокие оценки критичности и неопределенности, мы принимаем другое решение: IT Security остается за пределами продуктовой группы, сохраняя независимость и снижая функциональную связанность.
Кстати, ничто не мешает включить в продуктовую группу представителя безопасности функционально. Линейно этот человек будет подчиняться своему руководителю в централизованной функции, а работу получать от Владельца Продукта. То есть вопрос решается на уровне процессов: мы используем матричную координацию, сохраняя независимость контрольной функции и обеспечивая оперативное участие в работе продуктовой группы.

Матричная координация функции безопасности

Какие области ценности (Value Areas) и составы команд?

В практике проектирования продуктовых групп существует подход, при котором команды организуются вокруг областей ценности (Value Areas) — крупных потоков ценности либо клиентских задач, за которые команда отвечает end-to-end. Однако в продуктовой семье «Ежедневный банкинг» весь объём разработки распределен всего между шестью командами.
При анализе организационных способностей одна из ключевых — Адаптивность. В терминах теории транзакционных издержек (TCE) адаптивность связана с costs of adaptation — издержками переключения и перестройки. Эти затраты резко растут при специализации: чем уже профиль команды, тем дороже и медленнее она адаптируется к изменениям, новым фичам и перераспределению работы.
Чтобы избежать этого, мы применяем другой принцип: минимальная специализация команд при сохранении end-to-end ответственности.
Итоговое решение:
  • 4 взаимозаменяемые команды Digital Core, которые могут брать в работу любую фичу продуктовой семьи (транзакции, карты, бонусы, ежедневные сценарии клиентов);
  • 2 взаимозаменяемые команды Integration Cluster, обеспечивающие работу с ABS, CRM, DBMS и другими интеграционными компонентами.
  • Команда Marketing & Sales
Такой дизайн снижает стоимость адаптации, повышает гибкость, устраняет очереди между доменами и увеличивает пропускную способность всей продуктовой группы — без необходимости создавать отдельные Value Areas.

Итоговая структура продуктовой группы

Подводим итоги

Кратко резюмируя алгоритм и результат на примере продуктовой группы «Ежедневный банкинг»:
  • Мы начинаем с миссии и основных частей, определяя, какую роль играет продуктовая группа в бизнесе и какие элементы необходимы для выполнения этой роли.
  • Затем, опираясь на организационные способности, частотность и специфичность функций, а также типы операционных зависимостей, решаем, какие функции включать внутрь продуктовой группы, а какие — оставлять корпоративными.
  • Через оценку критичности и неопределённости уточняем состав поддерживающих функций и границы юнита.
  • С помощью принципа минимальной функциональной связанности и проверяем независимость ключевых функций и корректируем размещение контрольных ролей (например, IT Security).
  • Наконец, принимаем решение о лидерской модели (Triad Leadership) и композиции команд (4 Digital Core + 2 Integration Cluster), которое поддерживает выбранные способности — адаптивность и быстрый вывод продуктов на рынок — при разумных транзакционных издержках.
Так формируется структура продуктовой группы, в которой стратегический фокус, архитектура, команды и корпоративные функции связаны единым, целостным дизайном.

References

Pavlichenko, I., & Cesario, S. (2023). Creating Agile Organizations.
Treacy, M., & Wiersema, F. (1995). The Discipline of Market Leaders: Choose Your Customers,
Ackoff, R. L. (1971). Towards a system of systems concepts. Management Science, 17(11), 661–671.
Ackoff, R. L. (1999). Re-Creating the Corporation: A Design of Organizations for the 21st Century. Oxford University Press.
Coase, R. (1937). The nature of the firm. Economica, 4(16), 386–405.
Coplien, J. O., & Bjørnvig, A. (2018). A Scrum Book: The Spirit of the Game. The Pragmatic Bookshelf.
Galbraith, J. R. (2014). Designing Organizations: Strategy, Structure, and Process at the Business Unit and Enterprise Levels. Jossey-Bass.
Kates, A., Kesler, G., & DiMartino, M. (2023). Networked, Scaled, and Agile: A Design Strategy for Complex Organizations. Kogan Page.
Liker, J. K. (2004). The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer. McGraw-Hill.
Suh, N. P. (2001). Axiomatic Design: Advances and Applications. Oxford University Press. Williamson, O. E. (1975). Markets and Hierarchies. Free Press.
Williamson, O. E. (1985). The Economic Institutions of Capitalism. Free Press.
Worren, N. (2012). Organizational Design: A Step-by-Step Approach. Pearson.
2025-12-12 15:07 Структура