PRD — что это и как его правильно писать

Методология

PRD — это Product Requirements Document, документ требований к продукту. Проще говоря — письменный ответ на вопрос: «Что именно мы делаем, зачем и как поймём, что получилось?»

PRD пишется до начала разработки. Это не техническая спецификация и не дизайн-документ. Это контракт между тем, кто ставит задачу, и тем, кто её выполняет.

Зачем нужен PRD

Синхронизация. Все участники понимают задачу одинаково — до старта, а не после релиза.
Scope control. Чётко зафиксировано, что входит в задачу, а что нет. Без PRD scope расползается незаметно.
Основа для ревью. Когда результат готов, вы сверяете его с PRD. Есть расхождения — есть разговор.
История решений. Через полгода никто не вспомнит, почему выбрали вариант А. PRD — это память проекта.

Из чего состоит PRD

1. Заголовок и метаданные

Поле	Что писать
Название фичи/продукта	Короткое и понятное, как заголовок задачи
Автор	Кто написал PRD
Дата	Когда создан, когда обновлялся
Статус	Draft → Review → Approved → In Progress → Done
Стейкхолдеры	Кто принимает решение, кто делает, кто тестирует

2. Проблема (Problem Statement)

Что сейчас не так? Почему это важно? Кого это касается?

Хороший тест: если убрать этот раздел и показать PRD постороннему человеку — поймёт ли он, зачем всё это? Если нет — проблема описана плохо.

Пример плохо:

Нам нужна авторизация через OAuth.

Пример хорошо:

Сейчас пользователи регистрируются по email и паролю. 40% бросают процесс на втором шаге. Гипотеза: вход через Google/Apple сократит отток на этапе регистрации.

3. Цели и метрики (Goals & Success Criteria)

Что конкретно должно измениться после реализации? Формулируйте так, чтобы можно было проверить.

✅ «Конверсия регистрации вырастет с 60% до 80%»
✅ «Время ответа API не превысит 200ms на p95»
❌ «Улучшить пользовательский опыт» — это не метрика, это пожелание

4. Scope — что делаем и что НЕ делаем

Это самый важный раздел для тех, кто пишет PRD впервые. Без него задача всегда разрастается.

✅ В scope	❌ Вне scope
OAuth через Google и Apple	OAuth через Facebook и GitHub
Веб-версия	Мобильное приложение (отдельный PRD)
Базовый онбординг после входа	Полная переработка онбординга

Правило: если что-то явно не указано как «в scope» — значит, этого в задаче нет. Не додумывайте.

5. Пользовательские сценарии (User Stories)

Опишите, как реальный человек будет пользоваться тем, что вы делаете. Формат:

Как [кто], я хочу [что], чтобы [зачем].

Пример:

Как новый пользователь, я хочу войти через Google одним кликом, чтобы не придумывать и не запоминать пароль.

Для каждого сценария полезно описать happy path (всё идёт по плану) и edge cases (что может пойти не так).

6. Функциональные требования

Что система должна делать — конкретно, проверяемо, без воды.

При нажатии «Войти через Google» система перенаправляет на OAuth consent screen
После успешной авторизации создаётся аккаунт или выполняется вход
Если email из OAuth совпадает с существующим аккаунтом — предложить связать аккаунты
При ошибке OAuth — показать сообщение с кнопкой «Попробовать снова»

7. Нефункциональные требования

То, что не про «что делает», а про «как хорошо делает»:

Производительность: OAuth flow завершается за < 3 секунд
Безопасность: токены хранятся в httpOnly cookies, refresh token ротируется
Доступность: uptime 99.9%
Совместимость: Chrome, Safari, Firefox последних двух версий

8. Зависимости и риски

Что может заблокировать или сломать работу:

Зависимость от Google OAuth API — если API изменится, потребуется адаптация
Нужен доступ к Google Cloud Console для настройки OAuth credentials
Риск: если пользователь удалит Google-аккаунт, потеряет доступ → нужен fallback

9. Таймлайн и этапы

Фаза	Что	Срок
1	Backend: OAuth endpoints + token management	1 неделя
2	Frontend: UI кнопок + редиректы	3 дня
3	Тестирование + edge cases	2 дня
4	Деплой + мониторинг	1 день

10. Открытые вопросы

Всё, что ещё не решено. Этот раздел обязателен — он показывает, что автор честен в оценке готовности документа.

Нужно ли поддерживать «Sign in with Apple» на первом этапе?
Какой fallback, если OAuth-провайдер недоступен?
Кто отвечает за настройку OAuth credentials в production?

Частые ошибки

Ошибка	Почему плохо	Как правильно
Писать PRD после разработки	Документ превращается в формальность	PRD пишется до первой строки кода
Описывать решение вместо проблемы	Команда не понимает «зачем», только «что»	Сначала проблема, потом решение
Размытые критерии успеха	Невозможно понять, получилось или нет	Конкретные числа и проверяемые условия
Нет раздела «вне scope»	Scope расползается, сроки срываются	Явно фиксировать, что НЕ входит в задачу
Слишком длинный PRD	Никто не читает, документ бесполезен	1–3 страницы для типовой фичи
Нет открытых вопросов	Создаёт иллюзию, что всё понятно	Честно фиксировать неизвестное

Чеклист: PRD готов?

Проблема описана так, что её поймёт человек не из команды

Есть конкретные, измеримые критерии успеха

Scope чётко определён: что делаем И что не делаем

Пользовательские сценарии покрывают happy path и edge cases

Функциональные требования проверяемы (можно написать тест)

Зависимости и риски перечислены

Открытые вопросы зафиксированы

Документ прочитал хотя бы один человек, кроме автора

Минимальный шаблон для старта

Если вы пишете PRD впервые — начните с этой структуры:

## Проблема
Что не так сейчас?

## Цель
Что должно измениться? Как измерим?

## Scope
Что делаем / Что НЕ делаем

## Сценарии
Как пользователь будет это использовать?

## Требования
Что конкретно должна делать система?

## Открытые вопросы
Что ещё не решено?

Главное правило: PRD — это не бюрократия. Это инструмент, который экономит время и нервы. Короткий и честный PRD лучше длинного и формального.

Есть вопросы по теме — Telegram: t.me/pimenov

← Назад в Базу знаний