Владимир Завертайлов – Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий (страница 25)
Под болями мы подразумеваем препятствия, переживания, проблемы, барьеры, с которыми сталкивается человек на пути к своей цели. Нам необходимо устранить эти барьеры. Формулируя боль, сразу отвечайте себе на вопрос: каким образом она будет закрываться в нашем программном продукте.
Для определения приоритетов разработки нас будет интересовать два параметра: как часто «болит» и насколько сильно. И то и другое помогает выявить Проблемное интервью CustDev (см. § 4.3.8).
Как ни странно, даже в медицине, боль – субъективный фактор. Объективного «болиметра» не придумали. Кто-то от прививки в обморок падает. А кому-то лом пролетел через голову, в результате чего у него слегка испортился характер. Многие люди склонны драматизировать силу боли. Особенно свежих событий или событий, на которых они сфокусированы прямо сейчас. Отсекайте такие «выбросы» относительно средних величин.
Итак. В Агрегации требований для каждой персоны мы фиксируем боли. Если есть возможность собрать статистику по частоте и силе – это хорошо.
Не формулируйте боли в виде вопроса. Почувствуйте разницу:
То есть, боль не в том, что чебурек капает. А в том, что человеку стремно запачкать одежду – что подумают люди! И это может быть главным мотивом отказа от покупки.
4.2.4. CJM. Карта путешествия пользователя (Customer Journey Map)
В заказной разработке клиенты чаще и чаще стали спрашивать Customer Journey Map – карту путешествия клиента. Это наглядный инструмент для анализа проблемных точек, которые мы создаем пользователям своим сервисом. Инструмент старый. Пришел в digital из классического маркетинга. И очень вероятно, что руководитель проектов с ним рано или поздно столкнется. В чем идея?
В идеале для каждой целевой персоны (аватара) нам нужно создать и проанализировать его путь от того момента, как у него возникло смутное подозрение, что есть какая-то проблема, которую нужно решать, до того момента, как он становится приверженцем бренда и готов его рекомендовать. Впрочем, многие так далеко не думают – ограничиваются первой покупкой. Но мы будем настойчивы!
Итак. Наш покупатель проходит через 6 крупных, условных фаз:
1. Awareness. Осознание. Осведомленность. Что-то его смутно мучает, но что именно – он не очень понимает. Например, человеку хреновенько на работе. Он не так жжет, как раньше, и ничего не успевает. На этой фазе он начинает гуглить, думать, что с ним не так, читать статьи про эффективность и т. д.
2. Consideration. Изучение, осведомление. Например, человек понял, что ему нужен тайм-менеджмент, и именно в самоорганизации его проблема. Теперь он ищет инструмент, в котором бы мог структурировать все свои дела. Наивный!
3. Decision. Выбор и принятие решения. Решение для человека в целом понятно. Хочется выбрать что-то конкретное. Для тайм-менеджмента это может быть выбор между блокнотом, календарем или программами ведения списка дел и проектов. Он читает рекомендации, смотрит, экспериментирует, проверяет и пробует сам.
4. Purchasing. Покупка. Наконец, все понятно. Выбор среди множества вариантов сделан. Победит тот продукт, который будет проще купить. Будут ли вежливы продавцы? Нужно ли будет куда-то идти или с кем-то разговаривать? Все это влияет на легкость покупки и пользовательский опыт.
5. Loyalty. Лояльность. Появляется первый пользовательский опыт использования продукта. С офлайн-продуктами это может быть как опыт доставки и монтажа, так и опыт использования самого продукта. В случае продуктов, которые пользователь покупает регулярно – он может остаться с этим поставщиком, стать лояльным. А может в ужасе сбежать в поисках другого решения.
6. Advocacy. Адвокат бренда. Наконец, если все очень хорошо – человек может рекомендовать бренд.
CJM обычно представляет собой табличку. По горизонтали мы выписываем шаги или фазы, через которые проходит пользователь. По вертикали – те параметры, которые хотим отслеживать. Как правило, это:
1. Цели и ожидания пользователя на каждом этапе. Его активности.
2. Вопросы, которые задает себе покупатель.
3. Мысли и чувства пользователя в этот момент.
4. Точки контакта. С чем приходится взаимодействовать пользователю. С сайтом, Инстаграмом[2] компании, службой поддержки, электронным письмом и т. д. Тут есть одна тонкость, про нее напишу отдельно.
5. Уровень счастья / удовлетворенности пользователя на каждом из этапов.
6. Ожидания. Только не в духе Аршавина: «Ваши ожидания – ваши проблемы».
7. Барьеры. Что мешает, какие есть сложности. Провести анализ глазами клиента, проанализировать отзывы и обратную связь, пожелания и жалобы клиентов.
8. Решения. Способы преодоления барьеров. Штормим, думаем, как облегчить жизнь.
9. Дополнительные параметры. Например, ответственные за этап, перечень ключевых запросов и т. д.
Проще всего построить такую таблицу в Google Docs. Получается практичный инструмент, в который нужно регулярно заглядывать и обновлять.
Однако CJM часто красиво визуализируют, рисуют чуть ли не в Фотошопе, добавляют графики. И из рабочего инструмента CJM вырождается в маркетинговую пыль в глаза для красивых презентаций. Это первый минус CJM: из инструмента он превращается в имитацию инструмента. Хотя, если важны красивые презентации, CJM производит впечатление.
Второй минус – точки контакта. Их может быть очень много на каждом этапе. Сценарий перемещения по этим точкам может быть нелинейным и крайне запутанным. И содержать агентов влияния (вроде жены, мамы, подружки), общение с оператором, пересылку ссылок на избранное, корзину или оплату.
По-хорошему, нам нужно развернуть весь путь пользователя в цепочку шагов. Но это будет безумно широкая таблица, которой будет невозможно пользоваться. А как учесть разные маршруты и возвраты на предыдущие шаги – вообще не очень понятно. Поэтому ограничиваются наиболее типовыми маршрутами.
Третий минус – трудоемкость. По-хорошему, нам нужно строить такие карты для каждой целевой персоны и для каждого маршрута. Но это недели, если не месяцы, работы аналитика. Дорого и непонятно зачем. Если же рассмотреть какой-то общий сценарий – карта получается слишком неконкретная.
В заказной разработке обычно мы концентрируемся на той части CJM, которая касается взаимодействия пользователя с сайтом. И рассматриваем лишь самые важные маршруты для самых частых персон. В такой форме это оправданно и позволяет улучшать пользовательский опыт в программном продукте.
Итак. CJM – инструмент для анализа пользовательского опыта на каждом шаге и точке контакта при взаимодействии пользователя с брендом. Инструмент неплох для заказной разработки или для анализа готового программного продукта. В продуктовой разработке лучше использовать фреймворк RAT+JTBD (об этих аббревиатурах – в параграфах 4.3.3 и 4.3.7). Важно найти баланс между трудоемкостью и практичностью. А еще CJM любят вставлять в красивые презентации. Если это произошло – значит, CJM уже мертв.
4.2.5. Решения
Аналитика никому не нужна.
Нужны выводы из аналитики.
Итак. Мы определились с сегментами. Описали целевые персоны. Выявили их боли и мотивы.
Все это было проделано, чтобы понять, какие вещи (функции, разделы, экраны) мы должны предусмотреть в будущем проекте для того, чтобы эти боли закрыть.
Какими должны быть предложенные решения?
В первую очередь, не случайными, а закрывающими выявленные выше потребности персоны. Например: мы делаем отзывы со ссылками на соцсети не просто так, а потому что выяснили, что наш персонаж Леночка не решается покупать косметику без отзывов, но не так наивна, чтобы верить анонимным отзывам на сайте интернет-магазина.
Важно, чтобы решения отвечали уровню проекта. Если заказчик хочет простой корпоративный сайт, можно предложить интеграцию с чем-то диковинным, калькулятор с 3D-моделями. Но аккуратно, с оговоркой, что это идея на развитие. Иначе у заказчика останется неприятный осадок, что его не слышат либо пытаются развести на дополнительные опции.
Как правило, мы описываем предлагаемые решения сначала рядом с каждым аватаром, чтобы четко прослеживалась связь решений, болей и мотивов. Для каждой персоны решения размечаем цветными рамками (цветовое кодирование: одна персона – один цвет). Используем иконки для разметки этапов, акцентов или вопросов, которые нужно разобрать.