Совет для продакт-менеджеров: связывайте бэклоги продукта с концепцией продукта

Одной из постоянных задач для гибкой команды разработчиков, ориентированных на продукт, является сопоставление того, что они делают «прямо сейчас», с тем, во что продукт должен превратиться, скажем, через 2-3 года.

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

Возьмем пример из реальной жизни.

Я был частью гибкой команды, которая пыталась внедрить службу перевода текста для содержимого сайта . Решение было принято, и был использован сторонний инструмент машинного перевода. Однако в дорожной карте продукта в конечном итоге упоминалось, что в будущем пользователи должны иметь возможность исправлять и предоставлять свой собственный контекстный перевод, а это означало, что возможность перевода должна иметь искусственный интеллект , чтобы он мог учиться самостоятельно на основе обратной связи.
Учитывая такое развитие событий, сделанный выбор не был удачным и, следовательно, потребовал значительной доработки, потому что общая картина не была связана с тем, что agile-команда должна была решить в спринте.

Можно возразить, что команды могут предпринять сознательные усилия для получения этой информации, но вопрос в том, почему эти «долгосрочные» цели нельзя зафиксировать в существующих agile-инструментах и ​​информационных панелях?

Agile-команды выполняют четко определенные и конкретные задачи в цикле разработки, но означает ли это, что это должно происходить за счет безразличия к эволюции продукта? Нет, я так не думаю.

Насколько мне известно, не существует быстрого инструмента или фреймворка, который бы отстаивал или рекомендовал эту информацию agile-команде в их повседневном функционировании, но можно ли создать такое представление в существующем представлении? Стоит попробовать? Давайте посмотрим, как мы можем это сделать.

Мы начнем с самого распространенного артефакта в agile — бэклога продукта.
Согласно Институту SCRUM, бэклог продукта — это список вещей, которые необходимо сделать в проекте. Эти вещи могут включать в себя улучшения и/или ошибки. Нумерованный список бесполезен, если команда не знает, какова структура приоритетов элементов. Здесь в дело вступает владелец продукта , который несет общую ответственность за работу с заинтересованными сторонами, чтобы получить четкие требования, устранить взаимозависимости и получить список приоритетов для элементов невыполненной работы по продукту.

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

С другой стороны, элементы бэклога продукта также сопоставляются с «истинным севером» продукта, который часто называют видением продукта. Это желаемое состояние продукта, которое часто достигается за счет выпуска нескольких версий и тесно связано с тем, чего хочет целевая аудитория или клиенты, и с ценностью, которую он им приносит.

Эта цепочка элементов, связывающая agile-команду с клиентами (включая невыполненные работы по продукту и видение), может быть представлена ​​следующим образом:

Дистанционная связь между agile-командой и тем, что нужно заказчику…

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

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

Как следует из названия, PVM представляет собой матрицу, в которой столбцы представляют размеры (от микро до макро), которые захватываются. Давайте разберемся с PVM с помощью приложения для заказа еды, цель которого состоит в том, чтобы предоставить пользователям опыт еды, а отправной точкой является заказ еды. Образец матрицы выглядит следующим образом:

Матрица видения продукта может иметь следующие поля:

• Версия продукта: это версия продукта, которая является официальной вехой выпуска и часто является тем, что получает клиент.
• Big Rock Item: это категория или тема, к которой относится функция. Эти элементы также могут быть областями долгосрочной потребности в продукте в видении продукта.
• Функция: это функция продукта, которая находится в разработке. Объект может принадлежать одной или нескольким темам (крупные камни).
• Идентификатор спринта: это номер спринта, в котором разрабатывается функция.
• Статус разработки: в этом поле отображается ход разработки (запланировано, проектирование завершено, разработка завершена, протестировано и выпущено).

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

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

Изучайте онлайн- курсы по управлению продуктами в лучших университетах мира. Заработайте программы Masters, Executive PGP или Advanced Certificate Programs, чтобы ускорить свою карьеру.

Избранная программа для вас: программа сертификации дизайнерского мышления от Duke CE