Как отслеживать запросы на функции, не теряя их

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

Откуда на самом деле берутся запросы на функции?

Из большего числа каналов, чем учитывает большинство систем отслеживания. Тикет поддержки с «было бы неплохо, если». Комментарий на публичном roadmap. Звонок продажников, где потенциальный клиент называет ту самую вещь, которая блокирует сделку. Виджет в продукте. У каждого канала своя владелица и свои инструменты, и именно поэтому запросы рассеиваются: очередь тикетов поддержки и бэклог продуктовой команды редко бывают одной и той же системой, а запрос, дошедший только до одного из них, на практике дошёл только до одного отдела.

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

Что на самом деле ломает отслеживание запросов на функции?

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

Второй сбой опаснее, потому что кажется, будто отслеживание работает. Запросы регистрируются. Ничего не выглядит сломанным, пока кто-нибудь не спросит «сколько людей просили X», и честный ответ — «нам пришлось бы прочитать все 400 строк, чтобы узнать».

Что на самом деле должен фиксировать запрос на функцию?

Достаточно, чтобы позже ответить на три вопроса, не перечитывая исходное сообщение: что было запрошено, по возможности собственными словами того, кто попросил; кто попросил, и как с ним связаться, если ответ в итоге — «мы это построили»; и что нужно знать, чтобы понять, обычный это запрос или единичный случай. Дословная цитата ценнее пересказа, потому что пересказ, написанный тем, кто триажировал запрос, уже несёт в себе его собственное прочтение — и именно это прочтение второй человек не сможет проверить шесть месяцев спустя.

Какие метки того стоят?

Две, и они отвечают на разные вопросы. Метка типа отделяет запрос на функцию от отчёта об ошибке, потому что обоим нужны разные владелицы и сроки, а смешивание их в одной очереди даёт самым громким жалобам обгонять запросы. Метка приоритета, ограниченная небольшим набором вроде low, medium и high, отделяет «блокирует кому-то использование продукта» от «было бы приятно», потому что оба заслуживают очень разного времени ответа, и ни один не должен наследовать темп другого. Правильная установка метки типа предполагает, что запрос — то, чем он себя называет; когда запрос на функцию на самом деле — отчёт об ошибке разбирает случай, когда собственные слова клиентки направляют эту метку в неверную сторону.

Автоматизированный триаж может применить обе в момент прихода запроса. В changeloop отправка через виджет получает метку feature-request или bug и метку priority:low|medium|high за один проход, плюс тег from-widget, чтобы источник был виден без открытия элемента. Этого достаточно, чтобы фильтровать бэклог за минуту вместо целого дня: покажи мне каждый высокоприоритетный запрос на функцию, пришедший через виджет в этом месяце.

Третья метка стоит того, как только появляется публичный roadmap: статус, который тот, кто попросил, может проверить сам. Публичный roadmap целиком разбирает статусы planned, building и shipped; коротко — эта метка превращает приватную очередь в то, что попросивший может посмотреть, не спрашивая снова.

Как решить, что строить дальше?

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

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

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

Как замкнуть цикл, когда что-то выпущено?

Это шаг, который системы отслеживания пропускают чаще всего, и тот, что попросившие действительно замечают. Замыкание цикла обратной связи с клиентом целиком разбирает механику; здесь важно то, что замыкание цикла работает только если исходный запрос остался связан с тем, кто его сделал. Шаблон запроса на функцию, построенный из GitHub issue, с привязкой личности попросившего к самому issue, а не спрятанной в комментарии — вот что делает возможным автоматическое уведомление «выпущено» вместо того, которое кто-то должен вспомнить отправить. Шаблон запроса на функцию показывает конкретный шаблон и назначение каждого поля.

FAQ

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

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

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

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

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

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