Сбор и проработка требований

После инициации (устав, договор, scope) начинается самая объёмная фаза — требования. В системе она строится вокруг живой BRD: документа, который растёт вместе с проектом и всегда отражает, что уже решено, а что ещё открыто.

Перед стартом нужны устав и scope — см. Инициация проекта.

Шаг 1. Запуск BRD: /requirements

Наберите /requirements. Агент:

1. Считывает устав, scope и (если есть) анализ договора.
2. Ищет в базе знаний Confluence переиспользуемые требования, спецификации и роадмапы проекта.
3. Предлагает структуру BRD — по блокам scope, с общими разделами. Структуру можно править: убрать блоки, добавить свои.
4. После подтверждения создаёт BRD как рабочий документ: у каждого блока свои подразделы — назначение, открытые решения, не описанное, вне scope, функциональные и нефункциональные требования, критерии приёмки.

До подтверждения структуры файл не создаётся — агент не пишет BRD «наугад».

Шаг 2. Карта неизвестных: /elicit

Требования редко приходят готовыми. Наберите /elicit — агент построит карту неизвестных по блокам:

• Открытые решения — острые вопросы, которые уже можно сформулировать («какой лимит задержки отклика приемлем?»).
• Не описанное — неопределённости, которые пока нельзя сформулировать как вопрос.
• Вне scope — что явно исключено по блоку.

Всё фиксируется в BRD блоками с ревью. Карта — не список задач в трекере: она живёт в документе и обновляется по мере решений.

Шаг 3. Проработка решений: /question

Когда вопрос стал острым, наберите /question — агент проведёт подробное интервью по одному решению за раз:

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

Когда общее понимание достигнуто, агент резюмирует договорённости и вносит решение в BRD: пункт переезжает из «открытых решений» в «решения» с кратким содержанием. Следующее решение — новым заходом /question.

Шаг 4. Спецификация: /specify

Когда по блоку требования достаточны, наберите /specify. Агент не переопрашивает — он синтезирует уже решённое в спецификацию реализации (implementation-spec.md):

• проблема и решение с точки зрения пользователя;
• развёрнутый список user story;
• решения по реализации (модули, интерфейсы, архитектурные решения) — без путей к файлам, которые быстро устаревают;
• решения по тестированию;
• что явно вне scope;
• ссылки на источники: BRD, устав, scope, страницы Confluence.

Если по блоку ещё нет конкретных требований и критериев — агент остановится и предложит сначала /elicit / /question, а не напишет шаблон из воздуха.

Шаг 5. Задачи: /tickets

Наберите /tickets — агент разложит спецификацию (или готовый срез BRD) на вертикальные срезы:

• каждый срез проходит полный путь через все слои (данные, логика, интерфейс, тесты) и в завершённом виде демонстрируем;
• каждый срез рассчитан на одну рабочую сессию;
• у каждой задачи — зависимости: какие задачи должны завершиться раньше («blocked by»);
• перед публикацией агент покажет разбивку и уточнит: гранулярность, правильность зависимостей, что слить или разделить.

Публикация — только через ваше подтверждение: каждая задача создаётся предложением в трекере (можно открыть в редакторе задач, поправить поля, и только потом создать). После создания агент предложит поставить ссылку на задачу в спецификации/BRD — чтобы документ и трекер не расходились.

Как это складывается в цикл

/scope (готово)
  → /requirements — структура и каркас BRD
  → /elicit — карта неизвестных по блокам
  → /question — решение за решением (пока не сняты неопределённости)
  → /specify — спецификация по готовым блокам
  → /tickets — задачи по спецификации
  → (далее: оценка и планирование — см. следующий гайд)

Чего агент не делает

• Не создаёт задачи молча — каждая публикация в трекер только через ваше подтверждение.
• Не выдумывает требования — если семян (устав, scope, Confluence) недостаточно, агент скажет, чего не хватает, а не заполнит документ из памяти.
• Не смешивает уровни — scope не превращается в список задач, а BRD — не в техническую спецификацию: у каждого документа свой уровень детализации.

С чего продолжать

• Планирование графика — оценка, структура работ и план.
• Проектные документы: создание и ведение — как живут созданные документы.