Как приоритизировать растущий поток запросов на функции

Отслеживание запросов на функции решает вопрос, где они живут. Оно не решает, какой выйдет первым, и именно на этом втором вопросе команды реально застревают. Бэклог из трёхсот сгруппированных, помеченных запросов всё равно нуждается в правиле решения, потому что “строй самое запрашиваемое” работает только пока два запроса близки, а у третьего есть громкая сторонница — а так бывает большинство недель. Фреймворки ниже — не конкурирующие ответы на один вопрос. Каждый подходит своему типу запроса, и использовать один для всех — обычно и есть настоящая ошибка.

Чем приоритизация запросов на функции отличается от приоритизации roadmap?

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

Что такое RICE, и работает ли он для запросов на функции?

RICE оценивает идею по охвату, влиянию, уверенности и усилию, затем делит первые три на четвёртое, чтобы получить сравнимое число. Он был создан для идей roadmap, в которые команда уже верит, где сложная часть — сравнивать разные ставки друг с другом. Запросы на функции уже приходят с числом охвата — счётом людей, попросивших об этом, — что конкретнее, чем охват, который обычно есть у свежей идеи roadmap. Место, где RICE напрягается с запросом, — уверенность и влияние: команда может быть уверена, что запрос реален, и всё же не иметь основы, насколько сильно он сдвинет метрику, потому что “влияние” для запроса, у которого уже есть название и след реальных пользователей, — это другой тип оценки, чем влияние идеи, которую никто за пределами комнаты ещё не видел.

Используй RICE для запросов, которые серьёзно рассматриваются и ещё не решены. Не применяй его к каждому входящему запросу; усилие на оценку окупается только на тех, что достаточно близки, чтобы нужен был тайбрейкер.

Взвешивать по доходу, или по тому, кто просил?

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

Какую роль на самом деле играют голоса?

Дешёвый, непрерывный сигнал для уже существующих запросов, и плохой способ узнать, какие запросы вообще должны существовать. Счёт голосов достигает только пользователей, уже нашедших запрос и посчитавших его достойным клика, а это значит, что сумма голосов публичной roadmap отражает видимость не меньше, чем спрос: старый запрос ближе к верху списка продолжает собирать голоса отчасти потому, что его легко найти, а более новый, столь же реальный запрос начинает с нуля. Статья о публичной roadmap предлагает вообще не показывать голоса на roadmap. Относись к голосам как к сигналу, который нужно группировать и взвешивать по свежести, а не как к рейтингу, который строят по порядку. Тикеты поддержки vs. запросы функций разбирает другое слепое пятно в счёте голосов: реальный разрыв может генерировать почти никаких голосов, если сталкивающиеся с ним пользователи никогда не находят доску, при этом громко проявляясь в поддержке.

Когда побеждает самый громкий клиент, и это проблема?

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

Как решение о приоритизации превращается в ответ?

Каждое решение здесь порождает победителей и проигравших, и оба заслуживают ответа, называющего реальную логику, а не просто смену статуса без объяснения. Как отказать в запросе на функцию разбирает, что говорить проигравшему запросу, способом, сохраняющим отношения нетронутыми, вместо того чтобы звучать как типовой отказ. Работа по группировке и маркировке, делающая всё это возможным с самого начала, разобрана в отслеживании запросов на функции; приоритизация работает только на запросах, уже зарегистрированных и сгруппированных достаточно хорошо, чтобы их можно было сравнивать.

FAQ

Какой фреймворк лучше всего подходит для приоритизации запросов на функции? Ни один сам по себе. Используй грубые счета, чтобы найти самый громкий сигнал, RICE — чтобы сравнить короткий список серьёзных кандидатов, и проверку по доходу или аккаунту — чтобы поймать случаи, когда тихий спрос от стратегического аккаунта перевешивает более громкую, но менее важную группу.

Стоит ли приоритизировать запросы на функции так же, как идеи roadmap? Нет. Идеи roadmap начинаются со стратегии; запросы на функции начинаются с уже существующего спроса. Оценивая их вместе, хорошо обоснованная стратегическая ставка с небольшим существующим спросом стабильно проигрывает запросу, у которого просто больше людей его попросили.

Точно ли голоса на публичной roadmap отражают спрос? Только среди людей, уже нашедших запрос. Более старые, более заметные запросы собирают голоса быстрее, независимо от того, сколько реального спроса стоит за более новым, так что относись к суммам голосов как к сигналу, сгруппированному и взвешенному по свежести, а не как к рейтингу, который строят по порядку.

Как часто нужно пересматривать приоритеты запросов на функции? По фиксированному циклу, а не только когда кто-то эскалирует. Ежемесячный или ежеквартальный проход, перегруппирующий запросы и перепроверяющий взвешивание, ловит дрейф — вроде горстки аккаунтов, доминирующих в том, что выпускается, — который чисто реактивный процесс никогда не выявляет сам.

Технические утверждения в этой статье не проходили независимую проверку. Если здесь что-то не так, сообщите нам, и мы исправим.

По теме на changeloop: Документация для разработчиков, Сравнение инструментов changelog