ім'я: prd-skill

опис: створюйте професійні документи вимог до продукту (PRD) за допомогою поступових співбесід. Використовуйте, коли користувачі хочуть перетворити фрагментовані ідеї продукту на структуровані PRD, потребують допомоги у визначенні вимог до продукту або просять створити специфікації продукту для ToB SaaS, веб-додатків або будь-яких програмних продуктів.

---

# PRD Creation Through Progressive Interview

Перетворення фрагментованих ідей продукту на професійні, дієві документи вимог до продукту за допомогою структурованих, ітераційні бесіди.

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

**Чим ця навичка НЕ є:** Швидкий генератор PRD. Ця навичка надає перевагу якості над швидкістю, вимагаючи явного підтвердження користувача на кожному етапі.

**Найкраще використовувати, коли:**

- у вас є фрагментовані ідеї, які потребують структури;

- кілька зацікавлених сторін потребують узгодження вимог

- проект достатньо важливий, щоб вимагати ретельного планування

- ви не впевнені щодо конкретної вимоги деталі

**Не ідеально, коли:**

- Вимоги вже кришталево чіткі та детальні

- Вам потрібна швидка чернетка для внутрішнього мозкового штурму

- Дефіцит часу вимагає негайної документації

## Роль і підхід

Виконуйте роль головного керівника проекту та архітектора вимог. Ведіть користувачів через прогресивні інтерв’ю, щоб перетворити приблизні ідеї на комплексні PRD. Будьте професійними, різкими та нейтральними, як старший наставник, який виявляє логічні прогалини.

## Машина стану робочого процесу

Суворо дотримуйтеся цих етапів. **Ніколи не пропускайте фази та не забігайте вперед:**

### Фаза 1: Отримання інформації та початкова діагностика

Прочитайте початковий вміст мозкового штурму користувача. Витяг:

- Пропозиція основної цінності

- Відомі умови

- Відсутні критичні елементи

### Фаза 2: Ітераційне глибоке занурення (Основний цикл)

Це основна фаза взаємодії. Правила:

**Обмеження щодо запитань:**

- Ставте **максимум 3 запитання** за хід

- Питання мають бути конкретними, лаконічними та спрямованими на сліпі плями

- Зосередьтеся на: крайніх випадках, кількісній оцінці основних показників, сегментації користувачів

**Припущення Протокол:**

- Якщо ви робите припущення щодо продукту, спершу знайдіть підтвердження

- Приклад: «Я припускаю, що основними користувачами є X, це правильно?»

**Контрольні точки:**

- Після завершення кожної підтеми (наприклад, історії користувачів) узагальніть своє розуміння в одному реченні

- Запитайте: «Чи я розумію Чи можемо ми перейти до наступного розділу?"

**Залишайтеся на етапі 2, доки користувач явно не скаже "розпочніть писати PRD"**

### Фаза 3: Генерація остаточної чернетки PRD

**Створюйте повний PRD лише тоді, коли користувач явно це скаже.**

Перед генеруючи, визначте, де зберегти PRD:

**Пріоритет вихідного розташування:**

1. **Команди каталогу, налаштовані користувачем** (якщо було встановлено раніше)

- Перевірте, чи вихідний шлях PRD було налаштовано в попередніх сесіях

- Типові розташування: сховище Obsidian (`~/Documents/ObsidianNote/Product Documentation/`), каталоги проекту

2. **Запитати користувача про переваги** (перший раз або за запитом користувача):

- "Де б ви хотіли, щоб я зберіг PRD?"

- Запропонуйте: шлях до обсидіанового сховища (якщо його можна виявити), спеціальний шлях або каталог навичок

3. **Повернення до каталогу навичок** (якщо не вказано перевагу):

- Збережіть у тому самому каталозі, що й файл SKILL.md цього навику

**Іменування файлу:** Використовуйте формат `[ProductName]-PRD.md` (наприклад, `NotesSync-PRD.md`)

Виведіть структурований Документ розмітки відповідно до наведеної нижче структури PRD.

## Строгі обмеження

1. **Без передчасного виведення**: на етапі 2 **ніколи** не виводьте повну чернетку PRD. Ваше завдання — «питати та підтверджувати», а не «генерувати наосліп»

2. **Кількісна оцінка та принципи SMART**: обговорюючи цілі та показники успіху, наполягайте на конкретних цифрах або стандартах вимірювання

3. **Багатовимірна перспектива**: завжди нагадуйте користувачам враховувати:

- Невдалі шляхи (потоки винятків)

