Постановка задачи и PRD: вопросы для собеседования (часть 2)
Как сформулировать аналитическую задачу, определить scope исследования и написать аналитический блок PRD. На собеседовании часто дают расплывчатый запрос вроде «почему упала конверсия» и ждут, что кандидат структурирует задачу: уточнит метрику, период, сегменты, возможные причины. Умение фреймить задачу — ключевой навык аналитика.
Вопросы 6–10 из 20
6Фича: пользователь может изменить адрес доставки в заказе до передачи в сборку. Какой вариант лучше всего похож на проверяемые `acceptance criteria`?
AПроцесс изменения адреса должен быть максимально удобным, понятным и визуально приятным для пользователя на любом устройстве
BДобавить отдельный экран с полем ввода адреса и кнопкой подтверждения, доступной на всех этапах заказа
CЕсли `status='new'` или `status='confirmed'`, адрес можно изменить; если `status='packing'` и дальше, адрес менять нельзя и показываем объяснение; после изменения адрес отображается в деталях заказа и в письме подтверждения
DРеализовать изменение адреса по аналогии с ведущими конкурентами, чтобы пользователи не испытывали затруднений и не обращались в поддержку
Ответ: Хорошие `acceptance criteria` бинарно проверяемы и описывают поведение по условиям, включая `edge cases`.
`Acceptance criteria` должны позволять однозначно ответить, выполнено требование или нет. Формулировки про «удобно» и «как у конкурента» не дают проверяемого результата. Указание состояний заказа и ожидаемого поведения делает критерии тестируемыми и снижает риск разночтений между продуктом, дизайном и разработкой. Отдельно полезно предусмотреть негативный сценарий как часть `edge cases`, например попытку изменить адрес после начала сборки.
7Команда делает кнопку повторного заказа в приложении. Что лучше всего записать как `acceptance criteria` для первой версии?
AУвеличить выручку на 10% за квартал
BПользователь может повторить предыдущий заказ за один сценарий; если товар недоступен, показываем замену или исключаем его из корзины с понятным сообщением
CСделать новый экран с красивыми карточками прошлых заказов
DУменьшить количество задач в беклоге по заказам
Ответ: `Acceptance criteria` описывают проверяемое поведение фичи, а не бизнес-результат в горизонте месяцев.
Метрики роста выручки важны, но они часто являются итоговыми и зависят от множества факторов. `Acceptance criteria` должны быть тестируемыми прямо на релизе: что пользователь может сделать и что происходит в ключевых `edge cases`. Хорошие критерии заранее описывают, что делать с недоступными товарами, чтобы избежать багов и недовольства. Это помогает сохранить `scope` и обеспечить качество первой версии.
8В середине разработки стейкхолдер просит добавить ещё один «небольшой» сценарий, который расширяет `scope`. Какое действие наиболее корректно с точки зрения PRD (Product Requirements Document)?
AСразу добавить запрос в текущий релиз, чтобы избежать конфликта
BОтказать без обсуждения, потому что `scope` фиксирован навсегда
CОценить влияние на сроки и риски, обсудить trade-off, обновить `scope` и при необходимости вынести часть в `non-goals` или следующий релиз
DПереписать `problem statement`, чтобы новый запрос выглядел как изначальная цель
Ответ: PRD (Product Requirements Document) помогает управлять `scope creep`: оценить влияние, зафиксировать решение и обновить `scope` и `non-goals`.
Запросы в процессе почти неизбежны, но важно не принимать их «по умолчанию». Корректный подход — оценить стоимость, понять, что придётся убрать или перенести, и явно договориться со стейкхолдерами. Если новый сценарий важен, его можно включить в `scope`, но тогда нужно обновить документ и ожидания. Если нет, его стоит зафиксировать в `non-goals` или бэклоге, чтобы избежать скрытых обязательств.
9Фича: объединение двух аккаунтов пользователя в один. Какой набор пунктов наиболее подходит для раздела `edge cases` в PRD (Product Requirements Document)?
AДобавить кнопку объединения аккаунтов и экран подтверждения
BСогласовать дизайн, тексты и дедлайны с маркетингом
CОба аккаунта имеют разные email/телефон, конфликт данных профиля, разные способы входа (пароль и SSO), активные подписки, дубли заказов, откат при ошибке на середине процесса
DУвеличить активность пользователей и снизить количество регистраций
Ответ: Для сложных операций важно заранее выписать `edge cases` и проверки корректности данных.
Объединение аккаунтов часто затрагивает критичные данные: подписки, заказы, историю действий и доступы. Без явных `edge cases` команда может пропустить конфликтные сценарии и получить необратимые ошибки. В PRD (Product Requirements Document) полезно описать, как разрешаются конфликты и что происходит при частичном сбое. Затем эти пункты превращаются в `acceptance criteria` и тестовые проверки.
10Запрос звучит так: «Сделайте поиск более релевантным». Какой следующий шаг лучше всего переводит запрос в `problem statement` и `acceptance criteria`?
AУточнить, для каких запросов и сегментов проблема, зафиксировать текущую боль, выбрать измеримый критерий качества (например, доля кликов на top-3) и согласовать `acceptance criteria`
BСразу выбрать новую ML-модель и начать внедрение, не меняя PRD (Product Requirements Document)
CСделать редизайн страницы поиска и добавить больше фильтров без измерений
DПопросить разработчиков ускорить сервис и считать, что релевантность улучшилась
Ответ: Чтобы избежать разночтений, `problem statement` должен быть конкретным, а `acceptance criteria` — измеримыми и согласованными.
Слово «релевантность» может означать разные вещи: качество выдачи, скорость, наличие ассортимента или удобство фильтров. Поэтому сначала важно описать конкретную проблему и для кого она важна. Затем выбирают измеримый критерий успеха и формулируют `acceptance criteria`, чтобы можно было проверить результат. Так вы снижаете риск сделать много изменений и не понять, стало ли лучше.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в TelegramДругие темы: Продуктовая аналитика