Этап 2: PRD - Создание документа требований к продукту

Этап PRD — это второй этап конвейера Agent App Factory, отвечающий за преобразование input/idea.md в полный документ требований к продукту, ориентированный на MVP (минимально жизнеспособный продукт). На этом этапе определяются целевые пользователи, основные функции, объем MVP и цели за рамками проекта, что обеспечивает четкое руководство для последующего проектирования UI и технической архитектуры.

Чему вы научитесь

• Преобразовывать input/idea.md в документ artifacts/prd/prd.md, соответствующий стандартному шаблону
• Понимать границы ответственности PRD Agent (только определение требований, без технической реализации)
• Осваивать фреймворк приоритизации функций MoSCoW, обеспечивая фокус на основной ценности MVP
• Составлять качественные пользовательские истории и проверяемые критерии приемки
• Знать, какой контент следует включать в PRD, а что оставить для последующих этапов

Трудности, с которыми вы столкнетесь

Возможно, у вас есть четкая идея продукта (этап Bootstrap завершен), но при преобразовании в документ требований возникают трудности:

• "Не знаю, какие функции должны быть включены, боюсь что-то упустить или перегрузить дизайн"
• "Много функций, но не знаю, какие необходимы для MVP"
• "Пользовательские истории написаны нечетко, команда разработки не может их понять"
• "Случайно смешал детали технической реализации с требованиями, что привело к расширению объема"

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

Когда использовать этот подход

Когда этап Bootstrap завершен и выполнены следующие условия:

1. Завершена структуризация idea.md (вывод этапа Bootstrap)
2. UI-дизайн или техническая архитектура еще не начаты (это последующие этапы)
3. Хотите определить объем MVP (избежать перегрузки функциями)
4. Нужно обеспечить четкое руководство для разработки и дизайна (пользовательские истории, критерии приемки)

Подготовка к началу

Предварительные условия

Перед началом этапа PRD убедитесь, что:

• ✅ Завершена инициализация проекта
• ✅ Ознакомлены с обзором 7-этапного конвейера
• ✅ Завершен этап Bootstrap, сгенерирован input/idea.md
• ✅ Установлен и настроен AI-ассистент (рекомендуется Claude Code)

Основная концепция

Что такое этап PRD?

PRD (Product Requirements Document, документ требований к продукту) — основная задача этапа PRD — определить ЧТО делать, а не КАК делать.

Это не технический документ

PRD Agent не является архитектором или UI-дизайнером, он не будет решать за вас:

• ❌ Какой технологический стек использовать (React vs Vue, Express vs Koa)
• ❌ Как проектировать базу данных (структура таблиц, индексы)
• ❌ Детали макета UI и взаимодействия (расположение кнопок, цветовые схемы)

Его задача:

• ✅ Определить целевых пользователей и их проблемы
• ✅ Перечислить основные функции и приоритеты
• ✅ Четко определить объем MVP и цели за рамками проекта
• ✅ Предоставить проверяемые пользовательские истории и критерии приемки

Зачем нужен PRD?

Представьте, что вы говорите строительной бригаде: "Я хочу построить дом"

• ❌ Без чертежей: строительная бригада может только догадываться и построить дом, в котором вы совсем не захотите жить
• ✅ С детальными чертежами: четко определено количество комнат, функциональное зонирование, требования к материалам, строительная бригада работает по чертежам

Этап PRD — это превращение "Я хочу построить дом" в "Три спальни, две гостиные, главная спальня выходит на юг, открытая кухня" — детального описания.

Фреймворк приоритизации функций MoSCoW

На этапе PRD используется фреймворк MoSCoW для классификации функций, обеспечивая фокус на основной ценности MVP:

Категория	Определение	Критерий оценки	Пример
Must Have	Функции, без которых MVP абсолютно не может обойтись	Без них продукт не может предоставить основную ценность	Приложение для учета расходов: добавление записи расхода, просмотр списка расходов
Should Have	Важные, но не блокирующие функции	Пользователь заметит отсутствие, но можно временно использовать обходное решение	Приложение для учета расходов: экспорт отчетов, статистика по категориям
Could Have	Дополнительные функции, улучшающие продукт	Не влияет на основной опыт, пользователь не заметит отсутствие	Приложение для учета расходов: напоминание о бюджете, поддержка нескольких валют
Won't Have	Функции, явно исключенные из рассмотрения	Не связаны с основной ценностью или имеют высокую техническую сложность	Приложение для учета расходов: социальный обмен, инвестиционные рекомендации

