Для руководителей проектов инструменты полезны. Во-первых, для понимания, как Product Owner принимает решение. Во-вторых, на вырост. В-третьих, скорее всего, Product Owner что-то из этих штук сам делать поленится, или его нужно будет возвращать в реальность. А кто будет делать все то, что делать надо, но не делает никто другой – вы уже в курсе.

Итак. Путь к крутому руководителю проектов и продуктов лежит через аналитику. Разберитесь в этом. Погнали!

4.1. Цель аналитики digital-проектов

Если не знаешь, какой херней ты занимаешься на работе, – назови это «Аналитика».

Народная мудрость

К сожалению, вокруг аналитики digital-проектов в последнее время накрутили много хераборы. Методов и подходов стало слишком много. Непонятно, за что хвататься и что применять.

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

Если раньше аналитика была вспомогательной функцией, сейчас – стала чуть ли не самоцелью. Я видел команды, которые по полгода играют в «Дизайн-мышление» или еще какой-то новомодный метод, производя только трындеж. Бюрократия – такая бюрократия. Правда, кризис оставил бездельников за бортом.

Давайте исходить из того, что:

Цель аналитики в digital-проекте – получить структуру будущего проекта и четкий план действий: сначала мы делаем это, потом то, а затем – вон то.

Понятно, что и план и структура со временем могут меняться. Понятно, что в сложном проекте лучше семь раз подумать. Поэкспериментировать. Но в какой-то момент нужно перестать анализировать все подряд. И начать писать код.

4.1.1. Что нас ждет в этой главе

Инструментарий руководителя digital-продукта

Для заказной разработки нам понадобится Агрегация требований, прототипирование и подготовка технической документации. Когда есть заказчик (или владелец продукта) – этого достаточно.

Для самого владельца продукта существует ряд дополнительных подходов: HADI-циклы, CustDev, методы сегментации пользователей и различные способы скоринга бэклогов.

Методы дополняют друг друга. Однако стоит к ним относиться как к арсеналу: снаряжаясь на войну, вы не сможете забрать на себе весь арсенал. Вы выберете один или два вида оружия и что-то из защиты. Кто-то возьмет лук, поскольку меткий. Кто-то меч по руке. Но весь арсенал вы на себе не потащите.

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

Как этим пользоваться: прочитайте главу один раз. Ознакомьтесь со всеми методами. Выберите те, которые вам понравились. Изучите их подробнее. Начните применять. Время от времени пересматривайте подходы. Возможно, в качестве эксперимента, захочется попробовать какой-либо другой метод.

Итак. Что нас ждет.

Во-первых, мы рассмотрим метод Агрегации требований. Формально он состоит из 5 шагов:

1. Видение проекта. Это основные характеристики будущего продукта. Его цели и задачи – так, как их понимают создатели продукта.

2. Целевые персоны. Здесь мы идем от пользователей. Сегментируем рынок. Выделяем боли и потребности пользователей. Проводим интервью. Строим сценарии поведения и CJM – карту путешествия клиента.

3. Конкурентный анализ.

4. Структура проекта. Какие экраны нам нужны. Что на них будет.

5. Идеи на будущее. Все то, что было бы неплохо сделать.

Во-вторых, посмотрим, как делать регулярную аналитику в продуктовых командах на основе HADI-циклов. Разберем 4 силы, действующие на продукт. Поговорим о фреймворках RAT и JTBD.

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

В-четвертых, поговорим про техники скоринга и приоритизации бэклогов, так, чтобы галлюцинации основателей действовали минимально.

В-пятых, посмотрим, как UML-диаграммы помогают при проектировании программных продуктов, продумывании взаимодействия с пользователем.

4.2. Агрегация требований в заказной разработке

Эта техника лучше всего работает в заказной разработке. Либо когда уже в общих чертах понятна задача, осталось только вытащить детали из голов стейкхолдеров, примерить их на целевую аудиторию, убедиться, что не допущены ошибки конкурентов и учтены тренды отрасли. Подходит для большинства сайтов и мобильных приложений. Позволяет синхронизировать видение у заказчика и разработчика, а также довольно точно подсчитать бюджет разработки. Это, в основном, – кабинетный анализ, который можно подкрепить интервью с потенциальными пользователями (см. главу о Customer Development) и A/B-тестами. В итоге у нас должна получиться структура будущего проекта. Для фиксации предлагаю использовать формат интеллектуальных карт.

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

Чаще всего, в заказной разработке мы создаем Агрегацию требований в формате интеллектуальных карт. Например, XMind или XMind Zen. Альтернативные программы можно найти в конце главы, в списке литературы.

Агрегация требований РостСельМаш (фрагмент)

По итогам агрегации мы узнаем:

▶ какие цели и задачи у будущего проекта;

