{"id":13502,"url":"\/distributions\/13502\/click?bit=1&hash=a81ed6f897d123d854b91b907b479be2ea058a6a8ec03bd6f76bfc8a24665263","title":"\u0425\u043e\u0447\u0443 \u043d\u0430\u0440\u0438\u0441\u043e\u0432\u0430\u0442\u044c \u0438 \u0430\u043d\u0438\u043c\u0438\u0440\u043e\u0432\u0430\u0442\u044c 3D-\u043c\u0443\u043b\u044c\u0442\u0444\u0438\u043b\u044c\u043c. \u0413\u0434\u0435 \u0443\u0447\u0438\u0442\u044c\u0441\u044f?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"7eb01878-f5ab-5bdb-ae26-b8e9a900dfa1","isPaidAndBannersEnabled":false}

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

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

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

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

Типичные проблемы в управлении разработкой, от которых спасает Impact Mapping

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

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

Пример Impact Mapping для интернет-магазина одежды и обуви

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

Проектные менеджеры не могут взять задачу с такой формулировкой, потому что это не соответствует 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 сведены к нулю, бизнес-цели клиентов достигаются быстро.

0
31 комментарий
Написать комментарий...
Dmitry Ilyin
 Я Андрей Путин

это сразу звучит гордо, впечатляюще и  масштабно!

Ответить
Развернуть ветку
Андрей Путин

ну вот. Я про PDCA и запутанные среды, а вы опять про Путина! ;)

Ответить
Развернуть ветку
Антон Гранд

Моль

Ответить
Развернуть ветку
Николай Кекиш

Интересно, какой процент магазинов могут себе позволить такую разработку. Судя по размаху подхода, то тут стоимость на разработку будет выше прибыли 95 процентов интернет-магазинов.

Ответить
Развернуть ветку
Dmitry Ilyin

все интернет-магазины с оффлайновой сетью могут позволить.

но считать, или хотя бы прикидывать, рентабельность и приоритетность задач - must для любой мало-мальской разработки.

Ответить
Развернуть ветку
Андрей Путин

Чтобы посчитать юнит-экономику, не нужно быть ни математическим гением, ни ярдовой компанией.

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

Для этого есть огромное количество практик для этого (тактические: юнит-экономика, Матрица Эйзенхауэра, Scrum Planning Poker, стратегические: Impact Mapping, юнит-экономика).

Часто клиенты убеждены, что разработка сама по себе без нормального целеполагания даст экономический эффект (вот эти вот все "Лишь бы сделать правильную архитектуру", "Сделать UX дизайн", "Реализовать фич больше чем у конкурента"). Не удивительно, что этого не происходит. И чтобы решить эту проблему, клиенты начинают использовать методики упорядоченных систем (техническое задание например).

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

Ответить
Развернуть ветку
Артем Богданов

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

Ответить
Развернуть ветку
Андрей Путин

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

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

Определяем конверсию по разным сегментам. Интересуют два: C1, CN (первый покупатель, последующие покупки).

Всё, данные настроены.
Мы часто сталкиваемся с запросами о том, что клиентам нужна аналитика более серьёзная. Иногда это оправдано, часто - нет, потому что слабая аналитическая культура при любом, самом продвинутом инструменте (AA, OWOX, etc) всегда остаётся слабой культурой. Так что если сейчас никакие данные не используются, начните с самых простых инструментов и далее можно усложнять.

Очень частая ошибка в измерениях C1/CN. Это легко исправляется)

Ответить
Развернуть ветку
Артем Богданов

Я имею в виду, что повышение конверсии формы на 10%, допустим, со 100 до 110 заказов, может быть связано как с изменением формы, так и с изменением ценности предложения (у других сейчас дешевле/нет/плохие условия доставки и т.п.), суточной/недельной и выше динамикой спроса, погодой, праздниками, новостями, изменением характера трафика или вообще входить в стандартный разброс.

А у небольших ИМ сегодня 30 заказов, завтра 50, послезавтра 10. А/B тестирование на таких величинах не сможет подтвердить эффективность решения, а при расширении времени теста до, скажем, 1 мес. на измеряемый показатель начинает оказывать влияние целый набор переменных (в нач. месяца товар стоил А, сейчас А+А*10%; в нач. месяца оставалась зп, сейчас - нет, да и трафик стали получать с нового канала и т.п.) К тому же мы не имеем оснований сравнивать этот месяц ни с прошлым, ни с прошлогодним, потому что это совершенно другие периоды со своими условиями. 

Словом, малые выборки показательны только на периодах, когда они становятся большими, однако на больших периодах возрастает количество и роль неизвестных факторов. Ведь так?

Ответить
Развернуть ветку
Андрей Путин

Это да. На маленьких цифрах (маленький трафик, малое количество заказов, маленькая история измерения) сложно делать выводы на причины.

Несколько соображений конкретно по интернет-магазинам:

Воронка нижних уровней как правило не подвержена очень сильным колебаниям на протяжении месяца: если в чекауте до заполнения всех полей доходило от исходного числа 15%, то так и доходят. Даже сезоны со скидками вроде черной пятницы не приводят к сильным колебаниям конверсии там, так что можно попробовать так наблюдать. Так что я бы посоветовал посмотреть туда.

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

Не станем говорить про A/A/B тесты потому что у маленьких проектов нет денег на поддержание сложной инфраструктуры с тремя версиями проекта (мы же говорим про целеполагание в разработке, с маркетингом можно обойтись только GTM+Google Experiments)

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Андрей Путин

