Постановка задачи и PRD: вопросы для собеседования (часть 3)
Как сформулировать аналитическую задачу, определить scope исследования и написать аналитический блок PRD. На собеседовании часто дают расплывчатый запрос вроде «почему упала конверсия» и ждут, что кандидат структурирует задачу: уточнит метрику, период, сегменты, возможные причины. Умение фреймить задачу — ключевой навык аналитика.
Вопросы 11–15 из 20
11Вы добавляете возможность смены email в профиле. Что из перечисленного лучше всего положить в раздел граничных случаев PRD (Product Requirements Document)?
AСписок граничных ситуаций: email уже занят, ссылка подтверждения истекла, вход через SSO без пароля, два запроса на смену email подряд
BПеречень внутренних команд и зон ответственности по маркетингу, поддержке и разработке функции смены email
CОписание основной счастливой траектории: пользователь меняет email и видит обновлённый адрес в профиле сразу после подтверждения
DБизнес-цели и ожидаемые эффекты запуска: рост активности в разделе профиля и снижение оттока пользователей за квартал
Ответ: Граничные случаи — это нестандартные ситуации и ошибки, которые важно заранее описать, чтобы реализация была предсказуемой.
Смена email связана с безопасностью и идентичностью, поэтому у неё много граничных сценариев. Если эти ситуации не описаны, команда может реализовать поведение на своё усмотрение, и позже это будет трудно исправлять. В PRD (Product Requirements Document) полезно перечислить спорные ситуации и ожидаемую реакцию системы. Затем эти пункты превращаются в конкретные критерии приёмки и проверки.
Подробный разбор → 12В чём наиболее точная разница между критериями приёмки и тест-кейсами, если вы пишете PRD (Product Requirements Document)?
AКритерии приёмки задают список задач разработки на спринт, а тест-кейсы для проверки фичи отдельно не нужны
BКритерии приёмки описывают, что должно быть верно для принятия фичи, а тест-кейсы фиксируют шаги проверки этих условий
CТест-кейсы фиксируют цели бизнеса и продуктовые гипотезы, а критерии приёмки задают идеи и направления для будущих экспериментов
DКритерии приёмки и тест-кейсы по смыслу совпадают, поэтому в PRD можно оставлять любой один раздел из двух
Ответ: Критерии приёмки задают условия принятия результата, а тест-кейсы описывают процедурные шаги проверки.
В PRD (Product Requirements Document) полезно держать критерии приёмки компактными и ориентированными на поведение продукта, чтобы их понимали все роли. Тест-кейсы обычно детальнее и могут жить в тест-плане или системе тестирования. Если смешать эти уровни, PRD превращается в перегруженный документ или, наоборот, теряет проверяемость. Чёткое разделение повышает качество и снижает риск споров о готовности.
Подробный разбор → 13Вы пишете требования к продукту на напоминания об оплате счёта. Что лучше всего сформулировать как явно исключённую из релиза область для первой версии?
AОдно напоминание пользователю за 24 часа до даты оплаты как часть рабочего сценария первой версии
BАвтосписание и интеграции со сторонними банками отнесены за границы релиза первой версии
CЦель увеличить долю успешных оплат на 15% за квартал как бизнес-метрика релиза
DДизайн экрана напоминаний в стиле iOS как требование к интерфейсу первой версии
Ответ: Явно исключённые области помогают защитить границы релиза и не дают близким по смыслу расширениям расползаться по проекту.
Напоминания легко превратить в большой проект про платёжную инфраструктуру и автосписания. Если это не цель текущей итерации, нужно явно обозначить такие пункты как исключённые из релиза. Тогда команда фокусируется на доставке базовой ценности и тестируемых критериев приёмки. В документе можно указать, что расширение возможно позже, но оно не является обязательством текущего релиза.
Подробный разбор → 14Команда получила задачу «ускорить загрузку ленты». Какой вариант лучше всего подходит как измеримые критерии приёмки?
AЗафиксировать порог: `p95_feed_load_time` ≤ 2 секунд на 4G, на медленной сети показывать скелетон без блокировки
BЛента должна загружаться быстрее обычного и ощущаться плавной для большинства пользователей в типичных условиях работы
CПользователь должен быть доволен скоростью открытия ленты, без конкретных пороговых значений и описаний крайних случаев
DКоманде нужно оптимизировать серверную часть и уменьшить число запросов, тогда лента ускорится сама без явных целей
Ответ: Критерии приёмки должны быть измеримы и проверяемы, а не описывать намерение или выбранный способ реализации.
Фразы «быстрее» и «плавно» звучат понятно, но без порогов не дают критерия готовности. В требованиях важно описать ожидаемый результат: какие значения считаются приемлемыми и что должен видеть пользователь в плохих условиях, то есть в крайних случаях. Отдельно полезно не фиксировать способ решения, чтобы команда могла выбрать оптимальный подход. Тогда проверка качества становится однозначной.
Подробный разбор → 15Вы делаете `guest checkout` (покупка без регистрации). Что наиболее корректно описать в области задачи для MVP?
AПолная миграция профиля, бонусов и персональных рекомендаций для гостей с автоматическим созданием аккаунта на этапе оплаты
BГлубокая переработка каталога и поиска под гостей, чтобы они не видели разделы, доступные только зарегистрированным пользователям
CПокупка без создания аккаунта с вводом email и телефона, но без истории заказов и без программы лояльности на этом этапе
DИнтеграция с корпоративными кабинетами, закупочными процедурами и выгрузкой документов в учётные системы клиентов
Ответ: Область MVP должна описывать минимальный набор поведения, который решает проблему и не раздувает релиз.
Для `guest checkout` ценность обычно в том, чтобы убрать барьер регистрации и дать завершить покупку. История заказов и программа лояльности — полезные расширения, но это другой слой продукта и может быть вынесен из текущей области задачи. Хорошее описание границ фиксирует: что поддерживаем сейчас и каких зависимостей избегаем. Это помогает команде не расширять задачу до «переделаем весь аккаунт».
Подробный разбор → Другие темы: Продуктовая аналитика