Что такое продукт или дисфункции продуктовых компаний

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

Уверен, что если я скажу, что количество людей, которые работают в этой компании - это 10 человек, то вы не задумываясь мне скажете - "Очевидно, что продукт этой компании - это доставка еды!"

А вот если я скажу, что численность компании это 3000 человек, то вы задумаетесь. Задумаетесь - "Не может же столько людей заниматься одним продуктом?! А может тут несколько продуктов? Ну есть как бы внешний продукт, который мы продаем клиенту, и чтобы это делать, у нас есть продукты: приложения для клиента, приложение для курьера, мессенджер…".

Что изменилось по сути? Бизнес-модель компании не поменялась, не появилось дополнительных сегментов клиентов. Изменилось лишь количество вовлеченных в развитие компании людей.

Но именно в этом направлении происходит развитие ситуации в большинстве крупных компаний. Крупным компаниям свойственно декомпозировать любую проблематику на части и зоны ответственности. То есть в этом случае мы начинаем декомпозировать наш изначальный продукт на различные зоны ответственности - "продукты" (например, по воронке продаж, изобретать внутренние продукты и т.д.).
А почему это вообще важно?

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

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

К сожалению, по этому пути идут многие компании. Узкое определение продукта, например мессенджер в рамках доставки еды, приводит к локальной оптимизации, когда мы фокусируем команды на развитие компонентов, а не продукта в целом. Это приводит к появлению множества серьезных дисфункций.
Перечислю лишь часть из них:
1
Зависимости или потребность в большом объеме "ручной" координации
Формируя структуру не вокруг реального продукта, а вокруг каких-то его частей или компонентов (то есть в другой системе координат), мы изначально закладываем в эту структуру потребность в большом объеме координации. В этой ситуации продуктовые задачи, в нашем примере связанные с развитием сервиса доставки еды, идут в разрез со структурой, построенной вокруг "микропродуктов" или компонентов.
1
То есть продуктовые задачи придется переводить на язык структуры команд, и потом координировать команды, чтобы итоговая продуктовая задача была сделана.

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

Для решения этой дисфункции, осознанно или нет, компании часто пытаются использовать различные координационные практики типа OKR, SAFe, SoS, проектного управления и т.п
2
Ложная загрузка
Создавая команды вокруг "микропродуктов" или компонентов, мы явно или неявно формируем фокус на развитие данных частей продукта. Чтобы это развитие происходило, мы назначим для каждой части продукта и соответствующей команды менеджеров - "локальных PO". Такой "локальный PO" будет иметь свои метрики успешности и будет генерировать поток задач для команды. И, что самое интересное, поток задач на любой из этих микропродуктов никогда не закончится.

Почему? Ответ очень прост - это его прямая ответственность. Отсутствие задач развития по сути будет означать некомпетентность соответствующего менеджера в развитии своего микропродукта. Даже если развитие этой части продукта уже не приносит значимой ценности с точки зрения продукта в целом или компании.

Такой эффект можно наблюдать в больших компаниях. Его внешним проявлением часто является постоянный рост количества таких "микропродуктовых" команд.
3
Избыточное потребление ресурсов
Предыдущая дисфункция “ложная загрузка” создает иллюзию, что все команды перегружены работой, так как каждый из "локальных PO" генеририует поток "приоритетных" задач. Как правило, в такой системе отсуствует прозрачность и сквозные приоритеты по продукту в целом. Поэтому если в продукте возникают новые большие задачи, то часто такие компании принимают решения в пользу создания новых команд со своими новыми узкими зонами ответственности. Хотя задачи части существующих команд могут быть неприоритетны с точки зрения продукта в целом, а не их локального фокуса.

Можете попробовать разложить эту дисфункцию в виде CLD диаграммы. И вы явно увидите наличие самоусиливающегося цикла в такой системе.

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

Весь вопрос в том, зачем изначально закладывать эти дисфункции в структуру компании?

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

Алексей Воронин
LeSS-friendly Scrum Trainer, основатель LeSSFlip
Эксперт в области орг дизайна продуктовых компаний. Партнер компании ScrumTrek. Сооснователь продуктового акселератора ctrek.
Где узнать больше?
Это введение в фреймворк продуктовой разработки LeSS. На тренинге вы сможете понять, как выстроить продуктовую группу с точки зрения структуры и процессов.
Тренинг Certified LeSS Basics (CLB)
Есть вопросы?
Не знаете, с чего начать решение проблем роста в вашей ситуации? Подходит ли вам LeSS? Есть другие вопросы? Мы ответим на них.
Нажимая кнопку «Отправить», вы даете согласие на обработку ваших данных в соответствии с условиями