Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий

Итак. В заказной разработке нужно принимать во внимание не только целевых пользователей продукта, но и целевые персоны заказчика. Мы их рассматривали во вкладке «Видение». Однако если между интересами стейкхолдеров и пользователями есть потенциальный конфликт – нужно его решать.

4.2.3.10. Как описать персону

Так, чтобы в нее поверили.

Если назвать персонажа Вася Пупкин и добавить дурацкую фотку со стока, в Васю никто не поверит. Как и в выводы, сделанные такой персоной. То есть, дурацкая фотография или нелепое имя напрочь убивают доверие к аналитике. Какая бы качественная работа ни была дальше.

Подбирайте характерные для реальной группы фотографии. Придумывайте нормальные человеческие имена. И отмечайте в описании детали, которые придают персонажу характер. Что-то, что позволит слушателю узнать в нем реального человека, с которым приходилось работать.

В идеале стоит проиллюстрировать сказанное реальными скриншотами с форумов, социальных сетей и отзовиков. Выдернуть настоящих потребителей. Например, из CRM-системы клиента. Это не всегда возможно. Но попытаться стоит.

Описывая характер, ограничения и подход к принятию решений, говорите именно с точки зрения взаимодействия с будущим программным продуктом. То есть, если наш сайт посвящен продаже товаров на B2B-рынке, для нас неважно, что Иван – крепкий семьянин. Но важен его опыт в закупках и глубокое знание рынка.

Персоны удобно хранить в Google-таблицах или интеллектуальных картах.

Целевая персона РостСельМаш в XMind

Пример.

Для компании в музыкальной индустрии (скажем, звукозаписывающей студии) можно смоделировать таких персонажей:

1. Михаил, 45 лет, преподает игру на скрипке в музыкальном колледже, пользуется интернетом менее года. Выходит в сеть исключительно с домашнего компьютера через широкополосное соединение. Никогда не совершал покупки посредством интернета, предпочитает делать заказы по телефону.

2. Анна, 29 лет, исполнительный директор. Активный пользователь интернета в течение последних пяти лет, для выхода в сеть использует все, что есть под рукой: MacBook, iPad или свой iPhone.

Таким образом, потенциальными клиентами компании являются совершенно разные типы людей с абсолютно разными потребностями.

В некоторых случаях смоделированные персоны можно применять и в таком виде. Однако полностью проработанные персонажи имеют более подробное описание с указанием тех целей, ради достижения которых они зайдут на сайт компании.

Оживить персонажей помогают небольшие истории:

«Николай всю жизнь в сельском хозяйстве. На ферме работал еще при совхозе, теперь предприятие частное, а Николай на том же месте. Знает свое дело, но в последние годы с развитием хозяйства старая советская техника сменяется новыми машинами, сложность которых и роскошный внешний вид пугают».

«У Андрея советский тип воспитания, его отец, а теперь и он сам считает зазорным нанимать кого-то для ремонтных работ, это не только затратно, но и попросту недостойно. Семья расширяется, получены ключи от ипотечной трешки без ремонта. Андрей закупает материалы небольшими партиями, по шагам под каждую задачу. Так легче для семейного бюджета, да и движется процесс небыстро из-за работы и времени в пути до квартиры».

4.2.3.11. Верхнеуровневые мотивы

Зачем пользователь зашел на ваш сайт или открыл мобильное приложение (или что вы там разрабатываете?). Какую задачу он на самом деле решает? Вот это и есть – мотив. Чуть позже мы посмотрим на концепции CJM и Jobs To Be Done, чтобы разбивать мотивы на шаги.

То есть, для нас важен мотив некого Андрея найти магазин для выгодных и удобных онлайн закупок стройматериалов, а не то, что он хочет сделать ремонт в своей квартире. Это, конечно, тоже важно и легло в основу истории. Но мы моделируем персону именно с точки зрения взаимодействия с сайтом. А значит, формулируем мотив посещения сайта.

