Шаблон PRD (документ вимог до продукту) + повний приклад для копіювання
Востаннє оновлено: 28 липня 2026.
Більшість сторінок із шаблоном документа вимог до продукту дають вам порожню форму. У Atlassian це чотири розділи інструкцій навколо порожньої таблиці метрик успіху. У Product School в назві є «(with Example)», але прикладу немає. Блок markdown із 12 розділів нижче — це весь шаблон, без реєстрації, готовий до копіювання. Розділ 4 далі заповнює кожен із цих 12 розділів на повноцінному практичному прикладі: портал для рахунків клієнта, який зчитує PDF за допомогою LLM і направляє сумнівні випадки людині. Скопіюйте порожній. Прочитайте заповнений. Напишіть свій.
Ключові висновки
- PRD відповідає на питання що будувати і навіщо; технічний дизайн-документ відповідає на як.
- 12 розділів підходять для проєкту будь-якого розміру. One-pager — це той самий шаблон, лише з меншою кількістю рядків.
- Non-goals обов'язково потрібно прописувати. AI-агент для кодингу не може здогадатися про межі обсягу з того, що не написано.
- Критерії приймання мають бути перевірюваними машиною: «p95 under 400ms», а не «швидко».
Яку форму PRD обрати?
Обирайте форму за тим, хто читатиме документ, а не за тим, наскільки великим здається продукт. Окрема фіча для власних інженерів потребує one-pager. Розробка, яку передають зовнішній команді, потребує повного PRD з 12 розділів, бо критерії приймання одночасно є точками затвердження (sign-off gates). Специфікація для AI-агента для кодингу потребує тих самих дванадцяти розділів, розрізаних на фази.
| Форма проєкту | Що використовувати | Розділи, які реально заповнюються | Типова довжина |
|---|---|---|---|
| Окрема фіча, один спринт | One-pager | Проблема, цілі, non-goals, користувацькі історії, відкриті питання | ~1 сторінка |
| Повна фаза продукту, внутрішня команда | Стандартний PRD з 12 розділів | Усі 12 | 3-5 сторінок |
| Розробка, передана агенції чи підряднику | PRD з 12 розділів, критерії приймання як точки затвердження | Усі 12, з чітко заповненими NFR та власниками відкритих питань | 5-8 сторінок |
| Специфікація для AI-агента для кодингу | PRD з 12 розділів, розрізаний на фази | Усі 12, плюс шляхи до файлів, обмеження стеку, список «не чіпати» | 1-2 сторінки на фазу |
Шаблон документа вимог до продукту на одну сторінку, який усі шукають, — це не окремий артефакт. Широко скопійований one-pager Ленні Рачицького, опублікований з реальними прикладами в його розсилці, — той самий скелет, лише без зайвої церемонії. One-pager — не інший документ. Це ті самі дванадцять розділів із видаленими порожніми рядками.
Agile-команди теж часто ставлять це питання, зазвичай формулюючи його як: чи витримує PRD, коли з'являється беклог. Витримує — у форматі one-pager: PRD зберігає «навіщо» і межі, а тікети — саму роботу.
Шаблон PRD (Markdown для копіювання)
Ось усе це у форматі markdown, безкоштовно, без форми для email. Вставте це в Notion, Confluence, Google Docs, Linear, Word або закомітьте в GitHub як PRD.md, щоб він версіювався разом із кодом. Люди просять цей шаблон у дев'яти різних форматах; markdown — той, що переживає вставку в усі з них, і єдиний, який AI-агент для кодингу читає без спотворень.
# PRD: [Назва продукту або функції]
## 1. Заголовок
- Власник (продукт):
- Керівник розробки:
- Керівник дизайну:
- Статус: Чернетка | На перегляді | Затверджено | Випущено
- Останнє оновлення:
- Історія змін: дата / автор / що змінилося
## 2. Постановка проблеми
Один абзац. Кому болить, як часто, у скільки це обходиться зараз. Без мови рішень.
## 3. Цілі та метрики успіху
| Ціль | Метрика | Базове значення | Ціль | Як вимірюється | Дата |
|---|---|---|---|---|---|
## 4. Non-goals
Сформульовані позитивно: «Ця фаза не включає X».
## 5. Користувачі та персони
Хто це використовує, що вони вже знають, який пристрій, як часто.
## 6. Користувацькі історії та критерії приймання
Як [персона], я хочу [дія], щоб [результат].
- Given [контекст], when [подія], then [спостережуваний результат].
## 7. Функціональні вимоги
Пронумеровано. Одна вимога на рядок. Тестовано. Жодного речення зі словом «і».
## 8. Нефункціональні вимоги
Продуктивність / безпека та ізоляція орендарів / резидентність та зберігання даних / доступність (accessibility) / безвідмовність (availability).
## 9. Залежності та інтеграції
Зовнішні системи, API, облікові дані, хто володіє доступом, час на підключення.
## 10. Віхи та фазування
| Фаза | Обсяг | Критерії виходу | Цільова дата |
|---|---|---|---|
## 11. Відкриті питання та ризики
| Питання або ризик | Власник | Потрібно до | Вплив, якщо не відповісти |
|---|---|---|---|
## 12. Додаток і посилання
Дизайни, дослідження, нотатки про конкурентів, попередні тікети, контракти.Дванадцять розділів по порядку: заголовок, постановка проблеми, цілі та метрики успіху, non-goals, користувачі та персони, користувацькі історії з критеріями приймання, функціональні вимоги, нефункціональні вимоги, залежності та інтеграції, віхи та фазування, відкриті питання та ризики, додаток.
Що повинен містити PRD? 12 розділів і слабка версія кожного
Документ вимог до продукту повинен містити постановку проблеми, вимірювані цілі, явні non-goals, персони, користувацькі історії з критеріями приймання, функціональні та нефункціональні вимоги, залежності, віхи, відкриті питання з власниками та історію змін. Усе інше — додаток. Тест для кожного рядка той самий, що ISO/IEC/IEEE 29148:2018 застосовує до вимог загалом: перевірюваність, однозначність, єдиність.
Більшість PRD провалюють цей тест в одних і тих самих трьох місцях.
| Розділ | Слабка версія | Сильна версія |
|---|---|---|
| Постановка проблеми | «Обробка рахунків повільна». | «Операційний персонал вручну перевносить 300+ invoices a week; середній час обробки — 6 minutes; 4% містять помилку введення, яку виявляють лише при звірці». |
| Метрика успіху | «Покращити ефективність». | «Скоротити середній час обробки з 6 minutes до менш ніж 90 seconds до 2026-11-01, за виміром на операційній панелі». |
| Користувацька історія | «Користувачі повинні мати змогу шукати». | «Користувачі можуть фільтрувати список рахунків за постачальником, діапазоном дат і статусом; результати повертаються менш ніж за 400ms p95; порожній стан показує дію Clear filters». |
| Non-goal | (розділ залишено порожнім) | «Ця фаза не підтримує мультивалютні рахунки або зворотний запис в ERP». |
| Нефункціональна вимога | «Має бути безпечним і швидким». | «Ізоляція на рівні рядків для кожного орендаря, перевірена автоматичним тестом при кожному релізі; список рахунків p95 under 400ms». |
| Відкрите питання | «TBD: потреби зі звітності» | «Який PO number є визначальним, якщо рахунок показує два? Власник: директор з операцій клієнта. Потрібно до 2026-08-08». |
Двом розділам зазвичай приділяють менше уваги, ніж вони заслуговують.
Нефункціональні вимоги — це те місце, де обсяг непомітно подвоюється. Продуктивність, ізоляція орендарів, резидентність даних, зберігання, доступність, безвідмовність — кожен із цих пунктів є інженерним рішенням із власною ціною, і жоден не з'являється в користувацькій історії. Пропишіть рядок про безпеку тут, а не як розмиту фразу, і сформулюйте його так, як хочете, щоб його перевіряли — за орієнтир можна взяти наш чек-лист безпеки перед запуском. Якщо в розробці є AI-компонент, вимоги до готовності до продакшену теж належать сюди, а не до пізнішої фази «зміцнення», яку так ніколи й не запланують: наш чек-лист переходу від PoC до продакшену — це версія, яку використовуємо ми.
Відкриті питання потребують трьох колонок, а не однієї. Питання, власник, дата «потрібно до». Питання без власника — це рішення, яке ніхто не приймає, і воно спливе як запит на зміну на шостому тижні. Варто зазначити: PRD пишуть уже після того, як вирішили розробляти, а не купувати. Якщо постановка проблеми досі читається як список бажаних фіч, рішення «розробляти чи купувати» ще фактично не ухвалене.
Практичний приклад: заповнений PRD для порталу рахунків
Ось повний практичний приклад із заповненими всіма 12 розділами. Розробка: портал для рахунків клієнта для логістичного оператора середнього розміру. Клієнти завантажують PDF-рахунки, LLM видобуває позиції, система позначає розбіжності з даними замовлення, а все, у чому вона не впевнена, потрапляє в чергу перевірки людиною. Стек: Next.js, Supabase/Postgres, один крок видобування LLM. Копіюйте, друкуйте, експортуйте в PDF — що вам потрібно.
# PRD: Портал для рахунків клієнтів, Фаза 1
## 1. Заголовок
- Власник (продукт): Директор з операцій, клієнтська сторона
- Керівник розробки: Delivery lead, Techsy
- Керівник дизайну: Продуктовий дизайнер, Techsy
- Статус: Затверджено для розробки
- Останнє оновлення: 2026-07-28
- Історія змін:
- 2026-07-14 / продукт / перший чернетковий варіант
- 2026-07-21 / розробка / додано правило порогу впевненості до 6.2
- 2026-07-28 / продукт / перенесено зворотний запис в ERP до non-goals
## 2. Постановка проблеми
Операційний персонал отримує рахунки клієнтів у вигляді PDF-файлів електронною
поштою і вручну вносить їх у систему замовлень. Обсяг перевищує 300 invoices a week,
середній час обробки — близько 6 minutes кожен, і приблизно 4% містять помилку
введення, яку виявляють лише при звірці наприкінці місяця. Кожне виправлення коштує
повторного проходу і дзвінка.
## 3. Цілі та метрики успіху
| Ціль | Метрика | Базове значення | Ціль | Як вимірюється | Дата |
|---|---|---|---|---|---|
| Скоротити ручну обробку | Середній час обробки | 6 min | under 90 sec | Операційна панель, тижнева медіана | 2026-11-01 |
| Скоротити помилки введення | Рахунки, виправлені при звірці | 4% | under 1% | Місячний звіт фінансів | 2026-12-01 |
| Утримати навантаження на перевірку | Частка, направлена на перевірку людиною | n/a | under 25% | Метрики черги порталу | 2026-11-01 |
## 4. Non-goals
Ця фаза не підтримує мультивалютні рахунки, зворотний запис в ERP, самообслуговування
клієнтів для кредит-нот або мобільний застосунок. Видобування охоплює лише PDF.
Фотографії паперових рахунків і скани нижче 200 DPI відхиляються при завантаженні
з поясненням причини.
## 5. Користувачі та персони
- Операційний клерк (основний, 6 осіб): працює з чергою винятків цілий день,
глибоке знання предметної області, лише desktop.
- Контакт клієнта з AP (зовнішній, ~140 акаунтів): завантажує рахунки, низька
толерантність до тертя при налаштуванні акаунта.
- Фінансовий менеджер (другорядний): бере місячний звіт, потребує аудиторського
сліду по кожному рахунку.
## 6. Користувацькі історії та критерії приймання
6.1 Як контакт клієнта з AP, я хочу завантажити PDF-рахунок, щоб не надсилати
його поштою і не чекати.
- Given PDF розміром до 20 MB і 200 DPI або краще, when я завантажую його, then
портал повертає номер посилання протягом 5 секунд і показує «Обробляється».
6.2 Як операційний клерк, я хочу, щоб видобування з низькою впевненістю
затримувалося, щоб нічого неправильного не затверджувалося автоматично.
- Given розібраний рахунок, when впевненість видобування для будь-якої позиції
нижче 0.85, then рахунок направляється в чергу перевірки і ніколи не
затверджується автоматично.
6.3 Як операційний клерк, я хочу бачити розбіжність в одному місці, щоб
розв'язати її, не відкриваючи систему замовлень.
- Given рахунок, зіставлений із замовленням, when будь-яка кількість чи ціна за
одиницю в рядку відрізняється від даних замовлення, then портал показує обидва
значення поряд і позначає різницю.
6.4 Як фінансовий менеджер, я хочу фільтрувати рахунки, щоб закрити місяць.
- Given список рахунків, when я фільтрую за постачальником, діапазоном дат і
статусом, then результати повертаються менш ніж за 400ms при p95, а порожній
стан пропонує «Clear filters».
## 7. Функціональні вимоги
1. Завантаження приймає лише PDF, максимум 20 MB, один файл на подання.
2. Видобування повертає постачальника, номер рахунка, дату, валюту та позиції
з кількістю, ціною за одиницю і сумою.
3. Кожна позиція має оцінку впевненості від 0 до 1.
4. Зіставлення порівнює видобутий рахунок із відкритим замовленням за PO number.
5. Винятки потрапляють у чергу, впорядковану від найстаріших, призначувану
одному клерку.
6. Кожна зміна стану записує запис аудиту з автором дії, часовою міткою,
попереднім значенням.
7. Затверджені рахунки експортуються пакетом CSV для фінансової системи.
## 8. Нефункціональні вимоги
- Продуктивність: список рахунків p95 under 400ms. Видобування завершується
протягом 90 sec після завантаження при p95.
- Безпека та ізоляція орендарів: ізоляція на рівні рядків бази даних для
кожного орендаря. Клієнт ніколи не може прочитати рахунок іншого клієнта.
Перевіряється автоматичним тестом при кожному релізі.
- Резидентність і зберігання даних: документи зберігаються в ЄС. Оригінали
зберігаються 7 years, дані видобування — 90 days.
- Доступність (accessibility): черга повністю керована з клавіатури,
контраст WCAG 2.2 AA.
- Безвідмовність (availability): 99.5% щомісяця, підтримка в робочі години.
## 9. Залежності та інтеграції
- Дані замовлень: репліка Postgres лише для читання. Доступ належить IT
клієнта, облікові дані потрібні до 2026-08-15.
- Провайдер видобування LLM: контракт і угода про обробку даних підписані
до початку розробки.
- Email-сповіщення: наявний транзакційний провайдер, домен відправника
перевірений клієнтом.
## 10. Віхи та фазування
| Фаза | Обсяг | Критерії виходу | Цільова дата |
|---|---|---|---|
| P1 | Завантаження, видобування, маршрутизація за впевненістю | 50 реальних рахунків від початку до кінця, under 25% у черзі | 2026-09-19 |
| P2 | Зіставлення замовлень і перегляд розбіжностей | Розбіжність коректно позначена на 20 підготовлених випадках | 2026-10-10 |
| P3 | Аудиторський слід, експорт CSV, звітність | Фінанси закривають один місяць у порталі | 2026-11-01 |
## 11. Відкриті питання та ризики
| Питання або ризик | Власник | Потрібно до | Вплив, якщо не відповісти |
|---|---|---|---|
| Який PO number визначальний, якщо рахунок показує два? | Директор з операцій клієнта | 2026-08-08 | Логіка зіставлення заблокована |
| Чи надсилають 12 найбільших клієнтів скановані чи нативні PDF? | Delivery lead | 2026-08-08 | Поріг впевненості може бути неправильним |
| Чи підтверджено 7-річне зберігання з юристами клієнта? | Фінансовий менеджер клієнта | 2026-08-22 | Дизайн і вартість зберігання зміняться |
| Вартість видобування на рахунок при 300/week | Delivery lead | 2026-09-05 | Юніт-економіка невідома |
## 12. Додаток і посилання
Анонімізований набір зразкових рахунків (40 файлів), схема таблиці замовлень,
поточне дослідження часу обробки, Figma-флоу для завантаження і черги, підписана
угода про обсяг робіт (statement of work).Чотири рішення тут варті окремої згадки, бо лінива версія кожного з них коштує реальних грошей.
Розділ 3, базове значення. «6 minutes» — це не прикраса. Без базового значення ви не можете сказати, спрацювало щось чи ні, а через півроку хтось сперечається про це на нараді без жодних даних. Лінива версія, «покращити ефективність», робить проєкт неспростовним.
Розділ 4, non-goal. Зворотний запис в ERP перенесли до non-goals 2026-07-28, після того як його припустили як само собою зрозумілий пункт під час дзвінка з переглядом. Записати це як non-goal коштувало одного рядка і врятувало від суперечки про обсяг.
Розділ 6.2, поріг впевненості. Це правило, яке найчастіше пропускають наші власні перші чернетки. Якщо його прибрати, система автоматично затверджує рахунки, які мала б побачити людина, — і саме це зводить нанівець економію часу, обіцяну в розділі 3.
Розділ 11, власники. У кожного відкритого питання є ім'я і дата. Ця колонка — це різниця між документом і списком справ, який нікому не належить.
PRD говорить вам що. Він не говорить вам скільки часу чи скільки грошей — це окрема вправа: дивіться визначення обсягу розробки для цієї частини. І non-goal, який ви не записали, — це фіча, яку хтось таки збудує.
Як написати PRD, за яким AI-агент для кодингу справді зможе будувати?
PRD, написаний для AI-агента для кодингу, міняє стислість на явність. У агента немає неформального спільного контексту, немає спільної історії і немає інтуїції щодо того, що ви «очевидно» не мали на увазі. Чотири правила покривають більшу частину різниці, і вони випливають зі спостережень за тим, які специфікації спрацьовували, а які провалювалися в наших власних розробках за участю агентів.
1. Формулюйте non-goals позитивно. Люди здогадуються про межі обсягу з того, що не написано. Агенти — ні. «Не додавайте автентифікацію на цій фазі» має бути реченням у документі, інакше автентифікацію збудують, протестують і повернуть вам готовою.
2. Розрізайте роботу на фази відповідного розміру. Один моноліт на 40 сторінок породжує впевнений, розлогий, наполовину правильний pull request. Розріжте PRD на проходи, які агент завершує за один обмежений запуск, кожен зі своїми критеріями виходу.
3. Робіть критерії приймання перевірюваними машиною. «Швидко» — це не вимога, це настрій. «p95 under 400ms on the invoice list endpoint» — це тест, який агент може написати ще до того, як напише саму фічу.
4. Прописуйте шляхи до файлів і обмеження стеку в документі, а не в чаті. Контекст чату випаровується між сесіями. Специфікація — ні. Саме тому важливий plan mode у Claude Code: він читає ваші файли і пропонує план, нічого не редагуючи, доки ви не погодите, і цей крок затвердження набагато корисніший, коли план звіряється з письмовою специфікацією, а не з вашою пам'яттю про те, що ви просили.
Ось портал рахунків, розрізаний на одну фазу, яку агент може виконати за один прохід.
# Завдання для розробки: Завантаження та видобування рахунків (Фаза 1 з 3)
## Обмеження стеку (не замінювати)
Next.js 15 App Router, TypeScript, Supabase Postgres із row-level security,
розгортання на Vercel. Жодних нових залежностей без попереднього запитання.
## Файли, які можна створювати або редагувати
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql
## Не чіпати
- lib/auth/* (автентифікація виходить у Фазі 2; не додавайте флоу входу зараз)
- Усе під app/(marketing)/
- Наявна схема замовлень (orders). Читайте її. Ніколи не мігруйте її.
## Критерії приймання (спочатку напишіть їх як тести)
1. POST /api/invoices відхиляє не-PDF файли з кодом 415 і файли понад 20 MB з
кодом 413.
2. Позиція з confidence < 0.85 встановлює invoice.status = 'review',
ніколи 'approved'.
3. Кожен insert записує рядок аудиту з actor_id, action, created_at.
4. GET /api/invoices?vendor=&from=&to=&status= повертає результат менш ніж за
400ms на 10,000-row seed.
## Поза межами цього проходу
Зіставлення замовлень, UI розбіжностей, експорт CSV, email-сповіщення.Порівняно з людською версією змінилися три речі: з'явилися шляхи до файлів, з'явився список «не чіпати», а критерії приймання перетворилися з речень на твердження. Якому агенту ви це передасте, важить менше, ніж здається, хоча порівняння AI-агентів для кодингу варте прочитання перед тим, як зобов'язатися. Тримайте вимоги та правила проєкту в окремих файлах: Cursor rules і CLAUDE.md містять конвенції та інструментарій, а PRD — що будувати. Якщо ви хочете, щоб AI допоміг зі створенням обсягу, а не лише споживав його, це вже інший процес. А для самого кроку видобування вибір моделі та цикл оцінювання — це вже окрема робота з AI-інтеграції.
Що змінюється, коли PRD передають зовнішній команді
Коли PRD передають агенції чи підряднику, він перестає бути документом для узгодження і стає мовою контракту. Неоднозначність, яку внутрішня команда розв'язує двохвилинною розмовою, перетворюється на запит на зміну з ціною. Дослідження PMI Pulse of the Profession показало, що 47% неуспішних проєктів не досягають цілей через неточне управління вимогами. Саме заради цього і існує цей документ.
Три розділи в такій ситуації набувають непропорційної ваги. Критерії приймання стають точками затвердження, тож вони мають бути спостережуваними для людини, яка не є інженером. Відкриті питання потребують названого власника з боку клієнта, бо підрядник не може на них відповісти і побудує щось навколо цієї прогалини. А історія змін перестає бути бюрократією: це запис про те, що і коли було погоджено, — перше, до чого звертаються під час суперечки.
Рядок, який ми не раз бачили таким, що йде не так, — це якийсь варіант «користувачі можуть експортувати свої дані». Ніхто не записує, у якому форматі. Дорога версія цього для нас втілилася в експорт CSV, тоді як клієнт мав на увазі оформлений PDF-пакет рахунків із власним брендингом, і переробка спалила близько тижня розробки, який ніхто не закладав у обсяг. Чесне прочитання — провина лежала в документі, а не в постачанні. Критерій приймання спіймав би це за п'ять хвилин: given запит на експорт, when файл згенеровано, then це PDF, що відповідає наданому макету. Рядок non-goals спіймав би це теж, з іншого боку. Тож тепер це правило в нашому дискавері: будь-яка вимога, що спирається на іменник на кшталт «export», «report» чи «notification», отримує формат, тригер і прикріплений практичний приклад, перш ніж підписати statement of work.
Це і є більшість того, чим насправді є те, як ми ведемо розробку веб-застосунків: перетворення розмитої половини специфікації клієнта на перевірювані рядки ще до того, як хтось напише код.
Що насправді кажуть про шаблони PRD на r/ProductManagement
Введіть у пошук product requirements document template reddit, і ви побачите одну й ту саму скаргу, яка повторюється на r/ProductManagement: роздутість шаблонів. PRD, які ніхто не читає. Розділи заповнені лише тому, що в шаблоні був заголовок, а не тому, що комусь був потрібен вміст. Документи, які застарівають наступного дня після старту і тихо замінюються тредом у Slack. Це справедлива критика більшості шаблонів, включно з кількома серед перших десяти результатів за цим запитом.
Наша відповідь: видаляйте розділи, а не заповнюйте їх нічим. Персони йдуть першими на видалення, коли користувачі очевидні. Додаток — другий. Віхи можуть жити в трекері замість документа. Єдиний розділ, який ми ніколи не видаляємо, — non-goals, бо це єдиний розділ, який стає коротшим що більше роботи ви виконуєте, і єдиний, що надійно запобігає суперечці, яка інакше виникла б на шостому тижні.
Про автора
Mert Batur Gurbuz, співзасновник, Techsy.io. Кваліфікація: співзасновник Techsy.io, University of Birmingham. LinkedIn
Mert Batur Gurbuz — співзасновник Techsy.io, де команда випускає AI-агентів, системи автоматизації та voice/SDR-пайплайни для B2B-клієнтів. Він навчається в University of Birmingham і пише про стек LLM-інструментів, який команда Techsy справді використовує в продакшені.
Часті запитання
Що таке документ вимог до продукту?
Документ вимог до продукту (PRD) визначає, що команда будує і навіщо: проблему, цілі та їхні метрики, non-goals, для кого це, і вимоги, які визначають «готово». Він свідомо не містить деталей реалізації — вони належать до технічного дизайн-документа, який пізніше пише розробка.
Як написати документ вимог до продукту?
Почніть із постановки проблеми і не використовуйте в ній мову рішень. Додайте вимірювані цілі з базовим значенням і цільовою датою, потім пропишіть non-goals. Заповніть персони, користувацькі історії з критеріями приймання Given/When/Then, функціональні та нефункціональні вимоги, залежності, віхи та відкриті питання з власниками.
Що повинен містити PRD?
Дванадцять розділів: заголовок з історією змін, постановка проблеми, цілі та метрики успіху, non-goals, користувачі та персони, користувацькі історії з критеріями приймання, функціональні вимоги, нефункціональні вимоги, залежності та інтеграції, віхи та фазування, відкриті питання та ризики, і додаток. Усе, що не вписується в жоден із цих пунктів, найімовірніше, не є вимогою.
Якою має бути довжина PRD?
Від однієї до двох сторінок для окремої фічі, від трьох до п'яти — для фази продукту, від п'яти до восьми — коли розробку веде зовнішня команда і критерії приймання виконують роль точок затвердження. Довжина залежить від кількості зафіксованих рішень, а не від розміру продукту. Порожні розділи слід видаляти, а не наповнювати водою.
Чи PRD і BRD — це одне й те саме?
Ні. Документ бізнес-вимог (BRD) описує комерційний результат, якого хоче організація, і обмеження навколо нього, зазвичай ще до вибору рішення. PRD описує продукт, який цей результат забезпечує: користувачів, поведінку, критерії приймання, non-goals. У менших компаніях BRD часто зводиться просто до розділу постановки проблеми.
Чи пишуть Agile-команди PRD?
Так, зазвичай у форматі one-pager. Беклог утримує роботу, але тікети погано зберігають «навіщо», non-goals і метрику успіху. Команди, які повністю пропускають PRD, зазвичай наново винаходять його у вигляді сторінки Confluence під назвою «context» вже на третьому спринті проєкту.
Чи можна написати PRD у markdown?
Markdown — найкращий формат для цього. Він чисто вставляється в Notion, Confluence, Google Docs і Linear, версіюється в Git поруч із кодом як PRD.md, коректно показує diff у pull request і є єдиним форматом, який AI-агент для кодингу читає, не втрачаючи структуру. Шаблон вище — markdown саме з цих причин.
Як написати PRD для AI-агента для кодингу?
Будьте явними там, де зазвичай були б стислими. Формулюйте non-goals позитивно, бо агент не може здогадатися про межі обсягу з того, що не написано. Розріжте документ на фази, які можна завершити за один прохід. Пишіть критерії приймання як твердження з числами. Назвіть файли, які агент може редагувати, і ті, яких не може чіпати.
У чому різниця між PRD і технічним дизайн-документом?
PRD відповідає на що і навіщо: проблема, користувачі, поведінка, критерії приймання, non-goals. Технічний дизайн-документ відповідає на як: архітектура, модель даних, контракти API, розглянуті компроміси. Перший зазвичай належить продукту, другий — розробці, і дизайн-документ повинен читатися як відповідь на PRD.
Хто володіє PRD — продукт, розробка чи клієнт?
Продукт володіє документом і рішеннями в ньому. Розробка володіє зворотним зв'язком щодо здійсненності та нефункціональними вимогами. У розробці через агенцію клієнт володіє постановкою проблеми, цілями і кожним відкритим питанням про власний бізнес. Спільне володіння всім документом зазвичай означає, що ніхто його не підтримує.
Підсумок
Три речі варто запам'ятати. Шаблон корисний лише тоді, коли він заповнений, тож копіюйте форму практичного прикладу, а не порожню. Non-goals — розділ із найвищою цінністю на слово в усьому документі, і перший, який пропускають. А критерії приймання, написані як перевірювані твердження, однаково добре слугують двом читачам: інженеру, що затверджує постачання, і агенту, що пише тест.
Якщо ви пишете PRD, щоб передати його зовнішній команді, і хочете, щоб хтось ще подивився на нього до того, як він стане контрактом, ми з радістю прочитаємо його і позначимо неоднозначні рядки. Це той самий прохід, який ми робимо на власних розробках веб-застосунків.