Все статьи
Ключи для продуктовой трансформации международного бизнеса
Дата: 10.04.2022
История inDriver о том, как изменения в культуре и подходах к выстраиванию моделей объединили бизнес-девелоперов из 30+ стран и 16 продуктовых команд вокруг единых целей.
Доклад на конференции Enterprise Agile Russia 2021 29 ноября 2021 года.
Всем привет! Меня зовут Оля Качалина. Я руководитель отдела процессов и практик в компании InDriver. И сегодня расскажу о том, как одна холодная зима немножко поменяла весь мир и продолжает его менять. Кто-нибудь знает про компанию InDriver? Если да, поднимите, пожалуйста, руки… Вас достаточно много относительно средней статистики. Мы на самом деле не суперизвестны в России, потому что больше завоевываем мировые рынки. Сегодня я хочу вам рассказать, как менялась бизнес-модель при нашем масштабировании и как продуктовые трансформации и гибкие процессы этому способствовали.
Поэтому немножечко истории – как же все начиналось. Начиналось все далекой зимой 2012 года. В Якутии самые холодные зимы в России. И вот зима 2012 года не стала исключением. Она была достаточно холодной – машины у людей просто перестали заводиться. Возник довольно серьезный спрос на сервисы такси, и таксисты коварно сговорились друг с другом и подняли цены в два раза – и даже больше. Людей это совершенно не устраивало.
Как же работала бизнес-модель в самом начале? Была просто создана группа ВКонтакте, где люди договаривались друг с другом – кому-то нужно было доехать из точки А в точку Б, и кто-то был готов подвезти человека по цене, которая всех устраивала. Данная модель работала на первых этапах.
Постепенно образовалась целая компания, образовалось приложение, которое позволяло эту бизнес-модель с системой торгов реализовывать. Бизнес компании рос. И к весне 2018-го компания была представлена в 120 городах России и СНГ и стала выходить на международный рынок. Началась международная экспансия бизнеса.
Компания изначально, как я уже сказала, была дислоцирована в Якутске. Как это происходило? Были представители, по сути, отделов маркетинга – некоторые прото-бизнес-девелоперы, которые приезжали в страну, осознавали контекст того, что уже происходит в этой стране, какие запросы, и адаптировали имеющееся приложение в соответствии с этим контекстом. И так как все страны довольно-таки разные, разный менталитет накладывает особенности. К примеру, различные платежные системы. Если кто-то был в азиатских странах… Был кто-нибудь в Таиланде, например? Во Вьетнаме? Были? Как вам движение там? Пробовали поводить машину? Да, все сигналят, и нужно быть чрезвычайно сфокусированным. Действительно, например, в этих странах есть особенности приложений – они все такие супермерцающие. Там, как правило, есть одна большая кнопка, и важно ее нажать вовремя. Минутка промедления – уже попал в аварию, то есть случилось что-то не очень приятное. И, соответственно, так вот и происходил процесс — мы погружались в контекст страны и учитывали его. Появлялось все больше и больше стран.
Как это работало в самом начале? В разных странах работали маркетологи и команды быстрых запусков этих стран – они уже транслировали тот самый необходимый контекст главному маркетологу компании, который на уровне топ-менеджмента адресовал необходимые доработки CPO (прим. ред. — Chief Product Officer, директор по продукту). И CPO уже дальше каскадировал это в команды разработки.
Причем команды разработки представляли собой по сути три большие платформенные команды: iOS, Android, бэкенд – так как это мобильные приложения. И, как вы понимаете, в этом сеттинге никто не задумывался о комплексном улучшении приложения. Все было нацелено просто на запуск стран, и схема работала не очень оптимально.
Как я говорила, количество стран стремительно росло, количество связей и коммуникаций тоже довольно стремительно росло. Появился второй технологический центр в Москве, и коммуницировать приходилось уже всем со всеми. И все эти связи становились все более и более запутанными. Эта конференция про масштабируемые и крупные изменения, я думаю, находящиеся здесь люди достаточно хорошо представляют, что значат такие сложные коммуникации.
И что же мы решили? Мы решили, что дальше так жить нельзя, нужно что-то менять. И как раз здесь началось изменение подходов. Кажется, что к разработке и к выстраиванию продукта, но на самом деле к бизнес-модели как таковой. Потому что – что же произошло?
Первым – и, наверное, очень логичным – шагом кажется, что надо пересобрать команды. Нужно добавить им немножко фокуса, осмысленности, осознанности, потому что на таком масштабе три большие платформенные команды как будто бы не работают. Или работают не оптимально. И действительно, приблизительно год назад были пересобраны команды. Мы здесь приняли для себя следующий подход. Мы его назвали подход Team first. О чем он говорит? Этот подход декларирует то, что когда мы хотим реализовать какой-то, например, новый продукт, новую инициативу, решить какую-то, возможно, задачу, которая перед нами стоит, очень важно на первом этапе убедиться, что в команде присутствуют все необходимые компетенции для того, чтобы этот продукт запустить или реализовать какую-то инициативу. Если посмотреть на внутренний круг – это наша продуктовая команда. Там представлены все типы разработчиков, которые необходимы: iOS, Android, бэкенд, QA-инженеры, продуктовые аналитики, продуктовые и технические лидеры команды, дизайнеры, сейчас DevOps — это продуктовая команда.
Но если даже внутри продуктовой команды идеально выстроить процессы – и вы сами, наверное, с этим часто сталкивались, – всегда возникают моменты интеграции. И вот на моментах интеграции – если у нас во всей компании как-то иначе выстроены процессы – все может сломаться, даже если каждый в своей команде сделает все идеально. И поэтому очень важно убедиться, что и со стороны бизнес-девелопмента есть люди, которые точно так же сфокусированы на продукте, и со стороны всех вовлеченных лиц – у нас есть маркетологи, которые непосредственно конкретным продуктом занимаются, и так далее – на уровень организации.
Что получилось? У нас появилось 15 продуктовых команд – то есть команд, у которых есть очень четкий фокус работы. Они отвечают либо за конкретный продукт, либо за какой-то компонент этого продукта – если продукт достаточно большой; либо же за какой-то сервис, который также является продуктом для продукта. Например, есть мессенджер – он является единым сервисом для разных вертикалей. Вертикалей у нас стало уже больше – это не только сервис перевозок. Сейчас это пять вертикалей – плюс отдельное направление новых вертикалей, которые также выстроены по подходу Team first. На момент лета-осени у нас уже появилось 15 продуктовых команд, из них 12 платформенных, и уже порядка 37 стран присутствия на текущий день.
Наш подход Team first позволяет каждой команде получить определенный фокус, единую цель для всей команды и единую миссию. И здесь, цитируя, наверное, Асхата, который здесь тоже присутствует, можно сказать, что любая трансформация в компании – это всегда балансировка между централизацией и децентрализацией.
У нас, как вы видите, прошлая схема была достаточно сильно централизованной. Затем мы двинулись в сторону децентрализации, в сторону автономности команд – когда команда получает четкий фокус, нацеленность на свой продукт и по сути становится мини-стартапом внутри стартапа. Говоря проще – когда команда сама понимает, за что она отвечает.
Но простой пересадки людей недостаточно для достижения этой цели. Поэтому мы стали меняться дальше – ведь по мере нашей трансформации перед компанией вставали все новые и новые вызовы. В мае 2021 года у нас была совершена миллиардная поездка – миллиард пользователей. Как вы видите, темпы роста достаточно высокие по последним годам, и нам важно их поддерживать.
Очень часто задается вопрос: «А зачем вообще нужна трансформация?» Можно перечислить проблемы, которые нас подтолкнули к изменениям: несогласованность команд, долгие циклы разработки, низкое качество продуктов, низкая осознанность и вовлеченность ролей и компетенций инженеров в непрозрачной модели развития. Но основная цель, которая перед нами стоит – поддерживать достаточно высокие темпы роста. Компания ставит перед собой очень амбициозные цели – мы растем больше чем в два раза год от года, и нам важно поддерживать эти темпы. И если посмотреть на тренды по поездкам: верхний – это последний год; в этом году мы сделали 100 млн установок. При таких темпах роста жить в старой модели достаточно проблематично. И кажется, что уже невозможно по старой модели запускать новые страны – в какой-то момент они закончатся.
О чем же мы подумали? О том, что сейчас важно фокусироваться на том продукте, который мы создаем. И здесь у нас в числе ценностей компании появляется Customer Centricity (прим. ред. клиентоцентричность) как таковая. То есть мы фокусируемся на том, какую ценность мы создаем для наших пользователей и как мы можем в работе ориентироваться исключительно на наших пользователей. У нас были разные идеи по поводу того, как это может быть: можно, например, сделать отдельные команды для отдельных стран, чтобы сфокусировать их. Но тогда кажется, что во всех 37 странах должно появиться 37 маленьких «индрайверов», и это не выглядит оптимальным. Были идеи как-то по-другому перераспределять роли. Но в итоге мы решили, что нам нужно провести эти цели через всю компанию, сделать их едиными – притом что есть разные направления бизнеса.
Аккумулировав опыт индустрии, широкого рынка, разных практик и подходов, мы не нашли для себя какого-то золотого стандарта. У нас много продуктовой работы, работы с гипотезами. И мы решили создать свой собственный подход, свою систему. Самое важное ведь это не то, как мы выстраиваем процессы как таковые, не то, на какие мы встречи ходим и каким составом. Самое главное – это ценностная картинка, что с точки зрения ценностей мы вкладываем в сердце нашей работы. Мы задумались и выделили для себя, что в качестве таких двух столпов хочется выделить две вещи.
- Первая вещь – это работа с данными. Потому что мы в первую очередь являемся продуктовой компанией, коммерческой, которая является прибыльной. И мы этим гордимся. И очень важно принимать решения, основываясь на данных. У нас даже периодически на каких-то внутренних встречах возникают квизы формата «факт или гипотеза» – особенно когда заинтересованные лица часто приходят и говорят, что нужно точно сделать вот эту штуку, она точно сработает. Мы всегда задаем вопрос: это факт или гипотеза? И желательно, чтобы привели цифры. При принятии вообще любых решений мы всегда стараемся ориентироваться на данные – будь то какие-то бизнесовые, продуктовые решения или даже наши внутренние командные.
- И второй столп, на который хочется также ориентироваться выстраивая бизнес-модель внутри нашей компании – это работа с доверием. Если немножечко вернуться в историю – компания возникла сама по себе как достаточно локальный, дружественный стартап, где были очень понятные и прозрачные связи внутри между отделами, между пользователями. И при таком масштабировании для того, чтобы это доверие сохранялось, тот же самый доверительный контекст, очень важно в него дополнительно инвестировать. А без доверия невозможен результат. Наверное, многие из вас читали Патрика Ленсиони «Пять пороков команды» – он там это прозрачно простраивает, почему.
И основываясь на этих двух столпах, дальше мы уже выстраивали процессы. Возможно, на этой конференции это звучит как-то прозаично, но я все равно расскажу.
Мы приняли, что OKR – это действительно тот инструмент, который позволяет простроить связи от целей компании к целям каждого отдельного человека. OKR компании – ядро. Далее пять направлений – те самые пять бизнес-вертикалей, которые непосредственно генерируют выручку. Они ставят OKR в первую очередь.
Слева – горизонтальные OKR. Это OKR тех команд, которые создают сервисные поддерживающие продукты – вроде мессенджера или системы платежей. Они смотрят в нижние OKR и задают себе вопрос: «А как мы можем вложиться в те же самые цели?» И у нас есть Supportive OKRs, где все остальные поддерживающие отделы. Это уже не кросс-функциональные, как правило, команды – как, например, отдел People&Culture, который занимается развитием культуры, роста и людьми, там же Legal, Finance, и там, например, мой отдел процессов и практик, который точно так же широко смотрит на цели других отделов и ставит цели себе – так, чтобы все достигали OKR компании.
Но кажется, что в чистом виде не всегда очевидно, как можно поставить цели на достаточно большом масштабе. Поэтому у нас простроена довольно прозрачная система взаимозависимости бизнесовых метрик и продуктовых метрик. Представители бизнес-департаментов и представители продуктовых команд достаточно хорошо понимают, где чья зона ответственности и каким образом, выполняя ту или иную доработку в продукте, можно повлиять на ту или иную бизнес-ценность.
И таким образом получается, что каждая команда, основываясь на этих деревьях метрик, построила себе аналитический дашборд. И каждая команда имеет возможность достаточно хорошо понять, как она влияет на бизнес, и достаточно прозрачно поставить себе какие-то цели, протестировать гипотезы и всей командой посмотреть: вот у нас была гипотеза, мы реализовали фичу, которая позволяет реализовать эту гипотезу, – как она повлияла. Команда смотрит – действительно показатели пошли вверх или, может быть, наоборот, пошли вниз, и может авторизовать результат. Так каждый отдельный член каждой команды понимает, каким образом он приносит ценность всей компании.
Но в чистом виде поставить цели недостаточно. И на определенном масштабе компании хотят не только понимать верхнеуровневые цели, но хотят достаточного уровня предсказуемости относительно своих продуктов. Поэтому у нас есть процедура более детального масштабируемого квартального планирования: представители компании из бизнес-департаментов представляют контекст по запуску новых стран по каким-то актуальным моментам, а представители продуктового дивизиона подсвечивают фокусы продуктов – например, редизайн или что-то подобное. И есть большой блок, касающийся технологических инвестиций – так как очень важно заниматься и техническим качеством продукта и регулярно выстраивать эту технологическую платформу таким образом, чтобы реализовывать все бизнесовые и продуктовые амбиции. И далее команды, имея свои цели в виде OKR, имеют возможность поштурмить с представителями бизнес-девелопмента – и вообще любыми заинтересованными представителями компании – какое-то количество гипотез, отталкиваясь от своих целей.
Далее есть прозрачный процесс приоритизации этих гипотез. Примерно так это выглядело, когда мы пробовали в первый раз. Это несколько напоминало Clubhouse, где ты мог выбрать комнатку, к которой хочешь присоединиться. Иногда присоединиться к дискуссии, которая уже началась до тебя. Не все было оптимально, но в следующем квартале мы значительно улучшились, и эти беседы приобрели структуру. Таким образом, на выходе мы имели достаточно понятные квартальные планы. Это планирование имеет очень четкие продуктовые фокусы, потому как мы оцениваем не только в чистом виде, сколько мы будем реализовывать ту или иную фичу, мы оцениваем именно гипотезы – и оцениваем, до какой степени проработки гипотезы мы хотим дойти в этом квартале. Так, в некоторых гипотезах мы планируем только какие-то элементы дискавери, планируем их, может быть, в дизайн-спринты в некоторых командах, и какие-то гипотезы доходят уже до запусков.
Если вернуться чуть-чуть назад – у нас на досках появлялись какие-то веселые котики, что для меня сигнализирует о том, что все-таки с доверием мы неплохо поработали, если команды имеют смелость это всё добавлять на доски. И дальше представители всей компании могли прозрачно согласиться или не согласиться с полученными планами. И вот таким образом мы пришли от того, когда в чистом виде на уровне С-level менеджмента принимались какие-то решения о доработке продукта, к тому, что команды становятся действительно самостоятельными, автономными, осознанными, сами умеют ставить себе цели и авторизовывать результат. И с тем, что делают команды – не заигрываясь полностью в автономию и помня о том, что мы существуем в контексте большого InDriver, – с этими планами и с их реализацией согласны все представители на всех уровнях.
Мы на этом не останавливаемся. Наверное, трансформация как таковая не заканчивается никогда. Перед нами стоит огромное количество челленджей, и мы масштабируем наш подход Team first дальше – на технологические и платформенные команды. Я думаю, что из этого родится еще много каких-то открытий, интересных подходов и выводов.
Видео и слайды
