Как мы побеждаем неопределенность в Delivery Club

Друзья, всем привет! Меня зовут Коля Архипов, я отвечаю за Research & Development в Delivery Club.

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

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

Сегодня расскажу о гонке, которую наша команда прошла за последний год. Аналогия возникла сама собой — мы работаем в очень динамичной компании, лидере рынка FoodTech в России. Мы стремительно развиваем разные направления бизнеса, и это действительно драйвит! Мы не только успешно пришли к финишу, но и получили много инсайтов в процессе «гонки». Этим и хочу поделиться с вами.

Статья появилась после доклада на конференции РИТ++ 2020. Для тех, кто любит видео, — ищите его в конце статьи.

Чайник уже кипит? Супер! Итак, о чем сегодня пойдет речь:

1. R&D и неопределенность. С чем столкнулись мы.
2. Эксперименты. Как и зачем мы проводим их в бою.
3. Измеримость. Обсудим выбор метрик и работу с рисками.
4. Автономность. Как мы в DC Tech адаптировали фреймворк GIST и подход Inner Source.

Зеленый свет, сцепление, первая — поехали.

R&D и неопределенность

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

Сразу обозначим, мы про другое. R&D в Delivery Club — это решение прикладных задач. Наш бизнес стремительно развивается, растет количество заказов, а большая часть наших внутренних процессов основана на данных и алгоритмах. При росте объема входных данных некоторые алгоритмы перестают быть эффективными, и те компоненты, которые нас полностью устраивали вчера, сегодня мы зачастую находим неработоспособными.

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


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

Как достичь цели

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

Что именно стоит сделать

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

Когда мы сможем достичь цели

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

Зачем мой код вообще кому-то нужен

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

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

1. Процесс прозрачного, понятного экспериментирования как для бизнеса, так и для разработки.
2. Процесс выбора метрик. Всё, что мы делаем, должно быть измеримо. Очень здорово, когда разработчики видят реальные бизнес-метрики в реальном времени, мы все сразу понимаем, как наш код влияет на бизнес.
3. Всё это работает, только когда мы полностью автономны, то есть бизнес решает быстро и не тонет в каких-то бюрократических обсуждениях. Аналогично и разработка. У нас весь IT-департамент поделен на продуктовые группы (об этом рассказывали в одной из предыдущих статей), и часто, чтобы запустить фичу, необходимо доработать не только наш сервис, но еще и 2-3 рядом стоящих. Наша автономность здесь — доработать все необходимые компоненты самим, чтобы не зависеть от бэклога других команд.

Схематично на картинке ниже.

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

Не останавливаемся. Сцепление, вторая передача, стремительно набираем обороты.

Эксперименты

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

Выглядит довольно понятным, и тут вы, наверное, скажете — довольно теории! Пора переходить к реальным запускам.

Согласен с вами, но всё же ещё немного остановимся на процессе экспериментов. Посмотрим на картинку целиком.

1. Бизнес-задача — повысить качество нашего сервиса. Мы — товарный агрегатор, наши логисты доставляют заказы, для нас критически важно качество сервиса доставки.
2. Цель — улучшить метрику. В нашем примере это время доставки. Вполне понятная и обозримая величина — среднее время, за которое мы доставляем заказ.
3. Инкремент продукта — Just In Time. Важный подход, который мы внедрили в наши процессы: инкремент продукта, который предполагается внедрить, предлагает именно команда разработки. Мы достигли этого, фокусируясь на домене и процессах, которые происходят внутри платформы, а также изучая свою аудиторию через эксперименты. Мы интересуемся, как устроен FoodTech-рынок в других странах: эти знания помогают нам ориентироваться, на каких объемах какие инструменты работают эффективно. Совокупно полученные знания помогают команде разработки самой предлагать фичу бизнесу, чтобы достичь цели.

Давайте подробнее разберем, какой процесс находится под капотом у инкремента продукта.



