MVP. Как выводить на рынок товары и услуги, которые нравятся покупателям

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

По результатам мозгового штурма у вас должен появиться список всех идей, выдвинутых в отношении набора функций, направленных на реализацию каждого из рассмотренных преимуществ вашего ценностного предложения. Затем список предложенных функций для каждого из преимуществ должен быть ранжирован, исходя из их приоритетности. Вы можете оценивать каждую идею на основе ожидаемой потребительской ценности. Цель состоит в том, чтобы определить три-пять основных функций для каждого из преимуществ. На данном этапе нет смысла выходить за рамки небольшого количества приоритетных функций, потому что все изменится – и очень сильно – после того, как вы предъявите свой прототип пользователям.

Истории пользователей

Истории пользователей (используемые в Agile-разработке) – отличный способ формулировки идей для создания функций. Он позволяет убедиться в наличии в них явной выгоды для пользователей. История пользователя – это, по сути, краткое описание преимуществ, которые должна обеспечивать конкретная функция, включая указание на то, для кого она предназначена (целевой потребитель) и для чего будет использоваться. Хорошо написанные истории пользователей обычно соответствуют следующему шаблону:

Я как [тип пользователя]

хочу [что-то сделать],

чтобы [получить желаемую пользу].

Вот пример истории пользователя, которая соответствует этому шаблону:

Я как профессиональный фотограф

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

чтобы оперативно показывать их клиентам.

Этот шаблон обеспечивает хорошую стартовую позицию, но написание действительно полезных пользовательских историй требует определенных навыков. Билл Уэйк – один из пионеров Agile-разработки создал набор рекомендаций (атрибутов) для написания хороших пользовательских историй. Чтобы их было легче запомнить, он придумал акроним INVEST:

1. [I]ndependent – Независимость: Хорошая история должна быть независима от других историй. Истории не должны пересекаться по концепции и могут быть реализованы в любом порядке.

2. [N]egotiable – Обсуждаемость: Хорошая история – это не готовое описание функции. Детали того, как именно должно быть реализовано заложенное в пользовательской истории преимущество, должны быть открыты для обсуждения.

3. [V]aluable – Ценность: Хорошая история должна содержать в себе пользовательскую ценность.

4. [E]stimable – Оцениваемость: Хорошая история должна поддаваться разумной оценке ее масштаба.

5. [S]mall – Лаконичность: Хорошие истории, как правило, невелики по объему. Более пространные истории содержат в себе больше неопределенности, поэтому их следует разбить на части.

6. [T]estable – Тестируемость: Хорошая история должна содержать достаточно информации для того, чтобы она могла быть проверена на «достоверность» (на основе так называемых критериев приемлемости).

Фрагментация функций

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