Глава 3: ТЗ v1 + План v1

Пролог: от анализа к дизайну#

В Главах 1–2 вы научились получать пользу от агента быстро и безопасно.

Теперь VP Engineering говорит: “Отлично. Теперь это нужно превратить в управляемый Phoenix Project: что именно мы запускаем в Phoenix v1, какие риски, и как мы проверим, что релиз доставлен.”

Lance Bishop думает: “Это уже не разовая задача. Это проект. Нужно ТЗ.”

Разница:

• Одна задача: “проанализируй логи” → результат быстро
• Проект: Phoenix Project → нужно ТЗ, план, архитектура

Сцена из “The Phoenix Project” (2014)#

Глава 10-11 книги: Erik Reid спрашивает Bill про требования

Erik Reid (консультант по эксплуатации и наставник Bill Palmer) приходит в Parts Unlimited, чтобы разобраться в Phoenix Project. Он садится с Bill и задаёт простые вопросы:

Erik: “Покажи мне требования для Phoenix Project.”

Bill: “Требования? Ну… они есть. В головах разработчиков. И в Jira. И в цепочках писем с бизнесом.”

Erik: “Формальное ТЗ есть?”

Bill: “Нет. Мы Agile, мы не пишем ТЗ. У нас User Stories.”

Erik: “Хорошо. А нефункциональные требования? Производительность, безопасность, надёжность?”

Bill: (молчание) “Ну… мы предполагаем, что система должна быть быстрой и безопасной.”

Erik: “А что значит ‘быстрой’? Латентность p95 ниже порога? В пределах SLA?”

Bill: “Не знаю. Мы не фиксировали.”

Erik: “Управление рисками? Какие риски проекта? Какие планы митигации?”

Bill: “Риски? (смеётся нервно) Мы просто надеемся, что пронесёт.”

Erik молчит и смотрит на Bill.

Результат отсутствия ТЗ (реальная история из книги):

Через несколько месяцев Phoenix Project попадает в кризис: забыли про соответствие PCI DSS. Это критичное нефункциональное требование, NFR — без него нельзя обрабатывать платежи по картам.

Обнаружили проблему незадолго до релиза.

Варианты:

1. Отложить релиз на несколько месяцев (внедрять соответствие PCI DSS)
2. Релизнуть без платежей по картам (половина функциональности не работает)

Выбрали вариант 1. Релиз отложен. CEO в ярости. Команда в панике.

Erik: “Вот что бывает, когда нет формального ТЗ. Критичные НФТ ‘забываются’. Предположения не проверяются. Риски не митигируются.”

Ключевые проблемы подхода 2014:

• Нет формального ТЗ: требования в головах людей
• Нет единого источника истины: знания распылены между людьми/тикетами/почтой
• Предположения повсюду: “мы предполагаем, что…”
• НФТ игнорируются: фокус только на функциональности, не на производительности/безопасности/надёжности
• Нет управления рисками: “надеемся, что пронесёт”

Та же задача в 2026: ТЗ v1 для Phoenix Project с ИИ-агентом#

Контекст: Lance получает задачу “запустить Phoenix Project”. Вместо предположений — формализует требования.

Подход (2026):

Lance использует чат‑режим (например, ChatGPT/DeepSeek) для создания ТЗ v1:

Роль: ты — бизнес-аналитик, помогаешь формализовать требования.

Контекст:
- Компания: Parts Unlimited (2026)
- Проект: Phoenix Project (пользовательская платформа) — релиз Phoenix Project v1
- Проблема: Phoenix Project критичен для бизнеса и “не успевает”; релизы и изменения нестабильны, риски всплывают слишком поздно
- Критичный риск: “забытые НФТ” (например, PCI DSS для платежей)

Задача:
Создай ТЗ v1 для Phoenix Project (релиз Phoenix Project v1).

Правила качества:
- Не додумывай факты/требования. Всё, что не дано явно, оформляй как вопрос или предположение с пометкой.
- Если контекста недостаточно — начни с блока **«Вопросы для уточнения»** (до 10 пунктов), затем дай черновик ТЗ с пометками `TBD`.

