Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом.   В этой статье я хочу поделиться кейсом, как построить эффективную модель взаимодействия и управления работой 20 продуктовых команд, работающих на одну цель, на примере одного из самых крупных маркетплейсов страны, куда меня пригласили, чтобы построить эффективные и управляемые процессы создания продукта. В данной статье хочу сфокусироваться на построении модели каденций для улучшения взаимодействия. Каденции - встречи которые создают операционный ритм работы команд. Планирование. В чем состоял основной вызов? У нас как у домена единая цель - это увеличение GMV, количества товарооборота компании через маркетплейс. Чтобы бить в эту цель, необходимо чтобы все 20 команд, работающих на всем CJM (путь пользователя от поиска товара до получения его) планировали усилия по достижению цели Домена и были в полном синхроне при движении к этой цели. Основные проблемы с которыми мы сталкивались: Команды локально оптимизировали свой кусок CJM и не смотрели на весь, что приводило к упущенной выгоде. Мы могли все вместе посмотреть на весь CJM и понять где сейчас стоит работать, что дало бы больший рост метрик. Команды не учитывали пересечения и, как следствие, возникали ситуации когда разные команды вносили изменения в один экран со своим дизайном и решением, вместо того, чтобы учесть все изменения в одном дизайне. Это приводило к переделкам и трате времени. Тестирование одинаковых гипотез и разработка одного и того же функционала. Не учитывались зависимости команд, что рушило сроки и удлиняло time to market. Планирование сроков не работало, что делало все финансовое планирование бесполезным. Синхронизация и координация. Отсутствие должной синхронизации порождало ряд проблем: Во-первых кросскомандные проекты плохо управлялись, точнее они управлялись ситуационно, без четко выстроенной системы и часто возникали ситуации, когда одна команда запланировала доработку, а вторая нет и когда первой команде необходимо сделать доработку, то они вставали в очередь и time to market сроки по задаче ехали. Вторая проблема, которую мы видели - это отсутствие шэринга знаний и обучения между продактами и командами. Каждый делал свой кусочек, но забывал о том, что на самом деле мы делаем один продукт, и необходимо делиться опытом и создавать общие правила работы над продуктом. Например продакты не делились друг с другом о том, кто какие гипотезы протестировал, какие инсайты возникли, а команды не делились друг с другом тем какие лучшие практики в коде они используют. Все это бы позволило командам отказываться от того, что уже попробовали другие и не наступать на те же грабли и, как следствие, экономить время. Обзор результатов. Когда я делал диагностику компании я выявил большое количество отчетностей, которые требовали от команд и продактов. И самое интересное что со временем количество отчетов росло, но осведомленность руководства о прогрессе не улучшалась. Позже я это подтвердил опросом, который запустил на основных стейкхолдеров, который выявил низкую осведомленность работы продуктовых команд. Все это говорило о том, что predictabillity результатов находится на низком уровне. Если по простому, то стейкхолдеры однозначно не знают что уже готово и находится на проде, какой эффект это принесло, а что ожидать в краткосрочной перспективе. Планы команд стейкхолдеры знали, но своевременная осведомленность о том, что вышло, какие эффекты это принесло и что будет делаться дальше - вот этот момент страдал. И эту проблему должны были решать отчеты, которые не работали Еще одним важным аспектом построения эффективной модели каденций был запуск непрерывного процесса Discovery в каждой из продуктовых команд, тк уверенность в эффекте задач, взятых на планировании был невысоким. Чтобы увеличить уверенность в том, что задача принесет эффект и подкрепить это фактами, после проверки гипотезы необходимо было построить процесс discovery и организовать каденции. Таким образом модель каденций в итоге накладывалась на 2 процесса - это поиск, отбой идей, тестирование гипотез, а также планирование и предсказуемая поставка ценных решений. Модель каденций я начал строить исходя из уровней планирования в компании. В компании было три уровня планирования: Стратегия продукта на год. Квартальное планирование по ОКР (горизонт - квартал). Планирование спринта (горизонт - две недели). Вокруг следующих уровней планирования и предстояло выстроить систему каденций. Основной каденцией был квартал, тк именно на квартал команды коммитились донести эффект бизнесу, выраженный в GMV через реализацию ценных решений в продукте. Внутри квартала необходимы были более маленькие ритмы для доставки ценности и тестирования гипотез. Этими ритмами стали спринты. Мы договорились что длина спринта должна быть 2 недели и они должны начинаться и заканчиваться в одно и тоже время, чтобы проще было планировать и координировать работу команд. Чтобы эффективно порезать домен на команды мы пошли от метрик и выделили юниты, которые отвечают за метрику end-to-end. Acquisition Activation Retention Promo Payments Внутри домена есть 5 юнитов, каждый из которых отвечает за ключевую метрику продукта, внутри юнитов - продуктовые команды. Модель каденций которую мы определили и начали внедрять выглядит следующим образом: Модель каденций получилась разбита на 3 уровня и два ключевых процесса: 1 уровень - Домен 2 уровень - Юнит 3 уровень - Продуктовая команда Ключевые процессы: Discovery. Цель - Определить какие фичи мы будем реализовывать и отправлять в разработку, с подсчитанными и подтвержденными эффектами на метрики в ходе экспериментов. Delivery. Цель - реализовать MVP (минимально-жизнеспособную версию) фичи, провести А/В тест и далее решить раскатывать фичу на всех если эффект подтверждается или убирать. Каденции уровня домена включали: Спринт планирования и инноваций, ОКР планирование, Демо продуктовых команд, Синк домена, Overall service delivery review (Обзор сервиса поставок). Одна из ключевых каденций планирования квартала - это ОКР планирование. На самом деле ОКР планирование у нас получилось не как одна встреча, на который мы сели и все запланировали, а как процесс, ключевыми результатами которого было: Определение общей цели и ключевой метрики на квартал, на которую все 20 продуктовых команд будут работать. Это могли быть метрики AOV (средний чек), Сквозная конверсия в заказ или Retention Х дня. Или также совокупность метрик. Ключевая цель вначале спускалась с уровня VP на домен, а далее уже на общей встрече мы обсуждали и челленджили предложенную цель на предмет осуществимости, рисков и тд. И вполне могли предложить другие цели. Определение целей и ключевых результатов юнитов, которые складывались из целей и ключевых результатов продуктовых команд внутри. Опять же все ключевые результаты содержат метрические показатели выраженные в цифрах. Подсчет эффектов метрик команд на GMV. Беклог юнита и продуктовых команд на квартал. Определение и визуализация зависимостей команд между собой при поставке ключевых проектов/ фичей. Чтобы процесс планирования не растягивался, мы выделили в конце квартала Каденцию - “Спринт планирования и инноваций”, взяли данную технику из фреймворка SAFe, но переделали под себя. Основная цель данного спринта в том чтобы сфокусировано с помощью серии встреч провести определение ключевых целей, результатов и спланировать работу на квартал. Такой фокус позволял не растягивать этот процесс на месяц, а построить его сфокусировано за неделю-две. Первым делом в ходе спринта планирования и инноваций определялась цель с уровня VP на следующий квартал и далее ее синхронизировали с продуктовыми командами. Далее команды делали 1 драфт целей по ОКР и на встрече их синхронизировали и корректировали. Таких итераций по синхронизации драфтов было 2. Параллельно продакты делали беклог на квартал и считали эффекты, которые синхронизировали с финансистами, тк они давали обратную связь о том, насколько финансовые эффекты удовлетворяют целям компании. Финальным штрихом было построить роадмеп, обсудить его с разработкой и построить доску зависимостей, которая позволяла заранее спланировать работу по каждой фиче в квартале и сразу видеть зависимости. Пример такой доски можете увидеть ниже: Ключевые встречи и активности включали создание ключевых результатов, описанных выше. На встречах присутствовали продакты, лиды направлений, основные стейкхолдеры, финансисты, аналитики метрик. По ходу квартала необходимо было организовать регулярный чек, обзор результатов и корректировку вектора. Данные задачи мы реализовали через 2 каденции: Демо продуктовых команд Синк домена Тк команд 20 штук, то проводить обзоры спринта в каждой команде было неэффективно. Не могут же стейкхолдеры ходить на обзор спринта в каждую из 20 команд. Тогда они только и будут делать что ходить на обзоры. Мы эту задачу решили общим Демо днем. Но тк команд все равно 20, то такой Демо день мы разделили на 2 дня по юнитам. На каждый Демо день команды юнита выходили в демонстрацией работающего функционала, который либо в live формате демонстрировали, либо делали запись заранее и на встрече проводили Демо. Такая встреча сильно улучшила осведомленность стейкхолдеров, повысила шэринг знаний между командами и была интересной для всех участников, тк мы смотрели не скучные презентации, а именно работающий продукт. Также на данной встрече кратко рассказывали о достигнутых эффектах после раскатки фичей, делились неудачными экспериментами и рассказывали планы на следующий месяц. Данная встреча также помогла самим командам понимать кто что делает и организовывать дополнительное кросскомандное взаимодействие. В конце квартала Демо выглядело больше как общий обзор квартала На ней продакты+команды делились чего достигли/не достигли за квартал в формате рассказа и краткой демонстрации. На встрече участвовали стейкхолдеры и все команды. Это регулярная встреча юнит лидов, продактов и директора по продукту для синка движения к целям домена, препятствиям и рискам, а также для того, чтобы обсудить изменения/отклонения от целей и пересмотра приоритета по беклогу на квартал. В конце квартала на уровне домена мы проводили обзор сервиса поставки - Overall service delivery review. Цель встречи в том, чтобы собраться лидерами команд, включающих менеджеров продукта, юнит лидов, технических лидов, провести обзор метрик поставок за квартал и обсудить препятствия которые возникли. На выходе встречи у нас получался Action план по устранению препятствий в следующем квартале и улучшение метрик поставок. Ключевые метрики, на которые мы смотрели: Количество зеленых/серых/красных тестов после А/В фичи, Количество протестированных гипотез за квартал, Time to market (время от выбора задачи до прода), Throughput (пропускная способность). Каденции уровня юнита включали: PO sync Discovery Delivery sync Встреча продактов и юнит лида. Основные задачи которые решались на этой встрече: Обсуждение беклога гипотез. Каждый продакт рассказывал какие гипотезы проверил, какие инсайты получил и что собирается далее отдавать в разработку. Происходил общий челлендж друг друга и обмен инсайтами, Приоритизация и выбор следующих гипотез в Discovery на проверку, Генерация новых гипотез. Асинхронная каденция которая происходила при реализации общей фичи несколькими командами. На ней присутствовали технические и продуктовые лиды, которые обсуждали прогресс, зависимости и следующие шаги по фичам. Данная каденция происходила вокруг общей канбан доски, где представлены все эпики всех команд на квартал На уровне продуктовых команд были каденци (встречи) в разрезе двух основных процессов. Первый - Discovery, второй - Delivery. Команды работали по Scrum двухнедельными итерациями и внутри Scrum у нас был стандартный набор Событий (Спринт, Планирование, Дейли, Обзор, Ретроспектива). Но вдобавок к этому набору событий у нас был явно выделенный процесс Discovery, в котором также требовались циклы и события для управления этим процессом. Процесс Discovery мы организовали в Discovery спринтах, целью которых было провести эксперимент и получить новые знания, сделать выводы по гипотезе, нужно ли ее делать или нет. Внутри этого процесса были следующие события: Планирование дискавери спринта, Дейли, Ретроспектива. Обзор не проводился, тк обзор гипотез делался на PO sync discovery и Демо продуктовых команд, поэтому данная встреча была излишней. Во первых каденции систематизировали работу команд и создали предсказуемые и управляемые ритмы. У нас сильно улучшилась управляемость и прозрачность. Это подтвердили опросы, которые провели после запуска каденций. Также каденции нам позволили отказаться от ряда отчетностей в пользу более живой коммуникации. Она, как показала практика, работает более эффективно. У нас снизилось количество переделок, тк мы лучше управляли зависимостями. Каденции создали площадку шэринга знаний внутри компании как между продактами, так и между командами. Мы начали тестировать больше гипотез и улучшать эффекты внутри квартала, это подтвердилось на метриках. Конечно запуск всех каденций мы сделали не сразу. Это был эволюционный путь в несколько месяцев. И та модель, которая получилась - это модель проб и ошибок, а не определенный фреймворк. И мы до сих пор работаем над улучшением и изменением этой модели. У нас нет задачи натянуть каденции, а есть цель сделать работу Домена более управляемой, предсказуемой и несущей ценность бизнесу. Я надеюсь эта статья поможет вам построить эффективные процессы взаимодействия.  О том, что важно уметь лидеру команды сегодня и про компетенции Agile проджект менеджера мы расскажем на бесплатном вебинаре, регистрация на который доступна уже сейчас. А если понравилась статья также подписывайтесь на мой телеграм канал. Регистрация на бесплатный вебинар