Риски как модель: от реестра к управлению
Риск-реестр, который заполняют на старте и забывают, — это не инструмент. Это ритуал. Качественные оценки («высокий/средний/низкий») не помогают принимать решения. Они создают иллюзию контроля.
В методологии (PMI, ISO 31000) риск — это эффект неопределённости на цели. А неопределённость нельзя управлять «по ощущениям». Нужна модель.
Как перейти от списка к системе: • Количественная оценка вместо бинарных лейблов. Используйте Expected Monetary Value (EMV): Риск = Вероятность × Влияние. Не «высокое влияние», а «задержка на 10 дней = 800 часов простоя команды». Вероятность — в диапазонах (20–40%), а не в баллах. • Триггеры + правила решений. Риск управляем только при наличии явного индикатора и предопределённого алгоритма. Пример: «Если метрика X падает ниже порога Y → активируется план Б, резерв перераспределяется». Без этого реестр — просто архив. • Пре-мортем как часть планирования. Методика Г. Кляйна: «Проект провалился. Почему?». Это принудительно вскрывает когнитивные искажения и скрытые допущения. Команда ищет уязвимости до вложения бюджета, а не после срыва.
«Риски следует идентифицировать и анализировать непрерывно, поскольку неопределённость динамична по природе» (PMBOK Guide, 7th ed.).
На практике это меняет всё. Реестр становится живой моделью, связанной с базовыми линиями (это зафиксированные параметры проекта: объём, сроки и стоимость). Резервы рассчитываются на основе данных, а не интуиции. А команда перестаёт «тушить пожары» и начинает их предотвращать.
Какие практики количественной оценки и триггерного мониторинга вы используете? #ИнсафВафин #RiskManagement #PMBOK #ISO31000 #СистемныйПодход
· 13.07
Мне нравится сдвиг от реестра к модели: список рисков сам по себе мало что меняет, пока у него нет владельца, вероятности и триггеров. В high-load проектах я бы ещё привязал риск к SLO и раннему сигналу. Как вы это формализуете?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён