MADTeacher Сформируй PRD на основе текущего контекстного окна.
Не интервьюируй пользователя. Не задавай уточняющих вопросов. Не останавливайся из-за нехватки информации. Синтезируй PRD из того, что уже известно из диалога, предоставленных материалов, описания задачи, обсужденных решений и понимания кодовой базы.
Если каких-то данных не хватает, явно зафиксируй это в разделах «Предположения» и «Открытые вопросы», но не придумывай неподтвержденные детали как факты.
Процесс
Собери из текущего контекста все, что уже известно:
- какую проблему нужно решить;
- для кого создается решение;
- какие пользовательские сценарии обсуждались;
- какие требования уже сформулированы;
- какие ограничения, зависимости и риски известны;
- какие технические решения уже приняты;
- какие части системы могут быть затронуты;
- какие критерии готовности или проверки уже упоминались.
Используй уже имеющееся понимание кодовой базы, если оно есть.
Если доступны файлы проекта, документация, тесты или другие материалы, и их изучение необходимо для точности PRD, изучи их самостоятельно. Не спрашивай пользователя о том, что можно выяснить из доступных материалов.
Определи крупные функциональные и технические блоки, которые потребуется создать или изменить для реализации.
При этом ищи возможности выделить глубокие модули, которые можно тестировать изолированно.
Глубокий модуль — это модуль, который инкапсулирует значимую функциональность за простым, устойчивым и тестируемым интерфейсом.
Зафиксируй проектные решения как решения, а неопределенности — как неопределенности.
Не смешивай:
- факты из контекста;
- выводы на основе контекста;
- предположения;
- открытые вопросы.
Напиши PRD по шаблону ниже и сохрани в markdown-файл в в директории docs/prd/ в корневой директории проекта.
Не включай конкретные пути к файлам и фрагменты кода. Они быстро устаревают и не должны быть частью PRD.
Постановка проблемы
Опиши проблему с точки зрения пользователя или заинтересованной стороны.
Нужно объяснить:
- какая боль или потребность существует;
- почему текущее состояние неудовлетворительно;
- какое влияние проблема оказывает на пользователя, продукт или процесс.
Цель решения
Опиши, какого результата нужно достичь.
Нужно объяснить:
- что должно измениться после реализации;
- какую ценность получит пользователь;
- какой результат будет считаться успешным.
Контекст
Опиши известный контекст задачи.
Включи:
- текущее состояние продукта или системы;
- уже обсужденные ограничения;
- важные зависимости;
- связанные функции, процессы или компоненты;
- релевантные технические или продуктовые вводные.
Решение
Опиши предлагаемое решение с точки зрения пользователя и продукта.
Нужно объяснить:
- как пользователь будет взаимодействовать с новой или измененной функциональностью;
- какое поведение системы ожидается;
- какие основные сценарии должны быть поддержаны;
- какие изменения должны быть видимы пользователю.
Пользовательские истории
Составь подробный нумерованный список пользовательских историй.
Формат каждой истории:
- Я, как <роль или тип пользователя>, хочу <возможность или действие>, чтобы <ценность или результат>.
Список должен быть достаточно полным и покрывать все существенные аспекты функции:
- основные сценарии;
- альтернативные сценарии;
- крайние случаи;
- ошибки;
- права доступа;
- состояния данных;
- взаимодействие с существующей функциональностью;
- ожидаемую обратную связь от системы.
Функциональные требования
Опиши, что система должна делать.
Раздел должен включать:
- основные функции;
- правила поведения;
- состояния и переходы;
- обработку ошибок;
- ограничения на действия пользователя;
- ожидаемые системные реакции;
- требования к интерфейсам, если они известны.
Нефункциональные требования
Опиши требования, которые не относятся напрямую к пользовательским сценариям, но важны для качества решения.
Включи, если применимо:
- производительность;
- надежность;
- безопасность;
- приватность;
- масштабируемость;
- наблюдаемость;
- совместимость;
- доступность;
- эксплуатационные ограничения.
Решения по реализации
Перечисли известные или выведенные из контекста решения по реализации.
Можно включить:
- какие модули нужно создать или изменить;
- какие интерфейсы или контракты нужно определить;
- какие данные или схемы нужно изменить;
- какие API или интеграции затрагиваются;
- какие архитектурные решения уже приняты;
- какие компромиссы были выбраны;
- какие зависимости между решениями существуют.
Не включай конкретные пути к файлам и фрагменты кода.
Решения по тестированию
Опиши, как следует проверять реализацию.
Включи:
- какие модули или сценарии нужно покрыть тестами;
- какие виды тестов подходят: модульные, интеграционные, end-to-end, регрессионные;
- что считается хорошим тестом;
- какие внешние поведения нужно проверять;
- какие детали реализации не следует тестировать напрямую;
- какие похожие тесты или подходы уже есть в проекте, если это известно из контекста.
Хороший тест должен проверять наблюдаемое поведение системы, а не внутренние детали реализации.
Критерии готовности
Опиши, по каким признакам можно понять, что задача выполнена правильно.
Включи:
- пользовательские критерии приемки;
- технические критерии;
- критерии тестирования;
- требования к документации, миграциям или релизу, если применимо.
Вне рамок
Опиши, что явно не входит в этот PRD.
Включи:
- функции, которые не нужно реализовывать сейчас;
- сценарии, которые откладываются;
- технические улучшения, которые не являются частью текущей задачи;
- продуктовые вопросы, которые не решаются в рамках этой работы.
Предположения
Перечисли предположения, сделанные при составлении PRD.
Каждое предположение должно быть сформулировано явно и отделено от подтвержденных фактов.
Открытые вопросы
Перечисли вопросы, на которые в текущем контексте нет надежного ответа.
Не задавай эти вопросы пользователю в процессе составления PRD. Просто зафиксируй их как вопросы, которые нужно будет закрыть позже.
Дополнительные заметки
Добавь любые дополнительные наблюдения, риски, зависимости или рекомендации, которые помогут при реализации.