Team First: как мы перешли к кроссфункциональным командам и сохранили атмосферу стартапа
Привет, меня зовут Оля, я Head of Processes&Practices, занимаюсь продуктовой трансформацией в inDriver. Сейчас у нас активная продуктовая и инженерная культура, система OKR, масштабное продуктовое планирование и смелые планы на будущее. Но так было не всегда. И в этой статье я расскажу о тех вызовах, с которыми мы столкнулись в процессе трансформации и о том, чего уже удалось достичь.
Содержание
Проблемы с организацией
К зиме 2018 года inDriver был представлен в 120 городах России и СНГ. Весной мы начали международную экспансию и вышли в развивающиеся страны мира: ЮАР, Танзанию, Коста-Рику и другие. Сначала структура открытия новых регионов была простой: бизнес-девелоперы занимались привлечением водителей, а маркетинг — рекламой и увеличением трафика. Эта модель работала до 2020 года.
Весна 2018 года. Начало международной экспансии
Схема действовала просто. Маркетинг с помощью массированной рекламы активно помогал в запуске новых стран. Постепенно некоторые сотрудники маркетинга становились бизнес-девелоперами. Бизнес-девелоперы приезжали в определенную страну, узнавали больше про ее особенности и запускали приложение по чек-листу.
Единственное, что отсутствовало в этой схеме — понимание, как развивать продукт. Проджект-менеджеры в Якутске получали информацию от маркетинга и бизнес-девелоперов и вносили изменения в приложение без учета метрик и целей.
На тот момент у нас существовало по 2 бэкенд- и iOS-отдела, а также 3 Android-отдела (в Москве и Якутске). Задачи распределялись так: CPO вместе с бизнес-девелоперами формировали задачи на квартал, которые распределялись проджект-менеджерами. Дальше задача попадала тимлидам, от тимлидов — к разработчикам.
На тот момент это была типичная модель «Водопад»
Синхронизации команд проводились раз в неделю по понедельникам. Тимлиды собирались и смотрели на одну канбан-доску, распределяя задачи на неделю. Также на встрече обсуждали, где сейчас находится задача и почему она не двигается.
Как вы понимаете, схема была несовершенной и нуждалась в трансформации. Приведу 4 причины, по которым мы решили изменить подход к работе продуктового и технологического дивизионов:
Долгий цикл разработки. Выделю неточность оценки сроков, отсутствие важных требований к задаче и неповоротливость больших отделов. Тимлиды тратили много времени на менеджмент, не было положительного эффекта при найме инженеров.
Несогласованность в разработке продуктов. Отсутствие прозрачности по целям доработки продуктов и низкая коммуникация между отделами, падение вовлеченности в развитии продукта.
Непрозрачные роли и развитие инженеров. Отсутствие понимания ожиданий от ролей и должностей, а также системного подхода к развитию сотрудников (например, не было встреч 1:1).
Низкая стабильность сервисов и продуктов. Проблемы с легаси и отсутствие технологического развития продуктов приводили к снижению стабильности сервисов и продуктов. В результате росло недовольство водителей и пассажиров, снижался рейтинг приложения в Google Play и App Store.
Все это требовало решительных изменений. Так мы пришли к концепции Team First.
Team First
Team First — это концепция работы над созданием или изменением продукта, при котором формируются команды, в которых присутствуют все необходимые компетенции для достижения целей. Это требует значительного уровня самостоятельности и осознанности, а также инструментов, которые помогают команде перформить. А именно: целеполагания, распределения ролей и ответственности внутри команд, создания соглашений, по которым они должны работать.
К переходу на Team First нас побудил низкий уровень коммуникации между отделами. Например, есть страна, в которой мы запланировали запуск. Чтобы все прошло успешно, нужна поддержка отделов Operations, Digital, Marketing и Driver Acquisition. И когда это не команда, а разные отделы, задачи могут долго переходить от одной команды к другой. Нужно подключать или нанимать руководителей, чтобы они координировали весь процесс, а это сложно, долго и неудобно.
Когда ты идешь по пути Team First, то цель — «захватить» одну страну, собрать команду из разных отделов и всех необходимых компетенций. Она должна работать как единый механизм, каждый винтик которого направлен на достижение общей цели. Ведь даже если внутри одного отдела выстроить идеальные процессы, момент интеграции с другими подразделениями с высокой вероятностью может стать «узким горлышком» общего процесса.
Продуктовая трансформация
Процесс трансформации всегда труден и тернист. На первом этапе мы провели серию встреч, где руководители вовлеченных подразделений дизайнили новую структуру работы над продуктом inDriver. Составили роадмап, и в октябре 2020 года запустились первые 3 продуктовые и 4 платформенные команды, в ноябре — еще 3 продуктовые и 3 платформенные, в декабре — все оставшиеся. Для каждой из них мы прописали роли техлида, продакт-лида и команды разработки.
Платформенные команды inDriver сегодня
И продуктовые команды
Команды во главе с тандемом продакт-лида и техлида выстраивали собственные процессы, определяли цели продукта и роли в команде. Любопытным моментом стало распределение ответственности между ними. Мы пришли к соглашению, что задачу забирает себе в бэклог та команда, которой ее решение приносит больше ценности.
Например, есть задача сделать доработку на стыке водительской и пассажирской части приложения inDriver. Если задача приносит больше ценности водителям, то команда Driver забирает эту задачу себе, даже если техническая реализация затрагивает модуль команды Passenger.
Распределение ролей в продуктовых и платформенных командах
Параллельно запускалось внедрение ОКR на 4 квартал 2020 года для технологического дивизиона — пока для платформенных команд и руководителей. Это было важно для удержания фокуса, согласованного достижения целей и получения синергии. На момент начала трансформации никакого регулярного планирования не было, команды «жили» продуктовыми задачами, которые приходили сверху. О планировании я подробнее расскажу ниже.
В таком сетапе мы проработали до второго квартала 2021 года. Тогда мы решили масштабировать накопленный опыт техдивизиона и начали внедрение ОКR уже на всю компанию, выстраивая более фундаментальный подход к процессам. Мы продолжали путь итеративно-инкрементальных улучшений и задали тренд на осознанность и зрелость.
OKR как панацея
Что нужно для того, чтобы команды обрели самостоятельность? Важно делегировать ответственность за результат. Модель ОКR позволяет выстроить согласованную систему целей и ключевых результатов. Мы использовали следующую структуру:
Company OKRs — основные цели и ключевые результаты, которые компания ставит на год. Квартал к кварталу корректируются лишь целевые числовые значения.
Vertical OKRs — цели бизнес-вертикалей, которые напрямую влияют на бизнес-показатели компании. Они ставят ОКR, задавая себя вопрос: «Каким образом наша вертикаль способна внести вклад в ОКR компании?».
Horizontal OKRs — цели команд, отвечающие за компоненты продукта, которые являются едиными для всех вертикалей. Например, команды Messenger или Payments.
Supportive OKRs — отдельные команды и департаменты внутри компании, которые также напрямую или опосредованно влияют на достижение целей. Например, департаменты People&Culture, Legal и Finance, линейные подразделения внутри технологического или других дивизионов. Эти команды также задают себе вопрос, глядя на ОКR вертикалей: «А как наша команда может способствовать достижению общих целей?». Каждый раз они сами определяют, какие фокусы хотят взять на следующий квартал, даже если они напрямую не соотносятся с ОКR высшего порядка.
Паутина ОКR
Главный вопрос, которым задаются все практики ОКR — как определить влияние каждой из команд на цели компании? Для решения этого вопроса мы построили древо метрик, которое показывает связи бизнес-метрик с продуктовыми, а также позволяет однозначно определить зоны ответственности команд. На основе древа команды построили аналитические дашборы, чтобы отслеживать свои метрики в динамике и осознанно работать с продуктовыми гипотезами для достижения целей.
Аналитические дашборды строят все команды inDriver
Таким образом, каждый член команды видит, как выпуск той или иной фичи влияет на результат всей компании.
Масштабное планирование
Перечисленные выше шаги позволили сохранять высокий уровень автономности и осознанности каждой продуктовой команды. Но не стоит забывать, что структура inDriver — не набор отдельных сущностей и команд, а комплексная система. В подобном сеттинге важно добиваться согласованности работы, единого видения и принципов.
Поэтому мы внедрили масштабную процедуру продуктового квартального планирования. Оно включает в себя несколько этапов. Пререквизитом для планирования являются сформулированные ОКR команд.
Первым этапом лидеры бизнес-департаментов, продуктового и технологического дивизионов представляют продуктовые, архитектурные и бизнес-контексты, которые важно учитывать при создании планов.
После гипотезы трансформируются в ОКR
Далее команды переходят к мозговым штурмам продуктовых гипотез и инициатив, которые позволят достичь этих ОКR. Гипотезы совместно приоритизируются. На попадание той или иной инициативы или гипотезы в продуктовый план влияют 2 фактора: приоритет и уровень уверенности в том, что гипотеза сработает. Последний определяет майлстоуны для discovery- и delivery-процессов.
Весь процесс происходит в Miro
Чем больше данных, подтверждающих жизнеспособность идеи, тем дальше команда заходит в своей работе над ней. Мы считаем, что важно придерживаться итеративно-инкрементального подхода на каждом этапе создания ценности, регулярно собирать и анализировать данные.
В последнем квартале в планировании участвовало 12 продуктовых команд и порядка 350 человек. У команд были свои открытые комнаты, и каждый сотрудник inDriver мог заходить в них и предлагать свои идеи. То есть, в генерации гипотез участвовала не только команда, которая четко знает, куда ее продукт движется, но и любой заинтересованный сотрудник.
На финальном этапе процесса команды представляли свои планы друг другу, менеджмент-команде и всем заинтересованным лицам в компании. Команды сразу же получали обратную связь по планам. В результате у всех участников появлялась целостная картина, как команда выстраивает задачи на квартал: от совместной постановки целей до определения пути их достижения.
Трансформация продолжается
Таким образом, мы сделали значительный шаг вперед в области развития осознанности, зрелости и продуктовой культуры в inDriver. Вбирая лучшие практики на рынке, анализируя свой собственный опыт и создавая уникальные процессы и культурные аспекты, мы создаем Product Development Framework — масштабируемый подход к выстраиванию процессов и культуры в продуктовой компании. В основе фреймворка лежат 2 столпа.
Первый столп — это данные. Как продуктовая компания, мы стремимся к росту наших показателей и хотим принимать решения осознанно, ориентируясь на данные. Практически каждая команда у нас работает с бизнес- и продуктовыми метриками. Данные — объективная картина нашего текущего положения.
Второй столп — это доверие. Те из вас, кто читал книгу Патрика Ленсиони «Пять пороков команды» знают, что без доверия невозможен результат. Доверие позволяет выстраивать уверенные взаимоотношения с неизвестностью и неопределенностью, которые всегда сопровождают создание продуктов. С масштабированием бизнеса и увеличением количества людей доверия автоматически становится меньше, поэтому требуются дополнительные ресурсы и внимание для ее поддержания. Новые команды и инновационные продукты требуют новых подходов к созданию среды, основанной на доверии.
2 столпа в основе нашего фреймворка
После трансформации уровень технических и продуктовых команд значительно вырос. Ребята уже сами понимают, что такое команда, что нужно делать, каких результатов от них ждут и как решать возникающие проблемы. Команда разработки начала больше вовлекаться в развитие продукта и делать технические инвестиции в инфраструктуру.
До трансформации никто системно не задумывался о документации, технических инвестициях и рефакторинге — ребята просто делали входящие задачи. Но продуктовая трансформация это изменила. Помимо этого вскоре открылся офис в Москве, команды начали пополняться новыми специалистами и выходить на новые уровни.
Я убеждена, что трансформация не заканчивается никогда. Создание технологических продуктов требует постоянного процесса улучшений и изменений. Однако, многое уже сделано и многое еще впереди. Мы планируем создать прозрачную карьерную модель развития инженеров, завершить внедрение ОКR для всей компании и сформировать Product Development Framework. Возможно, что-то из этого станет основой для еще одной моей статьи на Хабре. Если у вас остались вопросы, буду рада ответить на них в комментариях.
