Известная иллюстрация, раскрывающая понятия 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, оставшиеся функции могут оказаться многосоставными, то есть они раскладываются на более мелкие.
Одним из первых это заметил Джефф Паттон и предложил один из лучших методов декомпозиции функциональности – картирование пользовательских историй (User Story Mapping), который он подробно описал в своей книге.[37]
Для этого функции продукта описываются в формате пользовательской истории (User Story[38]). Пользовательская история – способ описания функциональности в форме прямой речи с позиции пользователя. Шаблон описания такой: «Я как роль могу действие, чтобы ожидаемый результат». Например: «Я как пользователь приложения такси могу привязать платежную карту, чтобы каждый раз не вводить реквизиты заново при платеже».
Трудно описать все особенности метода. О нем очень хорошо изложено в книге, хотя мне, чтобы овладеть им, после прочтения потребовалось несколько сессий под руководством профессионалов. Основная идея заключается в том, что функциональность предстает в виде матрицы, где по горизонтали идут шаги, необходимые для достижения цели, а по вертикали – желательные особенности этого шага. После построения матрицы детали сортируются по принятым в команде критериям: важности для пользователя, важности для бизнеса и т. д. Далее выделяется MVP внутри отдельной функции.
У карты пользовательских историй (User Story Map) несколько уровней. Уровень типов пользователей, уровень активностей – это части маршрута, которые можно запускать по отдельности в разных релизах. Уровень нарратива – обязательная последовательность шагов. Уровень деталей – последовательность желательных особенностей на данном шаге
Шаблоны декомпозиции
Функциональность, описанную в виде пользовательских историй, можно декомпозировать при помощи не только картирования, но и других приемов, ставших уже шаблонными.
Например, разбиения по операциям. Тогда пользовательская история: «Я как пользователь могу управлять списком привязанных платежных карт, чтобы каждый раз не вводить реквизиты заново при смене источника платежа» раскладывается на пять историй, связанных с операциями при работе со списком: добавление, удаление, чтение, редактирование и выбор элемента. Одна из историй будет такая: «Я как пользователь могу добавить карту в список, чтобы каждый раз не вводить реквизиты заново при смене источника платежа».
Популярная диаграмма, описывающая цикл декомпозиции пользовательских историй
Пример декомпозиции пользовательской истории
В качестве примера декомпозиции возьмем историю: «Я как пользователь приложения такси могу привязать платежную карту, чтобы каждый раз не вводить реквизиты заново при платеже».
Пример того, какой интерфейс может спроектировать UX-дизайнер, не прибегая к шаблонам декомпозиции:
Теперь проведем декомпозицию и посмотрим, как изменится финальный дизайн.
Для начала прибегнем к разбиению по операциям и разделим работу со списком привязанных карт по известному акрониму CRUD: Create (добавить элемент), Read (просмотреть), Update (редактировать), Delete (удалить). В нашем случае добавляется еще одно действие – выбор активной карты, то есть к акрониму прирастает еще одна буква: CRUD+S, где Select – выбрать