UX/UI дизайн для создания идеального продукта. Полный и исчерпывающий гид

Известная иллюстрация, раскрывающая понятия MVP и MVR (Minimal Viable Release, минимально жизнеспособный релиз); на каждом этапе пользователи получают новые функции, что, безусловно, сказывается на их опыте

Как определить, какие функции должны входить в очередную поставку?

Чтобы отобрать функции для MVP, нужно сначала отсортировать все функции по приоритетности и затем, двигаясь от наиболее приоритетных к наименее приоритетным, определить набор, с которыми продукт будет минимально жизнеспособным. Иногда для запуска достаточно одной самой важной функции.

Существует множество способов приоритизировать функциональность – выбор зависит от скорости, с которой необходимо принять решение, и цены ошибки. Рассмотрим некоторые из них.

Быстрая приоритизация

Я использую быструю экспертную «рубашечную» оценку. Скажем, на стратегической сессии я выбираю трех экспертов, каждый из которых отвечает за свой критерий: важность для пользователей, важность для бизнеса, легкость технической реализации, и прошу их в размерах рубашек (S, M, L, XL) оценить каждую функцию.

Пример «рубашечной» сортировки функций по трем критериям: важности для пользователя, важности для бизнеса, трудозатрат в производстве

Пример того, как функции отсортированы по трем критериям. Здесь еще есть привязка к типам пользователей и контексту их опыта

Качественная приоритизация

Очень важно, чтобы все участники производственного процесса понимали, на чем сейчас правильнее всего сфокусироваться. Интуитивно кажется, что приоритетнее всего та инициатива, что окупится быстрее всего. Но может получиться так, что, занимаясь быстро окупаемыми инициативами А1, А2 и А3 и откладывая инициативу B1, мы можем потерять больше, чем если сразу займемся инициативой B1; цена просрочки по ней превышает доходы от А1, А2, А3. Одни инициативы спокойно ждут целый год, а другие откладывать нельзя ни на минуту, так как у них разная цена задержки.

Ожидаемая окупаемость инициативы составляла примерно пять месяцев, но после задержки длиной в шесть месяцев изменились рыночные условия – появилось много конкурентов, которые оттянули на себя часть пользователей. В итоге окупаемость была достигнута примерно через восемь месяцев

Следовательно, по каждой инициативе в портфеле можно начертить аналитический график стоимости месяца задержки.

Варианты графиков стоимости задержки:

• с ежемесячными тратами – если у вас есть квартира, которую вы не сдаете, то вам придется ежемесячно оплачивать коммунальные платежи;

• с фиксированной датой – если вы не успеете запустить сайт чемпионата мира к чемпионату мира, вы потеряете все;

• стандартная кривая – в большинстве случаев с каждым месяцем задержки рыночные условия ухудшаются, а из-за того, что конкуренты выступают с аналогичной инициативой, уменьшается ваш доход;

• неуловимый – в мире инноваций задержка может свести все старания к нулю.

Сопоставляя графики стоимости задержки между собой, всегда можно определить ту инициативу, которой нужно заняться прежде всего.

Метод, основанный на оценке стоимости задержки, требует сложного математического моделирования и потому редко применяется для приоритизации функциональности. Чаще его используют для работы с более крупными сущностями, например, чтобы определить очередность запуска продуктов внутри продуктового портфеля или очередность эпиков.[36]

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

Выделение MVP

После сортировки можно определить объем первого релиза – MVP. В этом случае мы начинаем «выпаривать функциональность» – убирать по одному стикеру-функции снизу, анализируя, остается ли финальный продукт жизнеспособным.

Пример Lean Project Canvas

Если для этапа генерации используется Business Model Canvas или его вариации – Opportunity Canvas, Lean Project Canvas и т. д., – то «рубашечная» производится в квадрате Possible Solutions (возможные решения).

Снимая стикеры снизу-вверх в поле Possible Solutions, мы снимаем связанные с ними стикеры из других полей. Если в каком-то поле остается лишь один стикер, то его убирать нельзя – в противном случае это будет означать, что продукт перестает решать проблему (поле Problem), приносить прибыль (поле Business Value) и т. п.

В результате в полях холста остаются только те элементы, что обеспечивают решению максимальную жизнеспособность

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

Картирование пользовательских историй (User Story Mapping)

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