Контроль объёма и управление изменениями
После того как scope одобрен, главная управленческая задача — не отходить от него молча: каждое расширение меняет бюджет, сроки и риски, а в клиентских проектах часто требует формального CR или дополнительного соглашения. В системе эту функцию выполняет /scope-check.
Важно: «маленькие дополнения» («пока вы тут — сделайте ещё и Y») не считаются тихим бэклогом. Они фиксируются.
Что хранит /scope-check
Один живой документ — scope-check.md — с четырьмя разделами:
| Раздел | Что в нём |
|---|---|
| Допущения | Базовые линии: на чём держится одобренный scope (объёмы, количество интеграций, среды, сроки, коммерческая база). 3–5 строк в стандартном случае, 10–15 в больших проектах |
| OOS / журнал изменений | Запросы, которые вышли за scope: тип, связанное допущение, источник, оценка влияния, статус |
| История изменений | Append-only журнал: что, когда, кто |
| Источники | Откуда взяты допущения (устав, scope, договор, BRD, план) |
Шаг 1. Базовая линия: /scope-check baseline
Наберите /scope-check baseline (или просто /scope-check — если базовой линии нет, агент создаст её). Агент извлечёт из устава, scope, договора и BRD существенные допущения — те, нарушение которых сдвинет цену или финиш:
- измеримые параметры: количество модулей, объём данных, число интеграций, среды, юрисдикции;
- явные включения и исключения;
- неявные границы (неоднозначность — это риск scope);
- коммерческая база (фикс / потолок / T&M / внутренний) — она задаёт строгость, но это не юридический совет.
Каждая строка — с источником, уверенностью, статусом («держится», «под давлением», «нарушено») и чувствительностью: что произойдёт, если допущение не выдержит.
Шаг 2. Оценка запроса: /scope-check assess
Когда появляется сигнал — новый запрос, «пока вы тут…», рост объёма, — агент оценивает его против базовой линии:
| Класс | Что это | Действие |
|---|---|---|
| В scope | Явно покрывается | Строки OOS нет |
| Исключено | Явно вне | OOS — зафиксировать и поднять вопрос |
| Серая зона | Разумное расширение? | Агент показывает доказательства — решаете вы |
| Новая работа | Не предполагалась | OOS — зафиксировать и поднять вопрос |
| Превышение объёма | Тот же scope, больше количества | Нарушение допущения — путь отличается от нового scope |
Критерий существенности: сдвинуло бы это цену, финишную дату или ключевой риск? Тривиальная вариация — в «наблюдаем»; существенное — в OOS/CR.
При оценке всегда фиксируется источник: кто, когда, где (тема письма, встреча, ключ задачи). Без источника строка не ставится.
Шаг 3. Регистрация: /scope-check register
Подтверждённые кандидаты попадают в журнал OOS/CR: id, что изменилось, тип (расширение / сужение / нарушение допущения / неоднозначность), связанное допущение, дата, источник, оценка влияния (диапазон допустим), поднят ли вопрос заказчику, статус («выявлено» → «оценено» → «уведомлено» → «цена согласована» / «поглощено» / «отложено»).
Каждая строка — черновик с вашим подтверждением: агент предлагает, вы решаете.
Шаг 4. Уведомление заказчику: /scope-check notice
Для существенных открытых вопросов на клиентских работах агент готовит черновик уведомления (в scope-check.md или отдельным датированным файлом):
- начинается с того, что обнаружено, а не с цены;
- ссылается на исходное допущение / фрагмент SOW;
- предлагает варианты: поглотить / отложить / формальный CR / дополнительное соглашение;
- спрашивает, как действовать; при возможности — договорённость до начала работ.
Без оправдательного тона и без позиции «против стороны». Юридическую формулировку — юрист.
Когда проверка запускается сама
Агент автоматически вызывает проверку scope в двух случаях (не ждёт вашей команды):
- Сигнал о росте — в диалоге, обходе
/manage, дельте или правках BRD появился «и ещё X», превышение объёма, выход за scope; - Новая работа в плане — перед тем как
/planили/ticketsдобавят новые блоки, фазы, эпики или наборы задач, которых нет в одобренном scope.
В обоих случаях: сначала оценка, потом — по вашему решению — поглощение, откладывание, CR или поправка scope.
Чего /scope-check не делает
- Не переписывает scope statement — если саму структуру блоков менять, это
/scope revise; - Не является ITIL CAB — это рабочий инструмент PM, а не организационная процедура;
- Не выдумывает цены и юридические выводы — оценки влияния в диапазонах с источником, решение о цене — ваше.
С чего продолжать
- Управление рисками — существенный OOS часто рождает новый риск.
- Планирование графика — принятое изменение попадает в план только после оценки.
- Отчётность для руководства — открытые изменения в отчёте.