Управление рисками

Управление рисками в системе — это живой реестр (risk-register.md), который агент ведёт вместе с вами: находит кандидатов, предлагает скоринг, вы подтверждаете, он записывает. Меры реагирования — отдельный шаг: агент не выдумывает митигацию на этапе идентификации.

Важно: риск — это возможное будущее событие. Текущая проблема (issue) в таблицу рисков не попадает — она в работе.

Шаг 1. Идентификация и скоринг: /risks

Наберите /risks. Если реестра ещё нет — агент создаст его; если есть — проведёт пересмотр: сверит каждый открытый риск с новыми доказательствами (план, последний отчёт, блокеры трекера) и предложит изменения скоринга или статусов.

Затем агент ищет новых кандидатов. Фильтр: риск управляем и существенен для целей, дат, бюджета или scope этого проекта. Каждый кандидат формулируется как причина → эффект на конкретный результат:

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

Скоринг

Вероятность (L) и влияние (I) — по 1–5; оценка = L × I:

Оценка	Зона	Реакция
20–25	Критический	Немедленная эскалация
12–19	Высокий	Активное управление, еженедельный пересмотр
8–11	Средний	Плановый ответ, пересмотр раз в 2 недели
4–7	Низкий	Мониторинг
1–3	Незначительный	Принятие / наблюдение

Масштаб 1–5 (а не просто «высокий/средний/низкий») — чтобы внутри одной зоны риски оставались ранжированы.

Подтверждение и запись

Кандидаты показываются списком — с оценкой, источником, обоснованием и пустым полем «Меры» — и записываются в реестр только после вашего подтверждения. Ответственный — конкретный человек (из RACI устава или вашего списка), «команда» ответственным не бывает.

Колонки реестра: ID, риск (причина → эффект), категория, L × I = S с зоной, ответственный, статус (открыт / принят / случился / закрыт), триггер, меры (митигация и контингент в одной ячейке), дата пересмотра, источники. Плюс легенда скоринга, журнал изменений и дата следующего пересмотра.

Шаг 2. Меры реагирования: /risk-mitigate

Наберите /risk-mitigate (опционально: R01 R03 — конкретные риски; без аргументов — все High/Critical без мер). Для каждого риска агент готовит:

• Митигацию — что делается сейчас, чтобы снизить вероятность или влияние: конкретные действия, даты, именованный ответственный;
• Контингент — что делать, если сработал триггер или митигация не сработала;
• при необходимости — уточнение триггера.

Обе меры пишутся в одну ячейку реестра (формат «М: … · К: …») после подтверждения.

Качество мер: управляемые ролями этого проекта; без ложных процентов выполнения; без пустых «мониторить внимательно» без измеримого действия. Если доказательств мало — агент скажет об этом и предложит уточнить.

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

/risks                 → реестр: кандидаты, скоринг, триггеры
/risk-mitigate         → меры: митигация + контингент
/manage (еженедельно)  → раздел «Проверка рисков»: что актуально, прогресс мер
/status-delta          → случился риск? → в реестре статус «случился», работа — в трекер

Пересмотр — по расписанию из реестра (дата следующего пересмотра) и по триггерам.

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

• Не выдумывает меры на этапе идентификации — поле «Меры» остаётся «не запланировано» до /risk-mitigate;
• Не создаёт задачи в трекере молча — принятые меры могут стать задачами через /tickets (предложением);
• Не ведёт GRC-реестр — это риски поставки проекта, не организационные риски безопасности;
• Не стирает реестр при обновлении — только слияние, с журналом изменений.

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

• Контроль объёма — существенные изменения scope часто порождают риски.
• Регулярная работа: обход и планёрки — еженедельная проверка рисков в обходе.
• Отчётность для руководства — риски и меры в отчётах.