Постановка задачи и PRD: вопросы для собеседования (часть 3)
Как сформулировать аналитическую задачу, определить scope исследования и написать аналитический блок PRD. На собеседовании часто дают расплывчатый запрос вроде «почему упала конверсия» и ждут, что кандидат структурирует задачу: уточнит метрику, период, сегменты, возможные причины. Умение фреймить задачу — ключевой навык аналитика.
Вопросы 11–15 из 20
11Вы добавляете возможность смены email в профиле. Что из перечисленного лучше всего положить в раздел `edge cases` PRD (Product Requirements Document)?
AПользователь меняет email и видит обновлённый адрес в профиле
BПостроить график миграции пользователей на новый экран профиля
CEmail уже занят другим аккаунтом, ссылка подтверждения истекла, пользователь вошёл через SSO и не имеет пароля, два запроса на смену email подряд
DУвеличить активность пользователей в профиле и снизить отток
Ответ: `Edge cases` — это граничные ситуации и ошибки, которые важно заранее описать, чтобы реализация была предсказуемой.
Смена email связана с безопасностью и идентичностью, поэтому у неё много граничных сценариев. Если `edge cases` не описаны, команда может реализовать поведение на своё усмотрение, и позже это будет трудно исправлять. В PRD (Product Requirements Document) полезно перечислить спорные ситуации и ожидаемую реакцию системы. Затем эти пункты превращаются в конкретные `acceptance criteria` и проверки.
12В чём наиболее точная разница между `acceptance criteria` и тест-кейсами, если вы пишете PRD (Product Requirements Document)?
A`Acceptance criteria` — это список задач разработки, а тест-кейсы не нужны
BТест-кейсы описывают цели бизнеса, а `acceptance criteria` описывают идеи
CЭто одно и то же, можно оставлять любой один раздел
D`Acceptance criteria` описывают, что должно быть верно для принятия фичи (что и при каких условиях), а тест-кейсы — как именно это проверять шаг за шагом
Ответ: `Acceptance criteria` задают критерий приёмки результата, а тест-кейсы — процедурные шаги проверки.
В PRD (Product Requirements Document) полезно держать `acceptance criteria` компактными и ориентированными на поведение продукта, чтобы их понимали все роли. Тест-кейсы обычно детальнее и могут жить в тест-плане или системе тестирования. Если смешать эти уровни, PRD (Product Requirements Document) превращается в перегруженный документ или, наоборот, теряет проверяемость. Чёткое разделение повышает качество и снижает риск споров о готовности.
13Вы пишете PRD (Product Requirements Document) на напоминания об оплате счёта. Что лучше всего сформулировать как `non-goals` для первой версии?
AОтправлять одно напоминание пользователю за 24 часа до даты оплаты
BНе делаем автосписание и не внедряем интеграции со сторонними банками в первой версии
CУвеличить долю оплат на 15% за квартал
DСделать дизайн экрана напоминаний в стиле iOS
Ответ: `Non-goals` помогают явно исключить близкие по смыслу расширения и защитить `scope` от расползания.
Напоминания легко превратить в большой проект про платежную инфраструктуру и автосписания. Если это не цель текущей итерации, это нужно явно обозначить как `non-goals`. Тогда команда может сфокусироваться на доставке базовой ценности и тестируемых `acceptance criteria`. При этом в документе можно указать, что расширение возможно позже, но оно не является обязательством текущего релиза.
14Команда получила задачу «ускорить загрузку ленты». Какой вариант лучше всего подходит как измеримые `acceptance criteria`?
AЛента должна загружаться быстрее и ощущаться плавной
BПользователь должен быть доволен скоростью, без конкретных цифр
CНужно оптимизировать backend и уменьшить количество запросов
D`acceptance criteria`: `p95_feed_load_time` не выше 2 секунд на 4G для поддерживаемых устройств; при медленной сети показываем скелетон и не блокируем скролл
Ответ: Лучшие `acceptance criteria` измеримы и проверяемы, а не описывают намерение или способ реализации.
Фразы «быстрее» и «плавно» звучат понятно, но без порогов не дают критерия готовности. В PRD важно описать результат: какие значения считаются приемлемыми и что должен видеть пользователь в плохих условиях как `edge cases`. Отдельно полезно не фиксировать способ решения, чтобы команда могла выбрать оптимальный подход. Тогда проверка качества становится однозначной.
15Вы делаете `guest checkout` (покупка без регистрации). Что наиболее корректно описать в разделе `scope` для MVP?
AПокупка без создания аккаунта с вводом email и телефона, но без истории заказов и без программы лояльности
BПолная миграция профиля, бонусов и персональных рекомендаций для гостей
CПереработка каталога и поиска, чтобы гостям было удобнее
DИнтеграция с корпоративными кабинетами и закупками
Ответ: `Scope` MVP должен описывать минимальный набор поведения, который решает проблему и не раздувает релиз.
Для `guest checkout` ценность обычно в том, чтобы убрать барьер регистрации и дать завершить покупку. История заказов и лояльность — полезные расширения, но это другой слой продукта и может быть вынесен в `non-goals`. Хороший `scope` фиксирует границы: что поддерживаем сейчас и каких зависимостей избегаем. Это помогает команде не расширять задачу до «переделаем весь аккаунт».
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в TelegramДругие темы: Продуктовая аналитика