Если вы считаете, что делать глобальные продукты просто, вы никогда не настраивали робот-пылесос Xiaomi.
Глобальные продукты делать сложно. Везде свои особенности, свой рынок. И любой продукт должен хорошо работать на каждом из них.
Коротко про наш бизнес и вопросы, которые стояли перед IT-командой
Мы строим QSR (англ. quick service restaurant — рестораны быстрого обслуживания) и расширяемся с помощью франчайзинга. В основе бизнеса лежит Dodo IS – система, через которую проходят все процессы, от приёма заказа до управления поставками ингредиентов.
Сейчас Dodo IS работает в 16 странах и для 3 концепций (пиццерии, кофейни и донерные). Наша стратегия — постоянное открытие новых стран, развитие мастер-франчайзинга (т.е. когда приходит партнёр, открывает несколько пиццерий в стране и затем сам начинает франчайзинг привлекать в этой стране). Мы должны быть готовы к такому росту, к постоянному подключению новых стран. 60 стран, 100 стран. Более чем реально.
Сегодня у нас 3 бренда, но уже понятно, что их может быть и 5, и 10 и 20. Не сейчас, но они будут — новые концепции со своими особенностями.
И как тогда обеспечивать вариативность системы и её поддержку? Как масштабировать без найма 100500 дополнительных разработчиков? Как определить, в какую часть Dodo IS инвестировать больше, а какую поставить на паузу? А как вообще открывать новые страны, там ведь везде свои законы и особенности? Ответы на эти вопросы нужно было искать как можно скорее.
Кроме этого, все запросы на доработки прилетали в нашу большую IT-команду. И каждый раз приходилось решать:
«А что важнее? Запустить программу лояльности в Эстонии или сторис в приложении для Евразии?»
«А что важнее? Сделать централизованное управление меню или кастомный трекинг?»
«А что важнее? Интеграция с агрегаторами или платная доставка?»
Эти вопросы кажутся странными, несравнимыми, но в то же время они вполне логичны, ведь в условиях ограничений приходится делать выбор, причём выбор на абсолютно разных уровнях.
Как думаете, кто должен давать ответы на такие вопросы? Кто должен выбирать? Бизнес-команда конкретного рынка, CPO или CEO компании?
Расскажу, как было у нас. За последние 5 лет мы прошли много трансформаций. Работали в едином темпе (общий старт итераций, у всех спринт 2 недели), экспериментировали с LeSS и управляли Dodo IS под все страны как единым продуктом, делили его и делали LeSS Huge, оставляя на уровне команд относительную свободу.
Но всегда, на протяжении последних лет была одна общая черта, которая не работала. Все запросы стекались в IT-команду и как-то разруливались на уровне CPO или владельца конкретного продукта. Вроде звучит логично и просто, но на деле наши бизнес-команды (а они работают на конкретном рынке) сталкивались с тем, что не знали, будем мы работать над вот этими задачами бизнеса дальше или нет. Продакт и CPO вынуждены были постоянно балансировать между рынками и пытаться встроить в бэклог задачи, нужные всем рынкам, да ещё и о поддержке не забыть.
Такая система при масштабе давала всё больше сбоев, напряжённых отношений и фактического разделения на IT и бизнес.
Нам нужна была новая структура. Но не такая, чтобы умело находить ответы на эти вопросы и ловко жонглировать приоритетами. Нам нужно было придумать её такой, чтобы этих вопросов не существовало в принципе.
И мы попробовали её создать. В основу легла концепция рыночных и глобальных команд с очень простым и понятным разделением ответственности.
Рыночные команды делают продукты и меняют Dodo IS, исходя из приоритетов конкретного рынка. Они делают решения максимально быстро, главное для них — скорость адаптации к рынку. Универсальность команд — их ключевая компетенция, они могут залезть в любую часть Dodo IS. Рыночные команды отвечают только за поддержку специализированных рыночных решений.
Так появились рыночные команды новых концепций Донер 42, Дринкит; новых перспективных рынков UK и международного; несколько команд Пиццы Евразии.
Глобальные команды делают продукты и меняют Dodo IS для всех стран и брендов, их приоритеты драйвятся глобальными целями Dodo Brands, а именно Планом 333. Они делают решения максимально гибкими, адаптируемыми и надёжными. Они преимущественно работают над своими компонентами.
Это команды производства, учёта, CVM (лояльность + клиентский профиль), Data, SRE и другие.
Взаимодействие рыночных и глобальных команд
Последние несколько лет я много изучал, как работает IT в других франчайзинговых сетях. И там есть одна особенность, которая очень сильно сдерживает развитие. У них нет глобальной части. У них только локально рыночные решения под страну, регион или несколько регионов. И если мастер-франчайзи региона построил сильное локальное IT, сделал какие-то решения, которые будут полезны всему бренду глобально, могут уйти годы на то, чтобы продать эти решения наверх. И не факт, что получится продать. Эта модель предполагает очень большой состав локальных рыночных команд (пусть и сгруппированных по регионам).
Наша структура и процессы дают возможность тиражировать решения от рынка в глобал и от глобала к рынку. В обоих направлениях. Если рыночная команда сделала фичу, которая может быть полезна всем – круто, глобальная команда может адаптировать или другая рыночная команда заберёт себе и подстроит под себя. Или рыночная команда может сразу сделать решение доступным для остальных, просто отдав в глобальную команду поддержку.
Глобальная команда сделала новую систему лояльности – супер, рыночные команды имеют полный доступ к решению и могут адаптировать его у себя.
Получается двустороннее взаимодействие, которое максимизирует и возможности для рынков использовать готовые инструменты, и приводит к тому, что глобальные команды могут интегрировать прорывные рыночные решения, которые уже протестированы.
Сейчас эта модель предполагает большую глобальную команду платформы Dodo IS и небольшие рыночные команды, хотя на горизонте 5-10 лет, с открытием новых рынков, этот баланс изменится.
В основе взаимодействия — общий код
Всё это не работало бы без одной важной составляющей. Общий код, доступный всем командам без исключения. Любой код может поменять абсолютно любой человек в Dodo Engineering — неважно, из какой он команды.
Есть такой подход, называется InnerSource. Это как Open Source, работающий внутри одной компании. Все принципы Open Source разработки, полностью открытый код, есть владельцы компонентов, отвечающие долгосрочно за его стабильность и развитие, и любой человек из компании может контрибьютить в него, пройдя ревью или любые другие правила, заданные владельцами. Баланс между скоростью рынков и стабильностью глобальных продуктов.
InnerSource не бесплатен. Его эффективность прямо зависит от вложений в инженерку, тесты, в качество глобальных продуктов, которые будут менять десятки команд. Если не автоматизирован регресс и он занимает пару дней, можно забыть о быстрых изменениях. Вот вроде бы банальная мысль, но без неё на практике ничего не заработает: рыночная команда будет вставать в виртуальную очередь, чтобы внести свои изменения, протестировать их, споткнуться на том что компонент-то не наш, нужна помощь ещё тестировщика из команды-овнера, а он недоступен, короче, дичь. Еще в 2017 году мы начали активно вкладываться в инженерные практики и вот сейчас эти вложения окупаются, оказывая прямое влияние на бизнес.
Как такая структура работает в реальности
Разберу очень простой реальный пример, иллюстрирующий работу. У нас есть рыночная команда Донер 42, задача которой – развивать свой продукт. И этому продукту потребовалось сделать платную доставку.
С одной стороны, ребята могли пойти к одной из глобальных команд, занимающейся доставкой или core-частью приёма заказа и договориться, чтобы для них сделали функцию платной доставки.
И если бы у них не было доступа к коду, так бы им и пришлось сделать, либо костылять что-то, не связанное с системой на своей стороне.
Но InnerSource даёт возможность сделать иначе. Ребята идут в core-компоненты доставки или приёма заказа и спокойно встраивают туда функцию платной доставки самостоятельно, де-факто открывая возможность использовать эту фичу командам других рынков. У них нет цели делать универсальные решения, у них нет цели сделать решение для других — они решают свою задачу.
На следующем этапе развития глобальная команда заберёт себе на поддержку функционал по платной доставке, допилит его где надо и будет полностью отвечать за его работоспособность.
Какие команды отвечают за поддержку
Поддержка и обеспечение SLA для сервисов зависит от того, что это за решение – рыночное или глобальное. К примеру, мобильное приложение Донер 42 целиком принадлежит рынку Донера, соответственно, API и мобила в их владении и обеспечение работы 24/7 ложится на плечи рыночных команд.
Если рыночная команда делает изменение, например, в трекере, т.е. в глобальном продукте, поддержка этого решения остаётся на глобальной команде. Таким образом глобальные команды самостоятельно устанавливают правила, как к ним можно приносить изменения, Pull Requests, требования к ним, прогон тестов, что-то ещё. Обеспечение работы 24/7 — на глобальных командах.
Что изменилось весной 22-го
В условиях новой реальности у нас 2 ключевые цели:
сохранить бизнес, чтобы развиваться в будущем;
избежать сокращений.
У нас, как у любой растущей компании, есть стабильное направление (бизнес в Евразии) и инвестиционные проекты для роста. Часть проектов для роста мы остановили, сфокусировались на Евразии, по сути — на задаче сохранения бизнеса. На этом сосредоточили максимум усилий.
Чтобы сохранить бизнес, нам нужно было справиться со следующими вызовами:
Пережить значительное увеличение цен на ингредиенты.
Решить проблемы с оплатами (отключение карт, Apple Pay, DDoS-атаки на платежные сервисы).
Увеличить выручку рынка Евразии.
Переехать на локальные сервера.
Всё, что нам нужно было сделать — остановить часть глобальных целей и перевести ребят на задачи Евразии. Поскольку рыночные команды уже были тесно интегрированы с бизнес-командами, это выглядело просто как расширение и помощь, без каких-либо серьёзных перетрясок, новых продуктов, прояснений того, что делать надо, а что нет. Общий код помог сделать этот переход вообще незаметным. Я даже ловлю себя на мысли что такая реакция и преобразования прошли как-то уж слишком гладко. Но это так!
Год прошёл, полёт нормальный
Такая структура с глобальными и рыночными командами – это не моё изобретение, не что-то сверхновое, это очень простое и логичное решение. Для нас оно выглядит сейчас слишком очевидным. Процесс перестройки и адаптации занял почти год. Эффект позитивный, неоднозначные вопросы исчезли, каждый продукт имеет свои цели, при этом пересечений много, все друг о друге знают и не скатываются в ситуацию, когда две команды делают одно и то же. И при необходимости легко перестраиваются, кризис это показал.
Эта модель позволяет нам масштабироваться. Сегодня у нас 16 стран и 5 рыночных команд. Рынки будут расти и стран станет 60, а рыночных команд — 15 или 20, при этом все они продолжат работать по тем же принципам: рынки — для скорости, глобал — для гибкости, общий код — для всех.