▶ что ждет от него целевая аудитория;

▶ что хорошего и плохого в проектах конкурентов;

▶ как все это учесть и совместить, чтобы одно другому не мешало;

▶ как лучше запустить проект: весь сразу или по частям, и с чего начать;

▶ какой будет структура сайта, на основе которой аналитик готовит прототипы и пишет техническое задание;

▶ рассчитываем довольно точно сроки и бюджет проекта.

4.2.1. Стейкхолдеры

Стейкхолдеры (stakeholder) – заинтересованные в проекте лица. В заказной разработке от них исходит большая часть требований.

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

В процессе реализации проекта власть в организации, если взять ее за 100 %, как-то перераспределяется. Как только появятся первые результаты проекта – все, кто хоть как-то был затронут этим решением, выскажут свое мнение. Иногда этих мнений слишком много. Или мнения слишком громкие. Или противоречивые. Придется разбираться. Чем раньше, тем лучше.

Проекты, в которых заинтересовано первое лицо компании-заказчика, проходят гораздо ровнее. Нужно четко понимать, кто у заказчика Альфа, кто Бета. Проекты, в которых внутри заказчика постоянные споры и конфликты, и нет никого умного, кто мог бы во всем разобраться и принять твердое, окончательное решение, с треском проваливаются. Либо идут медленно и печально. Либо требуют молоть языком больше, чем писать код.

Итак. В заказной разработке важно как можно раньше выявить стейкхолдеров. Выявить их интересы. Скрытые и явные конфликты. Понять иерархию стаи. Заручиться поддержкой Альфа- и Бета-стейкхолдеров.

4.2.2 Видение проекта

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

Обозначаем перечень и ожидания заинтересованных лиц (стейкхолдеров). На этом этапе целесообразно рассматривать стейкхолдеров только со стороны заказчика, поскольку пользователям сайта посвящена отдельная вкладка. Чаще всего заинтересованные лица делятся на несколько уровней:

▶ собственники и управленцы (могут совпадать, но не всегда);

▶ представители отделов продвижения и продаж;

▶ обслуживающий персонал (операторы, контент-менеджеры, администраторы).

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

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

На этапе видения определяются цели и задачи проекта. Цель – чего именно хотим достичь. Увеличение конверсии, увеличение числа интернет-заказов, оптимизация работы менеджеров. Задачи – что конкретно будем делать. Семантическая разметка, фишки в юзабилити, интеграция с CRM.

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

Вкладка формируется на основании данных, полученных при изучении первичных материалов от заказчика, его брифования, общения со стейкхолдерами. С поправкой на опыт и здравый смысл.

Кстати, про здравый смысл и галлюцинации!

4.2.2.1. Галлюцинации основателей

Мы с тобой свернули не туда вообще

И все закончится для нас теперь так себе.

Znaki

Вы когда-нибудь пробовали отговорить основателя от его идеи? Большинство из них настолько сильно убеждают себя, что на их продукт есть спрос, и настолько харизматичны (или властны), что проще дать сделать то, что они хотят, чем объяснить, почему нет.

Вот несколько галлюцинаций основателей, которые мешают:

▶ «Мы знаем нашу целевую аудиторию, просто сделайте, как мы сказали». По факту, аудиторию они не знают, а мантра «мы все знаем», повторенная несколько раз, дает ложную уверенность контроля. Типичный итог – отсутствие потребности в продукте. Нет сегмента покупателей.

▶ «Мою идею украдут». Сразу тревожный звоночек. Идеи не стоят ничего. Артемий Лебедев писал про «Идею на минус миллион» и вообще считает, что идеи имеют отрицательную ценность.

▶ «Мой продукт должен быть идеальным». Перфекционизм. Во-первых, это дорого. Во-вторых, за этим прячется боязнь показать продукт рынку. А вдруг обидят?

https://www.artlebedev.ru/kovodstvo/sections/161/

«Идея на минус миллион» от Артемия Лебедева

В ту же копилку:

▶ Тантрический стартап: три года без релиза, ни дня без чендж-реквеста!

▶ Обратная связь от пользователей откладывается на месяцы.

▶ «Сделайте нам прибыльный проект за процент от будущей прибыли». Нет денег на фоне повышенной хитрожопости. Либо нет денег на разработку. Либо на маркетинг. Либо на то и другое.

▶ Усложнители. Затея либо сразу настолько сложная, что в деталях путается даже сам основатель. Либо пытаются использовать какую-то технологию там, где она нафиг не нужна. Блокчейн для учета шкурок крупного рогатого скота, например. Фаза анализа проблемы и потребности пропускается, идем сразу в архисложное решение.

▶ Немасштабируемые продукты.

