Що таке PRD document?

PRD  (Product Requirements Document). Документ для команди розробки та стейкхолдерами. Ось які проблеми він допомагає вирішити:

☝ Чітке бачення продукту: PRD допомагає сформулювати цілі та завдання продукту так, щоб усі члени команди чітко розуміли, над чим вони працюють.

☝ Зниження ризиків: Завчасно опрацьований PRD дозволяє виявити потенційні проблеми та вразливості проєкту, що знижує ризик невдалого запуску.

☝ Покращена комунікація: PRD є центральним документом, що покращує комунікацію між усіма учасниками проєкту, включаючи дизайнерів, розробників, маркетологів і продакт-менеджерів.

З чого складається PRD?

1. Purpose — передісторія створення продукту: з якою метою він розроблений, яку проблему вирішує, які бізнес-цілі переслідує.

2. Customer & Value — інформація про користувачів продукту: хто вони, які у них проблеми та завдання, як вони їх вирішують зараз; яку цінність пропонує ваш продукт і які є ризики.

3. Solution — детальний опис рішення (тобто продукту, який ви будете розробляти): властивості продукту на високому рівні; план роботи над проєктом.

4. Execution — стратегія запуску та план дій після виходу продукту.

Як застосовувати PRD?

PRD використовується як відправна точка для розробки продукту. Він є основою для створення плану розробки, визначення бюджету та встановлення термінів.

Що далі?

PRD — це живий документ. Він може змінюватися та доповнюватися в міру розвитку проєкту. Важливо підтримувати його актуальність і оновлювати за потреби.

На проєктах  PRD використовують для максимально прозорої комунікації між усіма учасниками процесу. Як це виглядає на практиці?

• PRD створюється спільно з фаундером і стейкхолдерами. Документ проходить кілька етапів рев’ю. Після першої ітерації документ може здаватися достатньо повним і зрозумілим, але це часто оманливе відчуття :)

• Обов’язково дайте прочитати PRD комусь із дизайнерів та розробників. Постарайтеся отримати зворотний зв’язок: чи все зрозуміло у цьому документі? Чи може ваш колега після його прочитання відповісти на основні питання про продукт? PRD також можна завантажити в ChatGPT і попросити поставити вам питання, на які у документі немає відповідей.

• Для постановки задач дизайнерам я використовую PRD (розділ Solution) як основу для ТЗ. У цьому розділі рекомендую детально та просто описати всі функціональні модулі продукту.

• Команди дизайну та розробки можуть ставити питання у вигляді коментарів, і таким чином PRD постійно доповнюється та актуалізується.

ЩО МАЄ МІСТИТИ ВИМОГА ДО ПРОДУКТУ?

1. Структура Product Requirements Document (PRD)

1. Чіткі можливості для випуску

   • PRD має містити всі функціональні можливості, необхідні для релізу.

   • Для кожної бажаної функції повинен бути варіант використання (use case), що показує, як користувач взаємодіятиме з цією функціональністю.

   • Ці варіанти використання допомагають інформувати план тестування.

2. Додаткові деталі для складних функцій

   • Якщо функція є складною, рекомендується розбити її на підпункти.

   • Кожен підпункт (якщо доречно) також має мати свій власний варіант використання.

3. Огляд і мета випуску

   • PRD має детально описувати, чого саме прагне досягти команда продукту в межах цього конкретного випуску.

   • Не дублює інформацію з MRD, але деталізує завдання саме для поточного релізу (адже MRD може покривати кілька релізів одного продукту чи набору продуктів).

4. Інші вимоги

   • Системні вимоги чи вимоги до середовища (наприклад, підтримка певних операційних систем, браузерів тощо).

   • Вимоги до юзабіліті (наприклад, навігація однією рукою для мобільних додатків).

5. Припущення, обмеження та залежності

   • Припущення: те, що очікується, але не гарантовано (наприклад, доступ до Інтернету в усіх користувачів).

   • Обмеження: бюджетні, технічні чи інші фактори, які обмежують реалізацію.

   • Залежності: зовнішні умови чи інструменти, від яких залежить продукт (наприклад, інтеграція з Google Maps).

     
     

2. Приклад документа з вимогами до продукту

Нижче наведено основний план, який зазвичай включають у PRD (кістяк, який можна доповнювати залежно від проекту):

1. Завдання / ціль

   • Пояснити, навіщо створюється продукт (чи функція) і чого сподіваються досягти.

2. Особливості (Features)

   • Для кожної функції:

     • Опис (що це за функція та її призначення).

     • Мета (яку бізнес- або користувацьку проблему вона вирішує).

     • Варіант використання (use case), щоб показати, як користувач її застосовуватиме.

   • За потреби зазначити додаткові деталі (наприклад, що лежить поза межами сфери реалізації).

3. Примітки щодо потоку та дизайну UX

   • Загальний опис робочого процесу користувача.

   • Без надмірно деталізованих макетів або wireframes (це зазвичай роблять після затвердження PRD).

   • Мета — підтвердити, що цілі випуску досяжні з точки зору UX.

4. Вимоги до системи та середовища

   • Які середовища кінцевого користувача будуть підтримуватись (браузери, ОС, пам’ять, обчислювальна потужність тощо).

5. Припущення, обмеження та залежності

   • Повторити або деталізувати те, що може вплинути на реалізацію:

     • Припущення: очікувані, але не гарантовані умови.

     • Обмеження: фінансові, технологічні та інші рамки.

     • Залежності: сторонні інструменти, інтеграції, умови.

3. Етапи створення PRD

1. Консультація з маркетингом продукту (за наявності MRD)

   • Переконатися, що команда повністю розуміє бізнес-мотивації для релізу, який описується в PRD.

   • Використати наявні методи пріоритезації для визначення сфери випуску.

2. Створення документа

   • Використовувати нотатки та відгуки користувачів, які стосуються кожної функції, запланованої в релізі.

   • Документ має пройти кілька раундів внутрішнього перегляду в команді продукту (для уточнення всіх можливих запитань).

3. Перевірка з бізнес-стейкхолдерами

   • Поширити PRD серед бізнес-зацікавлених сторін, щоб перевірити й узгодити:

     • Чи відповідає документ меті випуску?

     • Чи правильно описані функції, необхідні для досягнення цієї мети?

4. Технічний огляд і доопрацювання

   • Надання PRD інженерам для оцінки та уточнення технічних деталей.

   • Запитання та зауваження розглядаються усно або шляхом внесення правок до документа.

   • Мета: зробити PRD достатньо чітким і повним, щоб уникнути сюрпризів у подальшому.

5. Передача іншим командам

   • Після узгодження з інженерами PRD передається командам дизайну UX та тестувальникам.

   • На основі PRD розробляють функціональні специфікації, дизайн UX та тест-план.

6. Залучення всіх учасників процесу

   • Завдяки спільній роботі над PRD, кожен знає:

     • Що буде реалізовано.

     • Яку користь принесе це бізнесу.

     • Як це вплине на кінцевих користувачів.

Підсумовуючи: Product Requirements Document (PRD) — це життєво важливий документ, який чітко описує цілі релізу, функції, варіанти використання, припущення, обмеження та залежності. Від ретельності та повноти PRD залежить узгодженість дій між бізнесом, технічною командою та всіма зацікавленими сторонами, а також успішна реалізація і впровадження кінцевого продукту.