Что такое продукт или дисфункции продуктовых компаний
Давайте попробуем разобраться, с тем что вы считаете продуктом или продуктами в вашей компании, и на что это влияет.
Представим, что ваша компания занимается доставкой еды. У вас есть мобильное и веб приложение для клиентов, есть мобильное приложение для курьеров, доставляющих еду, есть интеграции с ресторанами, внутри приложений есть мессенджер для общения клиентов со службой поддержки.
Представим, что ваша компания занимается доставкой еды. У вас есть мобильное и веб приложение для клиентов, есть мобильное приложение для курьеров, доставляющих еду, есть интеграции с ресторанами, внутри приложений есть мессенджер для общения клиентов со службой поддержки.
Так вот, вопрос в том, что вы будете считать продуктом или продуктами в этой компании. И второй вопрос - на что это будет влиять.
Уверен, что если я скажу, что количество людей, которые работают в этой компании - это 10 человек, то вы не задумываясь мне скажете - "Очевидно, что продукт этой компании - это доставка еды!"
А вот если я скажу, что численность компании это 3000 человек, то вы задумаетесь. Задумаетесь - "Не может же столько людей заниматься одним продуктом?! А может тут несколько продуктов? Ну есть как бы внешний продукт, который мы продаем клиенту, и чтобы это делать, у нас есть продукты: приложения для клиента, приложение для курьера, мессенджер…".
Что изменилось по сути? Бизнес-модель компании не поменялась, не появилось дополнительных сегментов клиентов. Изменилось лишь количество вовлеченных в развитие компании людей.
Но именно в этом направлении происходит развитие ситуации в большинстве крупных компаний. Крупным компаниям свойственно декомпозировать любую проблематику на части и зоны ответственности. То есть в этом случае мы начинаем декомпозировать наш изначальный продукт на различные зоны ответственности - "продукты" (например, по воронке продаж, изобретать внутренние продукты и т.д.).
Уверен, что если я скажу, что количество людей, которые работают в этой компании - это 10 человек, то вы не задумываясь мне скажете - "Очевидно, что продукт этой компании - это доставка еды!"
А вот если я скажу, что численность компании это 3000 человек, то вы задумаетесь. Задумаетесь - "Не может же столько людей заниматься одним продуктом?! А может тут несколько продуктов? Ну есть как бы внешний продукт, который мы продаем клиенту, и чтобы это делать, у нас есть продукты: приложения для клиента, приложение для курьера, мессенджер…".
Что изменилось по сути? Бизнес-модель компании не поменялась, не появилось дополнительных сегментов клиентов. Изменилось лишь количество вовлеченных в развитие компании людей.
Но именно в этом направлении происходит развитие ситуации в большинстве крупных компаний. Крупным компаниям свойственно декомпозировать любую проблематику на части и зоны ответственности. То есть в этом случае мы начинаем декомпозировать наш изначальный продукт на различные зоны ответственности - "продукты" (например, по воронке продаж, изобретать внутренние продукты и т.д.).
А почему это вообще важно?
Тема определения продукта важна, потому что имеет сильное влияние на организационный дизайн компании. То есть на то, какие структурные единицы у нас будут в компании, на каких продуктах они будут специализироваться, какие процессы нужно будет использовать, и какие дисфункции вы в результате получите.
То есть если мы решим, что в этой компании у нас несколько "продуктов", то у нас появятся структурные единицы - команды или подразделения, каждое из которых занимается развитием своего узкого "продукта" - мессенджера, мобильного приложения для клиента, мобильного приложения для курьера, интеграцией и т.д. Ну или в самом печальном случае мы можем получить даже компонентные команды, то есть команды собранные вокруг компонентов архитектуры, систем.
Тема определения продукта важна, потому что имеет сильное влияние на организационный дизайн компании. То есть на то, какие структурные единицы у нас будут в компании, на каких продуктах они будут специализироваться, какие процессы нужно будет использовать, и какие дисфункции вы в результате получите.
То есть если мы решим, что в этой компании у нас несколько "продуктов", то у нас появятся структурные единицы - команды или подразделения, каждое из которых занимается развитием своего узкого "продукта" - мессенджера, мобильного приложения для клиента, мобильного приложения для курьера, интеграцией и т.д. Ну или в самом печальном случае мы можем получить даже компонентные команды, то есть команды собранные вокруг компонентов архитектуры, систем.
Дисфункции "микропродуктов"
К сожалению, по этому пути идут многие компании. Узкое определение продукта, например мессенджер в рамках доставки еды, приводит к локальной оптимизации, когда мы фокусируем команды на развитие компонентов, а не продукта в целом. Это приводит к появлению множества серьезных дисфункций.
Перечислю лишь часть из них:
К сожалению, по этому пути идут многие компании. Узкое определение продукта, например мессенджер в рамках доставки еды, приводит к локальной оптимизации, когда мы фокусируем команды на развитие компонентов, а не продукта в целом. Это приводит к появлению множества серьезных дисфункций.
Перечислю лишь часть из них:
1
Зависимости или потребность в большом объеме "ручной" координации
Формируя структуру не вокруг реального продукта, а вокруг каких-то его частей или компонентов (то есть в другой системе координат), мы изначально закладываем в эту структуру потребность в большом объеме координации. В этой ситуации продуктовые задачи, в нашем примере связанные с развитием сервиса доставки еды, идут в разрез со структурой, построенной вокруг "микропродуктов" или компонентов.
Формируя структуру не вокруг реального продукта, а вокруг каких-то его частей или компонентов (то есть в другой системе координат), мы изначально закладываем в эту структуру потребность в большом объеме координации. В этой ситуации продуктовые задачи, в нашем примере связанные с развитием сервиса доставки еды, идут в разрез со структурой, построенной вокруг "микропродуктов" или компонентов.
1
То есть продуктовые задачи придется переводить на язык структуры команд, и потом координировать команды, чтобы итоговая продуктовая задача была сделана.
Как в примере на рисунке выше, для реализации задачи требуются доработки в большинстве частей продукта, за которые отвечают разные команды. Это потребует активностей по постановке задач, данным командам, координации приоритетов и контроля реализации, интеграции итогового результата и сквозного тестирования. Все эти задачи потребуют специальных ролей и процессов за пределами команд.
Для решения этой дисфункции, осознанно или нет, компании часто пытаются использовать различные координационные практики типа OKR, SAFe, SoS, проектного управления и т.п
Как в примере на рисунке выше, для реализации задачи требуются доработки в большинстве частей продукта, за которые отвечают разные команды. Это потребует активностей по постановке задач, данным командам, координации приоритетов и контроля реализации, интеграции итогового результата и сквозного тестирования. Все эти задачи потребуют специальных ролей и процессов за пределами команд.
Для решения этой дисфункции, осознанно или нет, компании часто пытаются использовать различные координационные практики типа OKR, SAFe, SoS, проектного управления и т.п
2
Ложная загрузка
Создавая команды вокруг "микропродуктов" или компонентов, мы явно или неявно формируем фокус на развитие данных частей продукта. Чтобы это развитие происходило, мы назначим для каждой части продукта и соответствующей команды менеджеров - "локальных PO". Такой "локальный PO" будет иметь свои метрики успешности и будет генерировать поток задач для команды. И, что самое интересное, поток задач на любой из этих микропродуктов никогда не закончится.
Почему? Ответ очень прост - это его прямая ответственность. Отсутствие задач развития по сути будет означать некомпетентность соответствующего менеджера в развитии своего микропродукта. Даже если развитие этой части продукта уже не приносит значимой ценности с точки зрения продукта в целом или компании.
Такой эффект можно наблюдать в больших компаниях. Его внешним проявлением часто является постоянный рост количества таких "микропродуктовых" команд.
Создавая команды вокруг "микропродуктов" или компонентов, мы явно или неявно формируем фокус на развитие данных частей продукта. Чтобы это развитие происходило, мы назначим для каждой части продукта и соответствующей команды менеджеров - "локальных PO". Такой "локальный PO" будет иметь свои метрики успешности и будет генерировать поток задач для команды. И, что самое интересное, поток задач на любой из этих микропродуктов никогда не закончится.
Почему? Ответ очень прост - это его прямая ответственность. Отсутствие задач развития по сути будет означать некомпетентность соответствующего менеджера в развитии своего микропродукта. Даже если развитие этой части продукта уже не приносит значимой ценности с точки зрения продукта в целом или компании.
Такой эффект можно наблюдать в больших компаниях. Его внешним проявлением часто является постоянный рост количества таких "микропродуктовых" команд.
3
Избыточное потребление ресурсов
Предыдущая дисфункция “ложная загрузка” создает иллюзию, что все команды перегружены работой, так как каждый из "локальных PO" генеририует поток "приоритетных" задач. Как правило, в такой системе отсуствует прозрачность и сквозные приоритеты по продукту в целом. Поэтому если в продукте возникают новые большие задачи, то часто такие компании принимают решения в пользу создания новых команд со своими новыми узкими зонами ответственности. Хотя задачи части существующих команд могут быть неприоритетны с точки зрения продукта в целом, а не их локального фокуса.
Можете попробовать разложить эту дисфункцию в виде CLD диаграммы. И вы явно увидите наличие самоусиливающегося цикла в такой системе.
Поэтому, как было сказано выше, на практике такие структуры только разрастаются.
Предыдущая дисфункция “ложная загрузка” создает иллюзию, что все команды перегружены работой, так как каждый из "локальных PO" генеририует поток "приоритетных" задач. Как правило, в такой системе отсуствует прозрачность и сквозные приоритеты по продукту в целом. Поэтому если в продукте возникают новые большие задачи, то часто такие компании принимают решения в пользу создания новых команд со своими новыми узкими зонами ответственности. Хотя задачи части существующих команд могут быть неприоритетны с точки зрения продукта в целом, а не их локального фокуса.
Можете попробовать разложить эту дисфункцию в виде CLD диаграммы. И вы явно увидите наличие самоусиливающегося цикла в такой системе.
Поэтому, как было сказано выше, на практике такие структуры только разрастаются.
Перечень таких дисфункций, которые порождает узкое определение продукта, можно продолжать.
Весь вопрос в том, зачем изначально закладывать эти дисфункции в структуру компании?
Если мы хотим получить оргдизайн с минимумом дисфункций, нам нужно начать с широкого определения продукта, для оптимизации системы в целом, а не ее локальных частей. Как подступиться к широкому определению продукта, мы и разберемся в следующей статье.
Весь вопрос в том, зачем изначально закладывать эти дисфункции в структуру компании?
Если мы хотим получить оргдизайн с минимумом дисфункций, нам нужно начать с широкого определения продукта, для оптимизации системы в целом, а не ее локальных частей. Как подступиться к широкому определению продукта, мы и разберемся в следующей статье.
Алексей Воронин
LeSS-friendly Scrum Trainer, основатель LeSSFlip
Эксперт в области орг дизайна продуктовых компаний. Партнер компании ScrumTrek. Сооснователь продуктового акселератора ctrek.
Где узнать больше?
Это введение в фреймворк продуктовой разработки LeSS. На тренинге вы сможете понять, как выстроить продуктовую группу с точки зрения структуры и процессов.
Тренинг Certified LeSS Basics (CLB)
Есть вопросы?
Не знаете, с чего начать решение проблем роста в вашей ситуации? Подходит ли вам LeSS? Есть другие вопросы? Мы ответим на них.
Нажимая кнопку «Отправить», вы даете согласие на обработку ваших данных в соответствии с условиями