Более 142 млрд евро ЕС за 2004 год потратил денег на разработку, которая не привела ни к каким целям. Как видите, это не только в России происходит. Почитайте Сазерленда - он начинает с неудачного кейса в ФБР, которые десять лет разрабатывали софт. Миллиарды долларов потрачены. Цели расписаны не то чтобы на 2 листа - тома бумаги исписаны. А результата не было. В запутанных средах конвейер не работает.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Артем Богданов

Эх, буквально позавчера смотрел ваш сайт и типовой расчет проекта, увидел 1+ млн в ценнике и вспомнил, что хорошее стоит дорого. Но data driven - это круто.

Ответить
Развернуть ветку
Сергей Калашников

5млн стоит у них интернет-магазин на Magento))

КП просто смех, без обид.

Ответить
Развернуть ветку
Андрей Путин

Не помню чтобы мы с вами работали..

Не удалось мне в статье донести мысль о том, что "интернет-магазин на Magento" - это не столько разработка, сколько целеполагание. Будем стараться больше.

Ответить
Развернуть ветку
Андрей Путин

Это не беда, деньги - вторичны.

Убежден, что практики IM/UE можно и вовсе без денег внедрять. Если есть желание - всё будет. Ни деньги, ни количество разработки само по себе к результату ведь не ведет.

Ответить
Развернуть ветку
Артем Богданов

Здорово наблюдать зарождение в РФ рынка дизайна, который умеет считать. Большинство решений должно внедряться только на основе расчетов, т.к. иначе их результаты случайны. Возьмите сайт моего ИМ в качестве песочницы для проверки гипотез ваших стажеров :) 

Ответить
Развернуть ветку
Andrey Petrosyan

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

Ответить
Развернуть ветку
Андрей Путин

Хорошо, что врачи не работают по методам, которые вы предлагаете.

Иначе бы это было примерно так:
- Доктор, у меня зуб болит, что делать?
- На методы лечения вы сами налегайте, а я могу дырку просверлить. Говорите какую, где.

Ответить
Развернуть ветку
Andrey Petrosyan

Согласен.
Я думаю к лечению 99% бизнес принципов не применимы. К админ управлению мед средой - да, можно, но лечение в целом это своя вселенная.
Хотя уже пытаются дистанционно лечить...

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Аккаунт заморожен

Комментарий недоступен

Ответить
Развернуть ветку
Андрей Путин

Если оно у вас не работает, значит вы не в том культурном пласте находитесь, или нарушаете техники. Чаще - всё вместе.

Во что выливается например Scrum? Недели начинают называть спринтами, а поток задач теперь - "бэклог". Вот и весь "эйджаил". не удивительно, что это не работает.

И культурный аспект - штука сложная.
Практики, работающие в красном уровне (см. спиральную динамику), не работают уже в синей компании. Agile, TQM/TOC - это всё аспекты верхних уровней осознанности, и если вы строите конвейер, то гибкость там строить иногда просто негде без осознанного движения (вот Тойоте удалось упаковать конвейер в гибкость, очень рекомендую посмотреть на их опыт).

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Андрей Путин

Цветовая градация придумана не нами, а мистером Грейвзом.

Есть в вики, оттуда взял эту ссылку https://romankalugin.com/teoriya-spiralnoj-dinamki-razvitiya-lichnosti-i-chelovechestva-ot-klera-grejvza/

Ответить
Развернуть ветку
Илья Геннадьевич Глушков

Заказчик: Нам нужно выполнить заказ, вы готовы?

Путин: А давай - те подумаем ....

Ответить
Развернуть ветку
Андрей Путин

Не совсем так ))

Заказ в запутанной среде (разработка ПО) и упорядоченной (простой, типа производства гамбургера, или сложной, типа производства моста), требуют разной квалификации.

Поэтому когда мы обсуждаем заказ, мы начинаем ориентироваться на важные цели клиента, составляя Impact Mapping (иногда мы его составляем, но клиент с этим не работает - часто встречается с крупными компаниями). Я считаю, что все-равно успех проекта должен обеспечиваться разработчиками. Иначе через год разработчики отползают от проекта: "мы просто делали ваши задачи. Откуда же нам было знать, что вы не зарабатывали на этих решениях". Вы же к врачу не приходите со списком: "прооперируйте мне тут и вот тут, и еще промывание желудка сделайте"? Вы приходите с задачей, а он обеспечивает решение. Так же должно быть и с инженерами, если они не хотят носить звание "кодер".

Ответить
Развернуть ветку
Егор Рублев

Не читал статью, но с бюджетом в 50к запустил за 5 дней магазин детских игрушек, причем база в 1С (уже была там)и нужно было ее интегрировать.

В декабре с маркета конверсия 12%, дрр 2%, заказов было чуть меньше 1000 (когда вышел сегодня из офиса было 983) это с учётом, что номенклатура меньше 50 позиций, если не ошибаюсь в пик было одновременно 47 товаров в наличии.

Ответить
Развернуть ветку
Андрей Путин
Автор

Статья не про это, статья про целеполагание в разработке. Как хорошо, что у вас все просто работает и никакой запутанности в 2019 году нет! Вы - гений. Или есть нюансы в маркетинговых затратах или маржинальности, которые мы не знаем.

Ответить
Развернуть ветку
Егор Рублев

15-25% чистая прибыль с учетом логистики. Но такой фурор легко списать на новый год. Я именно про сам факт того, что возможно творить волшебство, если что я "маркетолог" наемный рабочий.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Читать все 31 комментарий
null