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