Как наладить предсказуемую и управляемую поставку в масштабе 200+ человек и 20 продуктовых команд

В этой статье я хочу поделиться кейсом, как построить эффективную модель взаимодействия и управления работой 20 продуктовых команд, работающих на одну цель, на примере одного из самых крупных маркетплейсов страны, куда меня пригласили, чтобы построить эффективные и управляемые процессы создания продукта.

В данной статье хочу сфокусироваться на построении модели каденций для улучшения взаимодействия. (каденции - встречи которые создают ритм и регулярность)

Основные проблемы с которыми мы сталкивались:

Отсутствие должной синхронизации порождало ряд проблем:

Еще одним важным аспектом построения эффективной модели каденций был запуск непрерывного процесса Discovery в каждой из продуктовых команд, тк уверенность в эффекте задач, взятых на планировании был невысоким. Чтобы увеличить уверенность в том, что задача принесет эффект и подкрепить это фактами после проверки гипотезы необходимо было построить процесс discovery и организовать каденции.

Таким образом модель каденций в итоге накладывалась на 2 процесса - это поиск, отбой идей, тестирование гипотез и планирование и предсказуемая поставка ценных решений.

Модель каденций я начал строить исходя из уровней планирования в компании.

В компании было три уровня планирования:

Вокруг следующих уровней планирования и предстояло выстроить систему каденций.

Основной каденцией был квартал, тк именно на квартал команды коммитились донести эффект бизнесу, выраженный в GMV через реализацию ценных решений в продукте. Внутри квартала необходимы были более маленькие ритмы для доставки ценности и тестирования гипотез. Этими ритмами стали спринты. Мы договорились что длина спринта должна быть 2 недели и они должны начинаться и заканчиваться в одно и тоже время, чтобы проще было планировать и координировать работу команд.

Чтобы эффективно порезать домен на команды мы пошли от метрик и выделили юниты, которые отвечают за метрику end-to-end

Внутри домена есть 5 юнитов, каждый из которых отвечает за ключевую метрику продукта, внутри юнитов - продуктовые команды.

Модель каденций которую мы определили и начали внедрять выглядит следующим образом:

Модель каденций получилась разбита на 3 уровня и два ключевых процесса:

1 уровень - Домен

2 уровень - Юнит

3 уровень - Продуктовая команда

Ключевые процессы:

Каденции уровня домена включали:

Одна из ключевых каденций планирования квартала - это ОКР планирование. На самом деле ОКР планирование у нас получилось не как одна встреча, на который мы сели и все запланировали, а как процесс, ключевыми результатами которого было:

Ключевая цель вначале спускалась с уровня VP на домен, а далее уже на общей встрече мы обсуждали и челленджили предложенную цель на предмет осуществимости, рисков и тд. И вполне могли предложить другие цели.

Чтобы процесс планирования не растягивался мы выделили в конце квартала Каденцию - “Спринт планирования и инноваций”, взяли данную технику из фреймворка SAFe, но переделали под себя. Основная цель данного спринта в том чтобы сфокусировано с помощью серии встреч провести определение ключевых целей, результатов и спланировать работу на квартал. Такой фокус позволял не растягивать этот процесс на месяц, а построить его сфокусировано за неделю-две.

Первым делом в ходе спринта планирования и инноваций определялась цель с уровня VP на следующий квартал и далее ее синхронизировали с продуктовыми командами.

Далее команды делали 1 драфт целей по ОКР и на встрече их синхронизировали и корректировали. Таких итераций по синхронизации драфтов было 2.

Параллельно продакты делали беклог на квартал и считали эффекты, которые синхронизировали с финансистами, тк они давали обратную связь о том, насколько финансовые эффекты удовлетворяют целям компании.

Финальным штрихом было построить роадмеп, обсудить его с разработкой и построить доску зависимостей, которая позволяла заранее спланировать работу по каждой фиче в квартале и сразу видеть зависимости. Пример такой доски можете увидеть ниже:

Ключевые встречи и активности включали создание ключевых результатов, описанных выше. На встречах присутствовали продакты, лиды направлений, основные стейкхолдеры, финансисты, аналитики метрик.

