Перейти к основному содержимому
Nodary

Шаблон документа требований к продукту (PRD)

Шесть связанных документов, которые ведут функцию от проблемы до запуска: для кого она, что должна делать, как устроен сценарий, как понять, что она сработала, и каждое решение по пути. Скачайте их как файлы Markdown: они открываются в любом редакторе, показывают диаграмму на GitHub и в Obsidian и импортируются в Nodary в виде карты.

6 файлов Markdown в архиве .zip, 10 кБ

Бесплатно, без учётной записи и без e-mail. Пользуйтесь, меняйте, делитесь.

Прочитайте каждую страницу до скачивания

Обзор помещается на одном экране и ссылается на пять частей: разработка, дизайн и поддержка находят каждая свою страницу, а изменение остаётся небольшим. Строки курсивом подсказывают, что писать; примеры следуют одной функции, ссылкам для общего доступа с ограниченным сроком.

Документы

Файл Шаблон PRD/Документ требований к продукту.md

Документ требований к продукту

Как пользоваться шаблоном: строки курсивом содержат подсказки. Замените их своими словами, затем удалите. Значения в квадратных скобках заполняете вы. Держите эту страницу на одном экране: её первой читает занятой читатель, новый коллега или ИИ-агент.

Коротко

ПолеЭта функция
Функция[Название]
Одним предложением[Что сможет сделать пользователь после выхода]
Владелец продукта[имя]
Технический лидер[имя]
Лидер дизайна[имя]
Статус[черновик, на проверке, утверждён, выпущен]
Целевая версия[дата или версия]

Проблема

У кого проблема, чего она стоит сегодня и откуда вы это знаете. Проблема без доказательств остаётся догадкой: дайте ссылку на исследование в Пользователи и доказательства.

Пример (демонстрационная функция): Люди открывают клиенту документ на проверку, а потом забывают, что ссылка существует. Через месяцы она всё ещё открывается. В прошлом квартале трое клиентов спросили, как сделать так, чтобы ссылка перестала работать в определённый день.

[Проблема в двух-трёх предложениях]

Цели и не-цели

Цели говорят, что меняется для пользователя, а не что строит команда. Не-цели тоже решения: они не дают объёму тихо расти.

  • Цель: [что пользователь может сделать или чего ему больше не нужно делать]
  • Цель: [...]
  • Не-цель: [что эта версия намеренно оставляет за рамками]
  • Не-цель: [...]

Успех в одной строке

Одна метрика, которая через месяц после запуска скажет, сработало ли. Полный список в Запуск и метрики.

[Метрика] вырастет с [исходное значение] до [цель] к [дата].

Остальные части PRD

Каждая часть живёт в отдельном документе. Ссылайтесь на неё, а не копируйте, чтобы каждый факт жил и менялся в одном месте.

Шаблон можно свободно использовать, менять и распространять. Он сделан в Nodary, где эти файлы импортируются как карта связанных документов.

Скачать шаблон6 файлов Markdown в архиве .zip, 10 кБ

Как им пользоваться

  1. Сначала проблема, потом решение

    Заполните сначала проблему, цели и не-цели в обзоре вместе с разработчиком и дизайнером, которые будут делать функцию. Если вы втроём не согласны насчёт проблемы, остановитесь на этом.

  2. Сделайте каждое обязательное требование проверяемым

    Дайте каждому обязательному требованию критерии приёмки, которые сможет проверить другой человек. Требование, которое никто не может проверить, остаётся пожеланием.

  3. Отдайте на проверку и держите в актуальном виде

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

  4. Записывайте, что изменилось и почему

    Каждое решение попадает в журнал решений с именем того, кто его принял. Когда кто-то спросит, почему функция работает так, ответ будет в одной ссылке.

Импортируйте его в Nodary в виде карты

Nodary представляет собой рабочее пространство, созданное для ИИ, где документы команды связаны, а не копятся в кучу. Импортируйте .zip, и PRD появится с пятью частями под ним, со ссылками между страницами и нарисованной диаграммой. Отправьте его на проверку и попросите владельца или администратора рабочего пространства или проекта утвердить его, посмотрите, что изменилось с вашего прошлого визита, и дайте ИИ-агентам, подключённым по MCP, прочитать требования до того, как они напишут код.

  1. Откройте карту проекта и нажмите «Импорт».
  2. Выберите вкладку «Папка или ZIP», затем «Выбрать ZIP-архив».
  3. Выберите скачанный файл, проверьте дерево и импортируйте.

Бесплатный тариф вмещает десять документов на рабочее пространство, включая страницу самого проекта: шесть документов шаблона поместятся в новое пространство, и останется место ещё для трёх. В Nodary есть и встроенный одностраничный шаблон спецификации продукта (PRD).

Nodary для продуктовых команд и команд разработки
Живое представление-доска в 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 станет картой, которую ваша команда и ваши ИИ-агенты поддерживают в актуальном виде. Бесплатно для двух участников, одного проекта и десяти документов, без карты.