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

Одним из первых это заметил Джефф Паттон и предложил один из лучших методов декомпозиции функциональности – картирование пользовательских историй (User Story Mapping), который он подробно описал в своей книге.[37]

Для этого функции продукта описываются в формате пользовательской истории (User Story[38]). Пользовательская история – способ описания функциональности в форме прямой речи с позиции пользователя. Шаблон описания такой: «Я как роль могу действие, чтобы ожидаемый результат». Например: «Я как пользователь приложения такси могу привязать платежную карту, чтобы каждый раз не вводить реквизиты заново при платеже».

Трудно описать все особенности метода. О нем очень хорошо изложено в книге, хотя мне, чтобы овладеть им, после прочтения потребовалось несколько сессий под руководством профессионалов. Основная идея заключается в том, что функциональность предстает в виде матрицы, где по горизонтали идут шаги, необходимые для достижения цели, а по вертикали – желательные особенности этого шага. После построения матрицы детали сортируются по принятым в команде критериям: важности для пользователя, важности для бизнеса и т. д. Далее выделяется MVP внутри отдельной функции.

У карты пользовательских историй (User Story Map) несколько уровней. Уровень типов пользователей, уровень активностей – это части маршрута, которые можно запускать по отдельности в разных релизах. Уровень нарратива – обязательная последовательность шагов. Уровень деталей – последовательность желательных особенностей на данном шаге