Структура ТЗ:
1. Цель проекта (1-2 предложения)
2. Функциональные требования (ФТ): обязательные/желательные/опциональные
3. Нефункциональные требования (НФТ): производительность/надёжность/безопасность/сопровождаемость
4. Критерии приёмки: измеримые метрики

УСЛОВИЯ ОСТАНОВКИ:
- Если бизнес-задача неясна — задай вопрос
- НЕ додумывай требования, которые не были упомянуты

Время выполнения:

• Агент генерирует ТЗ v1: быстро
• Lance делает ревью + корректировки: быстро
• Итого: быстрый цикл с проверкой

Результат (фрагмент ТЗ v1):

Примечание: в примерах ниже используются плейсхолдеры вида <WINDOW>/<THRESHOLD>/.... См. глоссарий — «Нотация плейсхолдеров».

## Нефункциональные требования (НФТ)

### Производительность
- НФТ-1: Латентность анализа: ≤ <WINDOW> для <N> деплоев
- НФТ-2: Пропускная способность: ≥ 1000 деплоев/час

### Безопасность
- НФТ-5: Агент работает в режиме только чтение, без записи/удаления в продакшене
- НФТ-6: Журнал аудита: все действия агента логируются
- НФТ-7: Нет чувствительных данных в логах агента (учётные данные, PII)

### Критерии приёмки
- AC-2: Латентность ≤ <WINDOW> для <N> деплоев (измеряется таймером)
- AC-4: Агент работает только в режиме чтения (ручная проверка безопасности)

Верификация: Lance проверяет ТЗ:

• Все ФТ заданы явно (без предположений)
• НФТ измеримы (метрики и пороги, а не “быстро” или “безопасно”)
• AC проверяемы (как проверить успех проекта)

Показывает VP Engineering. VP: “Безопасность? Журнал аудита? PCI compliance?”

Lance: “Да, всё учтено. НФТ-7: нет чувствительных данных. Если нужно соответствие PCI DSS — добавим явное требование.”

Сравнение: 2014 и 2026

Что изменилось:

• Формализация: требования не в головах, а в документе
• НФТ заданы явно: без предположений (“предполагаем безопасно” → “нет чувствительных данных в логах”)
• AC измеримы: “система работает” → “задержка ≤ , измеряется таймером”
• Управление рисками: “надеемся, что пронесёт” → риск-регистр с митигацией

Что НЕ изменилось:

• Ответственность человека: Lance проверяет ТЗ (агент может пропустить НФТ)
• Доменная экспертиза: нужно знать, что такое PCI compliance, задержка p95, аудит безопасности
• Ревью обязателен: ТЗ от агента — это черновик, не финальная версия

В этой главе вы научитесь:

• формулировать ТЗ v1 (функциональные/нефункциональные требования)
• создавать план v1: декомпозиция работ, риск-регистр, оценка
• использовать агента для декомпозиции задач и оценки рисков

Быстрый старт: ТЗ v1#

Цель#

Создать ТЗ v1 для Phoenix Project (релиз Phoenix Project v1): функциональные требования, нефункциональные требования, критерии приёмки.

Сцена: Phoenix Project#

Контекст: VP Engineering хочет “дожать” Phoenix Project до запуска.
Ставки: Если ТЗ неполное — реализуем “не то”, переделка займёт недели.
Задача: Формализовать “что строим” в ТЗ v1.

Вход#

• Бизнес-задача: запустить Phoenix Project v1 (пользовательский продукт) с приемлемым уровнем качества/безопасности
• Контекст из Глав 1-2: что агент уже умеет (сбор доказательств, формализация требований, первичный анализ артефактов)

Промпт для агента (готовый к копированию)#

Роль: ты — бизнес-аналитик, помогаешь формализовать требования для проекта.

Контекст:
- Компания: Parts Unlimited (2026)
- Проект: Phoenix Project (пользовательская платформа) — релиз Phoenix Project v1
- Проблема: Phoenix Project “не успевает”, а риски всплывают слишком поздно
- Критичный риск: PCI DSS для платежей

Задача:
Создай ТЗ v1 для Phoenix Project (релиз Phoenix Project v1).

