На карте
PRD — это Product Requirements Document, документ требований к продукту или отдельной функции. Он описывает назначение, ожидаемые возможности и поведение продукта, а также фиксирует проблему, пользователей, ожидаемый результат и границы работы.
PRD обычно готовят до начала реализации, а затем уточняют по мере появления новых данных и принятых решений. В гибком процессе это живой документ для общего понимания, который поддерживают в актуальном состоянии, вместо попытки заранее описать каждую техническую деталь.
Проверено 5 сентября 2026 года по официальным материалам Atlassian о продуктовых требованиях и шаблону PRD в Confluence.
Оглавление
- Как выглядит хороший PRD
- Зачем нужен PRD
- Что включить в документ
- Чеклист быстрой проверки
- Частые ошибки
- Минимальный шаблон PRD
- Официальные источники
Как выглядит хороший PRD
Целевое состояние простое: участник команды открывает документ и без устных пояснений понимает:
- какую пользовательскую или бизнес-проблему решают;
- какие цели и показатели результата согласованы;
- что входит в текущую работу;
- что сознательно оставлено за её пределами;
- какие пользовательские сценарии нужно поддержать;
- какие вопросы, риски и зависимости пока остаются открытыми;
- кто отвечает за решения и как менялся документ.
PRD фиксирует продуктовые требования и ожидаемое поведение. Подробности архитектуры, внутреннего устройства и реализации при необходимости выносят в связанные технические или дизайн-документы и связывают с PRD.
Зачем нужен PRD
- Общее понимание. Команда и заинтересованные стороны сверяют цели, сценарии и ограничения до того, как расхождения станут дорогими.
- Управление объёмом. Разделы «В работе» и «Вне работы» помогают сдерживать незаметное расширение задачи.
- Основа для проверки. После реализации результат можно сопоставить с целями, сценариями и критериями приёмки.
- История решений. Предположения, открытые вопросы и согласованные изменения остаются в одном месте.
- Совместная работа. PRD проще обсуждать и обновлять, когда он короткий, понятный и доступен всем участникам.
Что включить в документ
Набор разделов зависит от масштаба задачи. Для небольшой функции достаточно компактного PRD; для крупного продукта потребуются дополнительные исследования, макеты и связанные технические документы.
1. Метаданные и ответственные
| Поле | Что указать |
| Название | Короткое название продукта или функции |
| Владелец | Кто поддерживает документ и координирует решения |
| Статус | Например: черновик, на согласовании, согласовано, в работе, завершено |
| Даты | Создание, последнее обновление, целевой выпуск при наличии |
| Команда | Кто принимает решения, реализует, проектирует и проверяет результат |
| Связанные материалы | Исследования, макеты, задачи и технические документы |
Статусы и роли подстройте под рабочий процесс команды. Главное, чтобы по документу было видно его текущее состояние.
2. Проблема и контекст
Опишите текущее состояние, затронутых пользователей и последствия проблемы. Отделяйте наблюдаемые факты от предположений.
Слабая формулировка:
Нужна авторизация через внешнего провайдера.
Более полезная формулировка:
Часть новых пользователей не завершает регистрацию с электронной почтой и паролем. Команда предполагает, что вход через поддерживаемого внешнего провайдера сократит число прерванных регистраций. Перед разработкой нужно подтвердить исходную конверсию и выбрать показатель для проверки гипотезы.
Такая запись объясняет проблему и одновременно показывает, какие данные ещё нужно получить.
3. Цели и показатели результата
Сформулируйте ожидаемое изменение и способ его измерить. Для каждого показателя полезно указать исходное значение, цель, период измерения и источник данных.
Примеры формата:
- увеличить долю завершённых регистраций с
[исходное значение]до[цель]за[период]; - удерживать время ответа критичного запроса не выше
[значение]на выбранном процентиле; - сократить число обращений по восстановлению доступа на
[значение].
Числа нельзя подставлять для убедительности. Если исходных данных нет, зафиксируйте это как открытый вопрос или задачу исследования.
4. Границы работы
| В работе | Вне работы |
| Конкретные сценарии текущего выпуска | Сценарии, перенесённые в будущие этапы |
| Поддерживаемые платформы | Платформы, которые пока не поддерживаются |
| Выбранные интеграции | Альтернативные интеграции вне текущего объёма |
Формулируйте обе колонки конкретно. Новое требование не становится частью текущей работы автоматически: сначала команда оценивает влияние и обновляет PRD.
5. Пользовательские сценарии
Для каждого ключевого пользователя опишите задачу и ожидаемый результат. Можно использовать формат:
Как[роль], я хочу[действие], чтобы[ценность].
Пример:
Как новый пользователь, я хочу войти через доступного мне провайдера, чтобы не создавать отдельный пароль.
Дополните основной путь пограничными случаями:
- пользователь отменил вход;
- провайдер вернул ошибку;
- адрес уже связан с существующей учётной записью;
- провайдер временно недоступен;
- пользователь потерял доступ к внешней учётной записи.
6. Функциональные требования и критерии приёмки
Каждое требование должно описывать наблюдаемое поведение, которое можно проверить. Например:
- При выборе поддерживаемого провайдера система начинает процесс входа.
- После успешного подтверждения система создаёт новую учётную запись или входит в существующую согласно согласованным правилам.
- При отмене или ошибке пользователь получает понятное сообщение и может повторить попытку либо выбрать другой способ входа.
- Правила обработки совпадающих адресов описаны отдельно и согласованы с требованиями безопасности.
Точные экраны, протоколы и способы хранения данных должны опираться на актуальную документацию выбранного провайдера и техническое решение команды.
7. Нефункциональные требования
Опишите ограничения, которые определяют качество работы продукта и поддаются проверке:
- производительность и допустимое время ответа;
- доступность и восстановление после сбоев;
- безопасность, приватность и требования к данным;
- доступность интерфейса для людей с ограниченными возможностями;
- поддерживаемые браузеры, устройства и версии;
- журналирование, наблюдаемость и эксплуатационные ограничения.
Для каждого пункта задайте измеримый критерий или ссылку на действующий внутренний стандарт. Произвольные значения вроде времени ответа или процента доступности не подходят.
8. Предположения, зависимости и риски
Фиксируйте:
- предположения о пользователях и условиях использования;
- внешние сервисы и команды, от которых зависит выпуск;
- необходимые доступы и согласования;
- возможные отказы и способы восстановления;
- правовые, безопасностные и операционные ограничения.
У каждого существенного риска желательно указать владельца и план реакции.
9. Этапы и выпуск
Если сроки уже оценены командой, перечислите этапы, ответственных и зависимости. Не превращайте предварительную оценку в обещание: отмечайте уровень уверенности и обновляйте план после уточнения требований.
Минимальный вариант:
| Этап | Результат | Ответственный | Срок или статус |
| Исследование | Подтверждены проблема и исходные показатели | [роль] | [значение] |
| Проектирование | Согласованы сценарии и макеты | [роль] | [значение] |
| Реализация | Выполнены критерии приёмки | [роль] | [значение] |
| Проверка и выпуск | Пройдены тесты, настроено наблюдение | [роль] | [значение] |
10. Открытые вопросы и журнал решений
Открытый вопрос должен иметь владельца и, по возможности, срок ответа. После решения сохраните краткий итог и дату, чтобы PRD показывал развитие продукта.
Примеры:
- какие провайдеры входят в первый выпуск;
- как восстанавливать доступ при недоступности провайдера;
- кто отвечает за производственные настройки и секреты;
- какие данные подтвердят успех после выпуска.
Чеклист быстрой проверки
Этот список можно пройти за пять минут:
Частые ошибки
| Ошибка | Что происходит | Как исправить |
| Документ появляется после реализации | PRD превращается в отчёт и не помогает принимать решения | Согласовать проблему, цели и границы до основной реализации |
| Сразу задано решение | Команда не видит исходную проблему и не может сравнить варианты | Сначала описать контекст и ожидаемый результат |
| Показатели размыты | Успех нельзя проверить | Указать метрику, исходное значение, цель и период |
| Не обозначены границы | Объём растёт без явного решения | Вести разделы «В работе» и «Вне работы» |
| Требования чрезмерно детализированы | Документ быстро устаревает и ограничивает реализацию | Оставить в PRD продуктовые требования, а детали вынести в связанные документы |
| Нет предположений и вопросов | Неопределённость скрыта от команды | Записывать неизвестное, владельцев и решения |
| PRD не обновляется | Команда опирается на устаревшие договорённости | Назначить владельца и фиксировать существенные изменения |
Минимальный шаблон PRD
# Название продукта или функции
Владелец: [имя или роль]
Статус: [черновик / на согласовании / согласовано / в работе]
Последнее обновление: [дата]
## Проблема и контекст
Что происходит сейчас, кого это затрагивает и какие данные это подтверждают?
## Цели и показатели
Какое изменение ожидается и как команда его измерит?
## Границы
### В работе
- ...
### Вне работы
- ...
## Пользовательские сценарии
- Основной путь: ...
- Пограничные случаи: ...
## Требования и критерии приёмки
1. ...
## Предположения, зависимости и риски
- ...
## Открытые вопросы
- [Вопрос] — владелец: [роль], срок: [дата]
## Связанные материалы
- Исследование: ...
- Макеты: ...
- Технический документ: ...Короткий PRD полезен, когда помогает команде принимать решения и проверять результат. Поддерживайте его актуальным, добавляйте детали по мере необходимости и фиксируйте нерешённые вопросы.
Официальные источники
- Atlassian: How to create a product requirements document
- Atlassian Confluence: Product requirements document template
Следующий шаг
Если нужно выстроить единый шаблон PRD и связать его с процессом разработки, начните с текущих ролей, решений и точек проверки, а затем изучите Процесс: Идея → PRD → Dev Kickoff.
Если вы хотите адаптировать структуру PRD под роли и точки принятия решений в своей команде, это можно обсудить на конкретном рабочем примере.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov
