2 марта 2018 г. Impact Mapping: ориентируйтесь в процессах по карте влияния
Представьте ситуацию: вся ваша команда несколько месяцев в поте лица трудится над проектом, продукт классный, вы релизите пробную версию — и вдруг оказывается, что заказчик «совсем не то имел в виду». Или функционал его полностью устраивает, вы расходитесь, пожав друг другу руки, а через несколько месяцев наталкиваетесь на отзыв, в котором ваш бывший заказчик жалуется: он вложил сумасшедшие деньги в работу с вами, а продукт не приносит ему никакой прибыли. Конечно, это ударяет по имиджу компании.
«Как же так?» — задаетесь вы вопросом. User stories прописаны, общение с клиентом имело место регулярно и вовремя, система работы отлажена идеально.
Но как раз совершенство и отлаженность нашей внутренней системы порой и отвлекают внимание от очевидного факта: продукты функционируют не в идеальной вселенной, а в реальном мире. Для того, чтобы продукт был в нем успешен, необходимо еще в начале разработки разглядеть и принять во внимание глобальные цели клиента. И это не количество фич, не соблюдение бюджета и дедлайнов, а успешные изменения в бизнесе. Только тогда, когда каждый в команде четко понимает бизнес-цели клиента, его реальные потребности, разработка продукта будет успешной.
А как же быть, когда заказчик и сам не может четко сформулировать собственные цели? В таких случаях стоит призвать на помощь инструменты визуализации.
Хорошо для этого подойдет такая техника стратегического планирования, как impact mapping (карты влияния). Данный инструмент разрабатывался в рамках методологии agile, но подойдет и для классического проектного подхода. Он универсален и может быть полезен как директору по продукту, так и менеджеру проекта. Особенно выручит этот инструмент в ситуациях, когда заказчик плохо ориентируется в IT и разработке ПО.
Impact mapping: что же это такое?
Impact mapping — это графический инструмент, который позволяет четко обозначить границы проекта и построить необходимые технические и бизнес гипотезы. Он помогает еще на стадии стратегического планирования скоординировать работу различных специалистов, синхронизировав ее с глобальными бизнес-целями клиента. Результат — эффективные программные продукты, счастливые пользователи и повышение customer loyalty.
Суть метода настолько проста, что может показаться банальной. Но парадокс в том, что мы часто безосновательно игнорируем простые решения. Impact maps наглядно демонстрируют, какое влияние будет иметь та или иная функция на успешность проекта путем ответа на вопросы «зачем?», «кто?», «как?» и «что?»
Создатель инструмента, Гойко Аджич, сравнивает impact maps с картами автомобильных дорог: точно так же, как карта показывает главные и второстепенные дороги, соединяющие различные населенные пункты, impact map уточняет, что за продукт мы хотим создать и как это облегчит жизнь нашим клиентам.
Как это работает: четыре ключевых вопроса impact mapping
Создание карты влияния не отнимет много времени. Как правило, весь процесс занимает несколько часов, в отличие от нескольких дней, необходимых для решения тех же задач традиционными способами. Рассмотрим каждый этап создания impact map по отдельности.
1. Цель («Зачем»?)
В первую очередь нам необходимо определиться с целью. Внимание: под целью в данном случае подразумевается бизнес-цель проекта. Мы не описываем сам продукт, стадии его создания или границы проекта. Задача этого сегмента — объяснить, почему данный продукт будет полезен, в чем его бизнес-ценность. Это помогает команде лучше соотносить свою деятельность с конечным результатом, четче формулировать требования к функционалу и находить оптимальные дизайнерские решения.
Постановка цели будет результативна, если нам вместе с клиентом удастся прописать набор ключевых показателей, по которым в дальнейшем можно будет оценить эффективность продукта. Например, это может быть желаемый прирост прибыли для коммерческих продуктов, процент увеличения конверсии пользователей и т.п. Хорошо бы при этом ориентироваться на критерии SMART, а еще внимательно слушать заказчика, не навязывая ему свои идеи — даже если Вы уже делали нечто подобное и имеете вполне четкое видение конечного продукта.
2. Действующие лица («Кто?»)
Дальше нам следует ответить на вопрос: «А на чье же поведение мы хотим воздействовать?» Эта стадия разработки нашей карты влияния позволяет качественнее расставить приоритеты работе, смещая акцент с функций программного обеспечения на людей, которым оно будет полезно.
Фактически мы определяемся с целевой аудиторией и стейкхолдерами, пытаясь предугадать, кто может помочь нам в реализации намеченной цели, а кто — помешать. Этих людей мы и прописываем, как действующих лиц нашего проекта. Их мнение нам придется учитывать, их поведение — предугадывать и на их вкусы ориентироваться.
3. Влияния («Как?»)
В ходе этого этапа нам предстоит проанализировать, что мы можем сделать, чтобы модифицировать поведение действующих лиц. Нам необходимо приблизить их к осуществлению бизнес-цели проекта, определенной на первом этапе. Для этого следует разобраться, какие влияния будут наилучшим образом способствовать достижению цели и какие риски могут поджидать нас на этом пути.
В конкретных терминах мы прописываем, чего мы хотим от наших действующих лиц, чем их будущее поведение будет отличаться от возможного на данный момент. Например, мы хотим, чтобы клиенты заказчика с большей готовностью рекомендовали разработанный нами продукт или сервис своим знакомым. Что мы можем для этого сделать? Как минимизировать возможность негативного отзыва? На эти вопросы мы отвечаем, заполняя последнюю часть нашей карты влияния.
4. Поставляемый функционал («Что?»)
На последнем этапе мы определяем, что именно мы можем сделать, чтобы добиться необходимых влияний. Таким образом мы соотносим поставляемые функциональные возможности с ожидаемыми результатами проекта. Это позволяет четко определить, в какой потенциально возможный функционал следует инвестировать ресурсы, а в какой нет, и вовремя отказаться от реализации тех частей проекта, которые на практике не способствуют достижению значимых целей.
Как создать? Программное обеспечение для создания карт влияния
Карты влияния можно создавать вручную, используя при этом обычное офисное оборудование. Как правило, impact map для проекта, рассчитанного на 6-8 месяцев, помещается на доске стандартного размера. Можно также использовать специальные программы.
Интернет-сообщество impact mapping отсылает к трем программным продуктам, позволяющим самостоятельно создавать карты влияния: UXPressia, SpecLog и MindMup. Проанализируем вкратце все три варианта.
UXPressia является платной программой, позволяющей четко прописывать бизнес цели, в структурированном виде представлять действующих лиц и оказываемые ими влияния и разрабатывать правдоподобные user stories. Приложение доступно на английском языке. Бесплатная версия служит для ознакомления и позволяет протестировать его на одной карте с одним действующим лицом. Пакет «Professional» не имеет ограничения по количеству проектов и позволяет делиться ими с другими пользователями, экспортировать созданные карты в PDF и PNG форматы. Также вы получаете постоянную клиентскую поддержку. Недостатком программы, на наш взгляд, является очень ограниченный функционал пробной версии: новому пользователю сложно составить окончательно мнение о продукте и о удобстве его применения, а также немного сложный для зрительного восприятия дизайн приложения.
SpecLog — программа, разработанная командой Techtalk. Для построения карт влияния с ее помощью необходима установка программного обеспечения на компьютер. Особенностью программы является возможность связывать созданные карты влияния с беклогом продукта и story maps. Предусмотрен 30-дневный пробный период, а также тарифные планы, ориентированные на отдельного пользователя, сервер, и спецпредложения.
MindMup — сервис для формирования различных диаграмм связей и схем. Приложение является простым в управлении, умеет экспортировать результаты в PDF и синхронизировать данные. Можно загружать картинки, файлы, добавлять текстовые заметки, менять шрифты, стиль, цвет. Язык интерфейса — английский.
Приложение доступно в двух тарифных планах: Free и Gold. Бесплатная версия позволяет создавать карты размером до 100 КВ и сохранять их в облаке течение 6 месяцев. Следует обратить внимание, что после публикации ваши карты попадают в публичный доступ. Для использования данной версии не нужны создание аккаунта и регистрация. Тариф Gold позволяет создавать приватные карты, загружать их и хранить неограниченное время. Вы также можете заказать интеграцию или доработку функционала MindMup под ваши потребности.
Мы проанализировали графический инструмент impact mapping и возможности его применения для стратегического планирования на начальной стадии разработки продукта. Надеемся, вам понравился этот метод стратегического планирования, и вы сможете внедрить его в свою работу. Узнать больше вы сможете, посетив opensource impact mapping workshop от создателя данного agile инструмента Гойко Аджича.
Impact Mapping — как dev-команде перестать делать то, что требуют, и начать делать то, что нужно?
Доклад с прошлогодней конференции специалистов системного и бизнеса анализа — Analyst Days 2013 года от старшего аналитика питерского офиса компании DELL — Петрашева Дмитрия
На странице доклада можно найти презентацию и видео, а здесь текст…
Сразу сделаю ремарку, что компания у нас продуктовая и в моем рассказе, возможно, будет много нашей специфики. Но стоит пояснить, что сам подход достаточно универсален, чтобы быть примененным и в заказной разработке, и в каких либо специфичных сценариях.
Итак, почему я считаю что не всегда команда разработки в нашем случае делает то, что нужно и причем здесь Импакт Маппинг.
В двенадцати часовых поясах от него живет команда разработки, которая реализует необходимые фичи и в основном ни сном, ни духом почему изменения требуются именно такие. Бэклог для них это просто список покупок, за которыми отправили в магазин. Что именно будут готовить они, как правило, не знают.
Итак, какие общеизвестные проблемы растут из-за этого пробела в коммуникациях.
Проблемы
1. Так как решение о том, какие изменения нужны в продукте для достижения поставленной бизнес цели, принимается единолично менеджером продукта, не всегда эти решения эффективны и обоснованы.
2. Команда, которая не понимает куда стремится продукт, не мотивирована на то чтобы делать его лучше. Они просто закрывают фичи, не более.
3. Пояснять команде как именно должна быть реализована фича и почему именно в таком порядке, не зная исходной цели крайне сложно.
4. Развиваем профессиональное заболевание любого менеджера по продукту. Они просто обожают ближе к дате релиза расширять требования различными бесплатными на их взгляд мелочами. Все эти «небольшие правки» с большим трудом вырезаются из бэклога просто потому что мы не знаем действительно ли они не важны.
Мы уже пытались ранее решить эти проблемы различными способами.
1. У нас был документ с маркетинговыми требованиями — MRD. Постепенно отмер. Возможно, как дань переходу на agile, где принято больше говорить, нежели писать.
2. Были «темы»=themes, которые должны были описывать релиз и задавать общий тренд всех изменений одним абзацем. Тоже не пошло.
Импакт мапинг стал для нас очередной попыткой внести ясность в то, куда продукт движется и как мы, как команда разработки, этому способствуем.
Импакт маппинг
Импакт маппинг – это подход к стратегическому планированию, позволяющий построить логическую цепочку от бизнес-целей в голове у продакт-менеджера до изменений в продукте, необходимых для достижения поставленных целей.
Название подхода (импакт — воздействие) обуславливается тем, что мы пытаемся понять: кто и какое именно воздействие на нашу цель может оказать, и только потом принимаем решение, что нужно изменить в продукте для этого.
На выходе мы получаем карту mind map, которую в процессе обсуждения рисуют совместно бизнес и представители дев-команды. Никаких многостраничных документов, только одна хорошо структурированная схема.
Для подготовки карты требуется ответить на четыре простых вопроса.
Шаг 1. Why — зачем
Сначала требуется ответить на вопрос why – зачем
1. Зачем мы выпускаем данную версию продукта,
2. Почему мы считаем, что в продукте требуется что-то поменять
На данном шаге мы определяем цель. Цель естественно должна быть смартовой (SMART):
1. Конкретной,
2. Измеряемой,
3. Ориентированной на действие,
4. Достижимой в разумный промежуток времени.
Ответ на вопрос “Why” есть (должен быть) у нашего менеджера продукта, но навряд ли его цель соответствует критериям. Над этой целью придется еще поработать.
Хорошая цель представляет собой проблему, которую нужно решить, а не готовое решение.
Шаг 2. Who – Кто
Следом отвечаем на вопрос Who? — кто? Основная задача – определить круг заинтересованных (или не очень) лиц.
1. Кто нам может помочь с достижением цели?
2. Кто может помешать?
На этом шаге важно рассмотреть всех задействованных лиц, а не только юзеров. Все кто может повлиять на результат, должны попасть на нашу карту. Продукты не работают в вакууме, и использование продукта влияет не только на конечных пользователей.
В нашем случае это оказались и другие команды, с которыми интегрируемся, и маркетинг, и даже топ менеджеры компании.
Шаг 3. How – Как?
1. Отвечаем на вопрос по каждому задействованному лицу — как мы должны изменить (воздействовать на) поведение этого действующего лица, чтобы он посодействовал нам в достижении цели?
2. Определяем воздействие на юзеров и других действующих лиц
Это, пожалуй, единственный «вопрос» из всего подхода impact mapping’а, требующий пояснения на примере.
У нас был проект, перед которым была поставлена цель — «увеличить количество пользователей желающих продолжить разбираться с продуктом после триального периода»:
Был сформулирован impact — «shorten time to value», т.е. сократить промежуток времени, который требуется пользователю, чтобы понять какие возможности ему предоставляет продукт, какие его проблемы решаем (начиная с момента, когда пользователь открывает авторан).
Идеально сформулированное воздействие — простое и напрямую влияющее на цель.
По факту было сделано огромное количество изменений в документации, сетапе, GUI и так далее.
Шаг 4. What – Что?
Последний вопрос для построения карты — что. Именно на этом этапе появляются фичи.
Нужно понимать, что не всегда для оказания нужного нам воздействия требуется вносить изменения в продукт и что-то девелопить. Порой достаточно изменить документацию, например. Или другой пример — для привлечения пользователей не всегда нужны фичи, альтернативным решением может стать маркетинговая активность и проведение рекламных компаний.
Этапы построения карты
1. Определяем цель, не забывая о требованиях SMART,
2. Выбираем метрику, по которой будем смотреть насколько мы приблизились к цели,
3. Определяем промежуточные этапы для достижения цели (milestones),
4. Рисуем костяк карты, отвечая на четыре ключевые вопроса – why+who+how+what,
5. Ищем возможные альтернативы, причем желательно сфокусироваться не на фичах, а на ролях (who?) и на том, как на них воздействовать,
6. Определяем приоритетные направления на карте,
7. По мере продвижения не забываем удостоверяться, что мы действительно продвигаемся к цели максимально эффективным образом.
Пример карты
Пример честно позаимствован из книги, о которой будет упомянуто ближе к концу доклада.
1. Онлайн игра, преследующая цель расшириться до 1млн игроков (промежуточный этап вырасти в 2раза от 400 до 800к игроков),
2. Выделены несколько ролей, явно видно с достижением цели нам могут помочь не только игроки, но и рекламщики, например,
3. На каждой из веток выделено по несколько воздействий,
4. Фичи в явном виде соответствуют цели. Помните наши проблемы? Здесь мы явно видим что делаем, почему и более того видим несколько альтернативных вариантов движения к цели.
5. Звездочками на ветках карты отмечены приоритетные направления,
6. Ветви карты легко ложатся на пользовательские истории истории (As a… I want to… So that …).
Внедрение Impact Mapping в Dell
Я выступал в роли инициатора, поэтому в первую очередь все внедрение было поделено на этапы.
Время для этапа 1 определилось по звездам, но как выяснилось, конец текущего релиза, время, когда требуется начать выяснять задачи на следующую версию это и есть лучший момент для начала перехода на новые рельсы.
Начал я с того, что продал идею импакт маппинга менеджеру продукта и объяснил ему почему нам нужно жить по новому. Мы обсудили — с какими проблемами мы, как дев команда, обычно сталкиваемся, почему мы ощущаем недостаток понимания — куда движется продукт и почему это плохо.
Для нашего ПМа данный диалог оказался сюрпризом. Впрочем, отрицать очевидное он не стал.
Итак, я представил идею импакт маппинга и настоятельно разжевал, что результат достигается совместными усилиями и что мы не предлагаем ему опять начать единолично писать многостраничные MRD.
После этого я начал потихоньку тянуть из ПМа цель на грядущий релиз, по которому у нас уже был список фичей на обсуждение
1. самым сложным здесь было заставить менеджера поставить конкретную цель, которая была бы измерима и достигалась в ограниченный промежуток времени,
2. из собрания длиной в час, мы только сорок минут бодались вокруг цели, пока не выбрали что-то похожее на правду,
3. лишний раз убедился, что наличие мысли в голове у менеджера продукта не обязательно означает, что он может ее внятно сформулировать.
По окончанию первой встречи мы поделились впечатлениями и договорились
1. еще раз подумать о целях (в том числе и в более долгосрочной перспективе)
2. через неделю собраться снова уже для того чтобы попробовать нарисовать карту
За ту неделю пока менеджер продукта наш естественно НЕ думал о целях, я подготовился к следующему собранию. У меня была драфтовая цель, было понимание, что навряд ли наш менеджер согласится под ноль переработать все то, что у нас уже было ранее занесено в бэклог. Поэтому пришлось произвести некоторый реверс-инжиниринг бэклога и подготовить первый вариант карты на грядущий релиз самому:
1. роли были выявлены достаточно быстро
2. необходимые воздействия тоже
3. но далеко не все фичи удалось связать с поставленной целью. Забегая вперед скажу, что в результате большая часть «нелогичных фичей» была вырезана,
Получившийся черновик был представлен продакт менеджеру.
1. Мы обсудили то, что не вписывалось в цель и зарезали эти фичи/истории,
2. Обсудили чем еще можно сделать в рамках тех ролей, которые уже были выявлены,
3. Появилось несколько новых ролей, для которых не нужно было делать ничего на стороне продукта, кроме как предоставить необходимые материалы (маркетинг, пресейлзы),
На удивление наш продакт менеджер принял крайне активное участие в доработке карты, которая дорисовывалась у него на глазах. Именно благодаря ему на карте появилось большое количество ответвлений, не относящихся к изменениям в продукте.
К заключительной стадии внедрения импакт маппинга на наших продуктах мы начнем через релиз, когда планирование состава фичей на версию будет изначально обрисовываться с помощью импакт маппинга.
Пока что мы просто прощупали насколько успешными окажутся первые попытки.
Отзывы внутри компании
1. Продукт менеджер высказался, что его уже много раз пичкали различными около-скрамовскими методологиями, но именно этот подход его не напрягает и очень ему нравится (естественно ведь карта в зоне ответственности аналитиков и рисуется ими же).
2. Команда проявила хороший интерес к тому, что получилось. Особо им понравилось, что к их мнению прислушиваются, и что они могут предложить обоснованную с точки зрения бизнес-цели фичу.
3. Команда получила компас, с помощью которого проще проводить планирование спринтов и минимизировать споры вокруг очередности историй и деталей их реализации.
4. Наши менеджеры оказались счастливы от того, что теперь для понимания результатов релиз планинга не требуется проводить общую планерку, а достаточно посмотреть на карту. Обсуждение при этом достаточно легко переносится в офлайн.
5. Всем понравилось, что на карту проросла не только деятельность команды, но и в том числе активность которая ранее была теневой (работа маркетинга, проталкивание продукта на уровне бизнеса).
6. Аналитик использует карту на каждом созвоне по текущему состоянию дел (current state call), который проходит каждую неделю и проходится по ключевым веткам карты. Теперь в фокусе получается удерживать большее количество вопросов.
Для того чтобы получить больше информации о данном подходе, крайне рекомендуется одноименная книжка Гойко Аджича.
Impact mapping, юнит-экономика и PDCA: грамотное управление разработкой ecommerce
Зачастую клиенты обращаются к разработчикам как к волшебникам — с надеждой, что те создадут чудо-ИТ-продукт. Он решит все проблемы: приведёт толпы клиентов, увеличит продажи, снизит издержки. Вот только без усилий самого заказчика и без точных экономических расчётов это невозможно.
Оценивают ли заказчики экономический эффект от внедрения каждой фичи? Ставят ли разработчикам только те задачи, которые стопроцентно приведут к результату?
Практика показывает, что планирование со стороны заказчика, конечно, есть, но бэклог задач, поставленных перед разработчиками, редко соотносится с целями и задачами бизнеса и ещё реже пересматривается.
А ведь после месяцев разработки без понимания экономического эффекта легко прийти к отрицательным результатам и выйти за границы бюджета.
Другая проблема — конфликты интересов отделов и департаментов. Чтобы команда работала эффективно и проект достигал целей быстрее, часть задач в бэклоге должна иметь высший приоритет, а часть — более низкий.
Если у разных отделов (на стороне заказчика) нет понимания, что их задачи справедливо отодвигаются в угоду другим задачам, порождается большое количество домыслов и конфликтов.
Как именно подойти к вопросу планирования управления разработкой с учётом перечисленных проблем, рассмотрим в этой статье.
Эдвард Деминг сформулировал модель непрерывного управления качеством PDCA: plan — do — check — act («планирование — действие — проверка — корректировка»). Цикл PDCA тесно связан с философией agile и также призывает нас действовать короткими итерациями, находиться в тесной связи с реальностью и каждый раз проверять, идём ли мы в нужную сторону.
В одной из своих статей мы уже обсуждали, что программное обеспечение по agile — это запутанные системы с большим количеством факторов, причинно-следственные связи между которыми неясны. При заказе разработки любому заказчику сложно предвидеть все проблемы, с которыми столкнутся программисты, и сформулировать требования к готовому продукту.
Но есть эффективные способы, которые помогут добавить ясности и упорядочить работу. Давайте подробно рассмотрим методику Impact Mapping и юнит-калькулятор как один из прикладных инструментов DDDM (принятие решений на основе данных, data-driven decision making).
Метод Impact Mapping помогает чётко формулировать цели проекта в соответствии с целями всего бизнеса. Для этого нужно построить интеллект-карту с ответами на четыре главных вопроса.
Главное последствие использования карт влияния — чёткое решение бизнес-задач заказчика, а не функциональность ради функциональности.
Допустим, в ИТ-компанию приходит заказчик — владелец крупного интернет-магазина одежды и обуви с запросом на срочный редизайн сайта.
Проектные менеджеры не могут взять задачу с такой формулировкой, потому что это не соответствует data-driven-подходу в принятии управленческих решений.
Сначала нужно спросить зачем и определить цель проекта, затем оцифровать её, записать в числовом выражении. Иначе будет невозможно оценить результаты и сделать выводы («мы молодцы, достигли цели» или «мы не смогли достичь цели, давайте думать, почему и как это исправить»).
Например, после совместного обсуждения может выясниться, что бизнес-цель заказчика — рост продаж на 1,5% в ближайшие три месяца.
Проектным менеджерам необходимо сделать Impact Mapping вместе с заказчиком, и картина может получиться такой: добиться увеличения продаж на 1,5% можно четырьмя способами.
Метод Impact Mapping можно применять и для b2b-проектов, например оценивать процент использования портала при заказах (в идеале — 100 %). Для CRM- или BPM-системы целевым показателем может быть процент пользователей, работающих в CRM, от общего количества сотрудников.
В случае с нашим заказчиком, который хотел редизайн, возникает вопрос: возможно, редизайн ему вовсе не нужен? Чтобы это узнать, сравним все варианты решения и выберем самый выгодный. Полезный метод для такого сравнения — юнит-экономика. Он также помогает проверить, как ваши ценности соотносятся с реальными действиями.
Рассмотрим более подробно полезнейший инструмент: юнит-калькулятор, который мы сами всегда используем для ecommerce-проектов и рекомендуем использовать всем до того, как приступить к задаче на разработку.
Каждое действие (разработка каждого кусочка функции) в идеале должно быть связано с какой-то ценностью проекта. Зелёная кнопка или новый дизайн — всё должно как-то изменить метрики проекта и как-то окупиться. Ведь если разработка не связана с ценностью для бизнеса, затраты на разработку будут казаться заказчику очень высокими.
Юнит-экономика наглядно показывает рентабельность каждого изменения в проекте или проекта целиком: сколько зарабатывает (или теряет) бизнес с каждого заказа, с каждого пользователя, каждого конечного покупателя.
Для этого удобно использовать юнит-калькулятор в виде Excel-таблицы. Давайте рассмотрим самый упрощённый вариант такого калькулятора (на самом деле в юнит-экономике гораздо больше влияющих факторов и гораздо более сложные формулы, но на этом примере мы сможем уловить главные принципы расчёта).
В этой таблице мы меняем значения во влияющих ячейках (поток пользователей или потенциальных клиентов, конверсия, число платящих, доход на одного платящего, сколько в среднем платит клиент, издержки на каждой продаже или комиссия, число покупок на одного платящего), чтобы увидеть изменение значений в зависимой ячейке (gross profit, или доход).
В качестве влияющих ячеек можно добавлять любые факторы вашего конкретного бизнеса. Например, разные каналы продаж, стоимость привлечения новых пользователей, изменение затрат на логистику.
В некоторых случаях, получая задачи от клиентов, мы предлагаем им сначала воспользоваться юнит-калькулятором и оценить, какое влияние окажет внедрение новой фичи и как изменится доход.
Зачем нам это?
Не можем позволить себе работу в стол; дефицит квалифицированных разработчиков и требование рынка постоянно что-то улучшать приводят к тому, что бэклог проекта всегда больше, чем может сделать команда в реальности. Фичи, которые хочет внедрить клиент, нужно сортировать по приоритетам, а от некоторых и вовсе отказываться.
Сейчас мы работаем над ecommerce-проектом для крупного ювелирного бренда. Оплата заказов в их интернет-магазине ведётся на сайте банка. Клиент хочет переделать чекаут и сделать форму оплаты прямо на сайте.
Чтобы взять эту задачу в работу, проектному менеджеру нужно соотнести её ценность с конечными бизнес-целями проекта.
Основной проблемой может стать отсутствие аналитики. Что делать, если никто никогда не отслеживал, какой процент потенциальных покупателей «отваливается» на шаге оплаты? Действительно ли оплата через сайт банка плохо влияет на продажи?
Если разница в конверсии нулевая или незначительная, выгоды от изменения формы оплаты не будет, зато в это время мы не сможем сделать какие-то другие, более значимые функции. Эффект же может быть вообще противоположным: покупатели будут опасаться платить сразу на сайте, что снизит продажи. Без аналитики состояния «до» невозможно понять, хуже или лучше станет «после».
В этом примере сначала нужно подключить веб-аналитику, чтобы собрать данные для обоснованного решения. Если увидим, что проблема действительно есть, будем менять форму оплаты по циклу PDCA: спланировали — изменили — измерили — если результат не удовлетворил, откатили назад.
При заказе разработки клиенты обычно воодушевлены. Им кажется, что теперь-то найдётся та самая волшебная таблетка, которая решит их проблемы. Они фокусируются на ИТ, забывая о конверсии и рентабельности.
После работы с ФРИИ (Фондом развития интернет-инициатив) мы твёрдо усвоили, что составлять Impact Mapping и считать юнит-экономику каждого проекта необходимо до старта работ. И потом при внедрении любых новшеств постоянно их пересматривать и пересчитывать.
В идеале это должен делать заказчик. Но бывает, мы видим, что решения касательно разработки принимаются без учёта конкретных цифр, и в таких случаях готовы помочь консультацией.
Так мы развиваем у наших заказчиков data-driven-подход к принятию управленческих решений, и результаты этой работы нас радуют: bad features сведены к нулю, бизнес-цели клиентов достигаются быстро.
ну вот. Я про PDCA и запутанные среды, а вы опять про Путина! 😉
Интересно, какой процент магазинов могут себе позволить такую разработку. Судя по размаху подхода, то тут стоимость на разработку будет выше прибыли 95 процентов интернет-магазинов.
все интернет-магазины с оффлайновой сетью могут позволить.
Чтобы посчитать юнит-экономику, не нужно быть ни математическим гением, ни ярдовой компанией.
Для этого есть огромное количество практик для этого (тактические: юнит-экономика, Матрица Эйзенхауэра, Scrum Planning Poker, стратегические: Impact Mapping, юнит-экономика).
Часто клиенты убеждены, что разработка сама по себе без нормального целеполагания даст экономический эффект (вот эти вот все «Лишь бы сделать правильную архитектуру», «Сделать UX дизайн», «Реализовать фич больше чем у конкурента»). Не удивительно, что этого не происходит. И чтобы решить эту проблему, клиенты начинают использовать методики упорядоченных систем (техническое задание например).
Методы, которые применяются в упорядоченных системах, не обеспечивают достижения целей бизнеса в запутанной среде (любая разработка выше совсем элементарной).
Думаю, большинство интернет-магазинов даже не располагают данными, обьем которых достаточен, чтобы можно было оценивать статистически значимые изменения. Т.к. на ту же конверсию форм влияет куча переменных, а ведь их все надо определить, измерить и учесть при расчете погрешности.
Погрешности бывают, но те данные, которые можно получить с помощью настройки Гугл.Аналитики, достаточны для принятия большинства управленческих решений.
Определяем конверсию по разным сегментам. Интересуют два: C1, CN (первый покупатель, последующие покупки).
Очень частая ошибка в измерениях C1/CN. Это легко исправляется)
Я имею в виду, что повышение конверсии формы на 10%, допустим, со 100 до 110 заказов, может быть связано как с изменением формы, так и с изменением ценности предложения (у других сейчас дешевле/нет/плохие условия доставки и т.п.), суточной/недельной и выше динамикой спроса, погодой, праздниками, новостями, изменением характера трафика или вообще входить в стандартный разброс.
Словом, малые выборки показательны только на периодах, когда они становятся большими, однако на больших периодах возрастает количество и роль неизвестных факторов. Ведь так?
Это да. На маленьких цифрах (маленький трафик, малое количество заказов, маленькая история измерения) сложно делать выводы на причины.
Несколько соображений конкретно по интернет-магазинам:
Воронка нижних уровней как правило не подвержена очень сильным колебаниям на протяжении месяца: если в чекауте до заполнения всех полей доходило от исходного числа 15%, то так и доходят. Даже сезоны со скидками вроде черной пятницы не приводят к сильным колебаниям конверсии там, так что можно попробовать так наблюдать. Так что я бы посоветовал посмотреть туда.
Не станем говорить про A/A/B тесты потому что у маленьких проектов нет денег на поддержание сложной инфраструктуры с тремя версиями проекта (мы же говорим про целеполагание в разработке, с маркетингом можно обойтись только GTM+Google Experiments)