Правила качества:
- Не додумывай факты/требования. Если информации недостаточно — начни с вопросов и пометь `TBD`.
- Явно отделяй **требования** от **предположений** и **рисков** (не смешивай их).

Структура ТЗ:
1. **Цель проекта** (1-2 предложения)
2. **Функциональные требования (ФТ)**
   - Список требований (что агент должен делать)
   - Приоритеты: обязательные/желательные/опциональные
3. **Нефункциональные требования (НФТ)**
   - Производительность: задержка, пропускная способность
   - Надёжность: доступность, доля ошибок
   - Безопасность: авторизация, журнал аудита, чувствительность данных
   - Сопровождаемость: качество кода, тесты
4. **Критерии приёмки**
   - Как проверить, что проект выполнен успешно
   - Измеримые метрики: числа, а не "улучшить"

Формат ответа: Markdown с чёткой структурой.

УСЛОВИЯ ОСТАНОВКИ:
- Если бизнес-задача неясна — задай уточняющий вопрос
- Если контекст недостаточен — перечисли какие данные нужны
- НЕ додумывай требования, которые не были упомянуты

Пример результата (ТЗ v1)#

# ТЗ v1: Phoenix Project — релиз Phoenix Project v1

## 1. Цель проекта

Запустить Phoenix Project v1 (пользовательский продукт) с измеримыми НФТ и воспроизводимыми контрольными точками качества, чтобы бизнес перестал терять деньги из‑за задержек и аварийных релизов.

Ожидаемый результат: предсказуемый релиз‑цикл, измеримые НФТ и явные критерии приёмки вместо “героизма”.

## 2. Функциональные требования (ФТ)

### Обязательные

- **ФТ-1:** Каталог: просмотр товаров, поиск, карточка товара
- **ФТ-2:** Корзина: добавить/удалить/изменить количество
- **ФТ-3:** Оформление заказа — `checkout`: оформление, валидация, идемпотентность
- **ФТ-4:** Платежи: интеграция с провайдером (граница PCI)
- **ФТ-5:** Заказы: создание/статусы/история

### Желательные

- **ФТ-6:** Интеграция со складом/ERP: резервирование/списание
- **ФТ-7:** Уведомления пользователю о статусе заказа
- **ФТ-8:** Админ‑операции (минимум) для поддержки

### Опциональные

- **ФТ-9:** Персонализация/рекомендации
- **ФТ-10:** A/B‑эксперименты checkout

## 3. Нефункциональные требования (НФТ)

### Производительность

- **НФТ-1:** p95 latency checkout: ≤ <WINDOW>
- **НФТ-2:** Пропускная способность: ≥ <N> checkout/min (пик)

### Надёжность

- **НФТ-3:** Доступность ключевых путей: `browse`/`checkout`: <VALUE>, error budget ≤ <BUDGET>/<WINDOW>
- **НФТ-4:** Доля ошибок checkout: ≤ <VALUE>

### Безопасность

- **НФТ-5:** PCI DSS: граница платежей выделена; минимизация касания данных
- **НФТ-6:** Audit log событий заказов/платежей
- **НФТ-7:** Нет секретов/PII в логах (маскирование)

### Сопровождаемость

- **НФТ-9:** Покрытие кода: ≥ 80% (модульные + интеграционные тесты)
- **НФТ-10:** Документация: README, `runbook`, SOP для типичных задач

## 4. Критерии приёмки

### AC-1: Функциональность

- Агент успешно парсит 100 деплоев из тестового набора данных
- Статистика корректна (проверено вручную на 10 деплоях)
- Гипотезы отсортированы по вероятности

### AC-2: Производительность

- Латентность ≤ <WINDOW> для <N> деплоев (измеряется таймером)
- Пропускная способность ≥ 1000 деплоев/час (нагрузочный тест)

### AC-3: Надёжность

- Доля ошибок ≤ 5% (измеряется на 100 деплоях: ложные срабатывания/пропуски)
- Доступность <VALUE> (мониторинг доступности за период)

### AC-4: Безопасность

- Агент работает только в режиме чтения, без записи/удаления в логах продакшена
- Журнал аудита содержит все действия агента
- Нет credentials/PII в логах агента (проверено вручную)

### AC-5: Сопровождаемость

