6 способов сделать команду более вовлеченной в разработку продукта

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

При этом менеджеры продуктов и руководители команд сталкиваются с задачей вовлечения команд в продукт и бизнес-контекст. С такими изменениями мы работали в компаниях МТС, Альфа Банк и Х5 Retail group.

Почему четкое техническое задание — неоптимальное решение

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

Какие инструменты можно использовать

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

Удостоверьтесь, что у вас есть сформулированное «видение продукта»

Почему это важно? Если между участниками команды синхронизирован вектор, значит вы движетесь в одном направлении. Для команды важен смысл того, что они делают. Вспомните: когда вы делаете те вещи, смысл которых не понимаете, насколько у вас горят глаза этим заниматься?

«Видение продукта» можно сформулировать одним предложением, описав, каким продукт должен быть на горизонте. Формула «видения продукта» выглядит следующим образом:

«Для (ключевой пользователь), который (обозначение проблемы или возможности) (Название продукта) это (категория продукта), который (ключевое преимущество, убедительная причина для покупки), в отличие от (ключевой прямой конкурент) наш продукт (обозначение ключевого отличия)»

Например:

«Для часто путешествующих и работающих удаленно людей, которые тратят много времени на составление маршрутов путешествий перед поездкой, мобильное приложение Mesto позволяет смотреть готовые маршруты от других путешественников и быстро составлять свой собственный»

Наличие продуктовой измеримой цели

Важно:

Удостовериться, что у вас есть метрики, по которым можно измерять успешность продукта. Цели должны быть завязаны на эти метрики, чтобы у команды была возможность на них влиять;

Например:

Плохая цель — сделать поиск по товарам;
Хорошая цель — увеличить конверсию на добавление в корзину на Х%.

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

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

Рассказывать о результатах продукта

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

Быть проводником команды к пользователям

Команда, которая никогда не видела пользователей, несравнима с командой, которая регулярно с ними общается. Тут вы возразите: «А когда тогда им писать код?». Но на самом деле написание кода — это лишь малая часть создания продукта, а основная часть — исследование и тестирование гипотез. Вовлеченность команды в продукт круто мотивирует команду и увеличивает качество того, что они делают.
Как можно вовлекать в этот процесс команду?

Если вы работаете по Scrum, на обзоре спринта (демо), дайте команде самостоятельно продемонстрировать, что они сделали за спринт, пообщаться и собрать обратную связь у пользователей и заинтересованных лиц, которых вы пригласили на обзор.

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

Проводить Product backlog refinement с пользователями

PBR — это процесс (встреча), в течение которого уточняются элементы беклога (список требований по продукту. Это нужно, чтобы лучше понимать задачи в последующих спринтах.

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

Чтобы встреча прошла эффективнее, пригласите фасилитатора, который построит формат встречи и проведет ее наиболее эффективно.

Формулируйте единую цель на спринт на этапе планирования

Создание общей цели спринта на планировании спринта позволяет команде чувствовать совместную ответственность не за локальный кусочек задачи, а за результат по продукту в спринте и вклад в общую продуктовую цель. Избегайте постановки целей типа «Сделать все задачи». Вместо этого сфокусируйтесь на ценности для пользователя: «Сделать более удобный поиск по товарам, что позволит увеличить конверсию добавления в корзину на Х»

Как получить максимум?

Чтобы стать командой, стоит изменить парадигму поведения с «Я — Они», «руководитель — исполнители» на «Мы». Мы — команда, мы вместе идем к цели продукта.

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

Вначале вы можете столкнуться с сопротивлением: многие не привыкли к такому формату работы. Начните с малого. Обсудите «видение продукта» и сформулируйте продуктовые цели. Это позволит улучшить фокус команды на результат.

Результаты после вовлечения команды в продукт

Решения, получаемые от команд, стали более клиентоцентричными. Участники стали думать не только о том, чтобы выполнить задачу, но и о том, как сделать это наилучшим образом для пользователя. И это отразилось на качестве всего продукта;

Ускорение time to market до нескольких недель. Команды стали меньше времени тратить на написание технического задания и стали больше общаться, выпускать продукт небольшими порциями;
Командная работа улучшилась, поскольку ответственность команды сфокусирована на результат и метрики продукта, нежели на узконаправленные направления.

Фото: Flamingo Images / Shutterstock