Вы пишете PRD на экспорт заказов. В документе есть разделы «область охвата» и «вне области». Что лучше всего записать во «вне области» для первой версии?
Как сформулировать аналитическую задачу, определить scope исследования и написать аналитический блок PRD. На собеседовании часто дают расплывчатый запрос вроде «почему упала конверсия» и ждут, что кандидат структурирует задачу: уточнит метрику, период, сегменты, возможные причины. Умение фреймить задачу — ключевой навык аналитика.
Всего в этом разделе 20 вопросов. Каждый — с правильным ответом и кратким разбором теории. Разбито на 4 части по 5 вопросов.
1Вы пишете PRD на экспорт заказов. В документе есть разделы «область охвата» и «вне области». Что лучше всего записать во «вне области» для первой версии?
AЭкспорт списка заказов с фильтрами по дате и текущему статусу заказа
BЭкспорт в PDF и автоматическая отправка отчёта по расписанию на почту
CКнопка скачивания CSV в интерфейсе общего списка заказов на странице
DТекст ошибки и логирование, если файл по какой-то причине не сформировался
Ответ: Раздел «вне области» фиксирует, что сознательно не делаем в этой итерации, чтобы защитить границы задачи.
В область охвата попадает то, что команда обязуется доставить в рамках текущего релиза. Во «вне области» выносится всё, что звучит похоже, но расширяет задачу и угрожает срокам или фокусу. Это помогает заранее согласовать ожидания со стейкхолдерами и избежать расползания границ задачи. Хороший PRD показывает, что исключено сейчас и почему, и что может вернуться позже как следующая итерация.
2Вы добавляете промокоды в корзину. Какой вариант лучше всего подходит для раздела «граничные случаи» в PRD (документ требований к продукту)?
AСписок технических задач для бэкенда: индексы базы данных, кэш промокодов и оптимизация запросов в корзине
BОписание визуальных правок: тексты на экране, размеры кнопок и анимации применения скидки в корзине
CИстёкший промокод, промокод уже использован, не подходит к категории, несколько кодов подряд, округление скидки
DСводная таблица бизнес-метрик: ожидаемый рост среднего чека, конверсии в покупку и доли заказов с промокодом
Ответ: Раздел «граничные случаи» перечисляет ошибочные и нестандартные сценарии, где логика часто ломается или трактуется по-разному.
Граничные случаи помогают заранее договориться, что делать в нестандартных ситуациях: что показать пользователю и как посчитать результат. Это снижает количество багов и спорных трактовок уже после релиза. Если граничные случаи не описаны, команда часто реализует «как получилось», и поведение становится непредсказуемым. Чем ближе фича к деньгам и правилам, тем важнее явно выписать граничные случаи и проверки корректности.
3В PRD (Product Requirements Document) вы полагаетесь на внешнее API, которое должно вернуть расчёт ETA доставки. Как лучше всего зафиксировать такое допущение, чтобы защитить область охвата проекта?
AЗафиксировать допущение, как и когда оно проверяется, и что команда делает при отказе: план B и влияние на охват
BНе писать допущение в документ, чтобы не пугать стейкхолдеров рисками и не замедлять обсуждение релиза заранее
CЗаписать допущение как факт: внешнее API будет доступно и стабильно к запуску, отдельный план B не требуется
DПеренести обсуждение допущений в раздел «вне области охвата» и больше не возвращаться, чтобы упростить документ
Ответ: Допущения нужно явно фиксировать и привязывать к рискам: что проверяем и как меняется область охвата при отказе.
Скрытые допущения часто превращаются в сюрпризы на интеграции и ломают сроки. В PRD полезно написать, на что вы рассчитываете, как быстро это можно подтвердить и какой запасной вариант предусмотрен. Тогда команда заранее понимает, что является блокером, и может управлять риском. Это также помогает честно согласовать область охвата и ожидания результата, а не догонять проблемы постфактум.
4Какой вариант больше всего похож на проверяемые критерии приёмки в формате условие/действие/результат?
AОписание: экран должен быть удобным и приятным, чтобы пользователь возвращался и рекомендовал приложение друзьям и знакомым
BОписание: добавить заметную кнопку с понятным текстом и разместить её в нижней части экрана согласно дизайн-системе
CОписание: дизайн соответствует брендбуку, иконки подготовлены, все тексты согласованы с редактором и проверены лидом
DЕсли пользователь авторизован и нажимает сохранить, изменения сохраняются; при отсутствии сети показываем ошибку без потери данных
Ответ: Формат «условие, действие, результат» помогает писать критерии приёмки как проверяемые сценарии, включая граничные случаи.
Хорошие критерии описывают условия, действие и ожидаемый результат, чтобы тестирование было однозначным. Важно включать не только основной сценарий, но и `edge cases`, например отсутствие сети или конфликт данных. Тогда команда заранее согласует поведение и минимизирует спорные решения на разработке. Такой стиль делает PRD практичным инструментом для проверки готовности.
5Заинтересованная сторона пишет: «Добавьте страницу FAQ про восстановление пароля». Какой вариант лучше всего формулирует постановку проблемы для PRD (Product Requirements Document)?
AСрочно сделать страницу FAQ и добавить туда ответы примерно на двадцать самых частых вопросов о восстановлении пароля пользователями
BНарисовать новый экран восстановления пароля и согласовать тексты с юристами в едином стиле с другими разделами личного кабинета
CВнедрить ассистента в чат поддержки, который сам отвечает на типовые вопросы о восстановлении пароля и снимает часть нагрузки на операторов
DРастёт доля незавершённых восстановлений доступа и нагрузка на поддержку: нужно снизить отвал без ухудшения безопасности входа
Ответ: Хорошая постановка проблемы описывает саму проблему, аудиторию и последствия, а не готовое решение или конкретную фичу.
Постановка проблемы отвечает на вопрос, что не так и почему это важно: боль пользователя, влияние на бизнес и контекст. Формулировка решения вроде «сделать FAQ» может быть одним из вариантов, но она не объясняет, какая именно проблема решается. Когда проблема сформулирована, легче выбрать область охвата, не-цели и тестируемые критерии приёмки. Это снижает риск сделать красивую фичу, которая не влияет на реальную боль.