- Покрытие кода ≥ 80% (измеряется инструментом покрытия)
- Документация полная: README и `runbook` проверены ревью

Проверка результата (чеклист)#

• Цель проекта сформулирована (1-2 предложения)
• ФТ разбиты на обязательные/желательные/опциональные
• НФТ покрывают производительность/надёжность/безопасность/сопровождаемость
• AC измеримы: числа, а не “улучшить”
• ТЗ проверяемо: другой инженер может понять, что строим

Ожидаемый результат#

Артефакт: ТЗ v1 в формате Markdown

Время:

• Генерация ТЗ агентом: быстро
• Ревью и корректировки: быстро

Польза:

• Формализация: “что строим” зафиксировано
• Измеримость: AC позволяют проверить успех проекта
• Проверяемо: команда может сделать ревью ТЗ и дать обратную связь

Теория: ТЗ как контракт#

Концепция 1: Функциональные и нефункциональные требования#

Вы проектировали системы. Вы знаете разницу между что делать (ФТ) и как делать (НФТ).

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

• Что система должна делать
• Пример: “агент парсит логи CI/CD”

Нефункциональные требования (НФТ):

• Как система должна это делать: производительность/надёжность/безопасность
• Пример: “задержка ≤ ”

Почему НФТ важны:

В 2014 Phoenix Project в Parts Unlimited задержался на месяцы. Причина: команда забыла про PCI DSS compliance — критичное нефункциональное требование для обработки платежей по картам. Обнаружили незадолго до релиза. Erik Reid спросил Bill: “А у вас есть формальное ТЗ с НФТ?” Bill: “Нет, у нас Agile, мы не пишем ТЗ.” Erik: “Вот что бывает, когда НФТ ‘забываются’.”

В 2026 НФТ, заданные явно в ТЗ, предотвращают такие ошибки:

• НФТ‑Безопасность: PCI compliance required (если работаем с платежами)
• НФТ‑Производительность: задержка ≤
• НФТ‑Аудит: все действия логируются

Если НФТ в ТЗ → его не забудешь. Если НФТ “в головах” → забудешь и узнаешь незадолго до релиза.

Для работы с агентами:

Агенты часто фокусируются на ФТ и игнорируют НФТ. Вы должны их указать явно.

История из практики:

На проекте ZAPAD мы попросили агента “спроектировать API для анализа деплоев”. Агент выдал отличный дизайн:

• Endpoints (пример): GET /catalog, POST /checkout, GET /orders/{id}
• Форматы запросов/ответов: JSON
• Обработка ошибок: HTTP status codes

Но агент пропустил НФТ:

• Производительность: задержка не оговорена
• Безопасность: аутентификация не упомянута
• Надёжность: отсутствуют повторные попытки при временных ошибках

Мы реализовали этот дизайн. Результат: API работает, но медленно: задержка выше порога, без auth, без retry.

Фикс: добавили НФТ в промпт явно: “задержка ≤ , аутентификация через API key, повторные попытки при временных ошибках”.

Вывод: Агент не “понимает” НФТ автоматически. Вы должны их указать явно.

Концепция 2: Приоритезация#

Вы управляли проектами. Вы знаете, что не все требования одинаково важны.

Приоритезация:

• Обязательные: без этого проект не имеет смысла
• Желательные: желательно, но можно отложить на v2
• Опциональные: делаем если есть время

Почему это важно для работы с агентами:

Агенты не понимают приоритеты без явного указания.

Battle story:

На проекте ASIMOV мы попросили агента “декомпозировать проект на задачи”. Агент выдал 50 задач, все помечены как “important”.

Мы начали реализацию. Через неделю поняли: мы делаем NICE_TO_HAVE фичи (например, “Slack integration”), а MUST фичи (например, “парсинг логов”) ещё не готовы.

Фикс: попросили агента приоритезировать задачи: обязательные/желательные/опциональные. Агент пересортировал задачи. Мы сфокусировались на обязательных.

Вывод: Без приоритезации агент считает все требования одинаково важными.

Концепция 3: Критерии приёмки как Definition of Done#

Вы работали с командами. Вы знаете, что без DoD задача никогда не “готова”.

