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