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

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

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

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

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

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

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

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

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

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

Симптомы:

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

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

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

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

Но:

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

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

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

Но:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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