Перевод оригинальной статьи Сезарио Рамоса.
Это первая часть серии блог-постов об определении продукта в LeSS.
При разработке крупных продуктов команды, как правило, работают только над частью реального продукта. Эта часть – узкое определение продукта – часто является компонентом или конкретной активностью в процессе разработки. Это не продукт.
Узкое определение продукта создает различного рода проблемы для продуктовой группы. Узкое определение продукта локально оптимизирует производительность команд за счет производительности группы. Системная диаграмма (CLD) ниже объясняет эту динамику.
(См. Этот блог-пост для краткого обзора обозначения CLD.)
При узком определении продукта повышается вероятность того, что будут появляться специализированные группы, которые работают только в своем функциональном колодце, что, в свою очередь, снижает адаптивность и скорость обучения на общем уровне продукта. Более широкое определение продукта приводит к группам, которые охватывают несколько компонентов и видов деятельности, которые в совокупности отвечают потребностям конечных пользователей.
Устраните локальную оптимизацию узкого определения продукта
Часто используемое определение продукта – «что-то, что сделано для продажи». Продукт обеспечивает способ извлечения прибыли.
- У продукта есть пользователи, люди;
- Продукт предоставляет базовую функциональность, которая закрывает проблемы и отвечает потребностям пользователей;
- Продукт имеет бизнес-модель, источники доходов, независимую прибыль и убыток (P&L) или возврат инвестиций (ROI).
- Продукт разрабатывается и поддерживается системой людей, компонентов и процессов.
Определение продукта обуславливает, какие организационные элементы (люди, компоненты, процессы и системы) необходимы для разработки и запуска продукта. Если ваш продукт – «Ипотека», то Владельцем Продукта, вероятно, является человек из бизнеса, который понимает рынок. Бэклог Продукта может содержать такие элементы, как «Кредитные предложения для малого бизнеса», а пользователи, вероятно, будут клиентами, которые платят деньги. Ипотека – это широкое определение продукта, когда оно содержит все детали, необходимые для создания комплексного решения для конечного пользователя.
Как определить продукт?
Определение продукта включает в себя несколько компонентов, действий и предоставляет решения для потребностей и проблем конечных пользователей. Вы можете определить свой продукт, используя следующие два шага:
Шаг 1 — Определите необходимые организационные элементы для разработки и поддержки продукта.
Начните с элементов, ваших компонентных команд, которые вы в настоящее время называете продуктами, активностей, людей и процессов, которые есть в вашей группе. Затем изучите, как связана между собой работа, чтобы понять существующие типы зависимостей для разработки, поддержки и обслуживания вашего продукта.
Типичные шаги для достижения этой цели:
- Определите типичных внешних конечных пользователей для вашей группы.
- Определите постоянные потребности, которые эти конечные пользователи хотят решить, или задачи, которые они должны выполнить.
- Определите фичи для каждого из пользователей, которые они используют для удовлетворения потребностей или выполнения своей работы.
- Определите каналы, через которые пользователи используют функции для удовлетворения своих потребностей/проблем и т. д. (Например, Браузер, Приложение, API, Connector или Helpdesk)
- Затем, определите организационные элементы, которые вам необходимы для разработки фичи и удовлетворения пользователя. Сделайте это, изучая путь, как каждый элемент функциональности проходит через вашу организацию в руки клиента. Начните с каналов, проработайте компоненты, системы, людей и процессы до конца пользовательского пути.
Шаг 2 – Проясните источники доходов
Правильное определение продукта определяет группу, достаточно широкую, чтобы включать источники доходов. Без этого команды, скорее всего, будут оторваны от проблем рынка, где стоит реальная ценность, и вместо этого будут сосредоточены только на части продукта.
На этом шаге задайте вопросы вопросы: “Производят ли идентифицированные организационные элементы продукт, который генерирует доход для организации? Или есть недостающие части для этого?”. Также неплохо найти ответы на следующие вопросы:
- Как элементы вместе генерируют деньги? Например, может ли определение продукта иметь плату за использование? Продажа активов? Абонентская плата? Лицензирование? Если нет, что нужно добавить к определению продукта?
- Имеет ли определение продукта независимый P&L? Если нет, то какие организационные элементы отсутствуют?
- Какие KPI можно назначить определению продукта? Например, можете ли вы назначить увеличение валового дохода? Увеличение новых клиентов? Удовлетворенность клиентов?
Если вы не можете дать содержательный ответ на все вышеупомянутые вопросы, то определение вашего продукта слишком узкое, и вам необходимо его расширить.
Определение продукта завершено?
К этому шагу, вы определили набор организационных элементов, которые вместе создают ценность для конечных пользователей и имеют независимый источник дохода. Результат обычно включает десятки компонентов, навыков, видов деятельности и сотни людей.
С такой большой группой вы можете спросить себя: «Как я могу создать эффективные кросс-функциональные команды, которые включают все эти компетенции? В случае более чем десяти групп, мы рекомендуем организовать команды среди Области Ценностей и содержать зависимости для каждой области.
Это тема моего следующего блога.