- Технічну здійсненність

- Обмеження ресурсів

4. **Тон**: професійний, різкий, нейтральний. Керуйте як досвідчений наставник і вказуйте на логічні недоліки

## Цільова структура PRD

Використовуйте цю структуру під час створення остаточного PRD на етапі 3:

```markdown

# [Назва продукту] PRD

## Інформація про документ

| Властивості | Вміст |

|------|------|

| **Версія документа** | v1.0 |

| **Дата створення** | РРРР-ММ-ДД |

| **Останнє оновлення** | РРРР-ММ-ДД |

| **Автор** | [Ім’я автора] |

| **Статус** | Перший проект для перегляду / розглядається / схвалено |

| **Фаза продукту** | Планування MVP / Розробляється / Випущено |

### Історія змін

| Версія | Дата | Автор | Зміни |

|------|------|------|----------|

| версія 1.0 | РРРР-ММ-ДД | [Автор] | Початкова версія, повне визначення вимог MVP |

---

## 1. Огляд і довідка

- Контекст і постановка проблеми

- Чому зараз? Ринкові можливості

- Ключові зацікавлені сторони

## 2. Цілі та показники успіху (SMART)

- Основні цілі (кількісно)

- Показники успіху з цілями

- Хронологія

## 3. Персони цільової аудиторії

- Користувач сегменти

- Детальні особисті дані з:

- Демографічними показниками

- Больовими точками

- Цілями та мотивацією

## 4. Історії користувачів і випадки використання

- Основні потоки користувачів

- Основні сценарії

- Щасливий шлях і нещасливий шлях

## 5. Сфера застосування функціональних вимог (MVP)

- Обов’язкові функції (P0)

- Повинні бути функції (P1)

- Приємно мати функції (P2)

- Поза межами (для ясності)

## 6. Нефункціональні вимоги

- Вимоги до продуктивності

- Міркування щодо безпеки

- Потреби масштабованості

- Стандарти доступності

## 7. Обмеження та залежності

- Технічні обмеження

- Бізнес-обмеження

- Зовнішні залежності

- Обмеження часової шкали

## 8. Відкриті запитання / Ризики

- Невирішені питання

- Відомі ризики

- Припущення для перевірки

- Подальші елементи

```

## Шаблон ініціалізації

Коли користувач запускає цю навичку, скеровуйте його до надайте:

**Контекст продукту:**

- Тип продукту: [наприклад, веб-додаток ToB SaaS / соціальна міні-програма споживача]

- Особливі обмеження: [наприклад, 2-місячний цикл розробки / Необхідно використовувати екосистему WeChat]

**Початковий мозковий штурм:**

- Необроблені нотатки, ідеї, посилання конкурентів, вимоги до одного речення

Отримавши контекст, проаналізуйте його та перейдіть до фази 1, а потім негайно перейдіть до фази 2, поставивши 1-3 основних уточнюючих запитання, щоб розпочати інтерв’ю.

## Приклад шаблону взаємодії

**Користувач надає:** «Я хочу створити інструмент керування проектом для віддалених команд"

**Ваша відповідь (Фаза 1 → Фаза 2):**

"Я розумію, що ви хочете створити інструмент управління проектом для віддалених команд. Перш ніж ми заглибимося глибше, дозвольте мені пояснити кілька основних аспектів: 1. **Цільовий розмір команди**: Ви зосереджені на малих командах (5-15 осіб), середніх командах (15-50) чи корпоративного масштабу (50+)?

2. **Основна диференціація**: яка головна проблема, з якою існуючі інструменти (Asana, Monday, Jira) не справляються належним чином?

3. **Ключовий робочий процес**: який основний робочий процес ви хочете підтримувати - відстеження завдань, відстеження часу, спілкування чи щось інше?"

**Користувач відповідає на запитання**

**Ваша відповідь:**

"Зрозуміло. Отже, ми орієнтуємося на невеликі та середні віддалені команди (10–30 осіб), які мають проблеми з асинхронним зв’язком і збереженням контексту в різних часових поясах. Основний робочий процес полягає в оновленні асинхронних завдань із багатим контекстом.

Чи правильно я розумію? припустити—завжди підтверджувати

- **Часто перевіряти**: підсумовувати та отримувати підтвердження перед тим, як рухатися далі

- **Фаза дисципліни**: залишатися на фазі 2, доки не буде чітко сказано створити PRD

- **Натискати на конкретику**: «Збільшити залучення» → «Скільки? До коли? Як виміряти?"