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

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

Почему хороший отказ важен не меньше, чем хороший релиз?

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

Что заставляет отказ приземлиться плохо?

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

Что реально должен говорить хороший отказ?

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

Привет, Джейми,

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

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

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

Чем это отличается от замыкания цикла на выпущенной функции?

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

Должен ли отказ быть публичным, как статус на публичном roadmap?

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

Заслуживает ли каждый отклонённый запрос индивидуального ответа?

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

FAQ

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

Должен ли отказ когда-либо обещать пересмотреть запрос позже? Только если это реально вероятно и есть механизм реально его пересмотреть — например, метка, поднимающая его снова на цикле планирования. Расплывчатое «будем иметь в виду» без такого механизма функционально то же самое, что молчание, только сформулированное добрее.

Что если честная причина — то, чем компания не может поделиться, например конкурентная озабоченность? Скажите это прямо, вместо того чтобы придумывать более мягкую причину. «Мы не можем поделиться конкретным обоснованием здесь, но это не то, что мы планируем строить» честнее, и вызывает больше уважения, чем выдуманное объяснение, разваливающееся при уточняющем вопросе.

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

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

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