Постановка задачи и PRD: вопросы для собеседования (часть 2)
Как сформулировать аналитическую задачу, определить scope исследования и написать аналитический блок PRD. На собеседовании часто дают расплывчатый запрос вроде «почему упала конверсия» и ждут, что кандидат структурирует задачу: уточнит метрику, период, сегменты, возможные причины. Умение фреймить задачу — ключевой навык аналитика.
Вопросы 6–10 из 20
6Фича: пользователь может изменить адрес доставки в заказе до передачи в сборку. Какой вариант лучше всего похож на проверяемые `acceptance criteria`?
AПроцесс изменения адреса должен быть удобным, понятным и визуально приятным на любом устройстве пользователя в `production`
BДобавить отдельный экран с полем `address_input` и кнопкой подтверждения, доступной на всех этапах оформления заказа
CЕсли статус заказа `new` или `confirmed`, адрес меняется; при `packing` адрес блокируется с понятным сообщением
DРеализовать изменение адреса по аналогии с конкурентами рынка, чтобы соответствовать паттернам в виджете `checkout`
Ответ: Хорошие критерии приёмки бинарно проверяемы и описывают поведение по условиям, включая граничные случаи.
`Acceptance criteria` должны позволять однозначно ответить, выполнено требование или нет. Формулировки про «удобно» и «как у конкурента» не дают проверяемого результата. Указание состояний заказа и ожидаемого поведения делает критерии тестируемыми и снижает риск разночтений между продуктом, дизайном и разработкой. Отдельно полезно предусмотреть негативный сценарий как часть `edge cases`, например попытку изменить адрес после начала сборки.
Подробный разбор → 7Команда делает кнопку повторного заказа в приложении. Что лучше всего записать как критерии приёмки для первой версии?
AФункция повторного заказа должна обеспечить рост доли повторных покупок минимум на 15% за два месяца после запуска
BПользователь видит историю заказов с фото товаров, суммой и датой; жмёт «Повторить» и попадает в корзину
CПользователь повторяет предыдущий заказ за один сценарий; если товар недоступен, показываем замену или исключаем
DКнопка повторного заказа сокращает количество тикетов в поддержку по теме «как снова заказать то же самое»
Ответ: Критерии приёмки описывают проверяемое поведение фичи и ключевые граничные случаи, а не итоговые бизнес-метрики.
Метрики роста выручки важны, но они часто являются итоговыми и зависят от множества факторов. `Acceptance criteria` должны быть тестируемыми прямо на релизе: что пользователь может сделать и что происходит в ключевых `edge cases`. Хорошие критерии заранее описывают, что делать с недоступными товарами, чтобы избежать багов и недовольства. Это помогает сохранить `scope` и обеспечить качество первой версии.
Подробный разбор → 8В середине разработки стейкхолдер просит добавить ещё один «небольшой» сценарий, который расширяет область охвата. Какое действие наиболее корректно с точки зрения PRD (Product Requirements Document)?
AСразу добавить запрос в текущий релиз, чтобы избежать конфликта со стейкхолдером и не тормозить ход разработки
BОценить влияние на сроки и риски, обсудить компромиссы, обновить охват и при необходимости вынести в следующий релиз
CОтказать без обсуждения и сослаться на то, что охват зафиксирован в начале и уже не подлежит изменению до релиза
DПереписать формулировку проблемы так, чтобы новый запрос выглядел как изначальная цель проекта без новых оценок
Ответ: PRD помогает управлять расползанием требований: оценить влияние, зафиксировать решение и обновить область охвата.
Запросы в процессе почти неизбежны, но важно не принимать их «по умолчанию». Корректный подход — оценить стоимость, понять, что придётся убрать или перенести, и явно договориться со стейкхолдерами. Если новый сценарий важен, его можно включить в область охвата, но тогда нужно обновить документ и ожидания команды. Если нет — зафиксировать его в списке «вне охвата» или в бэклоге, чтобы избежать скрытых обязательств и расползания требований.
Подробный разбор → 9Фича: объединение двух аккаунтов пользователя в один. Какой набор пунктов наиболее подходит для раздела «граничные сценарии» в PRD (Product Requirements Document)?
AРазные адреса и телефоны, конфликт данных профиля, разные способы входа, активные подписки, дубли заказов, откат при ошибке.
BСогласовать дизайн интерфейса, тексты экранов и дедлайны выпуска с командой маркетинга и обновить общий план запуска фичи.
CДобавить кнопку объединения аккаунтов, экран подтверждения действия и понятный текст про последствия для пользователя.
DУвеличить общую активность пользователей и снизить число повторных регистраций за счёт упрощения шагов в воронке входа.
Ответ: Для сложных операций важно заранее выписать `edge cases` и проверки корректности данных.
Объединение аккаунтов часто затрагивает критичные данные: подписки, заказы, историю действий и доступы. Без явных граничных сценариев команда может пропустить конфликтные ситуации и получить необратимые ошибки. В PRD (Product Requirements Document) полезно описать, как разрешаются конфликты и что происходит при частичном сбое. Затем эти пункты превращаются в критерии приёмки и тестовые проверки.
Подробный разбор → 10Запрос звучит так: «Сделайте поиск более релевантным». Какой следующий шаг лучше всего переводит запрос в постановку задачи и критерии приёмки?
AСразу выбрать новую модель ранжирования и начать внедрение, не меняя документ требований и не уточняя сегменты
BСделать редизайн страницы поиска и добавить больше фильтров, не выбирая измеримый критерий и не согласуя с командой
CПопросить разработчиков ускорить сервис и считать, что релевантность улучшилась, без замера качества выдачи и боли
DУточнить, для каких запросов и сегментов проблема, выбрать измеримый критерий (доля кликов на топ-3) и согласовать
Ответ: Чтобы избежать разночтений, постановка задачи должна быть конкретной, а критерии приёмки — измеримыми и согласованными.
Слово «релевантность» может означать разные вещи: качество выдачи, скорость, наличие ассортимента или удобство фильтров. Поэтому сначала важно описать конкретную проблему и для кого она важна. Затем выбирают измеримый критерий успеха и формулируют критерии приёмки, чтобы можно было проверить результат. Так вы снижаете риск сделать много изменений и не понять, стало ли лучше.
Подробный разбор → Другие темы: Продуктовая аналитика