КакопределитьПродуктв Скраме

Скрам и Аджайл работают с продуктами, поэтому критически важно договориться о том, что такое Продукт. Определение Продукта напрямую влияет на состав Команды Разработки, количество команд и выбор Владельцев Продукта, поэтому я рекомендую обратить особое внимание на этот этап. С чего начать определение Продукта?

Постройте канвас ценностного предложения (VP)

Удобно определять Продукт, используя канвас ценностного предложения (Value Proposition Canvas). В этом канвасе мы исследуем клиента и записываем, какие задачи он решает, с какими проблемами сталкивается, что хочет получить.

Давайте представим, что я хочу открыть пиццерию, ориентированную на массовый рынок. Первое исследование клиентов даст примерно такие результаты:

Черновик канваса можно построить на наших предположениях, но после понадобится провести интервью с пользователями, которые подтвердят или опровергнут наши гипотезы.

Сформулируем ценностное предложение нашей пиццерии:

Объединяем всю информацию в канвас ценностного предложения. В случае с пиццерией он выглядит так:

Нас интересует левый треугольник «Продукты и сервисы». В нём мы собрали то, что будет решать задачи клиента. Например, приложение для Android решает задачу «Заказать пиццу на дом» и экономит время клиента. Но что из того, что собрано в этом секторе, можно назвать Продуктом?

Определяйте Продукт по возможности максимально широко

Глядя на наше ценностное предложение, я мог бы назвать Продуктом:

• приложение для Android;
• приложение для iOS;
• сайт;
• сервис заказа на кассе (скорее всего, там будет отдельное программное обеспечение, с которым работает продавец).

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

• Владельцам Продукта придётся тратить время на согласования между собой, потому что на самом деле они работают в рамках одного ценностного предложения и должны синхронизироваться.
• Появляются вынужденные зависимости между командами, потому что они являются частями одного ценностного предложения.
• Начинаются политические игры между Владельцами Продукта, будет тяжело договориться.
• Появляется рассинхронизация в приоритетах. Никогда одна и та же задача не будет в топе у всех Владельцев Продукта.
• Заинтересованные лица будут вынуждены бегать ко всем Владельцам Продукта, чтобы договориться об одном и том же.
• Разработчики работают в «колодцах» и не видят, что занимаются локальной оптимизацией.
• Организация работает неоптимально, ценность можно доставлять на рынок намного быстрее.

Теперь представим, что мы назвали все четыре сервиса одним Продуктом. В этом случае у нас один Владелец Продукта и несколько команд, работающих над одним Бэклогом Продукта. В каждой команде есть необходимые компетенции, чтобы изменять любой из каналов поставки ценностного предложения (сайт, Android, iOS, касса).

Очевидно, что в такой структуре один Владелец Продукта может быстрее принимать решения и эффективнее оптимизировать бизнес-ценность. Представьте, что стартовала рекламная кампания, и теперь заказ каждой 10 пиццы для пользователя бесплатный. В этом случае централизованный Владелец Продукта поставит на первое место в Бэклоге задачу «Реализовать рекламную кампанию сразу во всех каналах: сайт, Android, iOS, касса».

Более широкое определение Продукта позволяет эффективнее доставлять ценность на рынок, быстрее создавать выгоды и закрывать боли пользователей.

Проверьте характеристики Продукта

У настоящего Продукта есть три ключевые характеристики:

• решает конкретную проблему или создаёт выгоду для группы пользователей и заказчиков на рынке;
• имеет ключевые фичи (функциональность);
• есть понятная бизнес-модель, приносящая прибыль.

Проверьте, соответствует ли ваш Продукт этим критериям. Если нет — самое время его изменить.

Основные мысли статьи

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