Карточка запроса функции по интервью: проблема, контекст и обходной путь
Как оформить feature request по интервью: отделить предложенную функцию от проблемы, сохранить контекст, частоту, последствия, обходной путь и доказательства.
«Добавьте кнопку» — это начало разговора, а не готовое требование
Пользователь хорошо знает свою работу, но не обязан проектировать универсальное решение. Одна предложенная кнопка может скрывать потребность в контроле, скорости, совместной работе или снижении ошибки. Команде важно сохранить исходную просьбу и одновременно раскрыть задачу.
Карточка запроса не обещает разработку. Она помогает сравнивать сигналы и решать, что исследовать дальше. Не приписывайте частоту: «все просят» допустимо только при подтверждённом подсчёте по единому правилу.
Разведите сигнал, проблему и решение
Сохраните исходную формулировку
Запишите просьбу и таймкод без редакторского усиления. Укажите роль и сценарий обезличенно, если персональные данные не нужны для решения задачи.
Раскройте контекст действия
Что человек делал до затруднения, какой результат ожидал, что произошло вместо этого и каковы последствия? Просите недавний пример, а не прогноз будущего поведения.
Зафиксируйте обходной путь
Спросите, как задача решается сейчас: таблицей, ручной проверкой, другим сервисом или никак. Обходной путь показывает цену проблемы, но сам по себе не доказывает приоритет разработки.
Оставьте решение гипотезой
Запишите предложенную функцию отдельно и добавьте альтернативы для проверки. Решение попадёт в бэклог только после оценки ценности, охвата, сложности и стратегии команды.
Просьба добавить кнопку экспорта
Ниже — вымышленный учебный пример. Имена, условия и результаты приведены только для объяснения метода.
Добавьте кнопку «Отправить руководителю». Сейчас я копирую итог в письмо, потому что у него нет доступа к проекту.
Проблема может быть не в отсутствии кнопки, а в передаче результата человеку без доступа. Возможные решения шире: гостевая ссылка, экспорт, письмо или настройка прав.
Карточка должна сохранить исходную просьбу и контекст: итог нужен вне проекта; текущий обход — ручное копирование; риск — потеря форматирования или версии. Пример вымышленный.
| Поле | Что записать | Чего не делать |
|---|---|---|
| Исходная просьба | Дословная формулировка | Переписывать в готовое ТЗ |
| Контекст | Недавний сценарий и участники | Оставлять роль без задачи |
| Последствие | Время, ошибка или блокировка | Придумывать ущерб |
| Решения | Просьба и альтернативы | Обещать разработку |
Шаблон карточки feature request
Карточка подходит для первичной фиксации сигнала, а не заменяет исследование и спецификацию.
Идентификатор сигнала: Дата и источник: Роль пользователя: Исходная фраза / таймкод: Задача до затруднения: Контекст и участники: Что мешает: Последствия: Текущий обходной путь: Как часто наблюдалось: только подтверждённые данные: Предложенное решение: Альтернативные гипотезы: Что нужно проверить: Решение по следующему шагу:
Проверьте карточку до передачи в продукт
- Исходная просьба сохранена отдельно.
- Проблема описана через наблюдаемый сценарий.
- Частота не придумана по одному интервью.
- Нет обещания функции до принятия решения.
Разберём детали
Нужно ли включать имя клиента?
Только если это действительно требуется процессу и разрешено правилами работы с данными. Для анализа часто достаточно роли, сегмента и ссылки на защищённый источник.
Когда писать user story?
Когда команда уже понимает пользователя, задачу и границы будущего решения. Первичная карточка может предшествовать user story и не должна притворяться готовым требованием.