3.1 Гипотеза. Она может быть сформулирована на словах или показана схематично. Главное, понятно обосновать, почему она вообще должна работать. То есть теоретическая подготовка у эксперимента обязана быть.

3.14 Разработка. Не буду здесь останавливаться, подробнее о нашей разработке рассказано в этой статье. Мы используем Scrum, двухнедельные итерации со всеми необходимыми активностями.

3.2 Подготовка. Далее необходимо подготовить эксперимент. То есть нужно определиться с геосегментом или аудиторией, с которой мы хотим коммуницировать в процессе этого эксперимента. А также выбрать сегмент, с которым мы будем сравнивать результаты.

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

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

3.5 Вывод. Наверное, самый важный пункт этого процесса. В нашем случае вывод — это всегда нажатие трёх кнопок:

• rollout эксперимента дальше, на следующую географию или следующий сегмент аудитории;
• rollback, если что-то пошло не так;
• continue. Бывают такие случаи, когда мы видим влияние сторонних факторов, которое не учли, и в результате однозначный вывод сделать не можем. В этих случаях мы решаем продолжить.

Реальный эксперимент

Наконец-то пришло время посмотреть, как это работает на реальном примере. Ещё не устали? Начинается самое интересное.

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

Для начала обоснуем гипотезу.

Жадный алгоритм

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


В этом примере мы получаем суммарно 45 минут на подбор двух заказов. Кажется, мы можем лучше.

Just in Time

Задача этого алгоритма — выбрать именно того курьера, который прибудет в ресторан ровно ко времени, когда заказ будет готов. Что это нам даст? Позволит в конечном счете сократить время доставки за счет того, что:

• курьер будет проводить меньше времени в ресторане;
• мы будем выбирать курьера более оптимально.

Технически это реализовать довольно просто. При поступлении заказа мы выбираем курьера сразу, но не говорим ему о заказе, тем самым делаем «виртуальное назначение» и даём себе время поменять свой выбор. А окончательно решать (передавать ли заказ курьеру) будем только тогда, когда путь до ресторана будет равен оставшемуся времени на приготовление заказа. Схематично — на иллюстрации ниже.



В итоге мы подбираем заказы всего 30 минут, что меньше на треть, чем в предыдущем случае.

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

Переходим к подготовке эксперимента

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

Обязательно договариваемся с бизнесом о красных флагах и реакции на них. Красные флаги — это пороговые значения бизнес-метрик, которые мы не хотим пересекать в процессе эксперимента. Если пересекли, то в подавляющем числе экспериментов это rollback. Но бывают и исключения, когда мы точно знаем, что пересечение случилось не из-за нас, а стало следствием других факторов. В этом случае мы иногда можем решить продолжить эксперимент.

Что ещё нужно подготовить? Договориться с нашими коллегами из диспетчерской, которые в режиме реального времени наблюдают, что с заказами всё хорошо. Для них наше изменение будет видно, потому что раньше мы назначали заказ на курьера сразу, а теперь мы этого не делаем, даём себе некоторое время, чтобы передумать. Именно поэтому коллег стоит предупредить о планирующихся экспериментах.

Окей, идём дальше. Подготовили эксперимент, провели его и получили результаты. И тут начинается самое интересное — анализ.

Анализ эксперимента

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

Давайте разберем результаты. Графики мы покажем без конкретных величин, потому что целью статьи не является подробный разбор эффективности Just In Time алгоритма. Мы хотим больше сосредоточиться именно на нашем подходе при проведении экспериментов. По этой же причине мы не будем останавливаться на теории проведения А/В-тестов и определении статистической значимости результатов, это огромная тема для следующей публикации, а, возможно, даже для целого цикла.

