Постановка задачи и PRD: вопросы для собеседования (часть 4)
Как сформулировать аналитическую задачу, определить scope исследования и написать аналитический блок PRD. На собеседовании часто дают расплывчатый запрос вроде «почему упала конверсия» и ждут, что кандидат структурирует задачу: уточнит метрику, период, сегменты, возможные причины. Умение фреймить задачу — ключевой навык аналитика.
Вопросы 16–20 из 20
16У вас 2 недели до релиза, а список хотелок большой. Какое решение по `scope` и `non-goals` наиболее корректно для PRD (Product Requirements Document)?
AВключить всё в `scope`, иначе стейкхолдеры будут недовольны
BОпределить MVP `scope`, вынести остальное в `non-goals`/следующие итерации и явно зафиксировать допущения и риски
CУдалить раздел `non-goals`, чтобы документ выглядел позитивнее
DЗаменить `scope` на список задач разработки без объяснения целей
Ответ: Ограниченный срок требует чёткого MVP: фиксируем `scope`, выносим остальное в `non-goals` и договариваемся о компромиссах.
Если в PRD (Product Requirements Document) нет границ, команда почти всегда получает `scope creep` и срыв сроков. MVP помогает доставить ценность и собрать обратную связь раньше, а `non-goals` защищают от скрытых ожиданий. Важно также записать допущения и риски, чтобы никто не воспринимал ограничения как случайность. Такой PRD (Product Requirements Document) делает план предсказуемым и управляемым.
17B2B продукт вводит роли `admin` и `member` для управления доступами. Какой вариант лучше всего сочетает `scope`, `edge cases` и `acceptance criteria` для первой версии?
AСделать ролевую модель максимально гибкой и поддержать все возможные роли сразу
B`scope`: две роли `admin`/`member`; `acceptance criteria`: `admin` может приглашать и удалять пользователей, `member` не может; `edge cases`: удаление последнего `admin`, приглашение уже существующего email, пользователь удалён во время активной сессии
CСфокусироваться только на интерфейсе и отложить ограничения на backend
DСделать роли, но не описывать `edge cases`, чтобы команда сама решила, как лучше
Ответ: Сильный PRD фиксирует минимальный `scope`, проверяемые `acceptance criteria` и критичные `edge cases`, которые часто ломают доступы.
Роли и доступы — зона, где ошибки приводят к блокировке работы или утечке прав. Поэтому важно чётко описать, что входит в `scope` первой версии и какие действия разрешены. Затем `acceptance criteria` задают проверяемое поведение, а `edge cases` закрывают опасные сценарии вроде удаления последнего администратора. Такой подход снижает риск неконсистентной реализации и неожиданных дыр в безопасности.
18Два стейкхолдера спорят: поддержка просит внедрить чат-бота, маркетинг просит добавить баннеры самообслуживания. Жалоба пользователей одна: долго решаются типовые вопросы. Какой подход к PRD (Product Requirements Document) наиболее корректен?
AНачать с `problem statement` про время решения типовых вопросов, определить критерии успеха, затем выбрать `scope` решения и явно описать `non-goals`
BСразу выбрать чат-бот как решение и запретить обсуждение альтернатив
CСразу добавить и чат-бота, и баннеры, чтобы всем было приятно, не фиксируя `scope`
DСфокусироваться на дизайне баннеров и не описывать `acceptance criteria`, чтобы не ограничивать команду
Ответ: Когда спор про решения, полезно вернуться к `problem statement` и через него согласовать `scope` и `acceptance criteria`.
Если начать с решений, команда рискует выбрать самый громкий запрос, а не самый эффективный способ снять боль пользователя. `Problem statement` возвращает дискуссию к сути: что именно ломается и как измерим улучшение. После этого можно сравнить варианты по стоимости, рискам и влиянию, выбрать MVP `scope` и зафиксировать `non-goals`. Так PRD (Product Requirements Document) становится инструментом выравнивания и принятия решений, а не перечнем хотелок.
19Фича: удаление аккаунта. У продукта есть активные подписки и возвраты. Какие `acceptance criteria` лучше всего снижают риск некорректного поведения и закрывают ключевые `edge cases`?
A`acceptance criteria`: пользователь нажимает «Удалить», данные немедленно удаляются из БД; активные подписки и незавершённые возвраты не проверяются; пользователь получает письмо об удалении
B`acceptance criteria`: перед удалением показываем экран подтверждения и страницу прощания; аккаунт удаляется сразу после согласия; edge cases и подписки не рассматриваются как блокер
C`acceptance criteria`: удаление аккаунта снижает нагрузку на поддержку; кнопка доступна всем пользователям без ограничений; метрика успеха — рост числа удалений на 20% в месяц
D`acceptance criteria`: при активной подписке удаление требует сначала отмены; при незавершённых возвратах показываем блокирующее сообщение; после удаления пользователь разлогинен и не может войти; данные, которые обязаны храниться, остаются по правилам, остальное удаляется или анонимизируется; все статусы и ошибки описаны как `edge cases`
Ответ: Для рискованных операций `acceptance criteria` должны явно описывать ограничения и `edge cases`, чтобы не сломать деньги и соответствие правилам.
Удаление аккаунта затрагивает юридические требования, деньги и доступ. Поэтому важно заранее описать, когда удаление разрешено, а когда блокируется, и что происходит с подписками и возвратами. Хорошие `acceptance criteria` также фиксируют ожидаемое состояние после операции: сессии, доступ, повторный вход. Если эти условия не прописать, команда может реализовать техническое удаление, которое ломает финансовые процессы. Явные `edge cases` делают поведение предсказуемым и проверяемым.
20Вы решили, что полноценный офлайн-режим не входит в `scope`. При этом часть пользователей бывает без интернета. Как корректнее всего зафиксировать это в PRD (Product Requirements Document), чтобы избежать сюрпризов?
AНичего не писать: если офлайн не в `scope`, то поведение без интернета неважно
BПообещать полный офлайн-режим, чтобы не спорить со стейкхолдерами
CЗаписать офлайн как `non-goals`, но в `edge cases` описать ожидаемое поведение при отсутствии сети (сообщение об ошибке, повтор, сохранение введённых данных)
DСменить `problem statement` так, чтобы офлайн больше не упоминался
Ответ: Даже если что-то не в `scope`, корректное поведение в граничных ситуациях часто нужно описать через `edge cases`.
`Non-goals` означает, что вы не строите полноценный офлайн как продуктовую возможность. Но отсутствие сети остаётся реальностью, и без описания команда может реализовать поведение случайно: потеря данных, бесконечная загрузка или непонятные ошибки. Поэтому разумно исключить офлайн-функциональность из `scope`, но явно описать `edge cases` и минимально приемлемое поведение. Это защищает пользовательский опыт и снижает количество инцидентов после релиза.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в TelegramДругие темы: Продуктовая аналитика