▶ Подражатели. Уже давно замечал, что заявки на разные типы стартапов приходят волнами. Был когда-то всплеск на социальные сети. Аналоги купонаторов. Скандинавских аукционов. Как-то осенью нас засыпало заявками «Продайте долю в игре в соцсетях». Потом были маркетплейсы. Где-то людей «Бизнес-молодость» зомбирует, честное слово!

Давайте исходить из того, что у основателя есть определенная стратегия, видение, а наше дело – помочь все это реализовать по красоте, исходя из нашего опыта и знаний.

4.2.2.2. Почему брифы – зло

Я не люблю письменные брифы. В своей работе мы их почти не используем. Брифы не дают ясной картины. Теряется много важных деталей. И главное!

Брифы мешают строить долгосрочные отношения с клиентом!

С другой стороны, я понимаю заказчиков. Вернее, менеджеров на стороне клиента, которых отправили «найти подрядчика». Они (агентства), блин, все одинаковые! Гораздо проще заполнить один раз анкету. Разослать в сотню агентств. Получить КП-шки. Распечатать, отсортировать по «Итого:». И положить их боссу на стол. Минимальная ответственность. Минимальная трудоемкость. Божественный КПД – результата можно целую кучу навалить.

С одной стороны, так было и будет всегда. С другой стороны – понятна степень заинтересованности проектом. Агентствам нужно уметь под это подстраиваться.

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

Компания

Какие есть компетенции?

В чем суть бизнеса? Что приносит доход?

Узнаваем ли бренд? Какова лояльность аудитории?

Какие есть сложности?

Продукт

Сильные стороны. Почему это должны купить?

В чем отличие от аналогов?

Есть ли товары-заменители (не прямые)?

Жизненный цикл. Как часто пользуются? Как долго?

Покупатель (ЦА)

Кто он?

По сегментам аудитории: объем группы, темпы роста и т. д.

Чего он хочет? Потребности?

Какая цена приемлема?

Как привык потреблять? Получать информацию?

Конкуренты

Кто конкуренты? Какие у них сильные стороны?

Насколько наполнен рынок?

Чем вы лучше других? (Осторожнее с этим вопросом – тут горят пуканы!)

Каковы преимущества? Есть ли уникальные продукты, фичи?

Какие есть трудности и барьеры?

Планы развития?

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

Например, на e-commerce-проектах возникает несколько десятков вопросов по экономике, налогам, логистике, возвратам, интеграциям с внешними системами и т. д. Нужно включить вопросы по всему, что кажется непонятным и странным в проекте. А также затронуть все вопросы, ответы на которые лягут в основу вкладок Видение и Анализ целевых персон.

Итак. Ни один бриф не заменит голову. Письменные брифы – скорее, зло. Какова альтернатива?

4.2.2.3. Lean canvas

Lean Canvas – это популярный шаблон для фиксации целей продукта. В его основе – шаблон бизнес-плана Александра Остервальдера, оптимизированный под стартапы. Главный плюс – всю концепцию проекта можно разложить на один лист А4. И конечно, эта бизнес-модель вдохновлена методологией Lean Startup (читайте книгу Эрика Риса) и пропитана философией бережливого мышления.

https://disk.yandex.ru/i/VsCmklWdrAm7Ng

QR-код, по которому можно скачать шаблон Lean Canvas

Сегменты потребителей

Впишите сюда не только тех, кто покупает продукт, но и тех, кто им будет пользоваться (родители покупают игрушку, а ребенок ей играет). Еще лучше – собрать реальную группу людей, которые будут первыми тестировать продукт и помогут проверить гипотезы.

Проблема

Какую потребность ваш продукт или услуга закрывают? И кто еще это делает на рынке уже сейчас? Не забудьте, что помимо прямых конкурентов есть вторичные и косвенные (подробнее об этом поговорим в параграфе о Jobs To Be Done).

Уникальная ценность

По-другому – УТП, или почему клиенты захотят купить именно ваш продукт? В чем его ценность?

Решение проблемы

Пригодятся интервью с потенциальными пользователями и исследования, чтобы подтвердить ваши гипотезы.

Каналы

«Детям – мороженое, бабе – цветы» – для каждой аудитории ищите свои каналы.

Потоки прибыли

Кто платит. Кому. Когда. И за что. Если продукт или услуга бесплатны, решите, как будете монетизировать проект.

Структура издержек

От зарплаты работникам и арендной платы до затрат на рекламу и создание сайта.

Ключевые метрики

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

Скрытое преимущество

Найти его не так-то просто, поскольку это может быть не самая очевидная вещь: прямые руки работников или крутые поставщики.

4.2.2.4. Видение. Итоги

Итак.

1. Для фиксации самой верхнеуровневой информации о проекте удобно использовать Lean Canvas. Это может быть что-то типа паспорта проекта. Его отправной точки. Можно охватить взглядом и сразу понять суть.

