Эволюция продуктовых команд

Про то, почему и как в разных компаниях приходят к продуктовым командам. Мыслями поделился автор Telegram-канала для продактов alexcouncil Алексей Арефьев.

Вокруг продуктовой темы много хайпа: куча образовательных программ для продактов, народ идет повально учиться, компании хотят выстроить «продуктовый подход», продакт, продакт, продакт. Но откуда все это добро взялось и почему оно набирает?

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

 ​

Весь процесс эволюции продуктовых команд я разделил на этапы. Каждому свойственны свои особенности и симптомы. Изменения, которые появляются на каждом следующем этапе, выделены оранжевым. Давайте детальнее разберем.

1. Как-то

Все началось с того, что в компании есть какая-то разработка и это как-то работает.

PM — продакт менеджер, или тот, кто отвечает за развитие digital-продукта.

IT — подразделение, отвечающее за разработку.

Релиз — выпуск/публикация разработанной функциональности.

Роли PM и IT могут по-разному называться: ecom, digital, разработчики и так далее. Суть от этого не меняется, так как одни (PM на схеме) задачи ставят, другие (IT) помогают их реализовывать. Релиз — момент времени, когда задача готова и выпущена для эксплуатации.

Ситуация: есть некий поток задач, который сыпется в волшебную коробку под названием IT. Задачи могут прилетать с разных сторон. Часть идет через PM-подразделение, часть напрямую.

Симптомы:

  • Отсутствует бизнес планирования. Что-то как-то реализуется.
  • Часть задач выходит в срок, часть нет.
  • Нет релизного цикла.
  • Нагрузка на IT не распределена. Народ то перегружен, то недогружен. Внутри: тлен, безысходность, непонимание смысла жизни, выгорание.

2. Релизная схема, спринты

Нужно что-то менять и как-то сбалансировать нагрузку на людей.

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

Нагрузка на IT становится более сбалансированной. Плановые работы на регрессионное тестирование и подготовку релизов помогают немного упорядочить хаос. Сокращаются трудозатраты за счет стандартизации работ.

У системы появляется темп/шаг. Две недели спринта — релиз, две недели спринта — релиз.

Но:

  • Задачи все так же поступают со всех сторон.
  • Какие-то влезают в спринты, какие-то нет.
  • Бизнес-планирования все еще нет: сроки не выдерживаются — заказчики негодуют.

3. Пропускная способность спринтов

Как научиться выдерживать сроки?

Ситуация: начинаем оценивать задачи. Сколько стоит та или иная задача, допустим, в часах? Сколько часов мы можем закрыть за один спринт? Появляется пропускная способность спринта.

Зарождается планирование. Прозрачнее становится понимание возможностей команды. Чуть лучше становится управление ожиданиями заказчиков.

Но:

  • Поток задач в IT все также не упорядочен.
  • Нет понятного приоритета задач.
  • Не сбалансирована нагрузка на команду IT.
  • Отсутствует стратегия развития продукта.

4. Поток

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

Ситуация: все задачи на разработку проходят через PM. Исходя из оценки задачи, приоритетов и пропускной способности команды планируются задачи на спринт. Система «вытягивается», поток задач становится прямым. Появляется понятное бизнес планирование с приоритетами и сроками.

Нормализуется нагрузка на команду IT. На вход приходит фиксированный список задач. Изменения не вносятся во время спринта. Растет эффективность всей системы за счет постоянного потока и упорядочивания хаоса.

Вся система становится прозрачной. Видны «узкие места», те части процесса, в которых задачи могут «подвисать». Расширяем эти места — улучшаем time to market (время от момента, когда задачу придумали до ее фактической реализации).

5. Продуктовые команды

Можно ли эффективнее управлять развитием продукта и ресурсом разработки?

CPO — chief product officer или главный продакт-менеджер.

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

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

За каждым направлением выделяется продуктовая команда во главе со своим PM. Внутри команды есть полностью выделенные роли: разработчики, тестировщики, дизайнеры (опционально), аналитики (опционально).

На практике делить могут по платформам (web, app), по сущностям (личный кабинет, интернет-магазин), по воронке пользователя (acquisition, activation) и так далее. Отсюда появляются: продакт мобильного приложения, продакт личного кабинета, продакт activation...

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

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

Таким образом на уровне компании появляется прогнозируемое развитие продукта с фокусом на бизнес цели и сокращенным time to market.

Мысли

Этапы, которые я описал выше, — это лишь взгляд на то, что мне удалось увидеть. Те «боли» и потребности, которые возникали в разных компаниях, подталкивали систему к изменениям. Эволюционно все так или иначе приходили к одному — некоему подобию продуктовых команд.

