Как упорядочить хаос: управление рисками в ИТ-проекте

2 марта 2026

Основы современного риск-менеджмента в ИТ: этапы и типовые ошибки

Любой ИТ-проект связан с рисками: организационными, техническими, финансовыми и многими другими. Проектной команде важно грамотно управлять ими. Это позволит, в частности, в случае развития событий по негативному сценарию минимизировать издержки. О том, как выглядит процесс управления рисками на практике, рассказывает директор направления дата-практики компании IT_ONE Александр Самойлов.

Риск в ИТ-проекте – это неопределенное событие, которое в случае наступления может как отрицательно, так и положительно повлиять на ключевые показатели проекта: сроки, бюджет, качество и содержание. В отличие от проблемы (уже случившегося события, с которым нужно бороться здесь и сейчас), риск может наступить, а может и не наступить.

Итак, актуальность управления рисками обусловлена

высокой стоимостью ИТ-проектов
сложностью современных технологий
сильной зависимостью бизнеса от стабильной работы и качества ИТ-инфраструктуры
высокой скоростью изменений в технологической среде
возрастающими требованиями к обеспечению информационной безопасности.

Управление рисками (риск-менеджмент) – это проактивная деятельность, направленная на то, чтобы сократить количество потенциальных проблем в ИТ-проекте. Существуют различные методологии риск-менеджмента, а также соответствующие стандарты: международный стандарт ISO/EIS 31010:2009 и его российский аналог ГОСТ Р ИСО 31000:2010.

Рассмотрим, какие этапы управления рисками и типовые ошибки встречаются на практике.

Этапы управления рисками

Первый этап – идентификация рисков. Его цель – выявить и зафиксировать все потенциальные риски. В зависимости от опыта и креативности специалистов их может быть от единиц до нескольких десятков.

Для выявления рисков существует множество методов, которые могут взаимодополнять друг друга. Вот основные из них:

мозговой штурм
анализ контрольных списков с предыдущих проектов
метод аналогии (анализ аналогичного проектного опыта)
SWOT-анализ (анализ сильных и слабых сторон проекта)
анализ допущений (оценка допущений по ходу проекта как потенциальных рисков)
диаграмма Исикавы (декомпозиция риска)
карточки Кроуфорда (последовательное выявление рисков группой экспертов)
метод Дельфи (аналогичен мозговому штурму, но его участники не знают друг друга)
метод номинальных групп (сочетание экспертного подхода и совместного обсуждения).

Второй этап – качественный анализ рисков. Его цель – в первоначальном перечне рисков расставить приоритеты с учетом их влияния на проект и определить наиболее критичные.

Это важно, поскольку риски не равны по вероятности возникновения и степени потенциальной угрозы, а всем множеством рисков с одинаковой эффективностью управлять невозможно.

По нашей практике, несколько незначительных рисков обычно меньше влияют на проект, чем один риск высокого уровня.

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

Третий этап – количественный анализ рисков. Его цель – оценить риски в числовом выражении.

Изначально риски могут быть рассчитаны не только в деньгах, но и во времени (задержка реализации проекта, излишние трудозатраты – в часах), в качественных параметрах (например, репутационный ущерб – в баллах).

Впоследствии все нефинансовые параметры можно перевести в деньги с помощью методологии EMV (Expected Monetary Value). Ее суть заключается в определении всех возможных событий для каждого риска, оценке вероятности их возникновения, определении финансовых последствий и расчете EMV для каждого сценария.

Четвертый этап – планирование ответных действий. Его цель – разработанный план мероприятий для каждого приоритетного риска. Этот этап состоит из четырех ключевых шагов.

Шаг №1 – выбор и принятие одной из стратегии для отработки негативных рисков. Это может быть

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

Шаг №2 – назначение ответственного (владельца риска – risk owner). Для каждого риска необходимо выбрать сотрудника, который будет следить за ситуацией, готовить варианты решения и информировать команду.

