User Story Mapping и не только: методы отбора функций для MVP

В Purrweb мы серьезно подходим к разработке MVP  и считаем, что от этого этапа напрямую зависит судьба стартапа. Рассказываем, как методы User Story Mapping и MoSCoW могут помочь определиться с фичами для будущего MVP. Если нужны услуги разработки MVP под ключ, команда Purrweb возьмет процесс на себя.

Погодите-погодите, а что такое MVP?

MVP расшифровывается как минимально жизнеспособный продукт (MVP — англ. minimum viable product), концепция используется для  тестирования бизнес-идей. Идея MVP в том, чтобы упаковать ключевые функции в какую-то простую (и, что важно, симпатичную) продуктовую версию, а после проверить на рынке. Подробнее об MVP и этапах его разработки читайте в нашей статье.

Хочу максимально качественный фидбек! Про User Story Mapping и MoSCoW

Как определиться с функционалом для минимально-жизнеспособного продукта? Это всегда большой вопрос. Нужно найти баланс между «минимальным» и «полезным», при этом не забывая про качество. Мы выбрали две тактики, которые облегчат процесс отбора функций для вашего MVP.

User Story Mapping — метод, который воссоздает «путь» пользователя по MVP. Благодаря User Story Mapping вы можете проследить за всеми вариантами взаимодействиями с продуктом: от первого запуска до целевого действия (например, покупки).

Техника состоит из 5 шагов:

1. Определите цель. Ответьте на вопрос «А для чего я это делаю?» Ответ должен быть коротким, не больше одного предложения. Например, цель нашего стартапа с тортами для свадьбы – сделать онлайн-магазин десертов с веганским тестом, вкусной начинкой и быстрой бесконтактной доставкой.
2. Продумайте маршрут пользователя по вашему MVP. Куда он будет нажимать? Какие разделы открывать? Какие шаги проходить? На этом  этапе важно поставить себя на место пользователя и продумать все возможные сценарии.  Например, чтобы купить торт в нашем приложении, пользователь проходит путь в 5 этапов: просмотр, предоставление адреса и инструкций по доставке, управление заказом, оплата и доставка.
3. Пропишите функции для каждого шага. К примеру, для того, чтобы выбрать торт в приложении, вам понадобится каталог свадебной выпечки, с разными кремами и посыпками, а также панель поиска, страница настройки и  с бестселлерами (для тех, кто не может определиться) и т.д. Для оплаты понадобятся разные варианты оплаты: дебетовая/кредитная карта, Apple Pay, Google Pay или PayPal. Все это нужно обязательно прописать и продумать, в первый релиз многое может не попасть, однако в последующих версиях продукта эти опции могут очень даже пригодиться.
4. Расположите функции по убыванию от «MVP без этого не вывести в релиз» до «можно стартануть и так». Главные критерии ранжирования — насколько та или иная  фича поможет в достижении целевого действия. Например, для того же приложения с тортами выбор «того самого» украшения стола не будет возможен без каталога и панели поиска. А вот страницу с бестселлерами можно добавить позже.
5. Соберите MVP. В первую версию войдут функции с высоким приоритетом — то, без чего вы точно не сможете вывести продукт в релиз.

User Story Mapping — это не панацея. Альтернативой можно считать метод приоритизации MoSCoW. Никакой отсылке к родной (и нерезиновой) Москве тут нет. Это аббревиатура, представляющая функционал с учетом приоритетов — все, что так или иначе может (или не может) оказаться в вашем MVP.

Чтобы отделить важное от «хотелок», вы и ваша команда договариваетесь о критериях отбора — польза для клиентов, сложность выполнения, стоимость реализации. Всё это очень важно выяснить на берегу.

А теперь пробежимся по категориям, которые нам предлагает MoSCoW:

1. Must-have — самая важная категория. Сюда попадают фичи, без которых релиз продукта просто невозможен. Выясните с командой: а будет ли выполнено целевое действие пользователя, если мы не добавим эту фичу? Если ответ «нет», смело включайте ее в первый релиз. Например, для нашего стартапа с тортами критично важно внедрить фичу «Заказать торт на дом» — иначе для чего лопатиться с выбором начинки?
2. Если вместо четкого «да» всплывает нечто вроде «вероятно, да», то скорее всего вы пришли к категории Should-have. Сюда попадают все функции, которые также являются важными и ценными, однако первый релиз может состояться и без них. Для стартапа с тортами такой фичей стала бы фильтрация для поиска десертов с пометкой «Без глютена».
3. Категорию Could-have также называют «nice-to-have». Сюда закидываем все, что «хотелось бы сделать», но из-за нехватки ресурсов вы этого не сделаете — более того вывести MVP на рынок можно и без этих фич. Например, было бы здорово добавить возможность выбирать приоритетную доставку тортов и получить заказ самыми первыми. Для нас это могло бы стать дополнительным вариантом прибыли, но давайте честно – на этапе тестирования идеи это не так уж и необходимо.
4. Will-not-have – это абсолютно не критичные для релиза фичи. К примеру, клиентам магазина с тортами было бы интересно добавлять оценки и комментарии к каждому виду начинки, вроде “это понравится любителям шоколада”, “текстура ванильного крема супер бархатистая”. Однако, пока нам это не нужно и эту идею можно отложить в дальний угол и сосредоточиться на других категориях.

Функции из категории must-have будут вашим «тестом» — именно это отправится в первый релиз. Все, что попало в категории с более низким приоритетом, также советуем записать — к этому вы вернетесь потом, когда выведете MVP на рынок и получите обратную связь. Кто знает, может 80% вашей аудитории попросят вас именно о приоритетной доставке тортов? Узнаете наверняка, когда передадите MVP в руки целевой аудитории.

Подведем итоги

Пока вы читали эту статью, в мире закрылось около 126 стартапов. Не позволяйте вашей идее закончиться неудачей! Настоятельно рекомендуем  ответственно относиться к MVP — тестировать продукт и анализировать фидбэк пользователей. Методы User Story Mapping и MoSCoW помогут расставить приоритеты и упростить процесс отбора функций для будущего стартапа.

И помните: количество имеет значение! Чем больше обратной связи вы получите после запуска MVP — тем выше шансы на успех