User Story Map как инструмент управления ожиданиями и не только: практические советы
Привет! Нас зовут Катя Черных и Маша Вострикова, мы бизнес-аналитики в Х5 Tech. Мы любим инструмент User Story Map (карта пользовательских историй или USM), проводим по нему воркшопы в X5 и хотим поделиться своим опытом.
В статье рассказываем, как на этапе Discovery (начальный этап проработки задачи, на котором выявляются основные требования и анализируются поставленные бизнес-цели) прорабатывать большие инициативы, используя USM.
Фокус делаем на практическом использовании карты и на что обращать внимание при построении USM. Мы собрали возможные сложности, разобрали конкретные кейсы и описали варианты взаимодействия с заинтересованными лицами.
Краткая теория по USM
USM –это карта пользовательских историй, в основе которой лежит путь пользователя, и которая позволяет визуализировать этапы развития поставляемого решения.
Говоря более простым языком, подход USM помогает декомпозировать поставленную задачу на отдельные User Story и разложить их на карте, чтобы выстроить единое понимание масштаба и этапов реализации решаемой задачи.
В основном USM применяется для больших инициатив, где процесс достижения поставленной цели включает хотя бы несколько шагов.
Небольшая шпаргалка с разъяснением, на каком этапе и как именно нам может пригодиться карта:
Когда использовать? | Зачем? |
на этапе Discovery | — декомпозиция задачи — осознание масштабов задачи — держать фокус на целях и задачах пользователя |
на этапе согласования задачи | — сформулировать единое понимание, что должно быть сделано для достижения цели — выделить самое важное для запуска продукта — MVP (минимальный жизнеспособный функционал) — собрать Backlog и при необходимости разделить его на релизы |
на этапе проектирования и передачи в разработку | — донести до команды целостное представление о продукте/инициативе — учесть при проектировании будущие планы по развитию продукта/задачи с дизайнером, архитектором, командой разработки |
Пример, на котором будем тренироваться — USM для процесса покупки товаров через кассы самообслуживания в розничных магазинах.
Напомним, что USM включает в себя 4 уровня декомпозиции:
Процесс проработки задачи через USM
Рассмотрим процесс проработки инициатив с помощью USM, который состоит из следующих этапов:
1. Подготовка драфта USM
Приступать к построению USM нужно на этапе Discovery, но только тогда, когда понятны:
цели, которые нужно достичь в рамках поставленной задачи;
роли/персоны, для которых разрабатывается задача;
последовательность действий, которые необходимо выполнить; ролью/персоной для достижения поставленных целей.
Для определения потребностей и ключевых этапов продукта/проекта необходимо провести встречи/интервью с заказчиком и заинтересованными лицами. При наличии артефактов Impact Map (IM), Customer Journey Map (CJM) можно заимствовать информацию оттуда.
Материалов на тему «Как построить USM» довольно много, например:
В ходе построения карты вы будете сталкиваться с различными вопросами, идеями, сложностями и т. д. Рекомендуем их фиксировать в самой USM для дальнейшей проработки самостоятельно/с командой/с заказчиком.
По итогу подготовки драфта USM будем иметь:
Одну/несколько карт USM c персонами и декомпозированным функционалом.
Набор вопросов/комментариев по US картам.
Идеи по функционалу, которые помогут ускорить/упростить реализацию задачи.
2. Предварительное обсуждение с командой
После подготовки драфта USM на встрече с командой оценивается сложность пользовательских историй карты. Эта информация поможет заказчику/владельцу продукта при приоритезации и выделении MVP.
Данный этап нужен, если есть необходимость получить оценку сложных задач, где непонятна реализация. Предварительное обсуждение можно проводить со всей командой разработки или точечно обсудить вопросы по функционалу.
На этом этапе важно:
Оценить риски, которые могут возникнуть при реализации задачи.
Подтвердить идеи по ускорению/упрощению реализации задачи.
Определить сложность каждой US из карты.
Есть практика, что одна US должна выполнять не более одного спринта. Поэтому при оценке сложности возможна декомпозиция US и добавление US на дизайн.
При обсуждении карты с командой нужно быть аккуратным:
Можно сформировать неправильные ожидания, так как то, что обсуждается, может не попасть в MVP. Поэтому команде лучше пояснить, что USM может изменяться.
Может появиться неправильное понимание задачи и уход в детали, которые на данном этапе ещё не проработаны. Для этого необходимо помнить о целях встречи, останавливать полёт фантазии.
3. Приоритезация с бизнесом и выделение MVP
Приоритезация происходит в диалоге с заказчиком\владельцем продукта\командой\лидами, чтобы:
Согласовать список функционала, который нужно выполнить в рамках задачи.
Выделить MVP (минимальное количество US, которые помогут достичь поставленную цель) и спланировать ближайшие этапы реализации.
На этом этапе важно:
управлять ожиданиями Заказчика\Владельца продукта;
подсвечивать риски при отказе от реализации US;
не склонять к какому-то решению, а предоставить всю необходимую информацию для принятия решения.
Принятие решения о включении US в MVP выполняется не только вследствие понимания важности задачи для бизнеса, но исходя из сложности её реализации. Тут пригодятся оценки/идеи по ускорению, которые мы подготовили шагом ранее.
Все принятые решения сразу же визуализируются в USM.
Также необходимо придерживаться следующих идей:
Лучше сделать меньше и быстрее
Не забывать о ценности истории. Это поможет сохранить фокус при выборе вариантов реализации, проверке целостности декомпозиции
Помнить, что когда переносим истории на другой релиз, то берем на себя риски по увеличению нагрузки на поддержку, увеличения объема тех.долга, снижения лояльности и так далее
Знать, что есть разные способы приоритезации, которые помогут закрыть потребность быстрее. Они будут ниже
После выделения MVP можно приступать к детальному описанию приоритетных US. Полученной информации обычно достаточно, чтобы подготовить бриф, если это необходимо.
4. Презентация MVP задачи команде
После обсуждения и согласования карты USM с заказчиком необходимо презентовать итоговый план реализации команде разработки.
Для этого предварительно необходимо провести анализ US, входящих в первый этап реализации (MVP). На данном этапе прорабатываются варианты решения, описываются US+AC, согласуются бизнес-требования с заказчиком. Возможно привлечение дизайнера при необходимости.
Общая встреча с командой разработки инициируется аналитиком по готовности бизнес-анализа. На встрече будьте готовы ответить на вопросы со стороны команды, касающиеся описанных US.
Данный этап позволяет:
выровняться с командой по ожиданиям и приоритетам заказчика;
оценить масштабы MVP, и при необходимости, других этапов;
предварительно распланировать спринты с учётом иных приоритетов команды и оценить реальные сроки реализации MVP.
Если в дальнейшем в процессе проработки задачи мы понимаем, что желаемые сроки от заказчика недостижимы, мы возвращаемся к бизнесу для обсуждения и совместного принятия решения.
При переходе на следующие этапы реализации стараемся поддерживать карту в актуальном состоянии.
Практические кейсы при построении USM
1. Не бояться сделать карту неправильно
При построении USM много внимания уделяется вопросу: «А идеально ли я делаю USM?»
Не забываем, что USM, в первую очередь, это инструмент для погружения в задачу. И если вы начали погружаться с уровня ролей процесса, то почему бы и нет? Или с шагов процесса — тоже имеет место быть! На старте вы описали процесс более крупными мазками, затем детализировали — отлично! А если наоборот? Тоже применимо!
При погружении в задачу гранулярность US, шагов и целей, скорее всего, будет меняться, и в итоге вы остановитесь на той, в которой вам будет комфортно работать/обсуждать задачу с командой и бизнесом.
Главное — не бояться сделать первые шаги в USM!
2. Правильно формулировать US
Важно, чтобы формулировка показывала, какую ценность принесёт эта US для роли, и как это повлияет на закрытие поставленной бизнес-цели. Нейминг должен включать глагол или существительное, отражающие действие, которое будет совершено пользователем:
3. Стараться придерживаться хронологии процесса с учётом ценности каждого шага
В процессах, где это возможно, необходимо придерживаться хронологии. Это позволит не упустить этапы процесса, увидеть созависимые US при приоритезации и сделает карту более наглядной и читабельной.
Если же процесс имеет параллельные этапы, которые нельзя объединить под одной ценностью, придется пренебречь правилом «чёткой хронологии». Для этого на карте необходимо отобразить каждый из параллельных этапов друг за другом, при этом соблюдая хронологию внутри каждого. Последовательность этапов определяется на ваше усмотрение.
Если процесс имеет несколько сценариев выполнения, т. е. вариативность последовательности шагов, то рекомендуется отображать активности на карте в том порядке, который вам кажется более понятным и логичным.
Например, для касс самообслуживания после добавления товаров в виртуальную корзину и до начала оплаты можно менять количество товаров и применять скидки. Чёткой последовательности у данных действий нет, но на карте эти активности будут отображены один раз в выбранном на усмотрение автора порядке:
4. Не дублировать один и тот же функционал на карте
Если один и тот же функционал используется в разных местах процессах, то он описывается один раз, чтобы не создавать дублирующие US.
Например, функция «Вызвать сотрудника для помощи» на кассах самообслуживания может быть доступна в любом месте процесса, поэтому её стоит описать один раз в «самом удобном/логичном», по вашему мнению, месте процесса:
5. Обращать внимание на ценность схожего функционала
Если у нескольких US есть общая ценность, которую можно закрыть разными способами, и не важен порядок выполнения US, то удобнее создать одну активность и собрать в ней эти US.
Например, на кассах самообслуживания добавить товар в виртуальную корзину можно несколькими способами: отсканировать, выбрать из каталога, взвесить. При этом у всех US есть общая ценность — добавить товар в корзину. Если все US собрать под одной активностью/ценностью, то карта получится менее громоздкой, и при этом процесс не нарушится.
Если есть схожий функционал и он имеет разную ценность, то создаются несколько активностей.
Например, действие «Добавить пакет в корзину» можно совершить несколькими способами:
Покупатель самостоятельно добавляет пакет по кнопке.
Покупатель принимает предложение системы по добавлению пакета при переходе к оплате.
Если для этих US мы можем выделить разную ценность и US еще находятся на разных этапах процесса, то будет правильно сделать две разные активности. Для нашего примера можно выделить две ценности: в самостоятельном добавлении пакета и заботе о клиенте, если он забыл про пакет.
Такой подход поможет в приоритезации и не нарушит хронологию процесса
6. Записывать все US, а не только ближайшие по приоритету
В USM заносятся все истории, даже если они в ближайшее время не будут выполняться.
При этом при построении USM сами US не описываются детально, достаточно стандартной формулировки.
7. Стараться не отражать технические задачи на команду разработки
USM показывает потребности, которые нужно закрыть пользователю, без указания способов реализации. Зная бизнес-ценность технической задачи, её всегдаможно отнести к определённой US на карте.
8. Не перегружать USM
Если USM получается громоздкая и в ней есть параллельные шаги, и/или независимые цели, то можно сделать несколько USM.
Финальное решение остаётся всегда за автором карты, при этом стоит руководствоваться понятностью и здравым смыслом.
Способы приоритезации задач для MVP
1. Перенос
Это самый простой способ, когда реализация US полностью откладывается и переносится на более поздние этапы. Важно проконтролировать, что вы откладываете независимую от других US или разом все зависимые US.
Например, на кассах самообслуживания можно оставить в MVP только оплату товаров со штрих-кодом. Тогда все другие US, где товары добавляются в корзину не по шрих-коду, а из каталога (весовые товары, кофе, приготовленные булочки) переносятся на следующие этапы разработки:
2. Декомпозиция
Упрощение реализации задачи за счет её декомпозиции и выполнения только части функционала.
Например, сначала сделать только получение скидки по карте лояльности, а потом добавить возможность начисления и списания бонусов:
3. Замещение (компенсирующее действие)
Когда цель закрывается, но другим способом. Например, удаление товаров в корзине можно перенести на другой этап, но сначала сделать возможность при изменении количества указывать ноль. Такое решение может использоваться как временное и поэтому влечёт за собой накопление техдолга.
4. Делегирование (задолженность)
Применяется, когда функционал делается не руками команды, а, например, подрядчиком или функционал выполняется вне системы.
Заключение
В заключении скажем, что USM пишется с целью показать, какие шаги нужно сделать, чтобы выполнить поставленные цели и закрыть потребности пользователя. На ней визуально раскладываются задачи и договорённости, полученные в результате взаимодействия всей команды.
Также хотелось бы обратить внимание на риски из-за отказа от USM в работе над задачами:
Если пренебречь приоритизацией US, возникнет опасность смещения акцента с важных функций на малозначимые.
Отсутствие декомпозиции задачи может привести к неправильной оценке её объёма и сложности реализации.
Из-за недостаточного понимания этапов развития задачи архитектура решения продукта может быть разработана некорректно.
Отсутствие плана по этапам реализации задачи может привести к затягиванию сроков и неэффективному использованию ресурсов.
В связи с чем советуем не пренебрегать таким полезным и простым инструментом, который действительно помогает реализовать крупные проекты/продукты/инициативы.
Habrahabr.ru прочитано 2600 раз