• График «Общее время доставки». Напомню, мы ожидали, что общее время доставки будет иметь тренд на снижение. Он действительно есть, и это классно. Да, в процессе измерения присутствуют колебания — ожидаемо, поскольку подмешивается довольно много факторов. Например, фактор погоды для нас непредсказуем. Идет дождь, люди не хотят выходить из дома, они заказывают еду чаще. А курьеры не очень хотят работать в дождь, поэтому реже выходят на смены. Ключевая метрика имеет тренд на снижение, при этом в другом городе, с которым мы сравниваем (А/В), снижения не наблюдается — кажется, мы добиваемся того, чего хотели. Но давайте посмотрим на соседние бизнес-показатели, на которые мы также могли повлиять.
• График «Время в ресторане». Это очень важный показатель. По понятным причинам, в условиях пандемии мы не можем допустить, чтобы курьеры проводили в ресторанах времени больше, чем это было до наших изменений. Поэтому за этой метрикой мы смотрели так же пристально, как и за целевой. И здесь мы тоже видим тренд на снижение, это положительный результат.
• Графики «Занятость курьеров» и «Доля отменённых заказов». Важный момент: их поведение практически не изменилось в ходе эксперимента. Нас это полностью устраивает.

Вывод

В итоге мы имеем снижение ключевой метрики (1), снижение очень важной метрики (2), стабильные значения двух других ключевых метрик (3, 4), красные флаги не загорелись. Это позволяет сделать вывод об успешности эксперимента и валидности проверяемой гипотезы.

Класс! Побежали дальше, к следующей гипотезе? Она фантастически интересная и призвана улучшить жизнь всем! Но нет, это ещё не всё. Остался, пожалуй, один из самых важных шагов, про который нам не стоит забывать. Это нажать одну из трёх кнопок:

1. Rollout
2. Rollback
3. Continue

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

Эксперименты в реальных условиях

Остановимся коротко на том, почему мы экспериментируем сразу в бою. Такому подходу обычно противопоставляют аналитические симуляционные среды, которые на основе исторических данных могут с определенной точностью ответить, что «было бы», если бы мы внедрили такую фичу.

Почему мы выбрали для себя первый подход? Две причины.

• Во-первых, этот подход позволяет командам разработки и бизнеса изучать аудиторию.
  Это очень важный момент, ведь если немного порассуждать, то мы каждый день на работе сталкиваемся с вызовами самого разного характера. Например, мы можем не владеть какой-то технологией, тогда мы открываем доку, Хабр. Или мы можем не знать некоторых нюансов процессов внутри компании — идём к более опытным коллегам и спрашиваем.
  
  Но аудитория конкретного продукта уникальна. Узнать её лучше мы можем только через эксперименты.
  
  Для чего нам лучше знать аудиторию? Чтобы каждая следующая доработка продукта была удобной и правильной, не привносила дополнительного стресса в работу наших курьеров, делала работу партнёров с нами комфортной, а наших пользователей — счастливыми. Пока вы не знаете аудиторию, вероятность ошибки всегда выше, но каждый следующий инкремент, который вы предложите, будет больше подходить вашей аудитории, больше нравиться вашим клиентам. Вы будете получать результат быстрее, более приятный для всех участников процесса.
  
  Здесь стоит быть честным, что это довольно рискованный подход. Риск разочаровать аудиторию, клиентов, бизнес. Эта статья во многом и посвящена тому, как снизить такие риски: аккуратно и качественно выбирать метрики (несколько) и следить за ними в режиме реального времени. В случае, если что-то идёт не так, мы просто сразу выключаем эксперимент.

• Второе — это, конечно, скорость. Эксперименты в боевых условиях значительно точнее и быстрее покажут результат.

Прежде, чем побежим дальше, зафиксируем небольшие победы.


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

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

Измеримость

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

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

Как выбрать метрики

Наш опыт показывает, что хороший рецепт — когда метрик несколько. Одна целевая метрика — её улучшаем; и ещё несколько ключевых — их мы не должны уронить.

Внедрить единое пространство мониторинга, в которое смотрит и бизнес, и разработка. Это необязательно должен быть один инструмент, мы используем два: Metabase и Grafana, но в будущем планируем выбрать один из них. Самое важное — должно быть единое пространство, куда будут смотреть коллеги как из бизнеса, так и из разработки. И обязательно определить красные флаги.

