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

Я Андрей Путин, генеральный директор kt.team. Наша компания занимается разработкой сложных ИТ-решений (высоконагруженные интернет-магазины, b2b- и b2g-порталы, продукты с машинным обучением, дополненной и виртуальной реальностью и многое другое).

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

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

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

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

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

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

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

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

1. Чётко сформулировать цель, наметить план (plan).
2. Совершить нужные действия в соответствии с планом и целями (do).
3. При каждом обороте колеса (каждом цикле разработки) регулярно проверять, в правильном ли направлении мы движемся (check).
4. Если наши действия не приближают нас к цели, скорректировать их в нужную сторону (act).

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

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

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

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

1. Why? Зачем нужен этот продукт? Какую задачу бизнеса он должен решить?
2. Who? Кто может влиять на достижение этой цели?
3. How? Что он может сделать?
4. What? Какие конкретные шаги должен сделать ответственный в рамках своих задач?

1. Излишняя функциональность
   C Impact Mapping на виду ценность каждого действия. Если ценности нет, значит, решение избыточное, нужно от него отказаться.
2. Несогласованность действий, отсутствие контроля и координации внутри компании-заказчика
   Для ответа на вопрос «кто» нужно определить всех, кто влияет на решение проблемы. Руководители производственного отдела и отдела продаж, маркетологи и логисты, любые другие сотрудники, которые могут влиять на продукт разработки и итоговое достижение целей, должны как минимум встретиться и обсудить все задачи. Зона ответственности каждого будет записана в карту влияния (impact map). Это упрощает контроль над выполнением решений.Что бывает, если пропустить этот шаг, рассказываем в следующем кейсе. Мы делали b2b-портал для оптового поставщика продуктов питания. Заказчик описал нужную функциональность, но оказалось, что в жизни всё работает не так, как в его мечтах. Узнать об этом удалось только при тестировании продукта одним из департаментов, который никто не посчитал нужным привлечь к созданию технического задания (отдельный вопрос, зачем им вообще понадобилось техническое задание). Запуск проекта пришлось отодвинуть.
3. Трудно сравнивать варианты выбора
   Для каждой цели в Impact Mapping группируются все возможные варианты достижения этой цели. После проведения анализа и сравнения их эффективности на конкретных KPI и OKR можем быть уверены в правильности своего решения (и никаких мук выбора).
4. Сложно планировать время и бюджет на разработку
   Пожалуй, это самый распространённый страх заказчиков перед гибкими методологиями в разработке. Но когда все действия разбиты на шаги, планировать гораздо легче, правда? Если выполнять работы короткими итерациями (например, в две недели), соблюдать цикл PDCA, регулярно сверять свои действия с целями, быстро вносить корректировки при отклонениях, согласитесь, будет легче добиться успеха, чем при горизонте планирования в год или пятилетку.

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

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

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

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

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

Метод Impact Mapping можно применять и для b2b-проектов, например оценивать процент использования портала при заказах (в идеале — 100 %). Для CRM- или BPM-системы целевым показателем может быть процент пользователей, работающих в CRM, от общего количества сотрудников.

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Если у фичи, предлагаемой клиентом, нет значимой роли,
   наличие этих сведений может помочь клиенту изменить приоритеты бэклога.
2. Если юнит-калькулятор показывает, что изменение конверсии даже на 0,01 % даст значимый финансовый результат,
   начинать улучшения стоит с самых узких мест воронки продаж. Но далеко не всегда конверсия — главный фактор. Иногда лучше сначала поработать с retention (удержанием) или обеспечить проект качественным трафиком, и только после этого возвращаться к разработке фич.

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

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

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

Так мы развиваем у наших заказчиков data-driven-подход к принятию управленческих решений, и результаты этой работы нас радуют: bad features сведены к нулю, бизнес-цели клиентов достигаются быстро.

#разработка #планирование