Как написать PRD с помощью ИИ (бесплатный шаблон)

PRD (product requirements document, документ с требованиями к продукту) — это короткое описание простым языком: что вы создаёте, для кого это, что это должно делать и как вы поймёте, что оно работает. ИИ значительно ускоряет его написание: вы даёте черновые заметки, а он превращает их в структурированные разделы, пользовательские истории и крайние случаи. Ваша задача — дать решения, которые ИИ принять не может: цель, объём и то, что останется за рамками, — и проверить то, что он добавил.

В этом руководстве рассказано, что должно входить в PRD, как пошагово составить его с помощью любого ИИ-ассистента, какие промпты использовать для каждого раздела и как заполнить готовый шаблон.

Для чего нужен PRD (и для чего — нет)

PRD отвечает на четыре вопроса:

1. Зачем мы это делаем? Какую проблему решаем и для кого?
2. Что должно работать в первой версии?
3. Чего в ней не будет?
4. Как мы поймём, что всё получилось?

PRD — не техническое описание. В нём не говорится, какую базу данных или фреймворк использовать: это относится к отдельной техническому спецификации, если она вообще нужна. Это также не маркетинговый бриф и не бизнес-план. Если в PRD описано только поведение продукта, он полезен всем, кто его читает: дизайнеру, разработчику, заказчику, который согласовывает работу, или ИИ-конструктору, который превращает текст в код.

Кому он нужен

• Соло-основателям, которые хотят остановить расползание задач до того, как оно началось.
• Небольшим командам, которым нужно одно место, где хранится «что мы договорились».
• Тем, кто нанимает фрилансера или агентство: понятный PRD помогает получить точные оценки. См. нанять разработчика или создать с помощью ИИ.
• Тем, кто строит с помощью ИИ: пользовательские истории и список данных в PRD дают лучшие промпты, чем неструктурированный список пожеланий.

Что ИИ умеет хорошо, а что — нет

Самая частая ошибка — перевёрнутая последняя строка таблицы: ИИ уверенно заполняет пробелы правдоподобными догадками о ваших пользователях. Всё, что он пишет о пользователях, рынке или поведении, рассматривайте как вопрос для проверки, а не как факт.

Шаг 1. Выпишите то, что вы знаете

Прежде чем что-либо просить у ИИ, запишите черновые заметки. Пункты — это нормально. Охватите:

• Проблему в одном-двух предложениях с точки зрения пользователя.
• Кто с ней сталкивается. Будьте конкретны: «фрилансеры-бухгалтеры с 10–40 клиентами», а не «малый бизнес».
• Что они делают сейчас (таблица, почта, инструмент, который им не нравится).
• Один результат, который сделает первую версию успешной.
• То, что вы точно не будете делать.
• Жёсткие ограничения: сроки, бюджет, работа на телефонах, интеграция с уже используемым инструментом.

Если вы ещё не говорили ни с кем, у кого есть эта проблема, сделайте это в первую очередь. В руководстве как проверить идею приложения есть практичный способ. PRD, построенный на догадках, — это хорошо оформленная догадка.

Шаг 2. Попросите ИИ составить первый черновик

Вставьте свои заметки и попросите черновик в заданной структуре. Промпт, который хорошо работает:

Вот мои заметки о продукте. Превратите их в документ с требованиями к продукту, строго по этим разделам: Краткое описание, Проблема, Пользователи, Цели и метрики успеха, Объём (в работе / не входит), Пользовательские истории с критериями приёмки, Данные, Права доступа, Крайние случаи, Открытые вопросы. Документ — не больше двух страниц. Не выдумывайте фактов о пользователях или рынке: если в моих заметках чего-то нет, запишите этот вопрос в раздел «Открытые вопросы».

Последняя инструкция важна. Просьба направлять неизвестное в «Открытые вопросы», а не заполнять его, даёт гораздо более честный черновик.

Шаг 3. Доработайте каждый раздел

Пройдитесь по черновику по разделам. Эти уточняющие промпты помогают:

Проблема и пользователи

Перепишите формулировку проблемы в одном-двух предложениях с точки зрения пользователя. Без слов о решении.

Если в формулировке проблемы упоминается ваш продукт, она описывает решение, а не проблему.

Цели и метрики успеха

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

Выберите одну или две. «Двадцать бухгалтеров используют сервис каждую неделю в течение месяца» — измеримо. «Повысить продуктивность» — нет.

Объём

Перечислите всё в этом PRD, что можно перенести в следующую версию, не сломав основной сценарий.

ИИ-инструменты склонны добавлять функции. Этот промпт заставляет их делать обратное. Будьте беспощадны: большинство PRD для первой версии слишком большие. В статье что такое MVP объясняется, почему небольшие первые версии дают больше знаний.

