В статье «Кейс проектирования продуктовой группы» я подробно разбираю универсальный алгоритм дизайна продуктовых юнитов на примере Daily Banking: от миссии и ключевых способностей до границ юнита, состава команд и лидерской модели. В этой статье я фокусируюсь на одном из инструментов этого кейса — расширенной Heat Map с измерением специфичности, которая опирается на идеи теории транзакционных издержек (Transaction Cost Economics, TCE).
Тепловая карта с частотой и специфичностью
Базовая Heat Map представляет собой таблицу, где строки — элементы Бэклога Продукта, а столбцы — архитектурные компоненты и функции; ячейки помечаются, если для реализации конкретной фичи используется соответствующий компонент. Подсчет таких «зажженных» ячеек по столбцам показывает, какие компоненты и технологии используются чаще всего и должны быть представлены в составе продуктовых команд, чтобы они могли забирать широкий спектр работ из Бэклога Продукта.
Базовая Heat Map, которая показывает частотность
В продвинутой Heat Map частотность дополняется вторым измерением — specificity, заимствованным из теории транзакционных издержек. Специфичность отражает степень зависимости функции от уникального продуктового контекста, доменной экспертизы и архитектуры. В логике TCE высокоспецифичные функции целесообразно удерживать внутри юнита, поскольку их вынесение за пределы продуктовой группы приводит к росту транзакционных издержек — издержек координации, согласований и адаптации. Низкоспецифичные функции, напротив, могут быть централизованы без существенных экономических потерь.
В кейсе Daily Banking я использую четырёхуровневую шкалу специфичности:
- 0 — low: стандартизируемая, повторяемая, универсальная функция.
- 1 — moderate: требует доменного контекста, но легко переиспользуется.
- 2 — high: зависит от продукта и требует глубокой предметной экспертизы.
- 3 — very high: критична для ключевых сценариев и архитектурно связана с ядром продукта.
Для каждой функции мы отвечали на вопросы:
- насколько она зависит от уникального продуктового или доменного контекста;
- может ли без изменений обслуживать несколько продуктовых групп;
- насколько глубоко встроена в архитектуру Daily Banking.
Что касается частотности, то мы применили правило Парето (80%), поэтому используем четырехуровневую шкалу частотности:
- 0-20% — rare: редко используемая функция.
- 20-40% — occasional: эпизодически используемая функция.
- 40-80% — frequent: высоко частотная функция.
- 80-100% — constant: функция используется постоянно.
Комбинация частотности и специфичности позволяет определить экономическую границу продуктовой группы. Исходя из этой логики, мы построили матрицу принятия решений, которая позволяет различать функции и компоненты, подлежащие включению, исключению или требующие дополнительного рассмотрения.
Матрица принятия решений по частотности и специфичности
Исходя исключительно из анализа частотности и специфичности, на данном этапе CRM, ABS, DBMS, Call-center и Sales (branches) не соответствуют критериям автоматического включения в продуктовую группу. Частотность их взаимодействия носит эпизодический характер, а специфичность остается умеренной, что помещает эти функции в зону “consider” матрицы принятия решений. С точки зрения теории транзакционных издержек (Transaction Cost Economics, TCE) это означает, что централизованное размещение остаётся экономически оправданным, однако решение не является окончательным.
В то же время ряд функций однозначно соответствует критериям включения. Backend, Web, iOS и Android сочетают высокую или очень высокую специфичность с частым взаимодействием, что делает их внутреннее размещение экономически обоснованным и критически важным.
Одновременно с этим Marketing и Sales (digital) также попадают в зону “consider”. Несмотря на относительно высокую частотность их участия, их специфичность остается умеренной, что не дает достаточных экономических оснований для автоматического включения в продуктовую группу на данном этапе.
Чтобы учесть операционную реальность и издержки координации, на следующем шаге мы вводим дополнительную перспективу — тип операционных зависимостей по Томпсону (pool, sequential, reciprocal).
Краткие выводы и ссылки
Расширенная Heat Map с добавлением специфичности и дальнейшего анализа элементов желтой зоны сохраняет наглядность базового инструмента, но помогает принимать структурные решения на стыке стратегии, архитектуры и теории транзакционных издержек.
Полная логика алгоритма и все артефакты (включая схемы Heat Map, матрицу частотности/специфичности и кластеры команд) подробно описаны в:
- «Кейс проектирования продуктовой группы» (рус)
- Whitepaper: Product Group Design: A Practical Case Study (eng).