P.S. В схеме, которую приложил к статье, я оставил 6 этап под вопросом и написал: «Что дальше?» А ведь правда, что? Какая структура будет следующей? Что-то бирюзовое или еще какое? У меня нет ответа на этот вопрос.

Если у вас есть опыт или мысли на этот счет, поделитесь, пожалуйста, в комментариях или напишите мне в ЛС telegram. С удовольствием дополню схему.

0
19 комментариев
Написать комментарий...
Ivan Struzhkov

Статья не о разработке продукта. А о том что организованная работа лучше неорганизованной. Безусловный факт, но не раскрывающий суть вопроса. Если статья про эволюцию - неясно почему команда со спринтами сильнее команды без спринтов. какой критерий эволюции?

Ответить
Развернуть ветку
Константин Шахорко

Всегда интересовало, какие kpi у команды разработки?

Ответить
Развернуть ветку
Алексей Арефьев
Автор

На практике то, что видел до Продуктовых команд - факт выпуска функционала и его работоспособность. После того, как переходят на команды - часть KPI (встречались 30-50%) становятся бизнесовыми (конверсии, выручка, arpu). 

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Black Widow

Плюсую, и фиг где найдешь

Ответить
Развернуть ветку
Ваня Пупкмн

В тему призывается Ивано Диджитал, пожалуй, лучший продакт в России.

Ответить
Развернуть ветку
Дима Кивенко

Спасибо за материал. Вопрос - продуктовый подход в разработке своего продукта это одно. Когда продуктовый подход продаётся внешнему заказчику - другое дело. Не понятно кто все эти подходы и отдельные команды будет оплачивать. Что думаете об этом?

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

Про развитие модели - дальше надо развивать цикл разработки и тестирования. Ну и роль ПМ усиливать. 

Ответить
Развернуть ветку
Evgenii Medvedev

Мое скромное мнение, не роль ПМ (продакта, в контексте статьи) усиливать, а разводить роли прожекта и продакта по разным людям. Один продукт - одна команда - один продакт/прожект хорошо, но проблемы неизбежно начинается, когда у продакта кросс-командный продукт или к его команде приходит другой продакт, так как у него продукт задевает вашу зону ответственности. Тогда надо управлять и своими и чужими приоритетами, беклогом, рисками и ожиданиями и проектная работа начинает доминировать над продуктовой.

Ответить
Развернуть ветку
Алексей Арефьев
Автор

Да. это боль :(

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

Ответить
Развернуть ветку
Алексей Арефьев
Автор

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

С одной стороны на старте затраты на такую группу могут быть высокими, а профит в моменте команда может и не дать, тогда нафиг она нужна? 

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

Продуктовые команды лучше рассматривать в долгую, так как основной профит будет заметен на более длительном интервале времени. Конечно, если это не гроус хакинг команды, которые обещают вам за 2-3 дня прибыль х5-10-20 сделать. Но это уже другая историч :) 

Ответить
Развернуть ветку
taan luis

Похоже на классический проектный офис :)

Ответить
Развернуть ветку
Dima Kaminin

Что делать если сначала задачу оценивают например в 20 часов но по факту ее сделали за 50? Программист думает одно но когда дело доходит до реализации всплывают разного рода камни которые не были видны при первичной оценке

Ответить
Развернуть ветку
Pavel Doronin

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

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

Ответить
Развернуть ветку
Алексей Арефьев
Автор

Проходили подобную практику. Из рекомендаций

- Вести статистику по оценкам и расхождению от реальности. Дальше вводить поправочный коэфициент. Пример - оценивают в 20 часов, накидываем сверху Х часов. Но это недолгосрочно. 

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

Ответить
Развернуть ветку
Anastasia Shalygina

👍🏻

Ответить
Развернуть ветку
Anton Smelov

Обучения продактству много, но есть ли на него такой-же огненный спрос?

Ответить
Развернуть ветку
Алексей Арефьев
Автор

Реально сложно сказать. Рынок продуктового образования за последние 3 года сильно вырос. В вакансиях по ощущениям спрос тоже подрос, но какова реальная динамика понять тяжело. По запросам вордстата на "продакт менеджер" выросли запросы в 2 раза 2020 к 2019, но тоже так себе статитсика. Нужно ресерчить отдельно.

Ответить
Развернуть ветку
Evgenii Medvedev
Какая структура будет следующей? 

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

Ответить
Развернуть ветку
Алексей Арефьев
Автор

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

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

Ответить
Развернуть ветку
16 комментариев
Раскрывать всегда