По ходу квартала необходимо было организовать регулярный чек, обзор результатов и корректировку вектора. Данные задачи мы реализовали через 2 каденции:

Демо продуктовых команд

Тк команд 20 штук, то проводить обзоры спринта в каждой команде было неэффективно. Не могут же стейкхолдеры ходить на обзор спринта в каждую из 20 команд. Тогда они только и будут делать что ходить на обзоры. Мы эту задачу решили общим Демо днем. Но тк команд все равно 20, то такой Демо день мы разделили на 2 дня по юнитам.

На каждый Демо день команды юнита выходили в демонстрацией работающего функционала, который либо в live формате демонстрировали, либо делали запись заранее и на встрече проводили Демо.

Такая встреча сильно улучшила осведомленность стейкхолдеров, повысила шэринг знаний между командами и была интересной для всех участников, тк мы смотрели не скучные презентации, а именно работающий продукт. Также на данной встрече кратко рассказывали о достигнутых эффектах после раскатки фичей, делились неудачными экспериментами и рассказывали планы на следующий месяц. Данная встреча также помогла самим командам понимать кто что делает и организовывать дополнительное кросскомандное взаимодействие.

В конце квартала Демо выглядело больше как общий обзор квартала

На ней продакты+команды делились чего достигли/не достигли за квартал в формате рассказа и краткой демонстрации. На встрече участвовали стейкхолдеры и все команды.

Синк домена

Это регулярная встреча юнит лидов, продактов и директора по продукта для синка движения к целям домена, препятствиям и рискам, а также для того чтобы обсудить изменения/ отклонения от целей и пересмотра приоритета по беклогу на квартал.

В конце квартала на уровне домена мы проводили обзор сервиса поставки - Overall service delivery review

Overall service delivery review

Цель встречи в том чтобы собраться лидерами команд, включающих менеджеров продукта, юнит лидов, технических лидов и провести обзор метрик поставок за квартал и обсудить препятствия которые возникли. На выходе встречи у нас получался Action план по устранению препятствий в следующем квартале и улучшение метрик поставок.

Ключевые метрики, на которые мы смотрели:

Каденции уровня юнита включали:

PO sync Discovery

Встреча продактов и юнит лида.

Основные задачи которые решались на этой встрече:

Delivery sync

Асинхронная каденция которая происходила при реализации общей фичи несколькими командами. На ней присутствовали технические и продуктовые лиды, которые обсуждали прогресс, зависимости и следующие шаги по фичам.

Данная каденция происходила вокруг общей канбан доски, где представлены все эпики всех команд на квартал

На уровне продуктовых команд были каденци (встречи) в разрезе двух основных процессов. Первый - Discovery, второй - Delivery. Команды работали по Scrum двухнедельными итерациями и внутри Scrum у нас был стандартный набор Событий (Спринт, Планирование, Дейли, Обзор, Ретроспектива).

Но вдобавок к этому набору событий у нас был явно выделенный процесс Discovery, в котором также требовались циклы и события для управления этим процессом.

Процесс Discovery мы организовали в Discovery спринтах, целью которых было провести эксперимент и получить новые знания, сделать выводы по гипотезе, нужно ли ее делать или нет.

Внутри этого процесса были следующие события:

Обзор не проводился тк обзор гипотез делался на PO sync discovery и Демо продуктовых команд, поэтому данная встреча была излишней.

Конечно запуск всех каденции мы сделали не сразу. Это был эволюционный путь в несколько месяцев. И та модель которая получилась - это модель проб и ошибок, а не определенный фреймворк. И мы до сих пор работаем над улучшением и изменением этой модели. У нас нет задачи натянуть каденции, а есть цель сделать работу Домена более управляемой, предсказуемой и несущей ценность бизнесу.

Я надеюсь эта статья поможет вам сделать первый шаг к тому, чтобы улучшить эффективность взаимодействия при разработке продукта большим количеством команд, а если нужна подробная консультация и внедрение на практике, смело обращайтесь ко мне напрямую в телеграм, или на наш сайт. Также смело подписывайтесь на мой канал в телеграм.