2. Длинные письменные брифы лучше не использовать. Обсуждайте проект устно. Общайтесь. Погружайтесь в детали. Фиксируйте. Обычно для формирования видения нам нужно 1–3 сессии с клиентом. Важно быть на одной волне и строить долгосрочные отношения.

3. Для фиксации видения проекта удобно применять Mindmap. Важно учесть мнения всех стейкхолдеров. Выявить противоречия. Разрешить их. Сформировать цели и задачи проекта.

4.2.3. Потребители, сегменты, аватары и целевые персоны

Допустим, вы продаете стулья. Значит ли это, что ваша целевая аудитория – все люди, у которых есть ягодицы? Не значит. Да и достучаться до всех вы, скорее всего, не сможете.

Реальное объявление в детском парке. На какой сегмент рассчитывает автор?

Сегментация – разделение всего рынка на сегменты из потенциальных клиентов со схожими потребностями и поведением. Для digital-проектов сегменты будут нужны, чтобы определиться, какие функции нужны в продукте и как расставить приоритеты разработки.

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

Жестких правил и критериев для сегментации нет. Если у вас ведется подробная база пользователей и обращений, можно попробовать загнать ее в систему анализа бигдаты (вроде RapidMiner), поиграть с ней в кластерный анализ и попробовать выделить сегменты.

Довольно часто для сегментации используют критерии: география, демографические признаки (пол, возраст, семейное положение, доход, образование, профессия, религия, национальность и т. д.), психографию (хобби, образ жизни и т. д.), платежеспособность (LTV – Lifetime Value, сколько денег приносит клиент за все время сотрудничества).

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

Периодически нужно пересматривать сегментацию, искать новые сегменты и уточнять имеющиеся.

4.2.3.1. Анализ текущего поведения пользователей

Допустим, у вас задача – редизайн существующего проекта. Перед стартом работ нужно собрать срез статистики. Нам понадобятся доступы к счетчикам типа Яндекс Метрики и Google Analytics. Статистика нужна примерно за полгода-год.

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

Могут всплыть противоречия. Например, заказчик говорит: «Наш журнал читают представители всех возрастных и социальных групп». Типичная, кстати, галлюцинация. А по метрикам видно, что добрая часть визитов от женщин сильно за 50.

На это нужно обратить внимание. Обозначить задачу: сделать будущий сайт привлекательным, в том числе для ожидаемой аудитории – то есть, сделать так, чтобы тот журнал захотели прочитать, например, 16-летние хипстеры. И тут уже не редизайном попахивает. А сменой концепции журнала. «Спасибо» вам за такие выводы не скажут. Но цели могут скорректировать.

Тут же стоит обратить внимание на:

1. Точки входа.

2. Какие страницы пользуются популярностью. Какие – никому не нужны.

3. Показатели отказов.

4. Читаемость. Время сессии.

5. Поведенческие факторы. Кликабельность тех или иных элементов.

6. Реальную демографию.

7. Интересы пользователей.

8. Поисковые запросы (их можно взять за основу семантического ядра).

9. Какие события настроены в аналитике.

Безусловно, это нужно учесть при редизайне. Например, сохранить адреса популярных страниц (или, как минимум, поставить с них 301 редирект).

Как правило, мы делаем такой срез по статистике с краткими выводами и вставляем его в отдельную вкладку Агрегации требований. Скриншотить все экраны Google Analytics смысла нет. Акцент делаем на те моменты, которые влияют на структуру будущего проекта.

4.2.3.2. Аватары. Анализ целевых персон

Анализ целевых персон (он же – метод Аватаров) – ключевая вкладка Агрегации требований. Метод перекочевал в digital из классического маркетинга.

Суть: нужно выделить несколько (три-семь) целевых групп пользователей продукта и одушевить их. Сделать реальных людей: с фотографией, именем, мотивами и проблемами. Кто будет (должен быть) аудиторией нашего сайта или приложения, чем эти люди живут, какие имеют потребности и боли и что мы можем сделать, чтобы эти боли разрешались в нашем проекте.

Аватар – это вымышленный персонаж, в котором отражены основные характеристики целевой аудитории.

4.2.3.3. Как выделить группы

Все люди «как бы» разные. И у каждого проекта своя, «как бы» неповторимая аудитория. Ключевое слово – «как бы». Анализируя частные случаи, можно выделить закономерности и общие черты, которые позволят объединить людей в крупные группы.

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

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

4.2.3.4. Гипотезы сегментов. Эксперты

Итак. Сегмент классифицируется в первую очередь поведением. И в любом случае сегментация – это гипотеза. Однако как составить такие гипотезы, если у вас нет никаких идей на этот счет?

<1...7 8 9 10 11 >

На страницу:

Перейти

9 из 11

Другие книги автора

Владимир Завертайлов