На этом этапе обдумайте, как пользователь мог узнать о сайте. Какое действие на сайте будет ключевым для данного пользователя. И как в целом будет строиться его путь.

4.2.3.12. Боль. Сила боли

Нет

проблемы – нет продажи.

По каждой целевой персоне нам нужно понять, что у нее «болит»! Именно из этого вытекает набор функций, который мы должны предусмотреть на нашем проекте.

Например. На B2B-сайте мне как менеджеру по продажам важно параллельно работать с несколькими корзинами, поскольку я формирую и уточняю одновременно несколько заказов в течение дня. Для B2C такие опции, наоборот, навредят – получим слишком сложный интерфейс и брошенные корзины. Если в проекте есть обе персоны и они равнозначны – значит, нужно предусмотреть выбор профиля. Ух!

Под болями мы подразумеваем препятствия, переживания, проблемы, барьеры, с которыми сталкивается человек на пути к своей цели. Нам необходимо устранить эти барьеры. Формулируя боль, сразу отвечайте себе на вопрос: каким образом она будет закрываться в нашем программном продукте.

Для определения приоритетов разработки нас будет интересовать два параметра: как часто «болит» и насколько сильно. И то и другое помогает выявить Проблемное интервью CustDev (см. § 4.3.8).

Как ни странно, даже в медицине, боль – субъективный фактор. Объективного «болиметра» не придумали. Кто-то от прививки в обморок падает. А кому-то лом пролетел через голову, в результате чего у него слегка испортился характер. Многие люди склонны драматизировать силу боли. Особенно свежих событий или событий, на которых они сфокусированы прямо сейчас. Отсекайте такие «выбросы» относительно средних величин.

К примеру, в офис заказчика вашего программного продукта пришел дедушка и устроил скандал, что «на сайте нет версии для слабовидящих». Он чего-то там не разглядел и не туда нажал. Откомпостировал мозг всем по дороге. Досталось даже генеральному директору. Его все очень хорошо запомнили. Однако, если это первая такая жалоба за 10 лет – бежать и экстренно реагировать не стоит. Может, дедушка со справкой, и он так свою значимость миру показывает?

Итак. В Агрегации требований для каждой персоны мы фиксируем боли. Если есть возможность собрать статистику по частоте и силе – это хорошо.

Не формулируйте боли в виде вопроса. Почувствуйте разницу:

«Не испачкаю ли я руки, когда буду есть чебурек?»

«Чебуреки жирные! С них капает сок. Их невозможно есть так, чтобы ничего не текло во все стороны. Каждый раз, когда я покупаю чебурек, я боюсь, что испачкаю одежду. Жир очень плохо отстирывается. А уж ходить целый день в грязной одежде – это мерзко. Что обо мне подумают люди? Особенно вон та мымра из соседнего отдела! Мерзко, на десять из десяти!».

То есть, боль не в том, что чебурек капает. А в том, что человеку стремно запачкать одежду – что подумают люди! И это может быть главным мотивом отказа от покупки.

4.2.4. CJM. Карта путешествия пользователя (Customer Journey Map)

В заказной разработке клиенты чаще и чаще стали спрашивать Customer Journey Map – карту путешествия клиента. Это наглядный инструмент для анализа проблемных точек, которые мы создаем пользователям своим сервисом. Инструмент старый. Пришел в digital из классического маркетинга. И очень вероятно, что руководитель проектов с ним рано или поздно столкнется. В чем идея?

В идеале для каждой целевой персоны (аватара) нам нужно создать и проанализировать его путь от того момента, как у него возникло смутное подозрение, что есть какая-то проблема, которую нужно решать, до того момента, как он становится приверженцем бренда и готов его рекомендовать. Впрочем, многие так далеко не думают – ограничиваются первой покупкой. Но мы будем настойчивы!

Итак. Наш покупатель проходит через 6 крупных, условных фаз: