Запросы клиентов на новые функции

Просьба «добавьте кнопку» выглядит как готовое техническое задание. Но за одинаковой кнопкой могут стоять разные задачи, а одну задачу иногда решают настройкой, объяснением или исправлением существующего поведения. Если сразу отправлять каждую просьбу в разработку, продукт растёт быстрее, чем понимание его пользы.

Работа с заявками должна сохранять связь между словами пользователя, реальной проблемой и решением команды. Клиенту важно получить понятный ответ, а разработчикам — основание для выбора. Список пожеланий без контекста и статуса плохо решает обе задачи.

Сначала выясните рабочую ситуацию

Спросите, что человек пытался сделать, на каком шаге остановился и как справляется сейчас. Уточните частоту, затраченное время и последствия. Желательно увидеть последний пример, а не обсуждать только предполагаемое будущее использование.

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

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

Храните заявку и проблему раздельно

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

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

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

Отделите исправление от расширения продукта

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

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

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

Выберите следующее действие по силе подтверждений

Для заявки возможны разные шаги: уточнить проблему, проверить существующее решение, сделать небольшой эксперимент, включить в разработку, отложить или отказаться. Не обязательно выбирать только между немедленным выпуском и молчанием.

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

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

Просьба

Пользователь просит выгрузку в Excel, а по пятницам собирает список просроченных заказов. Варианты: выгрузка, отчёт или доступ к представлению.

Сообщения

Восемь обращений от трёх организаций: шесть от одной и по одному от двух. Это не восемь независимых подтверждений.

Сообщайте статус без скрытого обещания срока

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

Если срок не согласован, скажите об этом прямо и предложите доступный способ решить задачу сейчас. Когда обязательство уже включено в договор, его нельзя отменить простой сменой статуса: требуется согласование условий с клиентом.

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

Практическое задание

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