Из любопытства я поискала на hh объявления с аббревиатурой USM (User Story Map). Поделюсь наблюдением за формулировками:
• Бизнес-аналитик должен знать USM как принцип дизайн-мышления, а в соседней вакансии как «построение моделей и алгоритмов»,
• Продуктовый дизайнер должен понимать как метод исследований,
• Аналитик в отделе маркетинга должен владеть USM для планирования задач,
• Менеджер продукта должен понимать USM как ключевой артефакт продукта,
• Еще один системный аналитик Middle должен знать USM как метод декомпозиции задач.
Выглядит так будто наниматели не определились, что это такое.
Открыла книгу Джеффа Паттона «Пользовательские истории. Искусство гибкой разработки ПО», из которой когда-то узнала об этих картах, и на первых же страницах в предисловии Мартина Фаулера выбрала формулировку, которая мне ближе:
Построение карт историй (story mapping) — это техника, позволяющая увидеть цельную картину, чего не удастся сделать с помощью простого набора историй.
Эта техника задумана для коммуникации между всеми участниками продукта, для выработки единого понимания ими функций и задач по разработке. Честно говоря, мне только однажды повезло применять карту историй по ее прямому назначению. Для предварительной оценки трудозатрат нужно было увидеть общую картину продукта. Это было важно, чтобы принять решение запускать продукт в разработку или нет. В том числе понять, нужно ли инвестировать время в выявление детальных требований. Для такой задачи как раз хорошо подошла карта пользовательских историй, которую мы построили за 2 трехчасовые встречи с представителями заинтересованных сторон. Этого было достаточно, чтобы понять стоимость разработки и отказаться от продукта 😊
Авторы книг и статей советуют составлять User Story Map на общих встречах (story-writing workshops) с участием команды, владельца продукта и представителей других заинтересованных сторон. В реальности, ее редко применяют именно так, отсюда и различия в формулировках вакансий:
• где-то сначала заводят задачи в Jira и уже после этого представляют их в виде карты,
• где-то карту составляет аналитик на свое усмотрение по информации от заказчика,
• где-то карту используют только дизайнеры, чтобы упорядочить информацию от заинтересованных сторон.
Если коротко, то карта составляется в несколько шагов:
📍Определить название и цели процесса
📍Выделить роли участников
📍Определить верхнеуровнево шаги процесса или задачи пользователя, нужные для достижения цели. Разместить их на карточках горизонтально слева направо в порядке выполнения от начала к завершению
📍Определить истории в рамках каждого шага. Разместить их на карточках вертикально под каждым шагом.
📍При необходимости определить задачи, необходимые для разработки историй (необходимость зависит от целей составления карты).
📍Расставить приоритеты ранжированием (например, методом MoSCoW)
Книга Джеффа Паттона о User Story Mapping вышла в 2014 году и с тех пор написано много инструкций и примеров применения. Выбрала три статьи:
🔖Статья от Майка Кона с детальным описанием построения User Story Map. Работа с картой описана по шагам с примерами в картинках и рекомендациями к применению (ENG).
🔖Статья 8 шагов, чтобы построить карту пользовательских историй. Еще одно короткое пошаговое описание. Здесь гораздо меньше деталей, чем у Кона, но как памятка вполне подойдет (ENG).
🔖Как сторимэп помогает не завязнуть в разработке нового продукта на годы. Кейс от «Додо пицца», опубликованный в 2017 году. Очень понравился примерами и фото.
Читайте о бизнес-анализе в Телеграмм