Основа MVP

Функции Must Have должны быть ограничены 5-7, чтобы обеспечить фокус MVP на основной ценности и избежать расширения объема.

Пошаговое руководство

Шаг 1: Подтвердите завершение этапа Bootstrap

Перед началом этапа PRD убедитесь, что input/idea.md существует и содержит соответствующий стандартам контент.

# Проверьте существование idea.md
cat input/idea.md

Вы должны увидеть: структурированный документ с разделами, включающими краткое описание, проблему, целевых пользователей, основную ценность, предположения и цели за рамками проекта.

Если idea.md не соответствует стандартам

Вернитесь к этапу Bootstrap для повторной генерации или вручную отредактируйте и дополните информацию.

Шаг 2: Запустите конвейер до этапа PRD

В каталоге проекта Factory выполните:

# Если конвейер уже запущен, перейдите к этапу PRD
factory run prd

# Или запустите конвейер с самого начала
factory run

CLI отобразит текущий статус и доступные этапы, а также сгенерирует инструкции для помощника PRD Agent.

Шаг 3: AI-ассистент читает определение PRD Agent

AI-ассистент (например, Claude Code) автоматически прочитает agents/prd.agent.md, чтобы понять свои обязанности и ограничения.

Обязанности PRD Agent

PRD Agent может только:

• Читать input/idea.md
• Записывать в artifacts/prd/prd.md
• Использовать мыслительные фреймворки и принципы принятия решений из skills/prd/skill.md

Он не может:

• Обсуждать любые детали технической реализации или UI-дизайна
• Читать другие файлы (включая upstream-продукты)
• Записывать в другие каталоги

Шаг 4: Загрузка skills/prd/skill.md

PRD Agent загрузит skills/prd/skill.md, чтобы получить следующее руководство:

Мыслительные фреймворки:

• Целевые пользователи: Кто будет использовать? Каков их фон, роль, проблемы?
• Основная проблема: Какую фундаментальную проблему должен решить продукт?
• Основная ценность: Почему это решение ценно? Какое у него преимущество перед конкурентами?
• Метрики успеха: Как измерить успех?

Приоритизация функций по MoSCoW:

• Must Have (должно быть): Функции, без которых MVP абсолютно не может обойтись
• Should Have (следует иметь): Важные, но не блокирующие функции
• Could Have (может иметь): Дополнительные функции, улучшающие продукт
• Won't Have (не будет): Функции, явно исключенные из рассмотрения

Руководство по написанию пользовательских историй:

Как [роль/тип пользователя]
Я хочу [функция/действие]
Чтобы [бизнес-ценность/цель]

Требования к структуре документа PRD (8 разделов):

