prd-from-context

Сформируй PRD на основе текущего контекстного окна.

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

Если каких-то данных не хватает, явно зафиксируй это в разделах «Предположения» и «Открытые вопросы», но не придумывай неподтвержденные детали как факты.

Процесс

1. Собери из текущего контекста все, что уже известно:
   • какую проблему нужно решить;
   • для кого создается решение;
   • какие пользовательские сценарии обсуждались;
   • какие требования уже сформулированы;
   • какие ограничения, зависимости и риски известны;
   • какие технические решения уже приняты;
   • какие части системы могут быть затронуты;
   • какие критерии готовности или проверки уже упоминались.

2. Используй уже имеющееся понимание кодовой базы, если оно есть.

   Если доступны файлы проекта, документация, тесты или другие материалы, и их изучение необходимо для точности PRD, изучи их самостоятельно. Не спрашивай пользователя о том, что можно выяснить из доступных материалов.

3. Определи крупные функциональные и технические блоки, которые потребуется создать или изменить для реализации.

   При этом ищи возможности выделить глубокие модули, которые можно тестировать изолированно.

   Глубокий модуль — это модуль, который инкапсулирует значимую функциональность за простым, устойчивым и тестируемым интерфейсом.

4. Зафиксируй проектные решения как решения, а неопределенности — как неопределенности.

   Не смешивай:

   • факты из контекста;
   • выводы на основе контекста;
   • предположения;
   • открытые вопросы.

5. Напиши PRD по шаблону ниже и сохрани в markdown-файл в в директории docs/prd/ в корневой директории проекта.

   Не включай конкретные пути к файлам и фрагменты кода. Они быстро устаревают и не должны быть частью PRD.

Постановка проблемы

Опиши проблему с точки зрения пользователя или заинтересованной стороны.

Нужно объяснить:

• какая боль или потребность существует;
• почему текущее состояние неудовлетворительно;
• какое влияние проблема оказывает на пользователя, продукт или процесс.

Цель решения

Опиши, какого результата нужно достичь.

Нужно объяснить:

• что должно измениться после реализации;
• какую ценность получит пользователь;
• какой результат будет считаться успешным.

Контекст

Опиши известный контекст задачи.

Включи:

• текущее состояние продукта или системы;
• уже обсужденные ограничения;
• важные зависимости;
• связанные функции, процессы или компоненты;
• релевантные технические или продуктовые вводные.

Решение

Опиши предлагаемое решение с точки зрения пользователя и продукта.

Нужно объяснить:

• как пользователь будет взаимодействовать с новой или измененной функциональностью;
• какое поведение системы ожидается;
• какие основные сценарии должны быть поддержаны;
• какие изменения должны быть видимы пользователю.

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

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

Формат каждой истории:

1. Я, как <роль или тип пользователя>, хочу <возможность или действие>, чтобы <ценность или результат>.

Список должен быть достаточно полным и покрывать все существенные аспекты функции:

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

Функциональные требования

Опиши, что система должна делать.

Раздел должен включать:

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

Нефункциональные требования

Опиши требования, которые не относятся напрямую к пользовательским сценариям, но важны для качества решения.

Включи, если применимо:

• производительность;
• надежность;
• безопасность;
• приватность;
• масштабируемость;
• наблюдаемость;
• совместимость;
• доступность;
• эксплуатационные ограничения.

Решения по реализации

Перечисли известные или выведенные из контекста решения по реализации.

Можно включить:

• какие модули нужно создать или изменить;
• какие интерфейсы или контракты нужно определить;
• какие данные или схемы нужно изменить;
• какие API или интеграции затрагиваются;
• какие архитектурные решения уже приняты;
• какие компромиссы были выбраны;
• какие зависимости между решениями существуют.

Не включай конкретные пути к файлам и фрагменты кода.

Решения по тестированию

Опиши, как следует проверять реализацию.

Включи:

• какие модули или сценарии нужно покрыть тестами;
• какие виды тестов подходят: модульные, интеграционные, end-to-end, регрессионные;
• что считается хорошим тестом;
• какие внешние поведения нужно проверять;
• какие детали реализации не следует тестировать напрямую;
• какие похожие тесты или подходы уже есть в проекте, если это известно из контекста.

Хороший тест должен проверять наблюдаемое поведение системы, а не внутренние детали реализации.

Критерии готовности

Опиши, по каким признакам можно понять, что задача выполнена правильно.

Включи:

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

Вне рамок

Опиши, что явно не входит в этот PRD.

Включи:

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

Предположения

Перечисли предположения, сделанные при составлении PRD.

Каждое предположение должно быть сформулировано явно и отделено от подтвержденных фактов.

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

Перечисли вопросы, на которые в текущем контексте нет надежного ответа.

Не задавай эти вопросы пользователю в процессе составления PRD. Просто зафиксируй их как вопросы, которые нужно будет закрыть позже.

Дополнительные заметки

Добавь любые дополнительные наблюдения, риски, зависимости или рекомендации, которые помогут при реализации.