Шаблон документа требований к продукту (PRD)
Шесть связанных документов, которые ведут функцию от проблемы до запуска: для кого она, что должна делать, как устроен сценарий, как понять, что она сработала, и каждое решение по пути. Скачайте их как файлы Markdown: они открываются в любом редакторе, показывают диаграмму на GitHub и в Obsidian и импортируются в Nodary в виде карты.
6 файлов Markdown в архиве .zip, 10 кБ
Бесплатно, без учётной записи и без e-mail. Пользуйтесь, меняйте, делитесь.
Прочитайте каждую страницу до скачивания
Обзор помещается на одном экране и ссылается на пять частей: разработка, дизайн и поддержка находят каждая свою страницу, а изменение остаётся небольшим. Строки курсивом подсказывают, что писать; примеры следуют одной функции, ссылкам для общего доступа с ограниченным сроком.
Документы
Файл Шаблон PRD/Документ требований к продукту.md
Документ требований к продукту
Как пользоваться шаблоном: строки курсивом содержат подсказки. Замените их своими словами, затем удалите. Значения в квадратных скобках заполняете вы. Держите эту страницу на одном экране: её первой читает занятой читатель, новый коллега или ИИ-агент.
Коротко
| Поле | Эта функция |
|---|---|
| Функция | [Название] |
| Одним предложением | [Что сможет сделать пользователь после выхода] |
| Владелец продукта | [имя] |
| Технический лидер | [имя] |
| Лидер дизайна | [имя] |
| Статус | [черновик, на проверке, утверждён, выпущен] |
| Целевая версия | [дата или версия] |
Проблема
У кого проблема, чего она стоит сегодня и откуда вы это знаете. Проблема без доказательств остаётся догадкой: дайте ссылку на исследование в Пользователи и доказательства.
Пример (демонстрационная функция): Люди открывают клиенту документ на проверку, а потом забывают, что ссылка существует. Через месяцы она всё ещё открывается. В прошлом квартале трое клиентов спросили, как сделать так, чтобы ссылка перестала работать в определённый день.
[Проблема в двух-трёх предложениях]
Цели и не-цели
Цели говорят, что меняется для пользователя, а не что строит команда. Не-цели тоже решения: они не дают объёму тихо расти.
- Цель: [что пользователь может сделать или чего ему больше не нужно делать]
- Цель: [...]
- Не-цель: [что эта версия намеренно оставляет за рамками]
- Не-цель: [...]
Успех в одной строке
Одна метрика, которая через месяц после запуска скажет, сработало ли. Полный список в Запуск и метрики.
[Метрика] вырастет с [исходное значение] до [цель] к [дата].
Остальные части PRD
Каждая часть живёт в отдельном документе. Ссылайтесь на неё, а не копируйте, чтобы каждый факт жил и менялся в одном месте.
- Пользователи и доказательства: для кого функция и исследование, стоящее за проблемой
- Требования: что она должна делать, с приоритетами и критериями приёмки
- Дизайн и сценарии: сценарий, экраны, состояния и пограничные случаи
- Запуск и метрики: метрики, выкатка и чек-лист запуска
- Решения и открытые вопросы: что решили, кто и почему, и что ещё открыто
Шаблон можно свободно использовать, менять и распространять. Он сделан в Nodary, где эти файлы импортируются как карта связанных документов.
Файл Шаблон PRD/Документ требований к продукту/01 Пользователи и доказательства.md
Пользователи и доказательства
Для кого функция и что вы о них знаете. Каждое утверждение здесь должно указывать на свой источник.
Для кого
| Кто | Что пытается сделать | Что мешает |
|---|---|---|
| [Основной пользователь] | [...] | [...] |
| [Второстепенный пользователь] | [...] | [...] |
Пример (демонстрационная функция): Менеджер по работе с клиентами открывает клиенту черновик предложения на неделю комментариев. Сейчас она ставит себе напоминание отключить ссылку и иногда забывает.
Сегодня, без функции
Что пользователи делают сегодня, шаг за шагом, включая обходные пути. Обходной путь часто лучшая спецификация, какую вы получите.
- [Шаг]
- [Шаг]
- [Обходной путь]
Доказательства
| Источник | Что он говорит | Дата | Ссылка |
|---|---|---|---|
| [Интервью с клиентом] | [...] | [дата] | [...] |
| [Обращения в поддержку] | [...] | [...] | [...] |
| [Данные об использовании] | [...] | [...] | [...] |
Открытые вопросы
- [Вопрос], [кто отвечает], [к какому сроку]
Файл Шаблон PRD/Документ требований к продукту/02 Требования.md
Требования
Одна строка на требование, записанное как то, что пользователь может сделать. Приоритет: обязательно, желательно или возможно; версия выходит, когда выполнено каждое обязательное.
Пользовательские истории
| ID | Как | я хочу | чтобы | Приоритет |
|---|---|---|---|---|
| Т1 | [пользователь] | [...] | [...] | [обязательно, желательно, возможно] |
| Т2 | [...] | [...] | [...] | [...] |
| Т3 | [...] | [...] | [...] | [...] |
Пример (демонстрационная функция): Т1. Как человек, открывающий доступ к документу, я хочу выбрать день, когда ссылка перестанет работать, чтобы клиент терял доступ по окончании проекта. Обязательно.
Критерии приёмки
Для каждого обязательного требования проверки, которые доказывают, что оно работает. Пишите их так, чтобы тестировщик или ИИ-агент мог выполнить их, не спрашивая вас.
| Требование | Дано | Когда | Тогда |
|---|---|---|---|
| Т1 | [исходная ситуация] | [действие] | [результат, который можно проверить] |
| Т1 | [...] | [...] | [...] |
Нефункциональные требования
| Область | Требование |
|---|---|
| Производительность | [...] |
| Безопасность и конфиденциальность | [...] |
| Доступность | [...] |
| Языки | [...] |
| Совместимость | [браузеры, устройства, версии] |
За рамками
- [Чего эта версия не делает и почему]
- [...]
Открытые вопросы
- [Вопрос], [кто отвечает], [к какому сроку]
Файл Шаблон PRD/Документ требований к продукту/03 Дизайн и сценарии.md
Дизайн и сценарии
Ссылайтесь на файлы дизайна, а не вставляйте их. Держите здесь сценарий и решения, которые его объясняют, чтобы текст и экраны никогда не расходились.
Пользовательский сценарий
Основной путь от того места, где пользователь начинает, до того, что он получает. Если команда не может его нарисовать, он ещё не решён.
- Точка входаПервое действие
- Первое действиеКлючевой выбор
- Ключевой выборПодтверждение
- ПодтверждениеРезультат
Mermaid
flowchart LR n0["Точка входа"] n1["Первое действие"] n2["Ключевой выбор"] n3["Подтверждение"] n4["Результат"] n0 --> n1 n1 --> n2 n2 --> n3 n3 --> n4
Экраны
| Экран | Назначение | Ссылка на дизайн | Статус |
|---|---|---|---|
| [Экран] | [...] | [...] | [набросок, макет, финал] |
| [Экран] | [...] | [...] | [...] |
Состояния
У каждого экрана больше состояний, чем удачный путь. Отмечайте каждое, когда оно нарисовано, или пишите, почему оно невозможно.
- Пусто: пока нечего показать
- Загрузка
- Ошибка, и что пользователь может сделать дальше
- Нет прав
- Медленное или потерянное соединение
- Очень длинный текст и очень большие числа
Пограничные случаи
| Случай | Что происходит |
|---|---|
| [...] | [...] |
| [...] | [...] |
Пример (демонстрационная функция): Кто-то открывает ссылку через минуту после даты окончания: он видит, что срок ссылки истёк и к кому обратиться, а не страницу ошибки.
Открытые вопросы
- [Вопрос], [кто отвечает], [к какому сроку]
Файл Шаблон PRD/Документ требований к продукту/04 Запуск и метрики.md
Запуск и метрики
Одна основная метрика, две-три второстепенные и одна защитная: то, что не должно ухудшиться, пока растёт основная.
Метрики
| Метрика | Тип | Исходное значение | Цель | Как измеряем | Дата проверки |
|---|---|---|---|---|---|
| [...] | [основная] | [...] | [...] | [...] | [дата] |
| [...] | [второстепенная] | [...] | [...] | [...] | [...] |
| [...] | [защитная] | [...] | [...] | [...] | [...] |
Выкатка
| Этап | Кто получает | Дата | Дальше, когда |
|---|---|---|---|
| [Внутренний] | [команда] | [...] | [...] |
| [Бета] | [...] | [...] | [...] |
| [Все] | [...] | [...] | [...] |
Чек-лист запуска
- Справочная статья написана
- Поддержка проинструктирована
- Заметка о выпуске подготовлена
- События аналитики проверены
- Откат проверен
Откат
Что заставит вас выключить функцию и как. Решите это до запуска, пока никто не привязан к результату.
- Откатываем, если: [...]
- Как: [флаг, версия, скрипт]
- Кто решает: [имя]
Файл Шаблон PRD/Документ требований к продукту/05 Решения и открытые вопросы.md
Решения и открытые вопросы
Когда решение меняет PRD, добавьте строку сюда и обновите затронутую страницу. Журнал говорит почему; страница говорит, что верно сейчас.
Журнал решений
| Дата | Решение | Кто решил | Почему | Изменённая страница |
|---|---|---|---|---|
| [дата] | [...] | [...] | [...] | [...] |
Пример (демонстрационная функция): Ссылки работают до конца последнего дня в часовом поясе владельца, а не до полуночи по UTC. Решили владелец продукта и технический лидер, потому что в бете клиенты из других часовых поясов теряли доступ на день раньше. Изменённая страница: Требования.
Открытые вопросы
| Вопрос | Кто отвечает | К какому сроку | Ответ |
|---|---|---|---|
| [...] | [имя] | [дата] | [...] |
Как им пользоваться
Сначала проблема, потом решение
Заполните сначала проблему, цели и не-цели в обзоре вместе с разработчиком и дизайнером, которые будут делать функцию. Если вы втроём не согласны насчёт проблемы, остановитесь на этом.
Сделайте каждое обязательное требование проверяемым
Дайте каждому обязательному требованию критерии приёмки, которые сможет проверить другой человек. Требование, которое никто не может проверить, остаётся пожеланием.
Отдайте на проверку и держите в актуальном виде
Попросите проверку, когда требования готовы, и обновляйте PRD, когда решение их меняет. PRD, застывший на старте, к запуску уже неверен.
Записывайте, что изменилось и почему
Каждое решение попадает в журнал решений с именем того, кто его принял. Когда кто-то спросит, почему функция работает так, ответ будет в одной ссылке.
Импортируйте его в Nodary в виде карты
Nodary представляет собой рабочее пространство, созданное для ИИ, где документы команды связаны, а не копятся в кучу. Импортируйте .zip, и PRD появится с пятью частями под ним, со ссылками между страницами и нарисованной диаграммой. Отправьте его на проверку и попросите владельца или администратора рабочего пространства или проекта утвердить его, посмотрите, что изменилось с вашего прошлого визита, и дайте ИИ-агентам, подключённым по MCP, прочитать требования до того, как они напишут код.
- Откройте карту проекта и нажмите «Импорт».
- Выберите вкладку «Папка или ZIP», затем «Выбрать ZIP-архив».
- Выберите скачанный файл, проверьте дерево и импортируйте.
Бесплатный тариф вмещает десять документов на рабочее пространство, включая страницу самого проекта: шесть документов шаблона поместятся в новое пространство, и останется место ещё для трёх. В Nodary есть и встроенный одностраничный шаблон спецификации продукта (PRD).
Nodary для продуктовых команд и команд разработки
Как писать PRD, которым команда действительно пользуется
PRD не работает в двух случаях: он описывает решение, которое никто не поставил под сомнение, или его перестают обновлять после старта. Эти привычки предотвращают оба.
Начинайте с проблемы
Напишите, у кого проблема и чего она ему стоит, до любого решения. Команды, согласные насчёт проблемы, меньше спорят об экранах.
Скажите, чего не будете делать
Не-цели тоже решения. Записав их, вы не даёте функции расти неделю за неделей.
Делайте требования проверяемыми
«Быстро» и «удобно» проверить нельзя. «Ссылка перестаёт открываться в течение минуты после даты окончания» можно и сделать, и проверить.
Приоритеты: обязательно, желательно, возможно
Версия выходит, когда выполнено каждое обязательное требование. Желательное и возможное вы обмениваете, когда приближается срок.
Ссылайтесь на доказательства
Каждое утверждение о пользователях ссылается на интервью, обращение или данные, на которых оно основано, чтобы проверяющий мог убедиться сам, а не верить на слово.
Держите его живым
Обновляйте PRD, когда его меняет решение, и записывайте почему. В итоге он должен описывать то, что вышло, а не то, что планировали в первую неделю.
Вопросы о PRD
Что такое PRD?
Документ требований к продукту (product requirements document, PRD) описывает функцию или продукт до того, как их начнут делать: какую проблему они решают, для кого, что должны уметь, как измерять успех и что остаётся за рамками. Обычно за него отвечает продакт-менеджер; его читают разработчики, дизайнеры, поддержка и всё чаще ИИ-агенты для программирования.
Что должно быть в PRD?
Как минимум проблема и доказательства, цели и не-цели, пользователи, требования с приоритетами и критериями приёмки, основные сценарии и пограничные случаи, метрики успеха, план выкатки и журнал решений и открытых вопросов. В этом шаблоне есть документ для каждой группы.
Каким по объёму должен быть PRD?
Достаточным, чтобы команда могла сделать и проверить функцию, не задавая вам один и тот же вопрос дважды. Обзор должен помещаться на одном экране; требования растут вместе с решениями, а не с идеями.
Чем PRD отличается от технического дизайн-документа?
PRD говорит, что должна делать функция и зачем. Технический дизайн-документ говорит, как это сделает система: архитектура, данные, интерфейсы и риски. Сначала напишите PRD, потом свяжите их.
Могут ли ИИ-агенты пользоваться PRD?
Да. PRD из связанных документов даёт агенту нужный контекст. В Nodary агенты, подключённые по MCP, например Claude, ChatGPT или Cursor, читают требования и журнал решений с вашими правами, прежде чем что-то писать.
Можно ли использовать шаблон вне Nodary?
Да. Файлы написаны в обычном Markdown: Obsidian открывает распакованную папку как хранилище со всеми рабочими ссылками, а GitHub показывает файлы с диаграммой. Инструменты, которые импортируют Markdown по одному файлу, сохраняют текст и таблицы; проверьте, как они обрабатывают ссылки между файлами.
Держите требования там, где работает команда.
Импортируйте шаблон в Nodary, и PRD станет картой, которую ваша команда и ваши ИИ-агенты поддерживают в актуальном виде. Бесплатно для двух участников, одного проекта и десяти документов, без карты.