Итак. Путь к крутому руководителю проектов и продуктов лежит через аналитику. Разберитесь в этом. Погнали!
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 (читайте книгу Эрика Риса) и пропитана философией бережливого мышления.
Сегменты потребителей
Впишите сюда не только тех, кто покупает продукт, но и тех, кто им будет пользоваться (родители покупают игрушку, а ребенок ей играет). Еще лучше собрать реальную группу людей, которые будут первыми тестировать продукт и помогут проверить гипотезы.
Проблема
Какую потребность ваш продукт или услуга закрывают? И кто еще это делает на рынке уже сейчас? Не забудьте, что помимо прямых конкурентов есть вторичные и косвенные (подробнее об этом поговорим в параграфе о Jobs To Be Done).
Уникальная ценность
По-другому УТП, или почему клиенты захотят купить именно ваш продукт? В чем его ценность?
Решение проблемы
Пригодятся интервью с потенциальными пользователями и исследования, чтобы подтвердить ваши гипотезы.