В Support попадают asap'ы или критичные баги, которые не могут ждать следующего спринта. Как правило они поступают из нашей поддержки, поэтому и Support.
Когда только переходили на этот формат, этот бакет оставался пустым, задачи туда не планировались. Но это усложняло контроль над общим capacity спринта. Не всегда ставились label'ы и не было ясно что изменило спринт, иногда туда попадало слишком много задач, иногда мало :)
В итоге сейчас делаем так: в Product бакет попадают задачи из Ideas (гипотезы в GIST) — стратегические проекты; в Support бакет попадает так называемая «гигиена продукта» — мелкие задачи и минорные фиксы. Если прилетает asap или тикет из поддержки, то заменяем запланированную задачу из Support бакета этой новой задачей. Это упростило контроль состава спринта.
Потому что компании Delivery Club 10 лет и мы являемся лидерами на своём рынке. Кажется, это достаточно лонгтёрм.
За 10 лет было много трансформаций, а в конце 2018-го была одна из них. Модель — это не стратегия, а ответ текущим реалиям (про это как раз я писал в первой статье из этого цикла).
Если угодно, то и опыт Spotify это подтверждает. Они использовали разные модели в разные моменты жизни компании: в зависимости от числа сотрудников, от задач, от особенностей рынка.
Spotify — это культура в первую очередь, а не модель организации. А культуру невозможно скопировать из организации в организацию.
Мы в свою очередь берем практики и адаптируем под нашу культуру. Практики взяты из разных методологий и предыдущего опыта. В итоге получился единый процесс. Но процесс адаптации всегда уникальный. Думаю, что если и наш случай скопировать полностью в другой компании, то тоже ничего не получится и можно писать статью «Почему продуктовая трансформация не работает» :)
Я думаю важным моментом является практика Inner Source, которую мы используем с начала 2019-го года. Да, когда команда изолирована, то коммуникация внутри очень просто происходит, особенно, если внутри команды 3-4 человек.
Но помимо этого есть соседние команды. Коммуникация с ними важна, если команда взяла в Inner Source фичу, сервисы которой находятся во владении другой команды. Далее, есть product-менеджер, который озвучивает требования. Над ним есть ещё stakeholder'ы. Помимо этого есть ещё и другие департаменты: чтобы сделать фичу в логистике, команда плотно общается с операционкой (кол центр, операторы, диспетчеры, etc.), без них фича в вакууме просто не запустится, есть много оффлайн процессов.
Таким образом, область коммуникации выходит далеко за рамки технической команды из 3-7 человек.
Другой момент: планирование спринта, которое происходит за неделю до его начала. Он не просто так был введен, команда производит техническую аналитику. То есть чаще всего это момент, когда техническая команда впервые знакомится с этой фичей.
В этих условиях очень важно иметь предсказуемый измеряемый процесс. В первой статье этого цикла я писал про особенности FoodTech и насколько критично держать низкий Time to market.
У нас действительно много атрибутов, которые есть в Spotify-модели. И Inner Source они используют, чтобы не блокироваться релизными циклами соседней команды, и матричная структура, и процесс верификации гипотез — мы адаптируем GIST, а у них это называется Bets, но суть та же.
Но сказать, что прям брали их опыт для копирования, не возьмусь :)
Про чекают конкретно я бы назвал 2 момента:
1. Профиль использования одних и тех же вещей у пользователей меняется со временем. Тот же чекаут мы пересматривали несколько раз за последние 3 года. Вариант «сделать один раз и подкручивать раз в 6 месяцев» не подходит, когда бизнес и компания растет, увеличивается количество пользователей и заказов. Про скорость роста я указал в статье.
2. Есть гипотезы, как улучшить саму форму чекаута, её удобство, в конечно итоге — конверсию. Этот процесс не останавливался никогда. Всегда есть области для оптимизации.
Помимо этого есть небольшие, но важных фичи, которые меняют чекаут. Из последнего: бесконтактная доставка, чаевые курьерам. Об этом в том числе данная статья: возникают вещи, которые невозможно предугадывать. Но мы их быстро решаем за счет, в том числе, структуры департамента, команд и процесса разработки.
Опыт не всегда может быть адаптирован из-за особенностей рынка, климата и топологии городов. Легаси у нас есть, но, впрочем, как и у любой компании, которой больше 6 лет.
Приветствую! А про какой город конкретно речь? Я всё таки говорю о масштабе 150 городов. Конечно, ситуация в отдельно взятых городах может быть более благоприятной для велосипедов.
Вся разработка отталкивается от продуктов. Все продукты можно поделить на 4 типа:
1. Клиент, который покупает еду.
2. Доставщик.
3. Партнёр (ресторан/магазин).
4. Техподдержка: call-центр и диспетчеры, которые контролируют процесс.
Так вот для Клиентов у нас есть мобильное приложение и сайт, где внутри есть разные стримы, а под каждый стрим есть отдельная команда. Если перечислить, то это: доставка еды из ресторанов, доставка продуктов, еда навынос, доставка из аптек. Есть отдельные команды, отвечающие за поисковую выдачу, опыт пользователя во время и после checkout’a, скидки и акции, спец. подборки ресторанов.
Для Доставки мы делаем RiderApp (приложение для курьеров) и систему мониторинга для Диспетчеров. Внутри RiderApp, помимо функций принятия заказа, есть система выбора смен, система оповещений, информация по финансам.
Для Диспетчеров мы строим дашборд, который дает картину текущую ситуацию, и центр, в котором Диспетчер может вручную помочь Курьеру, если это требуется — переназначить заказ, выдать инструкции, выдать смену, связаться с рестораном.
Для Партнера мы делаем личный кабинет, в котором можно видеть статистику по поиску, заводить акции, управлять контентом (меню, ингредиенты, блокировки, расписания, картинки), настраивать зоны доставки. В этом же направлении есть команда интеграций с API ресторанов.
Для Техподдержки мы создаем инструменты для помощи пользователям.
Для каждого отдельного пункта, который я перечислил, есть команда, которая занимается развитием конкретной части продукта. Команда общается непосредственно со своими stakeholder’ами, чтобы понять, на сколько техническое решение отвечает текущим задачам.
Помимо этого есть направления RnD, которые занимаются оптимизацией бизнес процессов.
И есть ещё команда Platform, которая занимается пересмотром архитектуры.
Есть ли интерес в самых подробных деталях почитать про это?
Приветствую! Спасибо за вопрос. Тема действительно интересная, но скорее всего её не удастся уместить в 15-ти минутный формат, не хватит времени. Предлагаю обсудить эту тему в нашем канале telegram в режиме живого диалога. Вот ссылка: teleg.run/joinchat/BjL2NBYpsG2pe_N3sVEjfw
Если в канале не будет удобно, то договоримся там об отдельном звонке в zoom по этой теме.
В Support попадают asap'ы или критичные баги, которые не могут ждать следующего спринта. Как правило они поступают из нашей поддержки, поэтому и Support.
Когда только переходили на этот формат, этот бакет оставался пустым, задачи туда не планировались. Но это усложняло контроль над общим capacity спринта. Не всегда ставились label'ы и не было ясно что изменило спринт, иногда туда попадало слишком много задач, иногда мало :)
В итоге сейчас делаем так: в Product бакет попадают задачи из Ideas (гипотезы в GIST) — стратегические проекты; в Support бакет попадает так называемая «гигиена продукта» — мелкие задачи и минорные фиксы. Если прилетает asap или тикет из поддержки, то заменяем запланированную задачу из Support бакета этой новой задачей. Это упростило контроль состава спринта.
За 10 лет было много трансформаций, а в конце 2018-го была одна из них. Модель — это не стратегия, а ответ текущим реалиям (про это как раз я писал в первой статье из этого цикла).
Если угодно, то и опыт Spotify это подтверждает. Они использовали разные модели в разные моменты жизни компании: в зависимости от числа сотрудников, от задач, от особенностей рынка.
Мы в свою очередь берем практики и адаптируем под нашу культуру. Практики взяты из разных методологий и предыдущего опыта. В итоге получился единый процесс. Но процесс адаптации всегда уникальный. Думаю, что если и наш случай скопировать полностью в другой компании, то тоже ничего не получится и можно писать статью «Почему продуктовая трансформация не работает» :)
Спасибо за комментарий.
Я думаю важным моментом является практика Inner Source, которую мы используем с начала 2019-го года. Да, когда команда изолирована, то коммуникация внутри очень просто происходит, особенно, если внутри команды 3-4 человек.
Но помимо этого есть соседние команды. Коммуникация с ними важна, если команда взяла в Inner Source фичу, сервисы которой находятся во владении другой команды. Далее, есть product-менеджер, который озвучивает требования. Над ним есть ещё stakeholder'ы. Помимо этого есть ещё и другие департаменты: чтобы сделать фичу в логистике, команда плотно общается с операционкой (кол центр, операторы, диспетчеры, etc.), без них фича в вакууме просто не запустится, есть много оффлайн процессов.
Таким образом, область коммуникации выходит далеко за рамки технической команды из 3-7 человек.
Другой момент: планирование спринта, которое происходит за неделю до его начала. Он не просто так был введен, команда производит техническую аналитику. То есть чаще всего это момент, когда техническая команда впервые знакомится с этой фичей.
В этих условиях очень важно иметь предсказуемый измеряемый процесс. В первой статье этого цикла я писал про особенности FoodTech и насколько критично держать низкий Time to market.
У нас действительно много атрибутов, которые есть в Spotify-модели. И Inner Source они используют, чтобы не блокироваться релизными циклами соседней команды, и матричная структура, и процесс верификации гипотез — мы адаптируем GIST, а у них это называется Bets, но суть та же.
Но сказать, что прям брали их опыт для копирования, не возьмусь :)
1. Профиль использования одних и тех же вещей у пользователей меняется со временем. Тот же чекаут мы пересматривали несколько раз за последние 3 года. Вариант «сделать один раз и подкручивать раз в 6 месяцев» не подходит, когда бизнес и компания растет, увеличивается количество пользователей и заказов. Про скорость роста я указал в статье.
2. Есть гипотезы, как улучшить саму форму чекаута, её удобство, в конечно итоге — конверсию. Этот процесс не останавливался никогда. Всегда есть области для оптимизации.
Помимо этого есть небольшие, но важных фичи, которые меняют чекаут. Из последнего: бесконтактная доставка, чаевые курьерам. Об этом в том числе данная статья: возникают вещи, которые невозможно предугадывать. Но мы их быстро решаем за счет, в том числе, структуры департамента, команд и процесса разработки.
1. Клиент, который покупает еду.
2. Доставщик.
3. Партнёр (ресторан/магазин).
4. Техподдержка: call-центр и диспетчеры, которые контролируют процесс.
Так вот для Клиентов у нас есть мобильное приложение и сайт, где внутри есть разные стримы, а под каждый стрим есть отдельная команда. Если перечислить, то это: доставка еды из ресторанов, доставка продуктов, еда навынос, доставка из аптек. Есть отдельные команды, отвечающие за поисковую выдачу, опыт пользователя во время и после checkout’a, скидки и акции, спец. подборки ресторанов.
Для Доставки мы делаем RiderApp (приложение для курьеров) и систему мониторинга для Диспетчеров. Внутри RiderApp, помимо функций принятия заказа, есть система выбора смен, система оповещений, информация по финансам.
Для Диспетчеров мы строим дашборд, который дает картину текущую ситуацию, и центр, в котором Диспетчер может вручную помочь Курьеру, если это требуется — переназначить заказ, выдать инструкции, выдать смену, связаться с рестораном.
Для Партнера мы делаем личный кабинет, в котором можно видеть статистику по поиску, заводить акции, управлять контентом (меню, ингредиенты, блокировки, расписания, картинки), настраивать зоны доставки. В этом же направлении есть команда интеграций с API ресторанов.
Для Техподдержки мы создаем инструменты для помощи пользователям.
Для каждого отдельного пункта, который я перечислил, есть команда, которая занимается развитием конкретной части продукта. Команда общается непосредственно со своими stakeholder’ами, чтобы понять, на сколько техническое решение отвечает текущим задачам.
Помимо этого есть направления RnD, которые занимаются оптимизацией бизнес процессов.
И есть ещё команда Platform, которая занимается пересмотром архитектуры.
Есть ли интерес в самых подробных деталях почитать про это?
Если в канале не будет удобно, то договоримся там об отдельном звонке в zoom по этой теме.