company_banner

Продуктовая трансформация в Delivery Club Tech

    image

    Привет, Хабр! Как и обещал в предыдущем посте, продолжаю знакомить вас с Delivery Club Tech. Сегодня поговорим о продуктовой трансформации.

    Так совпало, что мой приход в DC в октябре 2018-го ознаменовался тотальной перестройкой всех процессов в команде. В тот момент перед IT-департаментом, да и перед всей компанией, стояли новые вызовы. Было понятно, что прежние процессы не отвечают новым требованиям. В основном они касались снижения Time to Market.

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

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

    Особенности команд


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

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

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

    image

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

    1. Consumer
    2. Logistics
    3. Vendor
    4. Internal

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

    В результате у нас получилась такая ячейка: «Product-менеджер — Team Lead — Dev — QA». К разработчикам мы относим бэкендеров и фронтендеров, но встречаются и команды без фронтов. Фронтендеры у нас либо Web Angular и JS, либо iOS/Android.

    Сейчас в каждой команде в среднем 5 ± два человека. Почему так? К этой формуле мы пришли не сразу. Наша статистика показывает, что именно такой состав команды позволяет добиваться максимально предсказуемого результата. То есть команда способна брать достаточно фич, чтобы произвести существенные изменения в продукте, но при этом сложность планирования остается ниже, чем это было бы при большем количестве людей. То есть погрешность в планировании становится минимальной.

    Какое-то время мы экспериментировали с ролями внутри команды, у нас были тимлиды мобильной разработки (iOS/Android) и тимлид бэкенда. Но в итоге мы пришли к матричной структуре:

    • Один тимлид (как правило, кто-то из бэкенда), у него в прямом подчинении находятся QA, бэкендеры и фронтендеры.
    • По вертикали во главе с product-менеджером идёт ячейка «тимлид — бэкенд — QA».
    • По горизонтали — техлиды. Они объединяют экспертизу сквозь все команды. Например, QA-лиды представляют техническую экспертизу по тестированию, автоматизации и CI/CD, помогают с менторингом и наймом QA-инженеров в команды направления.
    • Лид мобильной разработки и фронтенд-лид также находятся на горизонтали матрицы, в их зону ответственности входит менторинг и качество кода.
    • Для бэкенда мы планируем сделать гильдии разработки.

    image

    Ещё одна наша особенность: у нас нет project-менеджеров и технических аналитиков. Так изначально было в Delivery Club, и мы решили, что не будем это менять. Помните, у нас была проблема с фокусом команд на продукт? Так зачем создавать посредников между командой и product-менеджером? Для нас важно, чтобы команды, в первую очередь, заботились о том, как их фичи влияют на конечного пользователя, а не просто закрывали тикеты в Jira. Для этого людям нужно погружаться в контекст, в предметную область, в бизнес и даже в продуктовые метрики и финансовые показатели.

    Как результат, диалог команды разработки и product-менеджера происходит постоянно. Разработчики не просто берут у product-менеджера список задач и уходят всё это разрабатывать, а могут прийти к нему через пару часов и сказать, к примеру, «Слушай, мы можем вот тут кнопку сделать чуток попроще, зато на неделю быстрее», показать это на числах, и product-менеджер скажет ОК.

    Таким образом, задачу технической аналитики, оценки и декомпозиции техническая команда выполняет самостоятельно, а потом вместе с product-менеджером планирует спринт. Чтобы это работало, мы начинаем спринт как бы за неделю до его начала. Об этом следующий раздел.

    Процесс разработки и планирование спринта



    Pre-Planning


    За неделю до начала спринта product-менеджер приносит кейсы и дизайн, отвечает на вопрос «Что нужно делать?» Техническая команда решает, как она будет это делать и в какой срок всё будет готово.

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

    Planning


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

    Дальше задачи бьются по бакетам, их всего три:

    1. Product 60%
    2. Tech debt 20%
    3. Support 20%.




    Приведу пример. У нас есть команда из 3-х бэкендеров. Это 80 * 3 * 0.8 = 192 полезных часа. На продуктовую разработку мы потратим 116 часов (60%), на Tech debt — 38 часов (20%) и на Support — тоже 38 часов (20%).

    Grooming


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

    Demo


    Логичным завершением спринта является Demo, куда мы приглашаем все команды разработки, стейкхолдеров, коллег из бизнеса и даже руководителя Delivery Club.

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

    Это важный день для всей команды!

    Retro


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

    Например, в Product мы взяли 20 задач, а закончили 17. Следовательно, успеваемость по этому бакету — 85%. Хорошей успеваемостью в продуктовой разработке для нас является показатель от 90%. Если он ниже, мы разбираем на Retro, как можно улучшить эту метрику.

    Работа во время спринта


    Нас часто спрашивают про code review и как происходит тестирование. Тут у нас всё довольно стандартно.

    День начинается со стендапа. За 15 минут команда обсуждает, что делали вчера и что будут делать сегодня.

    Для работы над задачами мы используем Jira Flow и Git Flow, у нас Atlassian-стек. Ещё есть Scrum-доска с колонками to do — in progress — ready for code review — ready for QA — ready for life — done.

    Когда разработчик подготовил код, он делает ветку с действующим номером задачи в Jira — это фича-ветка. Её же он отправляет на pull request в Bitbucket. Разработчику требуется минимум два апрува. Также у нас есть интеграция с Jenkins, если билд позеленел, значит, можно мерджить. Права на мердж есть у техлида и тимлида. Иногда к pull request нужно подготовить unit-test. А иногда мы их намеренно не пишем, если знаем, что это некритичные зоны бизнеса, некритичный домен или фича экспериментальная, и можем её потом выпилить.

    Когда всё смерджили, отправляем на тестирование. Инженер по тестированию пишет автотесты либо прогоняет тест-кейсы вручную. Зависит опять же от того, насколько это критичный домен. А потом деплой.

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

    Направления разработки и структура IT-департамента


    В процессе трансформации мы пришли к новой структуре направлений разработки. Как вы помните, в самом начале мы писали о четырёх. Далее стало понятно, что для качественной и своевременной реализации целей нужно выделить ещё два направления. Таким образом, сейчас их 6:

    • Consumer — это всё про пользовательские продукты: сайт и мобильные приложения.
    • Logistics — про логистов, курьеров и доставку.
    • Vendor — про интеграции с нашими партнёрами (рестораны/магазины).
    • Internal — call-центр и поддержка.
    • R&D — решают наукоёмкие задачи.
    • Platform — улучшение архитектуры и платформы в целом.

    У каждого направления свой спектр задач и свои трудности.

    Consumer


    Приоритет этого направления — счастье пользователя. Основные продуктовые метрики здесь: retention, order conversion rate, consumer NPS. С технической точки зрения нам важно, чтобы все данные отдавались быстро. В этом направлении, пожалуй, самый большой highload, так как идёт работа непосредственно с конечным пользователем. А ещё огромное количество микросервисов, здесь их больше всего.

    Основные продукты — это сайт, в том числе мобильная версия, а также приложения под iOS и Android. Два основных стрима — это доставка продуктов и доставка готовых блюд из ресторанов. Технологический стек плюс-минус как везде: PHP, Go, Postgres, Redis и Memcache для кэша, Kafka для асинхронного взаимодействия.

    Logistics


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

    Один из главных челленджей в логистике возникает, когда растёт количество заказов, а с ним и нагрузка на систему. Чтобы справляться с нагрузками, нужно вносить качественные изменения в архитектуру. Кроме того, доставка еды сильно отличается от доставки, например, канцелярских принадлежностей, одежды, книг и прочего. Там всё немного проще: составили маршрутный лист, запланировали и поехали.

    С доставкой еды такой номер не пройдёт. У нас все on demand, ситуация меняется каждые 5-15 минут. Когда начинается дождь или снег, всегда повышается спрос. А когда на улице солнечно и не хочется сидеть дома, спрос снижается. В праздничные и выходные дни профиль спроса отличается от будней. Дорожная ситуация и пробки также вносят свои коррективы, особенно в тех зонах, где превалируют авто/мото-курьеры. Утренние, дневные и вечерние часы имеют разный профиль спроса.

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

    Одно из основных приложений, над которым работают в логистике, — это Rider App. Оно представляет собой Android-приложение, в котором курьеры смотрят, где забрать заказ и куда его следует доставить.

    Vendor


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

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

    Ещё один продукт, над которым работают в направлении Vendor, — дашборд, в который падают заказы на кухню. Кухня принимает заказ, видит его состав, определяет, как его готовить и, собственно, готовит. Когда заказ приготовлен, кухня подтверждает это в приложении и передаёт заказ курьеру. А дальше курьер работает с приложением Rider App.

    Internal


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

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

    R&D


    Когда нужно поменять какой-нибудь бизнес-процесс и заодно понять, как эти изменения отразятся на всей платформе в целом, подключается Research & Development. Ребята проводят эксперименты, строят модели, считают и взвешивают. Они же плотнее всего взаимодействуют с департаментом BI, где работают с большими данными, ML-моделями, проектируют нейросети, прогнозируют спрос. В этой связке BI помогает R&D с исследованиями и инструментарием.

    Исследования, в основном, касаются работы с данными. Например, как поведёт себя система, если поменять какой-то фактор. Большая часть задач для R&D сейчас поступает из логистики, так как у этого направления самый высокий уровень неопределенности.

    Platform


    Это техническое направление. В первую очередь, ребята нацелены на улучшения ядра системы, занимаются рефакторингом обработки заказов и декомпозицией нашего монолита. Это не является продуктовой разработкой в классическом понимании, но все улучшения так или иначе направлены на то, чтобы пользователям стало удобнее и проще взаимодействовать с приложением Delivery Club: уменьшать response time, чтобы страницы открывались быстрее, увеличивать capacity платформы, чтобы большее количество пользователей смогли сделать заказ и при этом опыт использования был для них максимально приятным.

    Результаты трансформации и новые вызовы


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

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

    Процесс включает в себя возможность реакции на asap задачи без вреда для продуктовой разработки, достаточно много точек коммуникации, чтобы гибко оценивать трудозатраты и своевременно реагировать на изменения требований от product-менеджера. На практике мы убедились, что процесс масштабируемый: нам удалось вырасти с 40 человек до 170 при том же процессе разработки и не теряя в перформансе.

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

    Спасибо, что дочитали!
    Mail.ru Group
    Строим Интернет

    Похожие публикации

    Комментарии 14

      +4

      Работает у вас всё так же хорошо, как и шестерёнки на КДПВ, которые блокируют друг друга?

        +1
        Монолит-с!
        +2
        только недавно отсмотрел видео о работе в этой прекрасной компании, вроде уже прошли протесты курьеров… поэтому читал статью скептически. пользуюсь приложением уже много лет. Если честно — даже самому интересно что там успела разработать новая команда за это время. Надеюсь одна из следующих публикаций повествует о том что было достигнуто за последние 2-3 года разработки
          0

          А я правильно понял что вы к спотифай-модели пришли, да?

            0
            Привет!

            У нас действительно много атрибутов, которые есть в Spotify-модели. И Inner Source они используют, чтобы не блокироваться релизными циклами соседней команды, и матричная структура, и процесс верификации гипотез — мы адаптируем GIST, а у них это называется Bets, но суть та же.

            Но сказать, что прям брали их опыт для копирования, не возьмусь :)
              0

              А тогда как относитесь к их же статье о том, почему спотифай-модель не работает?

                +1
                Spotify — это культура в первую очередь, а не модель организации. А культуру невозможно скопировать из организации в организацию.

                Мы в свою очередь берем практики и адаптируем под нашу культуру. Практики взяты из разных методологий и предыдущего опыта. В итоге получился единый процесс. Но процесс адаптации всегда уникальный. Думаю, что если и наш случай скопировать полностью в другой компании, то тоже ничего не получится и можно писать статью «Почему продуктовая трансформация не работает» :)
                  0

                  Ну вот в их культуре, к которой был адаптирован этот процесс — он не полетел. Почему думаете что у вас полетит в лонгтёрме?

                    +1
                    Потому что компании Delivery Club 10 лет и мы являемся лидерами на своём рынке. Кажется, это достаточно лонгтёрм.

                    За 10 лет было много трансформаций, а в конце 2018-го была одна из них. Модель — это не стратегия, а ответ текущим реалиям (про это как раз я писал в первой статье из этого цикла).

                    Если угодно, то и опыт Spotify это подтверждает. Они использовали разные модели в разные моменты жизни компании: в зависимости от числа сотрудников, от задач, от особенностей рынка.
                      0

                      Ну нет, у вас же не всё это время спотифай-модель :) Спотифай пытался заставить её работать сколько? Лет 10? Сейчас вот сбер пытается адоптить года 2 или типа того. И пока ни у кого выдающихся результатов не видно. То есть метрики-то выполняются, а работа-то не делается :-).

            0
            У вас описана классика scrum. Напомню, что согласно отцам-основателям методологии (тот же Сазерленд), достижение цели scrum- постоянное повышение производительности- осуществляется улучшением коммуникации внутри команды. Это избавляет от «серых зон», вносящих неопределенность в разработку и, в итоге, в неопределенность со сроками. Но вы указали, что у вас команды 3-7 человек. Это очень компактные команды, в них априори не существует проблем с коммуникацией. Пара-тройка разрабов всегда могут сами за кофе на кухне обсудить вопросы и выбрать техническое решение. Это самый тесный, самый эффективный способ коммуникации. Scrum им для этого не нужен. Почитайте Сазерленда- scrum начинается от 50 человек в команде. Когда коммуникации ослабляются и одна часть команды не знает, что делает другая. Все эти митинги, демо, ретро нацелены именно на то, чтобы команда не разваливалась на отдельные слабосвязанные группы.
            На мой взгляд, в вашем случае эффективней будет отказаться от ретро, демо, планирования спринтов. Попробуйте в рамках одной команды провести такой эксперимент в течение полугода: ежедневные летучки и через 2 недели выкладывание в релиз того, что успели. Думаю, вы увидите, что производительность команды возрастёт. Agile-методологии на то и гибкие, что допускают любые отклонения от классической реализации.
              0
              Здравствуйте!

              Спасибо за комментарий.

              Я думаю важным моментом является практика Inner Source, которую мы используем с начала 2019-го года. Да, когда команда изолирована, то коммуникация внутри очень просто происходит, особенно, если внутри команды 3-4 человек.

              Но помимо этого есть соседние команды. Коммуникация с ними важна, если команда взяла в Inner Source фичу, сервисы которой находятся во владении другой команды. Далее, есть product-менеджер, который озвучивает требования. Над ним есть ещё stakeholder'ы. Помимо этого есть ещё и другие департаменты: чтобы сделать фичу в логистике, команда плотно общается с операционкой (кол центр, операторы, диспетчеры, etc.), без них фича в вакууме просто не запустится, есть много оффлайн процессов.

              Таким образом, область коммуникации выходит далеко за рамки технической команды из 3-7 человек.

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

              В этих условиях очень важно иметь предсказуемый измеряемый процесс. В первой статье этого цикла я писал про особенности FoodTech и насколько критично держать низкий Time to market.
              0
              Support 20%.

              Спасибо за статью! А какая именно деятельность подразумевается под «Support»?
                +1
                Приветствую!

                В Support попадают asap'ы или критичные баги, которые не могут ждать следующего спринта. Как правило они поступают из нашей поддержки, поэтому и Support.

                Когда только переходили на этот формат, этот бакет оставался пустым, задачи туда не планировались. Но это усложняло контроль над общим capacity спринта. Не всегда ставились label'ы и не было ясно что изменило спринт, иногда туда попадало слишком много задач, иногда мало :)

                В итоге сейчас делаем так: в Product бакет попадают задачи из Ideas (гипотезы в GIST) — стратегические проекты; в Support бакет попадает так называемая «гигиена продукта» — мелкие задачи и минорные фиксы. Если прилетает asap или тикет из поддержки, то заменяем запланированную задачу из Support бакета этой новой задачей. Это упростило контроль состава спринта.

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

              Самое читаемое