Владельцы продукта имеют дело с довольно непростой задачей: обработка многочисленных отзывов из разных источников, перевод этих отзывов в удобоваримый формат, передача команде продукта. Отзывы - это важнейшая часть жизненного цикла продукта. Итерационный процесс разработки невозможен без отзывов. Мы уже говорили об этом в статье по организации сбора отзывов несколько недель назад. Но что делать, если отзывов слишком много? В этом случае бэклог продукта быстро становится раздутым и неуправляемым. А если владелец продукта перестает управлять бэклогом, он теряет контроль над будущим продукта.
Давайте сортировать
Как только на ваш продукт обрушился поток отзывов, пора принимать меры. Отзывы должны всегда идти напрямую от пользователей, для этого можно использовать такие инструменты как Bonfire, JIRA Issue Collectors, и JIRA Mobile Connect. Мы в Atlassian используем JIRA для работы с отзывами, пользователь может добавить отзыв напрямую в JIRA через https://jira.atlassian.com. Не все оставленные отзывы имеют какую-то ценность. Организуйте простую процедуру сортировки входящих отзывов. Необходимо вчитаться в каждую часть отзыва и понять, является ли отзыв:
- Обоснованным: “Когда я кликаю по кнопке X, я ожидаю события Y, но происходит событие Z”
- Уникальным: возможно, похожий отзыв уже в работе.
- Существенным для продукта: “Должна быть другая кнопка для функции X”
- Слишком затратным для реализации: “При нажатии esc броузер должен сохранять введенные в форму данные, на случай если я захочу повторно их использовать”
- Противоречащим принятому решению – команда продукта приняла решение, что работать функция должна именно так, а не иначе. Отзывы, касающиеся таких вещей, должны быть внимательно изучены.
Если бэклог продукта замусорен отзывами, по которым непонятно что делать и надо ли вообще что-то делать, вам сложно будет двигаться вперед. Отправьте малоприменимые отзывы на долговременную стоянку. Мы закрываем такие запросы с соответствующей резолюцией. Закрытый запрос - это на потерянный запрос! Среди закрытых запросов можно искать, делать выборку,также как и среди открытых. Короткие резолюции делают поиск среди закрытых запросов гораздо эффективнее. Не стоит удалять отзыв, который вы сочли малоприменимым, ведь, возможно, вам захочется к нему вернуться. Стоит потратить на такой отзыв немного времени, чтобы позже его можно было легко найти. Поля JIRA для резолюций могут быть настроены так, чтобы удовлетворить любой из описанных выше случаев. Эпики, компоненты и метки позволят отследить те вопросы, которые в будущем могут потребовать пересмотра.
Разложим по полочкам
Каждый рассматриваемый запрос отнимает время. Команда JIRA использует трехуровневый бэклог, чтобы разделить стадии прохождения отзывов.
Если детализировать схему, приведенную выше, то вместо единой области "passes review" (отзывов прошедших проверку) появятся еще два уровня.
На стадии необработанных (raw) отзывов, владелец продукта решает, стоит ли сохранить или пропустить отзыв. Если отзыв сохранен, то он попадает в категорию неприоритизированных. Это означает, что владелец продукта собирается что-то делать по поводу этого отзыва рано или поздно, но пока отзыв не может быть передан разработчикам. Как только владелец продукта решил дать дорогу отзыву, отзыв перемещается в очередь отзывов, готовых для аналитики. Эта очередь плотная, упорядоченная, из нее можно быстро набрать функций для очередного спринта.
Что случается, когда очередь отзывов, готовых для аналитики, редеет? Владельцу продукта надо просто протолкнуть вперед немного неприотизированных отзывов. Не нужно пересматривать весь бэклог, ведь есть выделенный набор запросов, ожидающих рассмотрения. Вместо того, чтобы просматривать сотни или тысячи потенциальных запросов, владелец продукта просматривает гораздо меньший набор.
GreenHopper - не только для разработчиков
GreenHopper - это Agile-плагин для JIRA. Многие команды разработчиков используют его, чтобы отслеживать свою работу по методологии agile. Владельцы продукта тоже могут использовать GreenHopper, чтобы отслеживать бэклог. PM команда JIRA для отслеживания бэклога использует Канбан-доски GreenHopper. Система Канбан - это процессный подход, поэтому легко отслеживать путь запроса от отзыва до функции. Обратите внимание, это отдельная Канбан-доска, не та, которую используют разработчики.
Дорожная карта бэклога JIRA имеет четыре состояния:
- Еще не готов – сырой отзыв
- Не обработан – добавлен в бэклог, но не готов для передачи в разработку
- Готов для аналитики – команда аналитиков в первую очередь должна работать над заявками с высоким приоритетом
- В разработке – ведется активная работа над функцией
Команда PM группирует запросы по Эпикам так, чтобы все связанные запросы были расположены рядом на экране. Группы могут быть легко свернуты, таким образом в случае необходимости PM смогут сфокусироваться на одном Эпике. Это помогает PM быстро пробегать весь бэклог.
Готовы перестроить свой бэклог? Попробуйте GreenHopper!