Последние несколько лет в сфере digital все говорят о продуктовых командах. Но если вбить термин в поисковике и погулять по ссылкам, окажется, что статей об этом явлении не так уж много. Поэтому предлагаем простую и внятную инструкцию, основанную на 15-летнем опыте AGIMA, которая поможет вам понять: нужна вам продуктовая команда или нет и, если нужна, то где ее взять.
Что такое продуктовая команда
Продуктовая команда — это команда, которая занимается развитием продукта. Иными словами, главная ее цель — улучшить метрики, понять пользователя и повлиять на бизнес-показатели. В этом ее основное отличие от проектной и функциональной команд, которые работают с конкретными требованиями клиента.
Свойства продуктовой команды
Лет десять назад были распространены именно проектные команды: они готовы были за определенное время сделать продукт таким, каким его задумал заказчик, не лучше и не хуже. Но со временем бизнесу стало понятно, что не всегда на старте получается точно определить, каким должен быть продукт. И поэтому бизнес стал смотреть в сторону продуктового подхода.
Так и появилась та система, о которой идет речь. Чтобы просчитывать выгоду от digital-продукта и менять его при необходимости, нужно понимать поведение пользователя. И понимать это поведение должны все люди, которые работают над продуктом. В этом и состоит отличие: раньше сам бизнес определял, что продавать, а что нет. Теперь в этом процессе трое:
- бизнес,
- пользователи,
- продуктовая команда, которая играет одновременно за первых и за вторых.
- она работает над одним продуктом или над изолированной его частью, не отвлекаясь на другие;
- у людей в команде есть все необходимые компетенции, чтобы сделать продукт и затем его развивать;
- работу команды можно прогнозировать, она измерима по времени;
- такая команда способна и стремится к самоорганизации.
Если вы не знаете, нужна ли вам продуктовая команда, предлагаем пошаговую инструкцию, которая поможет ответить на этот вопрос.
Цели продуктовой команды — продуктовые и бизнес-метрики. У проектной команды цели — запуск и реализация проекта в нужном объеме и в нужные сроки. Цели влияют на процессы и на структуру такой команды. Важная часть проектной команды — это delivery-команда. Она доставляет фичи до пользователя. Достаточно пары менеджеров и большого количества разработчиков. В продуктовой команде всегда должны быть 2 составляющих: discovery и delivery. Это значит, что сначала ты проводишь исследования, подтверждаешь, опровергаешь или ищешь гипотезы, а потом уже начинается разработка. А просто сидеть и пилить функционал без гипотезы — это уже похоже на функциональную команду.
Определитесь, нужна ли вам продуктовая команда
- Продуктовую команду не стоит собирать, если вы работаете над проектом, который в итоге не планируете превратить в digital-продукт. Ваш сайт может быть интернет-представительством, на котором ваши потенциальные клиенты узнают больше о вас и найдут ваши контакты, но при этом он может быть не интегрирован в ваши бизнес-процессы. Считать этот проект продуктом сложно. У проекта есть сроки завершения, а у продукта — нет. Как только вы добьетесь идеального решения для сайта, работать над ним больше не нужно. Можно обновлять новости и галереи, можно поддерживать его технически, но развивать его цели нет. Значит, продуктовая команда пока не нужна. Достаточно отдельных проджект-менеджера, дизайнера и программиста, которые правильно поймут ваши задачи и грамотно их реализуют.
- Собирать продуктовую команду рано, если идея цифрового продукта не получила подтверждения через аналитику и пока остается гипотезой. Чтобы эту гипотезу проверить, можно использовать коридорное исследование и панельный опрос, а еще провести исследование потенциального рынка, чтобы убедиться, что создание продукта экономически обоснованно. Также можно собрать небольшую growth team, которая быстро и с помощью нехитрый технических решений разработает черновую версию продукта. На таком продукте можно протестировать спрос. Если спрос подтвердится, то только тогда появится повод собирать продуктовую команду или привлекать кросс-функциональную команду на аутсорс.
- Консервативным компаниям, которые не привыкли к быстрым точечным решениям, тоже не стоит собирать продуктовые команды. Если в вашей компании правки, задачи и приоритеты спускаются исключительно сверху, а согласование любых изменений идет через несколько инстанций, то смысла собирать отдельную команду для продукта нет.
- есть план по развитию продукта,
- вы делаете продукт, который востребован конечным потребителем,
- продукт нужен бизнесу.
Определите состав продуктовой команды
Вы решили: продуктовая команда нужна. Теперь важно определить ее состав. Идти стоит от того, каким вы задумали продукт. Возможно, в команде будет достаточно одного программиста, дизайнера и аналитика. А может быть, нужны будут услуги десятков людей с разными компетенциями.
В любом случае продукту нужен руководитель — product-менеджер. Именно он будет принимать решения и нести ответственность за продукт, ориентируясь на запросы пользователей, бизнес-интересы заказчика и предпочтения самой команды.
Иногда к работе привлекают несколько продуктовых команд. Если работать нужно над сервисом, у которого много разных функций, то несколько команд — это способ сэкономить время. А чем быстрее развивается продукт, тем больше пользы бизнесу он приносит.В некоторых случаях, когда реализовать новую функциональность продукта нужно в сжатые сроки, в команду можно привлекать внешних специалистов. Эта практика помогает не раздувать штат, особенно если речь идет о реализации небольших фич или отдельных идей.
Продуктовые команды на входе получают запрос — какую-то проблему пользователя или самого бизнеса. Их ключевая компетенция — найти оптимальное решение для проблемы и только потом его реализовать. А проектные команды получают на входе конкретные требования, их задача и основная компетенция — реализовать эти требования в срок с нужным уровнем качества. Иногда даже способ реализации уже обозначен в начальных требованиях. Еще одно показательное отличие — это лидер команды. Продуктовую команду лидирует product-менеджер: он ищет оптимальные решения, балансируя между интересами бизнеса и конечного пользователя. Проектные команды лидирует project-менеджер, он балансирует в классическом треугольнике «сроки-качество-стоимость».
Выберите, с кем работать: инхаус или аутсорс
- Если у вас в штате уже есть все необходимые специалисты и у них есть экспертиза по всем нужным для реализации продукта направлениям, то работать нужно инхаус.
- Если какой-то экспертизы не хватает, то подумайте об аутсорсе. Искать и нанимать сотрудника долго и дорого. Если у вас нет какой-то экспертизы внутри, то при попытке нанять в штат такого эксперта вы рискуете столкнуться с рядом проблем:
— ответственность за выбор ложится на ваши плечи;
— риски в связи с наймом некомпетентного или неподходящего человека тоже на вас;
— время специалистов, потраченное на поиск и собеседования, и в целом срок вывода/погружения человека всегда негативно сказывается на продукте, а значит, и на бизнесе.
При работе с аутсорс-компаниями риски и ответственность также есть, но как минимум агентство их с вами делит и дает гарантии на свою работу. А время, потраченное на поиск и вывод некомпетентного, но с прокаченными софт-скиллами специалиста, которого еще не так просто уволить, никто не вернет.
Схема, когда часть членов продуктовой команды работает в штате, а часть трудоустроена в другой компании, называется гибридной. Она отлично подходит и в том случае, когда команду нужно быстро усилить в какой-то экстренной ситуации, Например, если:
— конкуренты дышат в спину;
— конъюнктура рынка меняется, и необходимо внедрять намного больше новых функций или менять вектор развития продукта;
— влияют событийные факторы, требующие запуска крупного функционала в сжатые сроки.
- Если у вас в штате вообще нет нужных специалистов, лучше найти команду полностью на аутсорс. В этом случае команда возьмет на себя начальную фазу продукта, и, если продукт «выстрелит», можно будет нанять экспертизу инхаус, чтобы развивать продукт самостоятельно или совместно с внешней экспертизой. Вот преимущества такого подхода:
— можно обстоятельно подходить к поиску специалистов, пока аутсорс-команда работает над продуктом — нет простоя, пока нужную экспертизу не наняли;
— можно привлекать команду продукта для собеседований и отбора,
— аутсорс-команда выстроит все процессы как в разработке, так и в управлении продуктом, а внутренней команде достаточно будет перенять их себе.
При выборе команды на аутсорс обязательно изучите ее. Важно, чтобы компания, которая будет вам помогать, рассказывала не только о своих победах, но и о своих неудачах. Это самая полезная информация для заказчика: во-первых, она показывает, что команда не боится ошибок и трудностей, а во-вторых, демонстрирует, как легко и насколько эффективно она находит выход из сложной ситуации
Продумайте, сколько команд вам нужно
Некоторые продукты настолько большие, что для работы над ними требуется несколько команд. Если вы точно решили делить проект на составные части, нужно учитывать риски.
В первую очередь это коммуникативные издержки: чем больше команд участвует в создании продукта, тем больше будет встреч и переписок, которые позволят оперативно передавать информацию от одной команды другой. Если над продуктом работает одна большая команда, таких издержек будет гораздо меньше. Но в то же время единой командой тяжелее управлять — большие команды сложно сделать самоорганизованными.
При этом если работу всех команд грамотно организовать, то каждая из них будет проводить ревью работы других.
- Команды бывают 2-х типов: discovery team (growth team) и core team. Discovery занимается разработкой и испытанием новых фич, отвечает за развитие и проверку гипотез. Core team занимается сопровождением продукта: следит, чтобы всё работало 24/7/365, решает аварийные ситуации, принимает меры, чтобы не допустить их в будущем, а еще внедряет новые, уже проверенные командой discovery фичи и развивает старые.
- У каждой команды на проекте должна быть своя зона ответственности. Лучше, если эти зона не будут пересекаться или будут пересекаться минимально. Например, пусть одна команда отвечает за дизайн, а вторая за разработку. Это лучше, чем если обе будут делать макеты или писать код. Но если избежать пересечения полностью невозможно, важно формализовать задачи: четко прописать, кто у кого принимает фичи и кто за какую часть работ отвечает.
Продумайте свое взаимодействие с командой
Продуктовый подход предполагает, что заказчик не дает команде четкого пошагового ТЗ, а формирует запрос, проблему или/и цель. Задача команды — решить проблему или достичь цели.
В большинстве современных подходов продуктовая команда работает спринтами — временными отрезками длиной в 1–4 недели. По их итогам обычно проводится встречи под названием «обзор спринта». На этих встречах команда и представители бизнеса обсуждают прогресс и корректируют бэклог.
Также все активные участники проекта посещают ретроспективы — встречи по итогам спринтов, на которых команда разбирает свои ошибки и методы их решения. А также фиксирует успехи и способы их достижения, чтобы повторить. Хотя эти встречи рассчитаны в основном на членов команды, при желании вы тоже можете в них участвовать. Главное — чтобы все участники общались на равных и никого не стеснялись.
Однако при этом почти любая продуктовая команда каждый день встречается на дейли-митингах. Это ежедневная короткая летучка по текущим вопросам, на которой каждый рассказывает о планах на день или получает новые задачи. Заказчику или его представителям ходить на такие летучки совсем не обязательно.
Подведем итоги
Продуктовая команда не является единственным способом работы над продуктом. Однако практика показывает, что этот подход очень эффективен. Именно продуктовые команды создали самые успешные и крупные продукты в сфере digital за последние годы.
- не каждый проект можно считать продуктом;
- продуктовая команда нужна не всем и не всегда;
- состав продуктовой команды определяется продуктом;
- команды на аутсорсе могут сэкономить ваши деньги, нервы и силы;
- продуктовая команда — это формат работы, который позволяет учитывать в итоговом продукте потребности пользователей и бизнеса.
Комментарии и обсуждения статьи на vc.ru.