В первой статье мы рассмотрели, как на практике выглядит работа инструмента Impact Mapping. Рассказали не только, о его применении в период подготовки к проекту, но и о реакции заказчиков на подобные встречи. Опыт очень интересный и полезный как для заказчиков программного продукта, так и для компании по разработке ПО.
Следующим этапом в нашей практике становится визуализация текущих рабочих процессов с помощью инструмента Customer Journey Mapping. Помогает лучше погрузиться в процесс и получить представление о будущей оптимизации, а также условно начинать разделять разработку на этапы.
Что такое Customer Journey Mapping?
Обычным переводом, который звучит как “карта путешествия клиента”, довольно сложно обойтись. В данном понятии подразумевается следующее. Благодаря обсуждениям с участниками и руководителями бизнес-процессов мы графически выстраиваем схему-карту, в которой отражены все точки взаимодействия системы и ролей, определенных на этапе Impact Mapping.
В результате мы сможем увидеть:
- Каким образом каждая роль влияет на процесс
- Точки соприкосновения разных ролей с системой, где осуществляются схожие по сути действия
- Места процесса, требующие немедленного улучшения
В первом пункте мы видим насколько сильно роль влияет на бизнес-процесс и стоит ли ее учитывать в дальнейшем. Второй пункт уже на этом этапе выделяет определенные шаблоны поведения внутри системы, что в будущем поможет оптимизировать ее быстрее и точнее, нежели улучшение каждой отдельной функции. А вот третий пункт является для нас сигналом, указывающим на что стоит обратить внимание в первую очередь.
От слов к делу
Если к прошлой встрече (Impact Mapping) как такового этапа подготовки не было ни с нашей стороны, ни со стороны заказчика, то теперь нам необходимо запастись маркерами для доски, самой доской и предварительной схемой будущей Customer Journey Map.
Сначала она выглядит очень простой, даже слишком. С первого взгляда не совсем понятно, как такая схема может дать плодотворные результаты для верного планирования разработки.
Слева мы отмечаем все роли, которые определили ранее на встрече, вверху отмечаем примерное деление всего процесса на блоки схожих действий и даём каждому отрезку название. Поскольку это лишь шаблон, то скорее всего в нём многое изменится.
Как всё начинается
Итак, приходит клиент, который может быть не особо рад второй встрече и не понимает, что мы будем на ней делать. Но когда он видит уже подготовленный, хоть и схематично, шаблон для заполнения, ему становится немного проще.
Для данной встречи не обязательно присутствие всех заказчиков, которые были в прошлый раз. Иногда достаточно лишь одного представителя, если он понимает весь процесс досконально и хорошо знает роли каждого участника.
Для начала мы кратко объясняем, что будет происходить в ближайшие часа два, и как это отразиться на нашей доске. Тут главное, чтобы клиент по возможности отключил все свои шесть мобильных телефонов, которые а) создают лишний шум обычными уведомлениями, б) отвлекают его и нас от самого процесса, который может из-за этого начать затягиваться к неудовольствию каждого участника.
После еще 10 минут дополнительных вопросов, манипуляций по отключению телефонов или установки их на беззвучный режим, мы наконец переходим к главному действию.
… «А что на самом деле происходит?»
Это самый частый вопрос, который мы задаём во время встречи по Customer Journey Mapping. Потому что то, как должен быть построен бизнес, и то, как он реально функционирует – две разных истории из параллельных вселенных. Не всегда, но как правило.
Весь процесс выстраивается следующим образом: берётся роль и прослеживается путь её взаимодействия с системой. Каждое действие отмечается точкой на линии в нужном блоке. Подписываем, что происходит в данной точке (отправляет письмо, получает счёт и так далее). В том случае, если есть альтернативное действие, например, вместо положительного ответа возможен отказ, его также необходимо отметить на линии в виде ответвления.
За основу берется процесс с наиболее благоприятным исходом для того, чтобы можно было проследить все соприкосновения роли с системой.
Основываясь на нашем опыте, лучше всего начать с ролей, которые влияют больше всех на процессы, поскольку на их описание тратится много времени и сил. Затем переходим к оставшимся ролям, на которые намного быстрее отражаются на схеме.
Вот так, постепенно происходит наполнение схемы. Рамка доски ограничивает пространство, что заставляет нас рисовать дополнительные линии и изгибать их, лишь бы точки влезли в необходимую часть процесса. Так мы увидим действительные проблемы текущего процесса, которые наш проект призван решить в будущем.
Итоги применения Customer Journey Mapping
Происходит всё действие примерно около двух часов. Результатом становится доска, на которой уже графически изображён реальный процесс работы компании, где сразу можно подцепить идеи для её оптимизации.
Более того, клиент также больше погружается в работу проекта и видит те участки, над которыми необходимо поработать в первую очередь. А значит, это облегчит нашу будущую коммуникацию с ним и улучшит понимание порядка разработки программного продукта.
Стоит отметить, что в нашем случае применяется упрощённый подход Customer Journey Mapping, поскольку мы не рассматриваем кривую эмоционального отклика во время соприкосновения с системой. Не все проекты нуждаются в таком дополнительном измерении. Они могут лишь усложнить весь процесс и поставить в тупик не только заказчика, но и нас самих.
И что же дальше?
По итогу двух встреч мы уже имеем реальный качественный материал. Не тот, который может оказаться фантомным, и узнаем мы об этом в самый неудачный момент разработки или, того хуже, после сдачи проекта заказчику. Именно его мы будем использовать в дальнейшей нашей работе над проектом.
Однако бывают ситуации, когда происходит большое количество взаимодействий между ролями, а также между ролями и системой. В таком случае необходимо провести финальную встречу и использовать инструмент User Story Mapping. О нём мы расскажем в нашей следующей статье.