Пользовательские истории и критерии приёмки

Запишите каждое требование как пользовательскую историю («Как [пользователь], я хочу [действие], чтобы [результат]») с двумя-четырьмя критериями приёмки в формате «Дано / Когда / Тогда».

Критерии приёмки — это чек-лист, по которому вы будете тестировать результат. «Дано: забронированный слот. Когда другой клиент смотрит календарь. Тогда слот не показан» — проверяемо. «Бронирование работает хорошо» — нет.

Крайние случаи и права доступа

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

Здесь ИИ особенно полезен: он быстро замечает пустые состояния и пробелы в правах, которые люди забывают.

Шаг 4. Проверьте как скептик

Перечитайте всё ещё раз и проверьте:

• Каждое утверждение о пользователях пришло от вас или из исследований, а не от ИИ.
• Раздел «вне объёма» как минимум не короче раздела «в объёме».
• У каждой пользовательской истории есть критерии приёмки, которые можно проверить без вопросов к вам.
• Раздел данных перечисляет каждый вид записей, которые хранит приложение, и кто их видит.
• У открытых вопросов есть ответственный и дата.
• Ничего технического не проскочило, если только это не реальное ограничение («должно работать офлайн» — требование; «используем Redis» — нет).

Затем покажите документ одному человеку, который будет пользоваться продуктом или его строить, и спросите, что неясно. Их вопросы — это и есть пробелы.

Шаблон PRD для заполнения

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

Название продукта: [название] Ответственный: [человек, который принимает решения] Статус: [черновик / на проверке / согласован] — Последнее обновление: [дата]

1. Краткое описание

[Два-три предложения: что это, для кого и главный результат.]

2. Проблема

[Проблема с точки зрения пользователя. Что они делают сейчас и почему это мешает.]

3. Пользователи

4. Цели и метрики успеха

• Цель: [результат, которого должна достичь первая версия]
• Метрика: [как вы её измерите и целевое значение]
• Не цель: [то, что люди могут предположить, но эта версия не пытается делать]

5. Объём

В первой версии:

• [функция]
• [функция]

Не в первой версии:

• [функция и почему она может подождать]
• [функция и почему она может подождать]

6. Пользовательские истории

История 1: Как [пользователь], я хочу [действие], чтобы [результат].

• Дано [контекст], когда [действие], тогда [результат].
• Дано [контекст], когда [действие], тогда [результат].

История 2: Как [пользователь], я хочу [действие], чтобы [результат].

• Дано [контекст], когда [действие], тогда [результат].

7. Данные

8. Права доступа

[Кто может войти, какие роли существуют и что каждая роль может видеть и менять.]

9. Крайние случаи

• [Пустое состояние: что показывается, когда данных ещё нет]
• [Неверный ввод: что происходит при неправильном email или пустом поле]
• [Доступ: что происходит, когда человек открывает страницу, которая ему не положена]

10. Интеграции и ограничения

[Платежи, email, существующие инструменты, сроки, бюджет, устройства, на которых всё должно работать.]

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

От PRD к промптам

Хороший PRD почти напрямую превращается в промпты для ИИ-конструктора:

• Краткое описание, пользователи и таблица данных становятся вашим первым промптом.
• Каждая пользовательская история становится одним последующим промптом.
• Каждый критерий приёмки становится тем, что вы проверяете в превью.
• Список «не в первой версии» — это то, что вы пока не просите.

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

Типичные ошибки

• Описание решения вместо проблемы. «Пользователям нужна панель» — это решение. «Владельцы не видят, какие счета просрочены, без открытия каждого из них» — это проблема.
• Нет раздела «вне объёма». Без него каждый разговор снова открывает вопрос объёма.
• ИИ придумывает пользователей. Выдуманные ИИ персоны выглядят настоящими, но ими не являются.
• Метрики, которые нельзя измерить. Если вы не можете это посчитать, это не метрика.
• Документ не обновляется. PRD, который не соответствует тому, что вы строите, хуже, чем его отсутствие. Указывайте дату последнего обновления и меняйте её, когда меняются решения.

Использование PRD в Mythex

Если вы строите в Mythex, можно вставить PRD прямо в чат. Начать в режиме Plan хорошо подходит для PRD: агент читает документ, предлагает подход и пошаговый чек-лист, который можно просмотреть на вкладке плана, и начинает менять файлы только после нажатия Build. Также можно сохранить то, что должно применяться всегда, — аудиторию, бренд, правила — как знания проекта, чтобы не повторять это в каждом чате. В документации по чату описаны режимы Build, Plan и Ask, а шаблоны — быстрый способ увидеть, как может выглядеть первая версия, прежде чем вы напишете полный документ.

Вопросы