Автор статьи: Дмитрий Курдюмов

Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group)

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

Для чего нам нужна была модель каденций?

В данном примере 20 команд работали на одну цель — увеличение товарооборота через маркетплейс.

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

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

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

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

Модель каденций 

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

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

• Стратегия продукта на год

• Квартальное планирование по ОКР (горизонт — квартал)

• Планирование спринта (горизонт — две недели)

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

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

Структура домена

Домен целью которого увеличить товарооборот делился на 5 юнитов (направлений в которых были продуктовые команды)

• Acquisition (привлечение клиентов)

• Activation (активация клиентов) 

• Retention (удержание клиентов)

• Promo (промо для клиентов)

• Payments (оплаты клиентов)

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

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

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

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

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

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

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

• Discovery. Цель — Определить какие фичи мы будем реализовывать и отправлять в разработку, с подсчитанными и подтвержденными эффектами на метрики в ходе экспериментов.

• Delivery. Цель — реализовать MVP (минимально‑жизнеспособную версию) фичи, провести А/В тест и далее решить раскатывать фичу на всех если эффект подтверждается или убирать.

Каденции на уровне домена

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

• Спринт планирования и инноваций

• ОКР планирование

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

• Синк домена

• Overall service delivery review (Обзор сервиса поставок)

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

• Определение общей цели и ключевой метрики на квартал, на которую все 20 продуктовых команд будут работать. Это могли быть метрики AOV (средний чек клиента), Сквозная конверсия в заказ или Retention Х дня. Или также совокупность метрик.

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

• Определение целей и ключевых результатов юнитов, которые складывались из целей и ключевых результатов продуктовых команд внутри. Опять же все ключевые результаты содержат метрические показатели выраженные в цифрах.

• Подсчет эффектов метрик команд на товарооборот

• Беклог юнита и продуктовых команд на квартал

• Определение и визуализация зависимостей команд между собой при поставке ключевых проектов/ фичей

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

Процесс планирования ОКР

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

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

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

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

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

Синхронизация по ходу квартала

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

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

• Синк домена

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

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

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

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

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

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

Синк домена

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

Ретроспективный анализ и улучшение

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

Overall service delivery review

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

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

• Количество зеленых/серых/красных тестов после А/В фичи

• Количество протестированных гипотез за квартал

• Time to market (время от выбора задачи до прода)

• Throughput (пропускная способность)

Каденции на уровне Юнита

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

• PO sync Discovery

• Delivery sync

PO sync Discovery

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

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

• Обсуждение беклога гипотез. Каждый продакт рассказывал какие гипотезы проверил, какие инсайты получил и что собирается далее отдавать в разработку. Происходил общий челлендж друг друга и обмен инсайтами

• Приоритизация и выбор следующих гипотез в Discovery на проверку

• Генерация новых гипотез

Delivery sync

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

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

Каденции Уровня продуктовой команды

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

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

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

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

• Планирование дискавери спринта

• Дейли

• Ретроспектива

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

Что нам дала система каденций?

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

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

Если понравилась статья — подписывайтесь на мой телеграм-канал, где регулярно делюсь новыми кейсами и инструментами.

Также в завершение напомню про открытый урок, который пройдёт сегодня в рамках курса «Delivery manager» в OTUS — про подходы к управлению портфелем проектов. Записывайтесь по ссылке, если интересно.