1. Обзор
2. Портрет целевого пользователя
3. Основное ценностное предложение
4. Функциональные требования (классификация по MoSCoW)
5. Пользовательские сценарии
6. Цели за рамками проекта (Won't Have)
7. Метрики успеха
8. Предположения и риски

Шаг 5: Генерация документа PRD

AI-ассистент сгенерирует полный документ PRD на основе содержимого input/idea.md, используя мыслительные фреймворки и принципы принятия решений из навыков.

Что делает PRD Agent:

1. Читает input/idea.md, извлекает ключевые элементы (целевые пользователи, проблемы, основная ценность и т.д.)
2. Классифицирует функции по фреймворку MoSCoW
3. Составляет пользовательские истории и критерии приемки для функций Must Have
4. Перечисляет цели за рамками проекта, чтобы предотвратить расширение объема
5. Предоставляет количественные метрики успеха
6. Записывает организованный документ в artifacts/prd/prd.md

Ключевое ограничение

PRD Agent запрещено обсуждать детали технической реализации или UI-дизайна. Если такой контент обнаружен, PRD Agent откажется записывать его.

Шаг 6: Подтверждение содержимого prd.md

После завершения работы PRD Agent будет сгенерирован artifacts/prd/prd.md. Вам необходимо внимательно проверить:

Контрольные точки ✅:

1. Целевые пользователи конкретны?

   • ✅ Есть конкретный портрет (возраст/профессия/технические навыки/сценарии использования/проблемы)
   • ❌ Размыто: "все" или "те, кому нужно вести учет"

2. Основная проблема четкая?

   • ✅ Описывает трудности, с которыми пользователи сталкиваются в реальных сценариях
   • ❌ Размыто: "пользовательский опыт неудовлетворительный"

3. Основная ценность можно количественно оценить?

   • ✅ Есть конкретные выгоды (экономия 80% времени, повышение эффективности на 50%)
   • ❌ Размыто: "повышение эффективности", "лучший опыт"

4. Функции Must Have сфокусированы?

   • ✅ Не более 5-7 основных функций
   • ❌ Слишком много функций или включены второстепенные

5. Каждая функция Must Have имеет пользовательскую историю?

   • ✅ Используется стандартный формат (как... я хочу... чтобы...)
   • ❌ Отсутствует пользовательская история или формат неверный

6. Критерии приемки можно проверить?

   • ✅ Есть конкретные, проверяемые стандарты (можно ввести сумму, отображается в списке)
   • ❌ Размыто ("пользовательский опыт дружелюбный", "плавная работа")

7. Should Have и Won't Have четко перечислены?

   • ✅ Should Have помечен как "будущая итерация" с объяснением причин
   • ✅ Won't Have объясняет, почему исключено
   • ❌ Отсутствует или слишком мало

8. Метрики успеха можно количественно оценить?

   • ✅ Есть конкретные значения (коэффициент удержания пользователей > 30%, время выполнения задачи < 30 секунд)
   • ❌ Размыто ("пользователям нравится", "хороший опыт")

9. Предположения можно проверить?

   • ✅ Можно проверить через исследование пользователей
   • ❌ Субъективное суждение ("пользователям понравится")

10. Содержит ли технические детали реализации или UI-дизайн?

    • ✅ Нет технических деталей и описаний UI
    • ❌ Содержит выбор технологического стека, проектирование базы данных, макет UI и т.д.

Шаг 7: Выбор продолжения, повторной попытки или паузы

После подтверждения правильности CLI отобразит опции:

Выберите действие:
[1] Продолжить (перейти к этапу UI)
[2] Повторить (пересоздать prd.md)
[3] Пауза (продолжить позже)

Рекомендуется сначала просмотреть в редакторе кода

Перед подтверждением в AI-ассистенте сначала откройте artifacts/prd/prd.md в редакторе кода и проверьте каждое слово. После перехода к этапу UI стоимость изменений будет выше.

Предупреждения о распространенных ошибках

Ошибка 1: Слишком много функций Must Have

Неправильный пример:

Must Have:
1. Добавление записи расхода
2. Просмотр списка расходов
3. Экспорт отчетов
4. Статистика по категориям
5. Напоминание о бюджете
6. Поддержка нескольких валют
7. Социальный обмен
8. Инвестиционные рекомендации

Последствия: Объем MVP слишком велик, период разработки длинный, риски высокие.

Рекомендация: Ограничьте 5-7 основными функциями:

Must Have:
1. Добавление записи расхода
2. Просмотр списка расходов
3. Выбор категории расхода

Should Have (будущая итерация):
4. Экспорт отчетов
5. Статистика по категориям

Won't Have (явно исключено):
6. Социальный обмен (не связано с основной ценностью)
7. Инвестиционные рекомендации (требуется профессиональная квалификация, высокая техническая сложность)

Ошибка 2: Отсутствие пользовательских историй или неверный формат

Неправильный пример:

Функция: Добавление записи расхода
Описание: Пользователь может добавить запись расхода

Последствия: Команда разработки не понимает, для кого это делается, какую проблему решает.

Рекомендация: Используйте стандартный формат:

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

Критерии приемки:
- Можно ввести сумму и описание расхода
- Можно выбрать категорию расхода
- Запись сразу отображается в списке расходов
- Отображаются текущая дата и время

Ошибка 3: Непроверяемые критерии приемки

Неправильный пример:

Критерии приемки:
- Пользовательский интерфейс дружелюбный
- Работа плавная
- Опыт использования хороший

Последствия: Невозможно протестировать, команда разработки не знает, что считать "дружелюбным", "плавным", "хорошим".

Рекомендация: Пишите конкретные, проверяемые стандарты:

Критерии приемки:
- Можно ввести сумму и описание расхода
- Можно выбрать из 10 предустановленных категорий
- Запись отображается в списке расходов в течение 1 секунды
- Автоматически записываются текущая дата и время

Ошибка 4: Слишком общее описание целевых пользователей

Неправильный пример:

Целевые пользователи: Все, кому нужно вести учет расходов

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

Рекомендация: Определите конкретный портрет:

Основная группа пользователей:
- Роль: Молодые люди 18-30 лет, недавно начавшие работать
- Возраст: 18-30 лет
- Технические навыки: Средний уровень, знакомы с приложениями на смартфонах
- Сценарии использования: Немедленная запись после повседневных расходов, просмотр статистики в конце месяца
- Проблемы: В конце месяца обнаруживают перерасход, но не знают, куда ушли деньги, нет контроля бюджета

Ошибка 5: Отсутствие или слишком мало целей за рамками проекта

Неправильный пример:

Цели за рамками проекта: Нет

Последствия: Последующие этапы PRD и Code могут привести к перегрузке дизайна, увеличению технической сложности.

Рекомендация: Перечислите хотя бы 3 пункта:

Цели за рамками проекта (Out of Scope):
- Функция социального обмена (MVP сосредоточен на личном учете)
- Финансовые советы и инвестиционный анализ (требуется профессиональная квалификация, выходит за рамки основной ценности)
- Интеграция со сторонними финансовыми системами (высокая техническая сложность, не требуется для MVP)
- Сложный анализ данных и отчеты (Should Have, будущая итерация)

Ошибка 6: Включение деталей технической реализации

Неправильный пример:

Функция: Добавление записи расхода
Техническая реализация: Используется React Hook Form для управления формами, конечная точка API POST /api/expenses

Последствия: PRD Agent отклонит этот контент (только определение требований, без технической реализации).

Рекомендация: Говорите только "ЧТО делать", не говорите "КАК делать":

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

Критерии приемки:
- Можно ввести сумму и описание расхода
- Можно выбрать категорию расхода
- Запись сразу отображается в списке расходов
- Отображаются текущая дата и время

Ошибка 7: Неколичественные метрики успеха

Неправильный пример:

Метрики успеха:
- Пользователям нравится наше приложение
- Работа плавная
- Удержание пользователей высокое

Последствия: Невозможно оценить, успешен ли продукт.

Рекомендация: Пишите количественные метрики:

Метрики успеха:
Цели продукта:
- Получить 100 активных пользователей в первый месяц
- Пользователи используют продукт не менее 3 раз в неделю
- Уровень использования основных функций (добавление записи расхода) > 80%

Ключевые показатели (KPI):
- Удержание пользователей: удержание за 7 дней > 30%, удержание за 30 дней > 15%
- Уровень использования основных функций: использование функции добавления записи расхода > 80%
- Время выполнения задачи: добавление одного расхода < 30 секунд

Методы проверки:
- Запись поведения пользователей через бэкенд-логи
- Использование A/B-тестирования для проверки удержания пользователей
- Сбор удовлетворенности через опросы пользователей

Ошибка 8: Непроверяемые предположения

Неправильный пример:

Предположение: Пользователям понравится наш дизайн

Последствия: Невозможно проверить через исследование пользователей, MVP может потерпеть неудачу.

Рекомендация: Пишите проверяемые предположения:

Предположения:
Рыночные предположения:
- Молодые люди (18-30 лет) сталкиваются с проблемой "не знают, куда уходят деньги"
- Существующие приложения для учета расходов слишком сложны, молодым людям нужно более простое решение

Предположения о поведении пользователей:
- Пользователи готовы тратить 2 минуты на запись расхода после каждой покупки, если это поможет контролировать бюджет
- Пользователи предпочитают минималистичный UI, не нуждаются в сложных графиках и анализе

Технические предположения о выполнимости:
- Мобильное приложение может реализовать быстрый 3-шаговый процесс учета
- Оффлайн-хранилище может удовлетворить базовые потребности

Резюме урока

Основа этапа PRD — определение требований, а не реализация:

1. Вход: Структурированный input/idea.md (вывод этапа Bootstrap)
2. Процесс: AI-ассистент использует мыслительные фреймворки из skills/prd/skill.md и фреймворк приоритизации MoSCoW
3. Выход: Полный документ artifacts/prd/prd.md
4. Проверка: Проверьте, четко ли определены пользователи, можно ли количественно оценить ценность, сфокусированы ли функции, содержит ли технические детали

Ключевые принципы

• ❌ Чего НЕ делать: не обсуждать техническую реализацию, не проектировать макет UI, не решать структуру базы данных
• ✅ Что делать: определять целевых пользователей, перечислять основные функции, четко определять объем MVP, предоставлять проверяемые пользовательские истории

Анонс следующего урока

В следующем уроке мы изучим Этап 3: UI - Проектирование интерфейса и прототипирование.

Вы узнаете:

• Как проектировать структуру UI на основе PRD
• Как использовать навык ui-ux-pro-max для генерации дизайн-системы
• Как генерировать интерактивные HTML-прототипы
• Выходные файлы и условия завершения этапа UI

---

Приложение: Ссылки на исходный код

Нажмите, чтобы развернуть расположение исходного кода

Время обновления: 2026-01-29

Функция	Путь к файлу	Номер строки
Определение PRD Agent	agents/prd.agent.md	1-33
Навык PRD	skills/prd/skill.md	1-325
Определение конвейера (этап PRD)	pipeline.yaml	20-33
Определение оркестратора	agents/orchestrator.checkpoint.md	1-100+

Ключевые ограничения:

• Запрещены детали технической реализации: prd.agent.md:23
• Запрещены описания UI-дизайна: prd.agent.md:23
• Обязательно должны быть целевые пользователи: pipeline.yaml:29
• Обязательно должен быть определен объем MVP: pipeline.yaml:30
• Обязательно должны быть перечислены цели за рамками проекта: pipeline.yaml:31
• Выходной файл должен быть сохранен в artifacts/prd/prd.md: prd.agent.md:13

Условия завершения (pipeline.yaml:28-32):

• PRD содержит целевых пользователей
• PRD определяет объем MVP
• PRD перечисляет цели за рамками проекта (Out of Scope)
• PRD не содержит деталей технической реализации

Содержание фреймворка Skill:

• Мыслительные фреймворки: Целевые пользователи, основная проблема, основная ценность, метрики успеха
• Фреймворк приоритизации функций MoSCoW: Must Have, Should Have, Could Have, Won't Have
• Руководство по написанию пользовательских историй: Стандартный формат и примеры
• Требования к структуре документа PRD: 8 обязательных разделов
• Принципы принятия решений: Ориентация на пользователя, фокус на MVP, четкие цели за рамками проекта, проверяемость
• Контрольный список качества: Пользователи и проблемы, объем функций, пользовательские истории, полнота документа, проверка запретов
• Чего НЕ делать (NEVER): 7 четко запрещенных действий

Обязательные разделы документа PRD:

1. Обзор (Обзор продукта, Контекст и цели)
2. Портрет целевого пользователя (Основная группа пользователей, Второстепенная группа пользователей)
3. Основное ценностное предложение (Решаемая проблема, Наше решение, Дифференциальное преимущество)
4. Функциональные требования (Must Have, Should Have, Could Have)
5. Пользовательские сценарии (Описание основного сценария)
6. Цели за рамками проекта (Won't Have)
7. Метрики успеха (Цели продукта, Ключевые показатели, Методы проверки)
8. Предположения и риски (Рыночные предположения, Предположения о поведении пользователей, Технические предположения о выполнимости, Таблица рисков)