Эта статья входит в серию из трёх статей, где мы делимся опытом подготовки к началу проекту. Уже рассказали про первые два этапа – Impact Mapping и Customer Journey Mapping.
Благодаря им мы смогли определить точную цель проекта, роли, которые влияют на процессы, а также описали улучшения по ролям, необходимые для оптимизации всей системы. Далее мы визуализировали все эти процессы в виде карты точек соприкосновения пользователей с системой.
Однако недостаточно знать о том, что улучшить в текущей системе. Необходимо понимать, каким образом это сделать и благодаря каким функциям. Для этого мы используем инструмент User Story Mapping.
Коротко об инструменте User Story Mapping
Как и в предыдущих случаях, название не даёт моментального понимания о том, как работает инструмент. Особенно для русскоговорящей аудитории, так как в большинстве случаев не используют перевод «Карта пользовательских историй» (который продолжает хранить в себе тайну за семью печатями).
User Story Mapping – это также инструмент для визуализации процессов на основе ролей. Помогает представить функциональность будущего продукта, а также способы его использования.
Несмотря на то, что инструменты User Story Mapping и Customer Journey Mapping схожи, так как оба помогают визуализировать процессы, у них есть отличия.
Самое главное отличие в том, что в User Story Mapping мы описываем то, как разработанная в будущем система должна функционировать, в отличие от Customer Journey Mapping, где мы описываем то, как она в действительности работает (со всеми её недостатками). Также они отличаются по внешнему виду.
И ещё одной особенностью User Story Mapping является то, что мы прослеживаем каждое возможное действие пользователя в системе.
Подготовка к встрече
К прошлой встрече мы готовили набросок будущей схемы на доске, которая впоследствие стала картой точек соприкосновения пользователей с системой. Теперь же мы переходим к более нестандартным решениям – используем окно в офисе в качестве места для будущей визуализации.
Помимо окна нам понадобится следующее: стикеры для заметок (минимум 2 цвета), фломастер или ручка, доска со схемой с прошлой встречи.
Стоит сразу оговорить, что мы используем упрощённый вариант пользовательских историй. Ранее были попытки осуществить использование инструмента по науке, однако либо в начале, либо в середине процесса происходил ступор, и работа вставала. Порой даже приходилось начинать всё заново.
Поэтому в отличие от оригинала, где за основу берется один пользователь или группа пользователей, схожих по функциям, мы по вертикали наклеиваем стикеры с написанными ролями. Аналогично с картой точек соприкосновения условно делим по вертикали всё пространство на отрезки со схожими процессами.
Время пораскинуть мозгами
Итак. К нам в офис приходит клиент и уже направляется к дивану напротив доски, когда мы вдруг предлагаем ему расположиться около окна. Минута замешательства, но он всё же садится на предложенное место. Потом видит, что на стекле уже наклеены стикеры. Тут мы объясняем, что сегодняшний вечер будет проходить не у камина, конечно, но тоже весьма интересно.
Теперь мы просим вновь рассказать поступательные движения каждого пользователя. Однако в этот раз будем не просто отмечать действие, а подписывать каждый стикер возможными опциями. Например, *роль* «может войти в личный кабинет», «может посмотреть свой профиль», «может отправить документы» и так далее. Таким образом мы описываем уже функционал будущего продукта.
В этой схеме работает тот же принцип, что и в Customer Journey Mapping – начинать с самой объёмной роли. Если во время описания одной роли вдруг возникают идеи по функциям другой (либо есть взаимосвязанные действия, затрагивающие несколько ролей), необходимо отметить стикерами и у другой роли тоже. Так, постепенно наша доска-окно заполнится. А на её основе можно будет выстраивать дальнейшие этапы.
В конце встречи одно из наших окон стало воплощением User Story Map
Результаты встречи по User Story Mapping
В целом эта встреча может занять много времени, так как несмотря на использование ранее озвученных информации и процессов, необходимо еще глубже погрузиться в них и выудить необходимое действие (-ия). Обычно она длится около четырёх часов с перерывом на 15-20 минут. Действительно долго, и это большая умственная работа. Зато по окончанию мы имеем уже представление о будущем программном продукте.
«У меня осталось 5% заряда, и я вхожу в режим экономии энергии. Так что у нас есть еще 5 минут, а дальше я отключусь» – примерно такие фразы мы слышим в конце встречи от заказчика. И все дружно его поддерживаем, потому что у самих «батарейки» тоже садятся.
Но столько времени и сил стоят того, чтобы их потратили на этот этап.
Далее мы оцифровываем стикеры с окна офиса в окно браузера. Чаще всего их количество в электронном аналоге увеличивается на процентов сорок. Во-первых, это связано с тем, что в течение встречи ради экономии времени и места в одном стикере мы пишем по несколько схожих функций. Во-вторых, после проверки очень часто находим неоговоренные/упущенные возможности, которые точно понадобятся в системе. Поэтому review – голова всему.
Сразу видно, насколько увеличилась карта в сравнении с её физическим аналогом
Какой же итог по использованию трёх инструментов можно подвести? Самый важный формулируется так. Если бы мы начали работать сразу с тем материалом, который предоставил нам заказчик, то в лучшем случае мы бы разработали работающий продукт, но без какой-либо пользы для бизнеса. И вскоре бы продукт либо не справился со своими задачами, либо бы просто был забыт.
Однако благодаря трём встречам мы смогли:
- вникнуть в бизнес и понять его работу;
- вывести точную и измеряемую цель проекта, которая заказчикам поможет оценить нашу работу и работу новой системы, а мы, в свою очередь, сделаем выводы по проекту и внесём необходимые правки в workflow;
- получить качественный и отвечающий реальности материал, который закладывает хорошую базу для будущего продукта;
- синхронизироваться с заказчиком в образе мыслей по проекту, что в будущем облегчит его общение с нами и наоборот.
Тот список инструментов, которые нами используются, не является исчерпывающим. Мы, как и многие компании, в вечных поисках «святого Грааля» в области разработки ПО, и учимся на собственных ошибках.
Поэтому наверняка вскоре должны будут появиться более совершенные инструменты в нашем арсенале, а старые уйдут на заслуженный покой. Как только это произойдёт, мы сразу же расскажем об этом в наших будущих статьях.
Stay tuned!
