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