Критерии приёмки — это DoD для проекта:

• Как мы узнаем, что проект выполнен успешно?
• Измеримые метрики: числа, а не “улучшить”

Почему это важно для работы с агентами:

Агенты не понимают “улучшить”, “оптимизировать”, “лучше”.

Battle story:

На проекте MORPHEUS мы попросили агента “оптимизировать производительность”. Агент выдал:

• “Используй кэш”
• “Добавь индексы в БД”
• “Параллелизируй запросы”

Мы реализовали всё это. Результат: задержка снизилась, но всё ещё выше целевого порога.

VP спросил: “Этого достаточно?”

Мы не знали. AC не было.

Фикс: добавили критерий приёмки: “задержка ≤ для деплоев”. Теперь понятно: если порог не достигнут — нужно ещё оптимизировать.

Вывод: Критерии приёмки делают успех проекта измеримым.

Концепция 4: Управление рисками#

Вы управляли проектами. Вы знаете, что риски нужно выявлять и митигировать, а не “надеяться, что пронесёт”.

Почему управление рисками важно:

Erik Reid спросил Bill Palmer в 2014: “Управление рисками? Какие риски проекта? Какие планы митигации?” Bill (смеётся нервно): “Риски? Мы просто надеемся, что пронесёт.” Результат: Phoenix Project задержался на месяцы из-за забытых НФТ — например, PCI compliance — это был неуправляемый риск.

В 2026 риск-регистр делает risks explicit:

• Риск-1: Забыть НФТ, например PCI compliance → Митигация: ТЗ с явными НФТ
• Риск-2: Недооценить сложность → Митигация: буфер 20% к оценке
• Риск-3: Неясные требования → Митигация: ревью ТЗ со стейкхолдерами

Разница: “надеемся, что пронесёт” (2014) и “5-7 рисков с планами митигации” (2026).

Для работы с агентами:

Агенты могут помочь выявить риски, если вы попросите явно: “перечисли 5-7 рисков проекта с вероятностью/влиянием”. Но митигацию придётся проверять вам — агент может предложить нереалистичные планы митигации.

Практика: План v1 — декомпозиция работ + риски#

Назначение#

Создать план v1 для проекта: декомпозиция работ (декомпозиция на задачи), риск-регистр, оценка времени.

Входы#

• ТЗ v1 (функциональные/нефункциональные требования)
• Контекст проекта (команда, сроки, ограничения)

Промпт для агента#

Роль: ты — project manager, помогаешь составить план проекта.

Контекст:
- Проект: Phoenix Project (пользовательская платформа) — релиз Phoenix v1
- ТЗ: [прикрепи ТЗ v1]
- Команда: 1 Senior backend-инженер (Richard Hendricks), 3 человека (разработка/инфра/QA)
- Сроки: несколько недель

Задача:
Создай план v1 для проекта.

Правила качества:
- Не выдумывай задачи “из воздуха”: каждая задача должна быть трассируема к пункту ТЗ или к явному риску/митигации.
- Если входных данных недостаточно (ТЗ/команда/сроки) — начни с вопросов и пометь неизвестное как `TBD`.
- Явно отмечай критический путь, зависимости и допущения.

Структура плана:
1. **Декомпозиция работ**
   - Декомпозируй проект на задачи (уровень детализации: несколько дней на задачу)
   - Для каждой задачи: название, описание, зависимости, оценка
   - Приоритезируй: обязательные/желательные/опциональные

2. **Риск-регистр**
   - Перечисли 5-7 рисков проекта
   - Для каждого риска: описание, вероятность (низкая/средняя/высокая), влияние (низкое/среднее/высокое), митигация
   - Отсортируй по критичности: вероятность × влияние

3. **Оценка времени**
   - Критический путь: какие задачи на критическом пути
   - Суммарная оценка: сумма оценок
   - Буфер: 20% на непредвиденное

Формат ответа: Markdown с таблицами.

УСЛОВИЯ ОСТАНОВКИ:
- Если ТЗ неясно — задай уточняющий вопрос
- Если контекст недостаточен (команда, сроки) — перечисли что нужно
- НЕ додумывай задачи, которые не покрыты ТЗ

