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