Когда запрос на функцию на самом деле — отчёт об ошибке
4 мин чтения
«Можете добавить настройку, увеличивающую лимит экспорта?» читается как запрос на функцию, и большинство систем триажа сразу так его помечают. Иногда так и есть. Иногда экспорт падает на числе ниже документированного лимита из-за ошибки, и клиентка, не видя код, придумала самое правдоподобное решение, какое может описать: дайте мне число побольше, и, может, заработает. Какие метки того стоят разбирает метку типа, которая делит бэклог на запросы на функции и ошибки; это случай, когда собственные слова клиентки направляют метку в неверную сторону, а цена ошибки — медленный дрейф к бэклогу, полному запросов, которых никто на самом деле не хочет, стоит только заглянуть под них.
Как выглядит запрос на функцию, который на самом деле — ошибка?
Он называет обходной путь вместо проблемы. Настоящий запрос на функцию обычно описывает результат, который продукт вообще не поддерживает: «дайте мне запланировать это на потом», «добавьте тёмный режим». Неверно классифицированная ошибка описывает конкретное число, порог или поведение, которое звучит как отсутствующая настройка, но на самом деле является симптомом: «увеличьте timeout», «добавьте опцию повторной попытки», «дайте мне экспортировать больше строк за раз». Признак в том, что просительница предлагает реализацию, настройку, переключатель, переопределение, вместо того чтобы описать цель, потому что она уже попробовала функцию как документировано, и та не сделала того, что документация обещает.
| Сигнал | Запрос на функцию | Ошибка, замаскированная под запрос на функцию |
|---|---|---|
| Что описывает просительница | Результат, которого продукт не может дать | Параметр, который она хочет изменить |
| Покрывает ли это уже документированное поведение | Нет, действительно отсутствует | Да, но работает не так, как документировано |
| Исчезает ли запрос при больших усилиях | Нет | Иногда, если ошибка зависит от порога |
| Куда должно направляться | Бэклог продукта | Очередь ошибок |
Почему это важнее, чем кажется?
Потому что у двух очередей разные владелицы, сроки и критерии успеха, и ошибка, заведённая как запрос на функцию, приоритизируется против запросов на функции, конкурируя за внимание с настоящими пробелами продукта вместо того, чтобы быть исправленной в срок, которого заслуживает ошибка. Как отслеживать запросы на функции разбирает, почему смешивание ошибок и функций в одной очереди позволяет самым громким жалобам обгонять настоящие запросы; запрос на функцию, тайно являющийся ошибкой, наносит обратный вред, остаётся в бэклоге продукта, собирая голоса за «функцию», которая исчезла бы, как только базовая ошибка была бы исправлена, что тратит впустую сигнал приоритизации для всех, кто читает этот бэклог.
Как отличить, когда собственные слова клиентки указывают в неверную сторону?
Спросите, чего она ожидала, а не что хочет, чтобы вы добавили. «Экспорт упёрся в 500 строк, а мне нужно 2000, можете поднять лимит» звучит как запрос на функцию повышения лимита, пока уточняющий вопрос, «500 — это документированный лимит», не раскрывает, что документированное число было 5000, и экспорт падает раньше времени. Только этот один вопрос, чего она ожидала против того, что произошло, выполняет большую часть работы по сортировке, потому что у настоящего запроса на функцию нет документированного поведения, которому он не соответствует; нечего ожидать, потому что возможности ещё не существует.
Должны ли это решать агенты поддержки или инженерки?
Агенты поддержки делают первый проход, потому что видят тикет первыми, но метка должна быть легко изменяемой и дёшево ошибочной, а не разовым решением, которое навсегда закрепляет элемент в неверной очереди. Лёгкая вторая проверка, инженерка, еженедельно просматривающая новые метки «запрос на функцию» на предмет всего, что пахнет замаскированной ошибкой, ловит те случаи, которые агент поддержки без контекста кодовой базы не смог бы распознать. Это не обязательно формально; это скорее пятиминутный взгляд, чем процесс ревью.
Меняется ли закрытие цикла после нахождения настоящей ошибки?
Да, и это улучшает сообщение, которое вы можете отправить. Закрытие цикла обратной связи с клиентом разбирает уведомление просительницы, когда её просьба выполнена; переклассифицированная ошибка получает лучшую версию этого сообщения, потому что «мы нашли и исправили ошибку за этим» звучит как компетентность, тогда как «мы построили функцию, которую вы просили» было бы правдой только случайно, потому что настоящий запрос на функцию, действительно более высокий лимит экспорта, может никогда не быть построен, как только ошибка исчезнет, а исходного лимита в 5000 строк окажется достаточно.
Что происходит, если неверная классификация никогда не замечена?
Бэклог заполняется запросами, которые выглядят как настоящий спрос, но им не являются, и решения о приоритизации, принятые против этого бэклога, наследуют искажение. «Функция» с сорока голосами может на самом деле быть сорока людьми, натыкающимися на одну и ту же ошибку, и построение буквального запроса, настройки для повышения лимита, который никогда на самом деле не был ограничением, доставляет сложность, которая ничего не исправляет, пока базовая ошибка продолжает порождать новые «запросы на функции» от клиенток, которые ещё не нашли эту ветку.
FAQ
Стоит ли добавлять формальный шаг для проверки каждого запроса на функцию на известные ошибки? Не формальный шаг, скорее привычку: кто бы ни триажировал новый запрос на функцию, должен спросить «уже ли документированное поведение утверждает, что делает это», прежде чем применять метку, потому что только этот вопрос ловит большинство неверных классификаций без добавления процессной нагрузки.
Что если клиентка настаивает, что это запрос на функцию, даже после того как ошибка найдена? Объясните, что вы нашли и почему предложенная ею настройка больше не понадобится, как только ошибка исправлена. Большинство клиенток просят обходной путь, потому что предполагали, что настоящее исправление недоступно, а не потому что конкретно хотели эту настройку.
Теряет ли переклассифицированный элемент голоса или комментарии, собранные как запрос на функцию? Он должен сохранить их, видимыми, потому что эти голоса — доказательство, которое привело к нахождению ошибки в первую очередь, а скрытие этого следа затрудняет обнаружение той же неверной классификации в следующий раз, на другом тикете.
Может ли это случиться наоборот, отчёт об ошибке, который на самом деле является запросом на функцию? Реже, но да: «это сломано» иногда означает «это не делает того, что я предполагала, что оно будет делать», что является отсутствующей возможностью, а не дефектом. Тот же вопрос, чего ожидала против того, что документировано, сортирует и в эту сторону.
Технические утверждения в этой статье не проходили независимую проверку. Если здесь что-то не так, сообщите нам, и мы исправим.