Шаг №3 – подготовка плана реагирования. Запланированные операции по реагированию на риски должны соответствовать серьезности риска, быть экономически эффективными в решении проблемы, реалистичными в контексте проекта и согласованными со всеми участниками. Например, очевидно, что для создания запасного канала коммуникации команде не нужно разрабатывать собственный мессенджер, а можно воспользоваться одним из готовых решений.

Стоит отметить: шаги №2 и №3 можно менять местами и объединять. Главное – получить план реагирования и ответственного за выполнение этого плана. Кроме того, если не удается придумать план реагирования, соответствующий принятой для риска стратегии, то можно вернуться к шагу№1, выбрать следующую стратегию и повторить шаги №2 и №3.

Шаг №4 – формирование реестра рисков для централизованного хранения всей информации о рисках. Чаще всего реестр представляет из себя таблицу, в которой отображены

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

и другие параметры.

Пятый этап – мониторинг и контроль. Его цель – постоянная поддержка реестра рисков в актуальном состоянии. Рекомендуется проводить регулярные (например, еженедельные) короткие встречи по рискам в рамках проектной команды, вносить соответствующие корректировки в реестре и доносить эту информацию до всех заинтересованных лиц.

Типовые ошибки в риск-менеджменте

По нашей практике, многие команды, даже опытные, допускают следующие ошибки.

«Составили реестр и забыли». К сожалению, многие проектные команды, сформировав таблицу рисков, забывают о ней до тех пор, пока тот или иной риск не превращается в проблему. Однако к этому моменту в проекте могут появиться новые риски, а старые – утратить актуальность. Управление рисками – непрерывный процесс, требующий постоянного мониторинга.
«Это и так понятно». Иногда кажется, что тот или иной риск лежит на поверхности и очевиден всем, а значит, его необязательно где-то фиксировать. Однако неоформленный риск легко забывается, и если сегодня он понятен всем, то завтра для кого-то может стать неприятным сюрпризом.
«Риск не сработал, а значит – не считается». После завершения проекта необходимо проанализировать реестр и оценить: какие риски сработали, какие не сработали, какие планы мероприятий и меры реагирования пригодились, какие оказались некорректными, какие риски были оценены верно, какие неверно и т. д. Анализ предыдущих рисков – даже тех, которые не сработали, – это полезный метод выявления рисков для нового проекта.
«Позитивный риск – это не риск». Как я упомянул в начале, полноценная стратегия риск-менеджмента предусматривает управление не только негативными, но и позитивными рисками: например, когда выручка команды от реализации проекта может оказаться вдвое больше запланированной. Игнорирование позитивных рисков приводит к упущенным возможностям. Стоит работать с ними так же, как с негативными: фиксировать, составлять план действий и назначать ответственного.

Риск-менеджмент – эффективный способ управления хаосом

Любой ИТ-проект содержит множество нюансов в процессах и взаимодействиях команды, стейкхолдеров, подрядчиков и т. д. Возникновение рисков при этом – неизбежность. Успех проекта во многом зависит от умения команды – в первую очередь, проектного менеджера, но не только – управлять этими рисками и обратить их из проблемы в преимущество.

И в качестве резюме – несколько советов.

Начинайте с малого. Если у вас нет опыта, не пытайтесь внедрить сложную систему риск-менеджмента сразу. Например, можно ограничиться базовым набором параметров реестра рисков, не уходя далеко в детали. Главное – обеспечить регулярность управления рисками.

Вовлекайте в процесс управления рисками всю команду, в том числе заказчиков проекта. Стейкхолдер, например, может заранее подсказать, что тот или иной риск имеет наивысший приоритет.

Ведите реестр рисков просто и наглядно. Обычная Excel-таблица или доска в Miro лучше чрезмерно сложной системы, которая может быть неудобна.

Обсуждайте риски открыто, без поиска виновных. Ведь в парадигме зрелого риск-менеджмента сработавший риск – это не чья-то вина, а запланированное мероприятие, к которому команда подготовилась.

276