Красные флаги

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

И ещё одна небольшая победа: мы ответили на вопрос «Зачем мой код вообще кому-то нужен». Давайте не забудем про неё!


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

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

Автономность

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

GIST

Здесь под автономностью мы будем понимать минимальную зависимость при принятии решения. Что мы сделали со стороны бизнеса, чтобы решать быстро и не утонуть в процессах согласований? Мы внедрили фреймворк GIST.


Это подход Goals, Ideas, Step-projects, Tasks. У компании есть понятные бизнес-цели, которые руководство прозрачно транслирует всем сотрудникам. Чтобы реализовать эти цели, сотрудники накидывают идеи. Идей может быть десяток или одна. Важно, что идея — это пока ещё не проект. Это некоторые подходы, которые хотелось бы реализовать. Step-project — вот это уже проекты: довольно крупные фичи, которые эти идеи реализуют. В рассмотренном нами примере Just In Time назначение как раз является Step-project. На последнем уровне находятся привычные нам таски — это уже декомпозированный Step-project, оцененный в трудозатратах.

Так как же подход помогает достичь автономности? Когда мы предлагаем сделать эту фичу (Just In Time), бизнес прозрачно видит:

1. Размер и стоимость реализации фичи.
2. Какую идею он реализует.
3. На какую конкретно цель компании направлен (импакт).

Далее нам остаётся сравнить его с соседним Step-project по тем же критериям: стоимость, импакт. Проводим встречу (они у нас регулярные), обсуждаем, расставляем приоритеты и принимаем решение.

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

Inner Source

Это как open source, только внутри компании. Архитектура Delivery Club — микросервисы, сейчас их более сотни. Часто, чтобы сделать фичу, необходимо доработать не только компоненты, за которые отвечает наша команда, но и соседние сервисы. И тут у нас два пути:

1. Положить в бэклог других команд доработки, договориться, что ребята их сделают.
2. Сделать самим.

В нашей адаптации процесс работает следующим образом. Есть большая фича Just In Time, она затрагивает три группы сервисов:

• платформу автоназначения, за которую отвечает R&D,
• платформу логистики,
• компоненты взаимодействия с партнёрами (рестораны и магазины).

Мы поступаем так:

1. собираем все задачи в бэклог команды R&D;
2. расставляем приоритеты и распределяем внутри команды, кто из ребят какой из компонентов будет дорабатывать;
3. договариваемся с техническими лидерами команд логистического и партнёрского направлений о нюансах реализации;
4. разрабатываем сами, коллеги проводят ревью;
5. далее мы сами тестируем;
6. на раскатку в продакшн уже отдаем владельцам сервисов.

После попадания в продакшн эти доработки остаются в зоне ответственности команд, которые являются владельцами этих сервисов.

Буду абсолютно честен, подход не идеален и у него есть риски. Основной — это сроки. Чаще всего мы дорабатываем компоненты в 2-2,5 раза дольше, чем это сделали бы владельцы сервисов.

Но очевидна и выгода, она значительно перевешивает небольшую задержку в реализации — это предсказуемость. Здесь важно отметить, что у других команд есть свой бэклог, свои приоритеты, и взять наши задачи «срочно» они чаще всего не могут. Поэтому для бизнеса наш срок — реалистичный, на него не повлияют возможные изменения приоритетов в других командах.

Итак, мои поздравления — финиш, победа!


Мы внедрили фреймворк GIST для быстрого и прозрачного принятия решений, и подход Inner Source для автономности в разработке, и теперь все элементы мозаики собраны. Пора закругляться, это была интересная гонка, спасибо вам за участие! Подведем итоги.

Выводы

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

Видеозапись доклада с конференции РИТ++ 2020.


На этом всё, спасибо, что были со мной в этом заезде. Я уверен, что мы находимся в самом начале и большие вызовы ещё ждут нас впереди. С радостью поделюсь ими, до новых встреч!