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

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

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

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

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

Эдвард Деминг сформулировал модель непрерывного управления качеством PDCA: plan–do–check–act (рус. планирование – действие – проверка – корректировка). Цикл PDCA тесно связан с философией Agile и так же призывает нас действовать короткими итерациями, находиться в тесной связи с реальностью и каждый раз проверять, идём ли мы в нужную сторону.

Чтобы разработка продукта была эффективной, необходимо:

Похоже на принципы разработки MVP, правда?

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

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

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

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

Допустим, в IT-компанию приходит заказчик — владелец крупного интернет-магазина одежды и обуви с запросом на срочный редизайн сайта.

Проектные менеджеры не могут взять задачу с такой формулировкой, потому что это не соответствует data-driven подходу в принятии управленческих решений. Сначала нужно задать вопрос «зачем?» и определить цель проекта, затем оцифровать её, записать в числовом выражении. Иначе будет невозможно оценить результаты и сделать выводы («мы молодцы, достигли цели» или «мы не смогли достичь цели, давайте думать, почему и как это исправить»).

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

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

В случае с нашим заказчиком, который хотел редизайн, возникает вопрос: возможно, редизайн ему вовсе не нужен? Чтобы это узнать, сравним все варианты решения и выберем самый выгодный. Полезный метод для такого сравнения — юнит-экономика. Он также помогает проверить, как ваши ценности соотносятся с реальными действиями.

Рассмотрим более подробно полезнейший инструмент: юнит-калькулятор, который мы сами всегда используем для e-Commerce-проектов и рекомендуем использовать всем до того, как приступить к задаче на разработку.

Каждое действие (разработка каждого кусочка функционала) в идеале должно быть связано с какой-то ценностью проекта. Зелёная кнопка или новый дизайн — всё должно как-то изменить метрики проекта и как-то окупиться. Ведь если разработка не связана с ценностью для бизнеса, затраты на разработку будут казаться заказчику очень высокими.

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

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

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

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

Свежий пример

Cейчас мы работаем над e-Commerce-проектом для крупного ювелирного бренда. Оплата заказов в их интернет-магазине ведётся на сайте банка. Клиент хочет переделать чекаут и сделать форму оплаты прямо на сайте.

Чтобы взять эту задачу в работу, проектному менеджеру нужно соотнести её ценность с конечными бизнес-целями проекта. Основной проблемой может стать отсутствие аналитики. Что делать, если никто никогда не отслеживал, какой процент потенциальных покупателей «отваливается» на шаге оплаты? Действительно ли оплата через сайт банка плохо влияет на продажи? Если разница в конверсии нулевая или незначительная, то выгоды от изменения формы оплаты не будет, зато в это время мы не сможем сделать какой-то другой, более значимый функционал. Эффект же может быть вообще противоположным: покупатели будут опасаться платить сразу на сайте, что снизит продажи. Без аналитики состояния «до» невозможно понять, хуже или лучше станет «после».

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

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

После работы с ФРИИ (Фондом развития интернет-инициатив) мы твёрдо усвоили, что составлять Impact Mapping и считать юнит-экономику каждого проекта необходимо до старта работ. И потом при внедрении любых новшеств постоянно их пересматривать и пересчитывать.

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