Меня зовут Наталья Кобякова, я Product owner и техлид клана аналитиков в Ak Bars Digital. В этой статье я расскажу, почему для проектирования функциональности наших продуктов вместо стандартных ТЗ мы используем методологию User Story Mapping и как это помогает нам вести разработку быстро и качественно.
Дисклеймер: в статье я не призываю окончательно и бесповоротно отказаться от ТЗ, но хочу сказать, что классическое ТЗ подходит не во всех ситуациях, и не для всех команд разработки.
Мифы о ТЗ
Главный миф о ТЗ — техническое задание жизненно необходимо, чтобы разработка любого цифрового продукта была выполнена качественно, а без него все будет как на картинке.
В таком подходе написание ТЗ — это отдельный этап разработки, на выходе из которого появляется подробный, максимально детальный документ, в идеале, написанный по ГОСТ. И без такого документа к команде разработчиков даже подходить нельзя. Даже среди команд, работающих по Scrum, нередко встречаются такие, где задачи на разработку приходят только после подготовки аналитиком ЧТЗ — частного технического задания.
При этом, как правило, все участники процесса забывают, что ГОСТы были придуманы на заре цифровизации. Получается, что они практически не менялись с тех времен, когда ЭВМ были размером с хороший шкаф-купе, память этих монструозных вычислительных машин была как у рыбки, а подходы к разработке были совсем другими.
До сих пор, в межгосударственном стандарте ГОСТ 19.101-77 есть требование прикладывать листинг программ «Текст программы» (физическая распечатка программного кода) наравне с другими обязательными документами, входящими в проектную и рабочую документацию.
Но, зачем?!
Вспомним, что в те давние времена еще не было не только «облаков», AirDrop, GitHub и прочих классных вещей, но даже элементарных дискет. Просто не существовало никакой физической возможности переноса программы с одной ЭВМ на другую. И операторы ЭВМ каждый раз вводили программу вручную, перепечатывая текст из того самого обязательного документа «Текст программы».
Собственно, как наследие тех времен, до сих пор широко распространены каскадная разработка (Waterfall) и подход к документированию по ГОСТ, ставшие актуальными именно в то время. Например, так пишут в Википедии:
«Без рывка в сфере вычислительной техники, сделанного в 1940-е гг. и чётко сформулированного технического задания к разработчикам такого рода, вычислительная техника не развилась бы до современных компьютеров…»
В 1970-х были разработаны стандарты оформления проектной и рабочей документации на разработку ПО, а четко сформулированное ТЗ было не только жизненной необходимостью, но и залогом успеха всего процесса разработки и ввода ПО в промышленную эксплуатацию.
Госзаказчики (и не только они!) и сейчас очень любят писать задания на разработку по ГОСТ — кажется, что это гарантирует качество. Почему? Потому что создает иллюзию того, что ход всего проекта будет под контролем, если все детально задокументировано. А если вдруг в процессе обнаруживаются отклонения, нужно вернуться на шаг назад и начать все заново — с переработки ТЗ.
В условиях отсутствия конкуренции этот подход был вполне оправдан: не сжигаются ресурсы на разработку, не тратится напрасно ценное время работы ЭВМ, все регламентировано и документировано.
Проблемы ТЗ для продуктовой разработки
Применим ли такой подход к разработке в современных реалиях? Применим, но для проектной, а не продуктовой разработки.
В чем же отличия?
-
Проект — всегда конечен, как по бюджету, так и по срокам запуска. Упрощенно: выиграть тендер, написать строгое и четкое ТЗ по требованиям заказчика, выполнить по нему разработку и запуск проекта к заданной дате, и после этого о существовании проекта забыть — это проектный подход. Под проект, как правило, собирается команда, которая будет расформирована или переведена на другие задачи сразу после успешного (или не очень, тут уж как повезет) запуска проекта. И в этом случае разработка с ТЗ оправдана.
-
Продукт — это постоянное развитие. Продуктовая разработка — это непрерывный бесконечный процесс, ставящий перед постоянной командой вызовы: разрабатывать новый продукт, выводить его на рынок, развивать и улучшать, формулировать гипотезы, обновлять интерфейсы, добавлять новые фичи, собирать метрики и на их основе строить новые планы, не имея определенного срока завершения работы. Успешность и готовность продукта измеряются прибыльностью, востребованностью, пониманием потребностей клиентов и готовностью к быстрым изменениям, а потому проектный подход тут практически не применим.
У нас в компании ведется продуктовая разработка кросс-функциональными командами, и наша основная цель — быстрое и успешное развитие продуктов. Поэтому в наших условиях длительное проектирование и написание ТЗ привели бы к существенным потерям: ценности, времени, качества и ресурсов.
Потеря ценности
В проектной разработке, как правило, ТЗ прорабатывает один человек: системный аналитик или технический писатель. Иногда, если компания серьезно ограничена в ресурсах, то даже менеджер проекта.
Этот человек сначала общается с бизнес-заказчиком, собирает набор требований к системе и описывает их в огромном, по объему, документе. При этом, в большинстве случаев, описываемая функциональность системы — это либо личные хотелки заказчика, либо прямое копирование у конкурентов, не подтвержденное исследованиями, гипотезами, опросами, метриками и данными.
По сути, на входе системный аналитик получает набор «галлюцинаций» (отличный термин от ФРИИ), на основе которых проектирует решение, формирует требования и оформляет это всё в ТЗ. Дальше этот документ отправляется на реализацию в команду разработки, вынужденную слепо и максимально точно следовать написанному.
И на деле, аналитик часто не знает, что действительно нужно конечному пользователю, потому что не всегда хорошо погружен в контекст, если вообще погружен.
Потеря времени
В проектной разработке техническое задание — фундамент всего проекта. Ему должно уделяться достаточно времени и внимания, чтобы все заинтересованные стороны убедились: проект будет таким, как планировалось на начальном этапе.
Однако, обычно ТЗ пишется «на конвейере» и в условиях постоянной нехватки времени. Заказчики не считают нужным прочитать его, хотя бы поверхностно, говоря «Ой, я все равно в этом ничего не понимаю», а разработчики не вникают в детали, делая то, что они привыкли делать ранее. В итоге на выходе появляются расхождения между картинкой, придуманной заказчиком, требованиями, описанными аналитиком, и результатом, разработанным командой. И проект уходит на следующий виток с теми же самыми шагами: новое ТЗ, новые согласования, сдвиг сроков запуска.
Потеря качества
Аналитик:
-
не может в одиночестве на этапе проектирования учесть все возможные аспекты разработки;
-
не способен проектировать решения на уровне системного архитектора (и не должен);
-
не отслеживает новые инструменты, фреймворки и тренды разработки, потому что у него времени на это нет;
-
и даже не всегда достаточно технически подкован, чтобы разбираться в сложных программных нюансах.
Увы, мне не так давно еще встречались ТЗ, где интеграция с внешней системой описывалась одной фразой: «ресурс А будет интегрирован с ресурсом Б». То есть, все, начиная с модели данных, заканчивая схемой взаимодействия, оставалось тайной, покрытой мраком.
Конечно, здесь могли бы помочь разработчики, но проектный подход не подразумевает их подключения на стадии ТЗ и ведет к удорожанию проекта, на которое заказчики идти не готовы. В итоге, качество проектирования страдает, качество разработки, как следствие, падает, качество выпущенного проекта оставляет желать лучшего.
Ресурсы разработки ограничены
Если одна женщина способна родить ребенка за 9 месяцев, это не значит, что 9 женщин способны родить ребенка за месяц. С командой разработки работает точно такой же принцип: на качественную разработку сложного комплексного программного решения требуются сильные, опытные разработчики, временной ресурс которых ограничен. И когда разработка ведется строго по ТЗ, далеко не факт, что мы используем этот ресурс оптимально, потому что запуск проекта состоится только после того, как будет выполнена реализация всех задач по ТЗ.
В моем опыте был кейс, когда разработка велась 2 года, и выпущенный «в мир» проект успел за это время морально устареть, хотя задумывался как инновационный.
User Story Mapping: что это такое и в чем польза такого подхода
В нашем рабочем процессе мы активно используем методологию User Story Mapping. USM или карта пользовательских историй — это инструмент проектирования продукта, в основе которого лежит путь клиента. На картинке приведен пример шаблона User Story Map, уже в итоговом, полностью завершенном виде, а ниже рассмотрим, как такая карта составляется.
Как составляется USM?
Работа над картой пользовательских историй состоит из шести основных шагов:
-
Формулируем проблему: что, для кого и зачем мы собираемся делать.
-
Обрисовываем общую картину: смотрим на верхнеуровневые процессы и действия пользователя, проходим по его шагам, двигаясь «на километр вперед, на сантиметр вглубь». Каждое действие фиксируем как отдельный эпик.
-
Исследуем и детализируем истории: изучаем возможные типы пользователей, рассматриваем разные варианты выполнения действий, прорабатываем негативные сценарии — так у нас появляются пользовательские истории, которые можно дополнительно декомпозировать на отдельные задачи.
-
Выделяем релизную стратегию: концентрируемся на том, что в первую очередь нужно бизнесу и людям, для которых создаем продукт. Определяем длительность спринтов, емкость команд, график релизов.
-
Выделяем исследовательскую стратегию: что войдет в MVP, какие гипотезы у нас есть, как мы сможем их проверить. Выделяем те истории, без которых продукт не сможет существовать, и откладываем все, что можно исключить на первом этапе без потери ключевых возможностей.
-
Выделяем стратегию разработки. Делим MVP на части, с точки зрения последовательности разработки так, чтобы как можно раньше все запустить. В итоге мы получаем четкую последовательность задач, разбитых на спринты, и видим, в какие сроки сможем поставлять обновления продукта для наших клиентов.
Как шаги выглядят на практике?
Мы работаем в распределенных командах, где все работают удаленно, а карта пользовательских историй — это инструмент для постоянной работы, поэтому для USM мы используем Miro. Все примеры, которые я приведу ниже, взяты из реальной жизни, с доски одной из наших команд. Итак, пройдемся по шагам нашего процесса.
Формулируем проблему
Недавно в нашем мобильном приложении Ак Барс Онлайн мы решили запустить кросс-продажи кредитных продуктов клиентам банка. Если для банка это дополнительная прибыль, то для клиента — предодобренный кредит без необходимости заполнять длинную заявку, посещать офис и приносить документы менеджеру.
Обрисовываем общую картину
При составлении общей картины мы привлекаем стейкхолдеров, на этом этапе происходит активное взаимодействие владельцев продукта и аналитиков, чтобы совместными усилиями понять, как пользователь взаимодействует с продуктом.
Так, в случае с кросс-продажами, мы прошли по всем шагам оформления кредита, обычно выполняемым клиентами, и составили общую последовательность действий. Наша доска после этого выглядела примерно так:
Исследуем и детализируем истории
После того, как определены шаги, каждый зафиксированный эпик и пользовательскую историю можно и нужно дополнительно декомпозировать, не забывая о ценности для клиента.
Формат пользовательской истории изначально подразумевает формулировку «Я, как пользователь, хочу X, чтобы получить Y». Но для доски в Miro такая фраза слишком длинная, поэтому:
-
в заголовок мы выносим ключевое действие, например «Загрузить документы, подтверждающие доход»;
-
а в описании истории фиксируем «Я, как пользователь, хочу сфотографировать и прикрепить к заявке документы, подтверждающие доход, чтобы сэкономить время и получить одобрение большой суммы без посещения офиса».
Декомпозиция историй выполняется до тех пор, пока каждая из историй не будет отвечать критериям INVEST (независимость, обсуждаемость, ценность, возможность оценки сроков реализации, компактность, тестируемость).
И скелет USM в Miro начинает обрастать деталями:
При декомпозиции историй мы дополнительно ищем ответы на вопросы:
-
кому еще функциональность может быть интересна;
-
какие у нас есть ограничения и какие из них действительно критичны;
-
какие исключительные ситуации могут возникнуть;
-
можем ли мы решить эту же задачу другими способами?
Этот этап — самый важный. Именно здесь можно найти моменты, которые будут вызывать у пользователя wow-эффект при работе с продуктом, и устранить препятствия, кажущиеся уже привычными. Так, например, мы обнаружили, что для зарплатных клиентов банка вовсе не обязательно требовать документы, подтверждающие доход, и клиентский путь для таких клиентов можно сократить втрое, сделав простое определение типа клиента на входе в заявку!
На этом же этапе у нас выполняется оценка трудозатрат на реализацию каждой истории в сторипойнтах (SP). Но тут есть важная деталь: в SP мы оцениваем не столько время, которое будет затрачено на разработку, сколько усилия на решение задач: объемность, сложность, понятность для разработчиков, возможные риски.
Задача по передаче документов на проверку сама по себе не сложная для нашей команды. Но она требует выполнить интеграционное тестирование со смежной системой, в которую должны быть переданы документы, и тестирование всего процесса, от прикрепления документов до получения результатов их рассмотрения, – а это уже существенное усложнение всей истории.
Выделяем релизную стратегию
У нас стандартная длина спринта — две недели, и в каждом спринте емкость команды, занимающейся кредитами (velocity) — 21 SP. Однако, реальная вместимость задач в спринте будет зависеть от количества праздников и выходных дней, а также возможных отпусков разработчиков. Поэтому для определения релизной стратегии важно рассчитать не только емкость команды, но и вместимость (capacity). Например, при средней емкости в 21 SP, в одном из спринтов сразу трое коллег из команды собираются уйти в отпуск, и вместимость составит только 7 SP. В релизной стратегии важно это учесть, потому что это напрямую повлияет на тот объем задач, который команда успеет выполнить в конкретный спринт.
Выделяем стратегию исследований
Определив релизную стратегию и имея набор оцененных задач, мы можем переходить к приоритезации и формировать последовательность, в которой будем реализовывать задачи с учетом их важности для клиентов и прибыльности для бизнеса.
При работе на доске это выглядит как раскладывание историй по спринтам с учетом их оценки и вместимости команды в конкретном спринте. На выходе из этого этапа мы получаем цельную картину, понятную не только разработчикам и аналитикам, но и стейкхолдерам, без необходимости вчитываться в детальную документацию. На такой доске сразу видно, что делаем, когда и какой результат получим.
А дальше идет разработка и реализация с командой, но это уже другая история…
Как USM закрывает проблемы?
Когда мы составляем карту пользовательских историй, мы разбираем каждый шаг клиента, и не просто понимаем, чего он хочет, но и с какой целью. А уже на основе проработанных пользовательских целей и потребностей разрабатываем и формализуем требования к системе. При разработке функциональности по этим требованиям мы планируем работы так, чтобы ресурсы разработки использовались максимально эффективно. Давайте сверим, как же USM закрывает проблемы, которые были описаны выше?
Постоянно помним о ценности
Мы разрабатываем USM на основе ценности для клиента, и весь бэклог основан на пользовательских сценариях. Для разработки всегда выбираем только то, что действительно важно для пользователя и несет ценность для бизнеса.
Экономим время
Очевидно, что при таком подходе нет лишней работы ни в каждом спринте, ни в целом. Мы делаем только то, что действительно необходимо для достижения наших целей, не тратим время на описание лишних фич в ТЗ. А благодаря гибким методологиям, мы можем оперативно пересмотреть наши планы, если поймем, что сформулированные гипотезы не подтвердились метриками и мы идем куда-то не туда.
Сохраняем высокое качество разработки
Пользовательские истории прорабатываются всей командой в ходе совместных обсуждений. История считается готовой к разработке только после того, как каждый член команды подтверждает, что ему все понятно, договоренности о реализации достигнуты, критерии приемки определены, и вся команда с ними согласна. Такой подход позволяет сохранять высокий уровень вовлеченности команды и заинтересованности в конечном результате.
Почему мы выбрали User Story Mapping?
Важно! Такой подход не отменяет документацию.
Все описанное не означает, что у нас вся документация ограничивается доской в Miro или строится на устных договоренностях в команде. Просто мы идем от обратного: не пишем ТЗ и не ставим по нему задачи.
Сначала мы формулируем истории и описываем пользовательские сценарии, затем обсуждаем вместе с командой критерии приемки, технические заметки, описание обработки ошибок и способы решения, детали реализации, и уже потом подтверждаем все договоренности и формализуем их в Confluence.
Как итог получаем и готовую документацию, и список задач. При этом каждый член команды знает, что он делает и зачем, и у каждого члена команды есть единое понимание бизнес-контекста.
Главное в USM для нас — это гибкость и адаптивность, формирование особой культуры разработки, когда каждый участник команды понимает свою роль, предлагать оптимальные варианты реализации, может влиять на результат, а не просто пишет код по ТЗ.
Статья подготовлена на основе моего выступления «User story map — карта поиска сокровищ при создании MVP» на митапе Three Amigos Talk. Переходите по ссылке, смотрите мой доклад и другие, возможно, будет интересно.
USM на примере: как построить и как использовать для формирования бэклога продукта. Четвертая статья из серии инструкций по инструментам, которые помогут сделать лучше ваши продукты и жизнь клиентов.
→ Аудио-версию этой статьи вы можете прослушать на канале Listen IT
User Story Mapping (USM, карта пользовательских историй) – инструмент целостного проектирования продукта на основе пользовательского пути.
Для чего применяется USM?
- Для проектирования пользовательского опыта в продукте
- Для определения границ MVP (минимальной работоспособной версии продукта) и планирования релизов на базе пользовательского сценария
- Для формирования единого понимания пользователя у команды разработки и заинтересованных лиц
Как построить User Story Mapping?
Для построения USM вам потребуется:
- Инструмент визуализации: стикеры или электронный инструмент вроде Miro или Mural
- Владелец продукта и команда разработки
- Представление о пользовательском сценарии (если у вас уже есть построенный CJM – берите его за основу)
- 1-2 часа
Ваша задача — спроектировать по шагам действия пользователя в продукте на основе его реального сценария.
Еще 50 инструментов для владельца продуктаОписания продуктовых практик и подходов, сгруппированные по 7 темам, от Дмитрия Кустова
Темы: анализ рынка, сегментация, описание и исследование клиентов, проектирование решений, управление бэклогом, управление продуктом, метрики.
Рассмотрим USM на примере
Магазин цветов решил запустить сайт. Визуализируем опыт клиентов с помощью техники USM.
- Расскажите историю клиента по шагам
- Сгруппируйте действия клиента в этапы
- Заполнение пробелов в истории (User Story)
- Приоритезируйте истории внутри каждого этапа пути
- Выделите релизы
- Насладитесь приоритизированным бэклогом
Обратите внимание, что итоговый приоритет определяется сценарием пользователя. Мы идем слева направо, и только затем по версиям – ведь мы хотим принести больше ценности пользователю. А для пользователя, как правило, ценность тем выше, чем более полно наш продукт закрывает его сценарий.
User Story Mapping – мощный инструмент, позволяющий команде разработки за пару часов взглянуть на бэклог продукта глазами пользователя.
Мы учим строить USM на тренинге «Владелец продукта: краткий курс выживания».
P.S.: Серию статей про продуктовые инструменты Роман Баранов и Дмитрий Кустов пишут, используя технику pair writing.
Подключайтесь к Telegram-каналу, где Дмитрий делится практиками и опытом.
Авторы
Agile Coach и LeanStartUp-практик с опытом работы в ИТ и в производственной сфере.
Вырастил более сотни Владельцев Продуктов в производственной, банковской, ИТ и пищевой отраслях.
Подробнее о Дмитрии
Роман Баранов
Партнер ScrumTrek. Руководитель программ корпоративной акселерации. В качестве ментора обучает резидентов стартап-акселераторов подходам Customer Development, Agile и Lean StartUp.
Подробнее о Романе
Другие статьи
Менеджер продукта vs владелец продукта: навыки и полномочия
Заключительная часть цикла из 4-х статей про менеджера продукта и владельца продукта, которая поможет вам понять ландшафт продуктового менеджмента.
Lean Canvas: инструкция по применению
Lean Canvas на примере: как построить и как использовать для формирования продуктового видения. Пятая статья из серии инструкций по инструментам, которые помогут сделать лучше ваши продукты и жизнь клиентов.
Как найти владельца продукта внутри компании
Чем грозит неправильное определение владельца продукта, как найти людей, между которыми распределены его функции сейчас, и понять, кто из сотрудников сможет взять все обязанности на себя.
Вы или ваш клиент придумали востребованный продукт и готовы запускать разработку. На первом шаге сталкиваетесь с вопросами: с чего начать? Как сформировать бэклог задач? Что взять в работу в первую очередь?
Инструмент User Story Map поможет правильно сформировать бэклог задач, приоритизировать его и выпустить в мир первый релиз с самыми нужными фичами.
User Story Map — это инструмент визуализации пользовательских историй и проектирования продукта на основании пользовательского пути.
Итак, как составить User Story Map?
Шаг 0. Подготовьте все необходимое
Выберите инструмент, в котором вам удобно будет визуализировать пользовательские истории. Это может быть miro, ватман со стикерами или любой другой знакомый вам инструмент.
Шаг 1. Сформируйте историю пользователя по шагам
Верхнеуровнево напишите, что делает пользователь в интернет-магазине (или в той системе, проектированием которой вы занимаетесь).
Шаг 2. Выписанные действие сгруппируйте в этапы
Объедините по смыслу выписанные действия пользователя по этапам.
Шаг 3. Дополните историю
Если вы видите, что на каком-то из этапов истории пропущены какие-то действия — именно на этом этапе необходимо их учесть.
Теперь у нас есть фич-лист — список функций, которые должны быть реализованы.
Чтобы фич -лист стал бэклогом, его необходимо приоритизировать.
Шаг 4. Приоритизируйте истории
А вот тут начинается самое интересное. Как приоритизировать фич-лист? Как разобраться, что должно быть реализовано в первую очередь, а что можно оставить на последующие релизы?
Все очень просто! Для того, чтобы приоритизировать бэклог, необходимо ответить себе не несколько вопросов:
- Что нужно сделать обязательно?
Без чего продукт будет нежизнеспособен? Без каких фич пользователь не сможет достичь цели, ради которой разрабатывается продукт?
Это те фичи, без которых создание продукта не имеет смысла, то есть обязательный минимум. - Что хорошо было бы сделать?
Какие фичи принесут пользователю пользу, удобство? Позволят быстрее принимать решение? - Что можно сделать? (А можно и не делать)
Отсутствие каких фич пользователь может и не заметить?
Шаг 5. Укомплектуйте релизы
Отлично! Теперь мы знаем, без чего продукт не может существовать.
Теперь комплектуем релизы, опираясь на расставленные нами приоритеты.
Готово!
Теперь ваша команда может посмотреть на бэклог продукта глазами пользователя (это важно!).
Обратите внимание, что итоговый приоритет определяется сценарием пользователя. Наша задача — дать пользователю больше ценности в продукте. Чем больше продукт закрывает сценарий пользователя, тем ценне для него продукт.
Релиз №1 (MVP)
- Найти товар
- Посмотреть описание
- Посмотреть фото
- Добавиьт в корзину
- Удалить из корзины
- Указать адрес и время доставки
- Ввести данные карты
- Подтвердить покупку
Релиз №2
- Фильтр по цене
- Выбрать упаковку
- Выбрать вариант оплаты
Релиз №3
- Фильтр по рейтингу
- Посмотреть видео
- Изменить количество товара
Бэклог (один из последующих релизов)
- Посмотреть отзывы
Безусловно, после выпуска первых релизов вы будете получать от пользователей обратную связь, у вас будет формироваться понимание, чего в продукте не хватает и вы непременно будете корректировать ваш бэклог с учетом этой обратной связи .
Ну а на первом этапе для правильной расстановки акцентов вам поможет User Story Map. Пользуйтесь!
Подписывайтесь на наш Telegram-канал, мы рассказываем о полезных рабочих инструментах, интересных кейсах, даем полезные рекомендации.
Чтобы получить консультацию по разработке мобильных приложений, пишите Роману Галыгину (генеральный директор mintrocket) .
Автор текста: Катя Ушкова
Что такое User Story Mapping
User Story Mapping (USM) – это инструмент целостного проектирования продукта на основе пользовательского пути. В дословном переводе – «карта пользовательских историй».Простыми словами, это визуальный путь пользователя по продукту.
Основу USM составляют следующие инструменты:
- User Persona – это пользователь, заинтересованный в продукте.
- User Story – это цели и задачи, которые пользователь решает с помощью продукта.
- User Journey – это действия и ощущения пользователя во время использования продукта.
С помощью карты пользовательских историй вы можете взглянуть на свой продукт глазами пользователя. Дело в том, что при создании продукта многие разработчики концентрируются исключительно на его функционале, теряя из виду реальные цели людей. В результате между разработчиком и клиентом возникает недопонимание, а продукт оказывается неспособным удовлетворить потребности пользователя.
Как построить карту пользовательских историй
Над USM обычно работает владелец продукта или команда разработки. При необходимости привлекаются дополнительные специалисты – например, маркетологи, дизайнеры (UX/UI), аналитики и т.д. Важно, чтобы команда не только отлично разбиралась в продукте, но и могла воспринимать его на уровне пользователя.
Для создания карты пользовательских историй необходим инструмент визуализации. Вы можете использовать следующие варианты:
- Традиционные инструменты – стикеры, флипчарт, меловая доска и так далее.
- Цифровые инструменты – графические редакторы, специальные сервисы (например, Miro, Mural и другие).
Теперь самый сложный этап – построение карты пути клиента. Вы должны спроектировать по шагам действия клиента при использовании продукта на основе реального сценария. Ниже мы рассмотрим конкретный пример. Для этого необходимо понимать преследуемые цели, предпринимаемые действия и шаги. Можно разделить создание USM на этапы.
Этапы работы над USM
- Подготовительный этап. На этой стадии определяете команду для работы над картой пользовательских историй и используемые инструменты визуализации, а также планируете время работы (может потребоваться до 1-2 дней). При этом не обязательно собирать всех сотрудников в одном месте. Вы можете организовать связь между ними посредством IP-телефонии.
- Брейншторминг. Команда проводит мозговой штурм, отвечая на ряд вопросов – например, «Как клиент использует продукт?» и т.д.
- Определение действий пользователя. На этом этапе вы определяете, какие шаги предпринимает клиент при работе с продуктом, объединяете их в более крупные этапы, а затем заполняете пробелы для каждого этапа. Здесь так же рекомендуется использовать метод «мозгового штурма», при котором каждый член команды сначала самостоятельно определяет действия пользователя, а потом совместными усилиями формируется общая карта действий.
- Определение приоритетов. Теперь вы должны расставить приоритеты внутри каждого этапа: что конкретно нужно сделать в первую очередь, что можно отложить, а что – сделать при наличии дополнительного времени или бюджета.
- Определение этапов реализации проекта. Наконец, необходимо выделить релизы – что будет представлено в 1-й версии проекта, во 2-й версии и так далее. При этом продукт на каждой стадии релиза должен достигать конкретных бизнес-целей.
Теперь необходимо взглянуть на получившуюся карту целиком и убедиться, что все шаги соотносятся с действиями, соответствующими определенным целям. На основе карты вы можете сформировать бэклог продукта, а саму карту сделать доступной для всей команды проекта (например, распечатать и повесить на стену).
Подключите телефонию МТТ для проведения переговоров Упростите сбор мнений клиентов с помощью телефонии 
User Story Mapping – пример
Предположим, вы запускаете свой интернет-магазин. В первую очередь, на карте пользовательских историй вы расписываете действия клиента по шагам – от поиска товара до его оплаты. Например:
- Найти товар
- Прочитать описание товара
- Посмотреть фотографии товара
- Положить товар в корзину
- Выбрать время и адрес доставки
- Ввести номер, срок действия и CVV-код карты
- Подтвердить оплату по SMS-коду
В этот момент карта пользовательских историй будет выглядеть следующим образом:
Нередко в карте может быть звонок оператора с помощью телефонии. Это также стоит предусмотреть, в зависимости от ваших сценариев. Теперь вы должны сгруппировать эти действия в этапы. В данном случае можно выделить 4 основных этапа взаимодействия с сайтом:
- Поиск товара
- Изучение информации о товаре
- Добавление в корзину
- Покупка
Распределяем действия по этапам и преобразуем карту:
Теперь необходимо заполнить пробелы: добавить действия, которые может совершить пользователь на каждом этапе взаимодействия с сайтом. Например, во время поиска товаров он может настраивать фильтры по цене, по рейтингу и так далее, а при изучении информации о товаре – смотреть видео, читать отзывы и пр. Добавляем эти действия в карту:
Теперь необходимо расставить приоритеты внутри каждого этапа. Например:
- Что нужно обязательно сделать.
- Что рекомендуется сделать.
- Что неплохо было бы сделать.
Для этого нужно поменять местами действия и распределить их по группам приоритета:
Остается лишь выделить релизы. Для этого отделите линиями разного цвета версии интернет-магазина в порядке их реализации. Таким образом, на заключительном этапе карта пользовательских историй будет выглядеть следующим образом:
После этого при желании можете сформировать бэклог своего проекта (интернет-магазина). Для этого необходимо выстроить по порядку все действия с учетом этапов слева направо. В данном случае это будет выглядеть следующим образом:
| Ver. 1 |
|
| Ver. 2 |
|
| Ver. 3 |
|
Один из важнейших принципов Agile звучит так: «Люди и их взаимодействие важнее процессов и инструментов». Это не означает, что последние не важны, суть этого высказывания следующая — их легко можно изменить и подстроить под свои нужды.
Люди в этом принципе — не только участники команды и заинтересованные стороны. Это еще и пользователи продукта, над которым работает команда. Чтобы сделать продукт полезным и удобным для пользователя, команде стоит сменить угол зрения. С этим вам помогут Пользовательские истории.
Что такое пользовательские истории?
Пользовательские истории (User stories) — это описание работы элемента или функции, составленное с точки зрения пользователя и написанные простым неформальным языком. Этот инструмент помогает команде делать продукт более ориентированным на пользователей.
Главная ценность user stories — в емком и понятном описании цели желаемой функции. После прочтения текста истории у всех участников команды должно быть понимание, зачем функция нужна пользователю и как приблизительно должна работать.
Зачем вводить пользовательские истории?
У пользовательских историй есть ряд преимуществ для Agile-проектов:
- истории написаны легким и понятным языком, их понимают все участники команды, вне зависимости от их задачи внутри проекта;
- объединяют участников команды, стимулируют на совместный поиск творческих, нестандартных решений;
- упрощают понимание, что хочет клиент;
- фокусируют на формулировании необходимого проекту пользовательского опыта;
- помогают разбивать большие нововведения на небольшие куски;
- закрытые пользовательские истории позволяют команде постоянно видеть прогресс и вдохновляют на дальнейшую работу.
В своих формулировках пользовательские истории в общих чертах объясняют, что необходимо сделать команде для их воплощения.
💡
В каждую историю необходимо включать образ пользователя, конкретное действие, которое он намерен выполнить, и ожидаемый результат по совершению действия.
Пользовательские истории — не задачи. У них есть три ключевых отличия:
|
Пользовательские истории |
Задачи |
|
|
Формулировка |
Максимально простой и понятный язык. |
Написаны техническим языком. |
|
Кому адресуются |
Адресуются всем участникам команды и заинтересованным лицам. |
Рассчитаны только на внутреннее использование ответственным за задачу специалистом. |
|
Основная задача |
Позволяет команде сосредоточиться на формировании пользовательского опыта. |
Дать подробное задание участнику команды. |
*Пользовательский опыт (User experience) — это сочетание всех полученных пользователем умений, знаний и впечатлений после взаимодействия с продуктом или услугой.
💡
Шаблон пользовательской истории выглядит так: «Как [конечный пользователь], я хочу [сделать это], чтобы [получить вот такой результат]».
Примеры пользовательских историй:
Пример 1. Главный редактор: «Как главный редактор я хочу видеть все взятые в работу стать, чтобы следить за сроками их выполнения».
Пример 2. Фронт-энд разработчик «Как фронт-энд разработчик я хочу видеть динамическое изменение проекта, чтобы вовремя обновлять его».
Пример 3. Менеджер по работе с клиентами «Как менеджер по работе с клиентами, я хочу фильтровать клиентов по категориям, чтобы быстро находить необходимого клиента».
При этом разные пользователи, упомянутые в разных историях, могут быть одними и теми же лицами, которым нужны разные функции для выполнения разных задач.
Историю можно преобразовать в задачу. А вот наоборот уже не получится.
Как написать пользовательскую историю
- Точно определите, как будет выглядеть выполненная история. Обычно пользовательские истории считаются готовыми в тот момент, когда пользователь получит необходимый результат — выполнит задачу или достигнет цели.
- Отметьте этапы, необходимые для работы над историей, задокументируйте все необходимые детали и назначьте ответственного за каждый этап.
- Определите, кем будет конечный пользователем в этой истории. Если пользователей несколько, стоит создать несколько пользовательских историй.
- Создайте историю для каждого шага в проекте — Карту пользовательских историй. Это упростит саму работу, обеспечит наглядность всем этапам и сформулирует полноценный пользовательский опыт. О том, как составить карту, мы расскажем ниже.
- Соберите обратную информацию от пользователей и клиентов. Зная, чего именно они хотят от вашего проекта, команде будет значительно проще создать действительно актуальный продукт. Также это поможет вовремя избежать проблем в пользовательском поведении.
- Создайте истории, которые можно закончить за один спринт. Если пользовательская история слишком объемная, есть смысл разбить ее на более мелкие.
Как только пользовательская история будет определена, убедитесь, что она доступна всей команде.
Очень важно, чтобы шаги внутри пользовательских историй соотносились с действиями, которые пользователь будет совершать при взаимодействии с продуктом. Например, если пользователю необходимо оплачивать покупки онлайн, не стоит делать функцию оплаты по получению.
Именно для формирования четкой последовательности между действием пользователя и результатом, который он хочет получить, необходимо писать пользовательские истории простым языком, не утяжеляя их лишними техническими деталями.
Карта пользовательских историй — что это такое и как ее составить
Карта пользовательских историй (User story map, USM) — это видение всего проекта с точки зрения пользователей и его опыта. Карта поможет увидеть взаимосвязи внутри проекта, которые ориентированы непосредственно на пользователя. Она визуализирует весь цикл взаимодействия пользователя с продуктом от начала и до конца.
Помимо пользовательских историй, в создании USM применяются два важных инструмента: портрет пользователя (User persona) и путешествие пользователя (User journey).
Портрет пользователя — это описание конечного пользователя, который намерен решить свои задачи с помощью продукта.
Путешествие пользователя — описание целей, задач и действий пользователя, его опыта и эмоций, которые он должен получить после взаимодействия с продуктом. Над ними работают обычно специалисты по UI и UX дизайну.
Рассмотрим на примере.
Вот как выглядят шаги пользователя в истории, которая звучит так: «Как мама в декрете, я хочу подобрать хороший курс, чтобы получить возможность работать из дома»:
Все шаги необходимо сгруппировать по этапам, каждый из которых отображает действие пользователя, в этом примере на сайте (может быть также в приложении, программе etc.):
Далее стоит детализировать пользовательские действия, добавив необходимые элементы, которые не являются шагами в пользовательских историях, но позже могут стать задачами.
После чего необходимо приоритезировать задачи в зависимости от заинтересованности команды ввести ту или иную функцию или от заинтересованности пользователя в ней. Это похоже на планирование спринта.
Те истории, которые команда намерена сделать, переформулировываются в задачи, которые описаны более техническим языком. Эти задачи отправляются в бэклог наравне со всеми остальными.
Как работать с пользовательскими историями в Kaiten
В Kaiten есть специальный модуль для составления Карты пользовательских историй — Story Maps. Модуль позволяет не только создавать карты историй, но и привязывать их к карточкам на досках. Использовать USM удобно для указания основных этапов работы над проектом. Также задачи с USM можно отправлять непосредственно на канбан-доску.
Шаблоны для карт пользовательских историй находятся в боковом меню слева в пункте Story Maps.
Обычно карта делится на два блока. В верхнем указаны направления работы и отмечены большие задачи, а ниже планируются релизы с датами и детальным описанием, что именно команда должна сделать в указанный период.
Каждая карточка в USM — это пользовательская история, которая была выделена в ходе составления карты пользовательских историй или добавлена после фидбэка от пользователей или заинтересованных лиц.
В Kaiten есть возможность связывать карточки на канбан-доске с карточками в USM. Благодаря ей вы сможете составлять USM в одном пространстве с основными задачами и следить за прогрессом в работе над пользовательскими историями, не прибегая к дополнительным инструментам. Это удобнее, чем составлять карты в отдельном сервисе или на доске, а потом переносить задачи в бэклог.
Подробнее о работе с инструментом для построения карты пользовательских историй читайте в инструкции Модуль User Story Mapping
Подытожим вышесказанное
Есть такой термин — «профессиональная деформация». Из-за долгой работы у человека может искажаться восприятие продукта своей деятельности. Также и в работе над проектом.
В какой-то момент участники команды могут начать воспринимать его только с технической стороны, игнорируя пользователей. В итоге выпущенный продукт не будет отвечать запросу пользователей. Из-за чего продукт будут игнорировать.
Чтобы избежать этого, полезно бывает перевернуть проект и оказаться по другую его сторону. Пользовательские истории для этого и нужны. Они помогают сформулировать, какой именно опыт должен получить от взаимодействия с продуктом. Карты пользовательских историй позволяют найти новые взаимосвязи внутри проекта, а также добавлять в бэклог те задачи, которые принесут больше ценности проекту и бизнесу.
Модуль USM в Kaiten поможет вам и вашей команде составить подробную карту пользовательских историй. Задачи оттуда можно отправлять на канбан-доску и связывать с другими карточками. Работая с Kaiten, вы будете видеть динамичный и детальный прогресс по всем своим задачам.
Зарегистрируйтесь в Kaiten и попробуйте модуль User Story Mapping бесплатно
Попробовать