Как сделать план “делегируемым” (контракт передачи контекста для подзадач)#

План v1 полезен не только людям. Он становится особенно ценным, когда вы начинаете делегировать задачи агентам/исполнителям, которые работают в отдельном контексте и не имеют “памяти” о вашей основной беседе.

Практическое правило: если задачу можно отдать специализированному исполнителю (отдельной роли/агенту), она должна быть самодостаточной и проверяемой.

Минимальная карточка подзадачи (что нужно, чтобы делегирование было устойчивым):

• Цель: 1–2 предложения (что именно нужно получить на выходе).
• Входы: конкретные артефакты (файлы/ссылки/фрагменты ТЗ/таблицы). Избегайте расплывчатых указаний вроде “разберись в репозитории”.
• Ограничения: права (read‑only по умолчанию), запреты, лимиты (время, стоимость), STOP‑условия.
• Формат результата: структура ответа (таблица/JSON/Markdown‑секции), чтобы следующий шаг мог “съесть” результат без ручной склейки.
• Критерии готовности (DoD): как проверить, что задача реально сделана (тест, метрика, чеклист).

Именно поэтому в хорошем плане v1 важно явно указывать не только “что сделать”, но и “как проверить” — иначе делегирование превращается в “веру в текст”.

План‑сначала (plan‑first): как “режим по умолчанию” для нетривиальных задач#

Если задача затрагивает несколько файлов, имеет неочевидные требования или высокий риск — выгодно не начинать с кода.

Вместо этого сначала добейтесь плана выполнения, который:

• перечисляет какие части системы будут затронуты (файлы/директории/компоненты),
• фиксирует вопросы для уточнения до начала работ,
• описывает шаги и артефакты с критериями готовности (DoD/план проверки),
• явно говорит, где нужен апрув человека.

Практический бонус: если агент “пошёл не туда”, чаще быстрее и чище вернуться к плану, уточнить ограничения/DoD и повторить цикл, чем “латать” результат перепиской.

См. как пример реализации принципа “start with plans” и “starting over from a plan”: Cursor: Best practices for coding with agents.

Когда подзадача стала стабильной — упакуйте её как «навык» — skill#

Хороший признак зрелости: одна и та же подзадача повторяется, у неё понятные входы/выходы, проверки и STOP‑условия. В этот момент выгодно перестать копировать инструкцию из чата в чат и превратить её в переносимый пакет процедур/знаний: краткое описание “когда применять”, инструкция “как выполнять”, плюс шаблоны и вспомогательные материалы.

В индустрии это оформляют как навыки: папка с SKILL.md (инструкции и метаданные) и, при необходимости, references/ (справки), assets/ (шаблоны) и scripts/ (повторяемые проверки). Ключевой принцип — “подгрузка по требованию”: агент видит список навыков по короткому описанию, а подробности грузит только когда выбран нужный навык (экономия контекста и меньше шума).¹

Пример результата (План v1)#

# План v1: Phoenix Project — релиз Phoenix v1

## 1. Декомпозиция работ

### Фаза 1: Основа — неделя 1

| ID | Задача | Описание | Зависимости | Оценка | Приоритет |
|---|---|---|---|---|---|
| T1 | Настроить проект | Создать репо, настроить CI/CD, подготовить инструменты | - | 1 день | MUST |
| T2 | Парсинг логов | Реализовать парсер логов CI/CD | T1 | <DAYS> | MUST |
| T3 | Извлечь данные | Извлечь дату, статус, длительность, failed_step | T2 | <DAYS> | MUST |

### Фаза 2: Анализ — неделя 2

| ID | Задача | Описание | Зависимости | Оценка | Приоритет |
|---|---|---|---|---|---|
| T4 | Рассчитать статистику | Вычислить долю успешных/упавших деплоев, топ-3 причины | T3 | <DAYS> | MUST |
| T5 | Сформировать гипотезы | Предложить несколько гипотез первопричины | T4 | <DAYS> | MUST |
| T6 | План проверки результата | Сформировать план проверки результата | T5 | 1 день | MUST |

### Фаза 3: Качество и безопасность — неделя 3

