Impact Mapping, юнит-экономика и PDCA: грамотное управление разработкой e-Commerce

Зачастую клиенты обращаются к разработчикам как к волшебникам, с надеждой, что те создадут чудо-IT-продукт.

Он решит все проблемы: приведёт толпы клиентов, увеличит продажи, снизит издержки.

Вот только без усилий самого заказчика и без точных экономических расчётов это невозможно.

Оценивают ли заказчики экономический эффект от внедрения каждой фичи?

Ставят ли разработчикам только те задачи, которые 100 % приведут к результату?

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

Другая проблема - конфликты интересов отделов и департаментов.

Чтобы команда работала эффективно и проект достигал целей быстрее, часть задач в бэклоге должна иметь высший приоритет, а часть - более низкий.

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

Как именно подойти к вопросу планирования управления разработкой с учётом перечисленных проблем, рассмотрим в этой статье.

и юнит-калькулятор как один из прикладных инструментов DDDM (принятие решений на основе данных, англ. data-driven decision making). Impact Mapping

Метод Impact Mapping помогает чётко формулировать цели проекта в соответствии с целями всего бизнеса.

Для этого нужно построить интеллект-карту с ответами на четыре главных вопроса. 1. Why?

Какую задачу бизнеса он должен решить? 2. Who?

Кто может влиять на достижение этой цели? 3. How?

Какие конкретные шаги должен сделать ответственный в рамках своих задач?

Пример работы метода Impact Mapping

Если ценности нет, значит, это избыточное решение - нужно от него отказаться. 2.

Несогласованность действий, отсутствие контроля и координации внутри компании-заказчика

Для ответа на вопрос «who?» нужно определить всех, кто влияет на решение проблемы.

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

Зона ответственности каждого будет записана в карту влияния (англ. impact map).

Это упрощает контроль над выполнением решений.

Что бывает, если пропустить этот шаг, рассказываем в следующем кейсе.

Мы делали B2B-портал для оптового поставщика продуктов питания.

Заказчик описал нужный ему функционал, но оказалось, что в реальной жизни всё работает не так, как в его мечтах.

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

Запуск проекта пришлось отодвинуть. 3.

Для каждой цели в Impact Mapping группируются все возможные варианты достижения этой цели.

После проведения анализа и сравнения их эффективности на конкретных KPI/OKR можем быть уверены в правильности своего решения (и никаких мук выбора). 4.

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

Но когда все действия разбиты на шаги, планировать гораздо легче, правда?

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

Главное последствие использования карт влияния - чёткое решение бизнес-задач заказчика, а не функционал ради функционала.

вместе с заказчиком, и картина может получиться такой: добиться увеличения продаж на 1,5 % можно четырьмя способами.

Метод Impact Mapping можно применять и для B2B-порталов, например оценивать процент использования портала при заказах (в идеале - 100 %).

Для CRM/BPM-системы целевым показателем может быть процент пользователей, работающих в CRM, от общего количества сотрудников. В случае с нашим заказчиком, который хотел редизайн, возникает вопрос: возможно, редизайн ему вовсе не нужен?

Чтобы это узнать, сравним все варианты решения и выберем самый выгодный.

Полезный метод для такого сравнения - юнит-экономика.

Он также помогает проверить, как ваши ценности соотносятся с реальными действиями.

Рассмотрим более подробно полезнейший инструмент:

Cейчас мы работаем над e-Commerce-проектом для крупного ювелирного бренда.

Оплата заказов в их интернет-магазине ведётся на сайте банка.

Клиент хочет переделать чекаут и сделать форму оплаты прямо на сайте.

Чтобы взять эту задачу в работу, проектному менеджеру нужно соотнести её ценность с конечными бизнес-целями проекта.

Основной проблемой может стать отсутствие аналитики.

Что делать, если никто никогда не отслеживал, какой процент потенциальных покупателей «отваливается» на шаге оплаты?

Действительно ли оплата через сайт банка плохо влияет на продажи?

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

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

Без аналитики состояния «до» невозможно понять, хуже или лучше станет «после». В этом примере сначала нужно подключить web-аналитику, чтобы собрать данные для обоснованного решения.

Если увидим, что проблема действительно есть, будем менять форму оплаты по циклу PDCA: спланировали - изменили - измерили - если результат не удовлетворил, откатили назад.

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

Если юнит-калькулятор показывает, что изменение конверсии даже на 0,01 % даст значимый финансовый результат, начинать улучшения стоит с самых узких мест воронки продаж.

Но далеко не всегда конверсия - главный фактор.

Иногда лучше сначала поработать с retention (удержанием) или обеспечить проект качественным трафиком, и только после этого возвращаться к разработке фич.

При заказе разработки клиенты обычно воодушевлены.

Им кажется, что теперь-то найдётся та самая волшебная таблетка, которая решит их проблемы.

Они фокусируются на IT, забывая о конверсии и рентабельности.

После работы с ФРИИ (Фондом развития интернет-инициатив) мы твёрдо усвоили, что составлять