Чек-лист: нужна ли вам продуктовая команда

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

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

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

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

Основные свойства продуктовой команды:

Если вы не знаете, нужна ли вам продуктовая команда, предлагаем пошаговую инструкцию, которая поможет ответить на этот вопрос.

Итак, продуктовая команда нужна, если:

— есть план по развитию продукта,

— вы делаете продукт, который востребован конечным потребителем,

— продукт нужен бизнесу.

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

В любом случае продукту нужен руководитель — product-менеджер. Именно он будет принимать решения и нести ответственность за продукт, ориентируясь на запросы пользователей, бизнес-интересы заказчика и предпочтения самой команды.

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

Инхаус-команда состоит у вас в штате. Аутсорс-команда трудоустроена не у вас, а, например, в компании, которая занимается разработкой в сфере digital. Оба варианта хороши, нужно выбрать тот, что подходит вам:

— ответственность за выбор ложится на ваши плечи;

— риски в связи с наймом некомпетентного или неподходящего человека тоже на вас;

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

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

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

— конкуренты дышат в спину;

— конъюнктура рынка меняется, и необходимо внедрять намного больше новых функций или менять вектор развития продукта;

— влияют событийные факторы, требующие запуска крупного функционала в сжатые сроки.

— можно обстоятельно подходить к поиску специалистов, пока аутсорс-команда работает над продуктом — нет простоя, пока нужную экспертизу не наняли;

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

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

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

Некоторые продукты настолько большие, что для работы над ними требуется несколько команд. Если вы точно решили делить проект на составные части, нужно учитывать риски.

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

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

Принимая решение, сколько команд нужно для работы над продуктом, также стоит учитывать и следующие факторы:

1. Команды бывают 2-х типов: discovery team (growth team) и core team. Discovery занимается разработкой и испытанием новых фич, отвечает за развитие и проверку гипотез. Core team занимается сопровождением продукта: следит, чтобы всё работало 24/7/365, решает аварийные ситуации, принимает меры, чтобы не допустить их в будущем, а еще внедряет новые, уже проверенные командой discovery фичи и развивает старые.

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

Продуктовый подход предполагает, что заказчик не дает команде четкого пошагового ТЗ, а формирует запрос, проблему или/и цель. Задача команды — решить проблему или достичь цели.

В большинстве современных подходов продуктовая команда работает спринтами — временными отрезками длиной в 1–4 недели. По их итогам обычно проводится встречи под названием «обзор спринта». На этих встречах команда и представители бизнеса обсуждают прогресс и корректируют бэклог.

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

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

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

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