| ID | Задача | Описание | Зависимости | Оценка | Приоритет |
|---|---|---|---|---|---|
| T7 | Модульные тесты | Написать модульные тесты: coverage ≥ <VALUE> | T2-T6 | <DAYS> | MUST |
| T8 | Интеграционные тесты | Написать интеграционные тесты | T7 | <DAYS> | MUST |
| T9 | Проверка безопасности | Журнал аудита, режим только чтение, отсутствие чувствительных данных в логах | T8 | <DAYS> | MUST |

### Фаза 4: Деплой и документация — неделя 4

| ID | Задача | Описание | Зависимости | Оценка | Приоритет |
|---|---|---|---|---|---|
| T10 | Деплой в staging | Деплой в staging, нагрузочное тестирование | T9 | <DAYS> | MUST |
| T11 | Документация | README, `runbook`, SOP | T10 | <DAYS> | MUST |
| T12 | Деплой в production | Деплой в production + мониторинг | T11 | 1 день | MUST |

### Optional (если есть время)

| ID | Задача | Описание | Зависимости | Оценка | Приоритет |
|---|---|---|---|---|---|
| T13 | Slack integration | Уведомления в Slack | T12 | <DAYS> | NICE_TO_HAVE |
| T14 | Grafana dashboard | Дашборд для метрик агента | T12 | <DAYS> | NICE_TO_HAVE |

## 2. Риск-регистр

| ID | Риск | Вероятность | Влияние | Митигация |
|---|---|---|---|---|
| R1 | Формат логов CI/CD неоднороден (разные форматы в разных проектах) | High | High | Поддержать 3-5 форматов: plain text, JSON, YAML; добавить fallback для unknown formats |
| R2 | Производительность недостаточна: задержка > <WINDOW> | Medium | High | Load testing на ранней фазе, если задержка > <WINDOW> → оптимизация: caching, parallel parsing |
| R3 | Агент генерирует ложные срабатывания (гипотезы неточны) | Medium | Medium | План проверки результата обязателен; проверка на исторических данных: точность ≥ 95% |
| R4 | Нарушение безопасности (агент логирует sensitive data) | Low | High | Проверка безопасности на неделе 3, ревью журнала аудита, нет credentials/PII в логах |
| R5 | Зависимости недоступны: CI/CD система недоступна | Low | Medium | Повторные попытки, деградация: работать с кэшированными данными |
| R6 | Ёмкость команды: Senior инженер может не успеть в плановый срок | Medium | Medium | Приоритезация MUST tasks, NICE_TO_HAVE отложить на v2 |
| R7 | Разрастание объёма работ: стейкхолдеры добавляют новые требования | Medium | Low | Зафиксировать ТЗ v1, новые требования → v2 |

**Критичность: вероятность × влияние**
1. R1: High × High → критичный
2. R2: Medium × High → критичный
3. R4: Low × High → критичный
4. R3: Medium × Medium → средний
5. R6: Medium × Medium → средний
6. R5: Low × Medium → низкий
7. R7: Medium × Low → низкий

## 3. Оценка времени

**Критический путь:** T1 → T2 → T3 → T4 → T5 → T6 → T7 → T8 → T9 → T10 → T11 → T12

**Суммарная оценка:**
- Фаза 1: <DAYS>
- Фаза 2: <DAYS>
- Фаза 3: <DAYS>
- Фаза 4: <DAYS>
- **Итого:** <DAYS> (~<WEEKS>)

**Буфер (<PERCENT>):** <DAYS> (~<WEEK>)

**Итого с буфером:** <DAYS> (~<WEEKS>)

**Вердикт:** Если команда работает на полной ёмкости, срок может быть **на пределе**. Рекомендуем:
- Отложить NICE_TO_HAVE: T13-T14 на v2
- Добавить буфер <WEEK>, итого: <WEEKS>
- Или добавить ресурсы (ещё 1 инженер на Фазу 3)

Проверка результата (чеклист)#

• Декомпозиция работ выполнена (несколько дней на задачу)
• Зависимости указаны (какие задачи зависят друг от друга)
• Риск-регистр содержит 5-7 рисков (с вероятностью, влиянием, митигацией)
• Оценка времени реалистична: суммарная оценка с буфером
• Критический путь идентифицирован (какие задачи блокируют релиз)

