В компаниях, проводящих продуктовые и цифровые трансформации, происходит уход от классических подходов и проектного управления к продуктовому подходу, где полностью меняется формат работы команд. Если раньше участники команд разрабатывали продукт по четкому техническому заданию, теперь они должны становиться активными участниками процесса и плотнее общаться с бизнесом, нежели получать готовые описания ТЗ.
При этом менеджеры продуктов и руководители команд сталкиваются с задачей вовлечения команд в продукт и бизнес-контекст. С такими изменениями мы работали в компаниях МТС, Альфа Банк и Х5 Retail group.
Почему четкое техническое задание может не быть оптимальным решением для продуктовых команд
Во-первых, знания о продукте и потребностях пользователей находились у менеджера продукта. Зачастую группы аналитиков становились узкими горлышками — все коммуникации замыкались на них, а скорость и качество передачи информации при этом страдали; Во-вторых, для написания четкого технического задания требовалось до нескольких недель. Но написанное быстро устаревало — нужно было постоянно обновлять содержание, вместо того, чтобы уже написать кусок кода и получить обратную связь от рынка; В-третьих, разработчики могли не понимать технические задания так же, как это делали пользователи и заинтересованные лица. И часто получалось так, что результаты спринтов не совпадали с ожиданиями; В-четвертых, при передаче технического задания наблюдалась передача ответственности друг на друга — вместо общей ответственности за результат продукта.
Какие видимые результаты произошли после вовлечения команды в продукт
Решения, получаемые от команд, стали более клиентоцентричными. Участники стали думать не только о том, чтобы выполнить задачу, но и о том, как сделать это наилучшим образом для пользователя. И это отразилось на качестве всего продукта;
Ускорение time to market до нескольких недель. Команды стали меньше времени тратить на написание технического задания и стали больше общаться, выпускать продукт небольшими порциями;Командная работа улучшилась, поскольку ответственность команды сфокусирована на результат и метрики продукта, нежели на узконаправленные направления.
Какие инструменты можно использовать
В первую очередь — инструменты, которые помогают обеспечить полный фокус команды на продукте. Свое начало они берут в гибких подходах Agile. Вот некоторые из них:
Удостоверьтесь, что у вас есть сформулированное «видение продукта», вы его регулярно транслируете и обсуждаете с командой
Почему это важно? Если между участниками команды синхронизирован вектор, значит вы движетесь в одном направлении. Для команды важен смысл того, что они делают. Вспомните: когда вы делаете те вещи, смысл которых не понимаете, насколько у вас горят глаза этим заниматься?
«Видение продукта» можно сформулировать одним предложением, описав, каким продукт должен быть на горизонте. Формула «видения продукта» выглядит следующим образом:
«Для (ключевой пользователь), который (обозначение проблемы или возможности) (Название продукта) это (категория продукта), который (ключевое преимущество, убедительная причина для покупки), в отличие от (ключевой прямой конкурент) наш продукт (обозначение ключевого отличия)»
Например:
«Для часто путешествующих и работающих удаленно людей, которые тратят много времени на составление маршрутов путешествий перед поездкой, мобильное приложение Mesto позволяет смотреть готовые маршруты от других путешественников и быстро составлять свой собственный»
Наличие продуктовой измеримой цели
Важно:
Удостовериться, что у вас есть метрики, по которым можно измерять успешность продукта. Цели должны быть завязаны на эти метрики, чтобы у команды была возможность на них влиять;
Например:
Плохая цель — сделать поиск по товарам;Хорошая цель — увеличить конверсию на добавление в корзину на Х%.
Во втором случае у команды нет готового решения и нужно придумать, как сделать так, чтобы увеличить конверсию. Для команды это будет вызовом.
Важно не просто ставить цели, а обсуждать их с командой, чтобы команда могла также формулировать и верить в достижение.
Рассказывать о результатах продукта
Рассказывайте команде после каждого релиза об эффекте для продукта, который принесла их работа. Как команда повлияла на продуктовые метрики и сколько денег начал зарабатывать продукт? Они будут гордиться своей работой.
Быть проводником команды к пользователям
Команда, которая никогда не видела пользователей, несравнима с командой, которая регулярно с ними общается. Тут вы возразите: «А когда тогда им писать код?». Но на самом деле написание кода — это лишь малая часть создания продукта, а основная часть — исследование и тестирование гипотез. Вовлеченность команды в продукт круто мотивирует команду и увеличивает качество того, что они делают. Как можно вовлекать в этот процесс команду?
Если вы работаете по Scrum, на обзоре спринта (демо), дайте команде самостоятельно продемонстрировать, что они сделали за спринт, пообщаться и собрать обратную связь у пользователей и заинтересованных лиц, которых вы пригласили на обзор.
В этом случае:Команда будет чувствовать ответственность за то, что делает;Команда будет лучше понимать потребности пользователей, чем они живут, а также как сделать продукт еще круче.
Проводить Product backlog refinement (PBR, grooming) с пользователями и заинтересованными лицами вместо детального ТЗ
PBR — это процесс (встреча), в течение которого уточняются элементы беклога (список требований по продукту. Это нужно, чтобы лучше понимать задачи в последующих спринтах.
Часто PBR проводится только командой и владельцем продукта, куда приносятся готовые требования от пользователей. Вместо этого организуйте совместный воршоп с командой, пользователями и заинтересованными лицами и напрямую уточните детали по элементам беклога у пользователей.
Чтобы встреча прошла эффективнее, пригласите фасилитатора, который построит формат встречи и проведет ее наиболее эффективно.
Формулируйте единую цель на спринт для всех участников на этапе планирования
Создание общей цели спринта на планировании спринта позволяет команде чувствовать совместную ответственность не за локальный кусочек задачи, а за результат по продукту в спринте и вклад в общую продуктовую цель. Избегайте постановки целей типа «Сделать все задачи». Вместо этого сфокусируйтесь на ценности для пользователя: «Сделать более удобный поиск по товарам, что позволит увеличить конверсию добавления в корзину на Х»
Как получить максимум?
Чтобы стать командой, стоит изменить парадигму поведения с «Я — Они», «руководитель — исполнители» на «Мы». Мы — команда, мы вместе идем к цели продукта.
Команда должна себя почувствовать активным участником процесса создания продукта для пользователей. Пусть идеи сотрудников лягут в ваш беклог как гипотезы, которые вы совместно впоследствии проверите.
Вначале вы можете столкнуться с сопротивлением: многие не привыкли к такому формату работы. Начните с малого. Обсудите «видение продукта» и сформулируйте продуктовые цели. Это позволит улучшить фокус команды на результат.
Фото: Flamingo Images / Shutterstock