Реестр рисков помогает принимать решения, когда приоритеты, владельцы и следующие меры видны сразу. Для структуры используйте сторителлинг данных в презентации (на английском): сначала метод и дата среза, затем воздействие и нужное решение.
После проверки формулировок рисков можно использовать создание презентации из текста, чтобы собрать черновик слайдов. Сохраните исходный реестр и ссылки на подтверждения: создание презентации само по себе не означает согласования мер.
Зафиксируйте метод и дату
Укажите шкалу, период и дату данных. Объясните, перемножаются ли вероятность и влияние или действует другое правило. Старую оценку нельзя выдавать за текущее состояние.
Сильное влияние при низкой вероятности требует другого решения, чем частое, но легко ограничиваемое событие. Не придумывайте точную вероятность, если данные дают только качественную оценку.
Покажите главные риски понятно
Описывайте риск через причину, возможное событие и последствия. Разделяйте присущий риск до мер и остаточный риск после них. Показывайте неопределённость, не придумывая точные вероятности.
Техническое препятствие не равно ущербу, который оно может вызвать. Такая граница не даёт дважды посчитать одно и то же последствие.
Рассмотрим миграцию системы управления идентификацией. R-01 — вымышленный пример планирования, а не отчёт об успешно завершённой миграции.
| Поле R-01 | Запись о миграции системы идентификации |
|---|---|
| Цель и период | Завершить сквозное тестирование рабочих процессов до запланированного запуска; оценить период до решения о переключении. |
| Причина | Соответствие ролей в старой и новой системах ещё не подтверждено. |
| Возможное событие | К моменту решения о переключении новый процесс идентификации не готов к сквозным тестам. |
| Последствия | Команда не сможет завершить необходимые тесты, поэтому запуск, возможно, придётся перенести. Продолжительность задержки пока не определена. |
| Ответственность | Руководитель миграции сообщает об изменениях; спонсор проекта согласует изменение запуска. |
| Предотвращение и подтверждения | Подтвердить соответствие ролей и протестировать типовые сценарии администратора, обычного пользователя и служебной учётной записи. Сохранить проверку соответствий и результаты тестов, включая ошибки. |
Если срок тестирования уже пропущен, несостоявшийся этап — возникшая проблема, а не будущая вероятность. Свяжите запись о проблеме с R-01 и сохраните историю. Дальнейшую неопределённость, например влияние на новую дату запуска, оценивайте отдельно, не начисляя повторно баллы за уже произошедшее событие.
Проверьте владельцев и меры
Для каждой меры нужны владелец, статус, целевая дата и ожидаемое подтверждение. «В работе» не является проверяемым следующим шагом. Если нет владельца или даты, это нерешённый вопрос.
Для R-01 задайте конкретный ранний сигнал: если подтверждение ролей остаётся заблокированным в течение двух последовательных еженедельных отчётных циклов, руководитель миграции выносит вопрос спонсору. Не ждите второго цикла, если решение о переключении или условия безопасности требуют действовать раньше. Два цикла — правило этого примера проекта, а не универсальный порог риска.
Резервный план — отложить переключение и сохранить доступность действующего сервиса идентификации до завершения недостающих тестов. Укажите, кто может согласовать этот вариант, можно ли продолжать поддержку старого сервиса и какие требования безопасности и эксплуатации действуют. Руководитель миграции может предложить план, но изменение запуска должен явно одобрить спонсор.
Снижать оценку остаточного риска можно только на основании подтверждённого соответствия ролей и результатов повторных тестов. Закрытая задача или один успешный вход не подтверждают все три сценария учётных записей. Пока ошибки не исправлены либо осознанно не приняты уполномоченным лицом, показывайте оставшийся риск и следующую точку проверки.
Orange Book HM Treasury связывает обработку рисков с ответственностью за согласование, наблюдением и резервным планированием. Меры R-01 — пример для проекта, а не обязательная процедура из этого руководства.
Следующим проверяемым шагом может быть техническая проверка, пункт договора или тест.
Не окрашивайте эти вопросы для решения или эскалации искусственно в зелёный.
Соберите короткий набор слайдов
- Вопрос решения и дата данных
- Метод и шкала
- Тепловая карта или список приоритетов
- Главные риски, причины и последствия
- Меры, владельцы и остаточные риски
- Решения и следующая проверка
Подробные строки реестра и источники перенесите в приложение. На основном слайде оставьте только то, что меняет ресурс, эскалацию или допущение.
Завершите следующей проверкой
Завершите презентацию решениями и датой следующей проверки.
Баллы описывают метод, а не будущее. Разделяйте подтверждённые факты, допущения и сигналы для наблюдения. Так можно распределять ресурсы или эскалировать вопрос без приписывания реестру несуществующей точности.
Укажите источник каждой оценки и человека, который её проверил, чтобы команда могла повторить расчёт. Если метод изменился, сохраните прежнюю версию и объясните, почему итог теперь другой.