Ожидаемый результат#

Артефакт: План v1 в формате Markdown

Время:

• Генерация плана агентом: быстро
• Ревью и корректировки: быстро

Польза:

• Декомпозиция: проект разбит на задачи
• Риски идентифицированы: план митигации готов
• Оценка реалистична: можно планировать sprint

Типовые ошибки#

Ошибка 1: ТЗ без НФТ#

Симптом: ТЗ содержит только функциональные требования (что делать), но не нефункциональные (как делать).

Пример: ТЗ: “Агент парсит логи, вычисляет статистику, предлагает гипотезы.”

Нет НФТ:

• Задержка? (сколько времени занимает анализ)
• Надёжность? (какая доля ошибок допустима)
• Безопасность? режим только чтение, журнал аудита

Почему это происходит: Агент фокусируется на ФТ, потому что они “очевидны”. НФТ требуют явного запроса.

Последствия: Реализуем систему, которая “работает”, но медленно/небезопасно/ненадёжно.

Как избежать: Явно запрашивай НФТ в промпте:

Создай ТЗ с ФТ и НФТ: производительность/надёжность/безопасность/сопровождаемость.

Ошибка 2: Критерии приёмки без метрик#

Симптом: Критерии приёмки содержат “улучшить”, “оптимизировать”, “лучше” (не измеримо).

Пример: Критерий приёмки: “Агент должен быстрее анализировать логи.”

Что значит “быстрее”? 10% быстрее? 2x быстрее? Непонятно.

Почему это происходит: Агент использует расплывчатые формулировки, потому что не понимает, что AC должны быть измеримыми.

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

Как избежать: Требуй измеримые метрики:

AC должны быть измеримыми: числа, а не "улучшить".
Пример: "задержка ≤ <WINDOW>" (не "быстрее").

Ошибка 3: декомпозиция работ слишком крупная или слишком детальная#

Симптом: декомпозиция работ содержит задачи “на час” (слишком детально) или “на недели” (слишком крупно).

Пример: Слишком детально:

• T1: “Создать файл main.go” (1 hour)
• T2: “Импортировать библиотеки” ()

Слишком крупно:

• T1: “Реализовать весь агент” (недели)

Почему это происходит: Агент не понимает оптимальный уровень детализации.

Последствия:

• Слишком детально → накладные расходы на отслеживание
• Слишком крупно → нет видимости прогресса

Как избежать: Укажи уровень детализации явно:

Декомпозируй проект на задачи (уровень детализации: несколько дней на задачу).

Резюме#

Что мы сделали#

• Создали ТЗ v1 с ФТ, НФТ и критериями приёмки: измеримые метрики
• Создали План v1 с декомпозицией работ, риск-регистром, оценкой времени
• Использовали агента для декомпозиции задач и оценки рисков

Артефакты#

• ТЗ v1: функциональные/нефункциональные требования + критерии приёмки
• План v1: декомпозиция работ: задачи/зависимости/оценки; риск-регистр: вероятность/влияние/митигация

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

1. ТЗ как контракт: ФТ (что делать) + НФТ (как делать) + AC (как проверить)
2. Приоритезация: обязательные/желательные/опциональные (не все требования одинаково важны)
3. Риск-менеджмент: идентифицировать риски рано, план митигации готов

Критерии приёмки главы#

Вы успешно освоили материал, если можете:

• Сформулировать ТЗ v1: ФТ + НФТ + критерии приёмки с измеримыми метриками
• Сделать План v1: декомпозиция (задачи/зависимости/оценки) + риск-регистр (вероятность/влияние/митигация)
• Явно указать уровень детализации задач (не «на час» и не «на недели»)

Следующие шаги#

В Главе 4 вы научитесь:

• проектировать архитектуру v1 (компоненты, API, компромиссы)
• использовать агента для дизайна системы
• валидировать архитектуру через ADR — записи архитектурных решений

Завязка: Вы знаете “что строим” (ТЗ) и “как разбить на задачи” (план). Но как спроектировать решение? Какие компоненты? Какие компромиссы? Об этом — в следующей главе.

От требований к плану. Вы прошли третий шаг.