Автор статьи: Дмитрий Курдюмов
Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х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.
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 и Демо продуктовых команд, поэтому данная встреча была излишней.
Что нам дали каденции?
Во первых каденции систематизировали работу команд и создали предсказуемые и управляемые ритмы. У нас сильно улучшилась управляемость и прозрачность. Это подтвердили опросы, которые провели после запуска каденций. Также каденции нам позволили отказаться от ряда отчетностей в пользу более живой коммуникации. Она, как показала практика, работает более эффективно.
У нас снизилось количество переделок, тк мы лучше управляли зависимостями.
Каденции создали площадку шэринга знаний внутри компании как между продактами, так и между командами.
Мы начали тестировать больше гипотез и улучшать эффекты внутри квартала, это подтвердилось на метриках.
Конечно запуск всех каденций мы сделали не сразу. Это был эволюционный путь в несколько месяцев. И та модель, которая получилась - это модель проб и ошибок, а не определенный фреймворк. И мы до сих пор работаем над улучшением и изменением этой модели. У нас нет задачи натянуть каденции, а есть цель сделать работу Домена более управляемой, предсказуемой и несущей ценность бизнесу.
Я надеюсь эта статья поможет вам построить эффективные процессы взаимодействия.
О том, что важно уметь лидеру команды сегодня и про компетенции Agile проджект менеджера мы расскажем на бесплатном вебинаре, регистрация на который доступна уже сейчас. А если понравилась статья также подписывайтесь на мой телеграм канал.
