Как управлять рисками ИТ-проекта

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

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

Риски в сфере ИТ делят на внешние и внутренние.

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

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

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

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

Управление рисками состоит из трех этапов: оценка, снижение рисков и борьба с последствиями.

Оценка рисков. На этом этапе находят и определяют все возможные опасности для проекта. Их разделяют по вероятности наступления или по величине угрозы. Это позволяет определить, с какими рисками надо бороться, а какими можно пренебречь.

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

Снижение вероятности возникновения риска. После оценки нужно принять меры, которые снизят вероятность наступления опасных рисков. Например, чтобы не потерять данные, сокращают интервал между резервными копиями. Чтобы не терять интернет-соединение, проводят резервный канал связи.

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

Дальше мы рассмотрим только этап оценки рисков в ИТ-проектах. Остальные стадии управления рисками сильно зависят от специфики бизнеса, размера компании и сроков проекта.

Качественная оценка — более простой способ оценки рисков. Риски делят по вероятности возникновения или по степени влияния на проект, например:

1. Риски с высокой вероятностью: баги в коде или болезнь сотрудников.
2. Риски со средней вероятностью: утечки данных, отключение интернета, атаки конкурентов.
3. Риски с низкой вероятностью: поломки оборудования.

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

Количественная оценка — более сложный способ оценки рисков, который позволяет оценить влияние негативного события на проект в каком-то числовом выражении.

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

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

После качественной и количественной оценок нужно определить, с какими рисками бороться, а с какими нет. Для этого используют три показателя: допустимая величина риска, риск-аппетит и уровень терпимости к риску.

Допустимая величина риска. Это максимальный ущерб от негативных событий, при котором можно продолжать работу без дополнительных вложений. Если ущерб будет выше допустимой величины, придется менять какой-то процесс или увеличивать бюджет.

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

Компания сдает в аренду сервер. Он должен соответствовать одному из классов надежности по общепринятой классификации Tier. Чтобы соответствовать минимальному классу Tier 1, сервер не должен простаивать больше 28,8 часа в год. Значит, допустимая величина риска — технические сбои, которые в сумме будут длиться менее 28,8 часа в год. Если время простоя увеличится, сервер не получится сдавать в аренду.

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

Владелец хочет, чтобы сервер соответствовал самому высокому классу Tier 4. Такое оборудование не может простаивать больше 26 минут в год. Это позволит брать максимальную абонплату с клиентов.

Риск-аппетит по этому проекту — технические сбои, которые в сумме будут длиться менее 26 минут в год.

Уровень терпимости к риску. Это возможные отклонения от риск-аппетита, которые готов принять руководитель. Показатель можно считать отклонением от плана. На каждом этапе проекта уровень терпимости может быть разным.

Владелец готов к тому, что сервер будет соответствовать классу Tier 3, время простоя в этом случае может составлять до 95 минут в год.

Технические сбои, которые увеличат время простоя с 26 до 95 минут в год, будут уровнем терпимости в этом проекте.

Эти показатели позволяют выделить критичные риски, с которыми нужно бороться, и незначительные, с которыми можно смириться.

В нашем примере можно мириться с финансовыми рисками. Например, если вырастет арендная плата за помещение, где стоит сервер, это не скажется на времени простоя оборудования. Заранее искать новое место и готовиться к переезду не нужно.

Зато есть другой риск: администратор, который обслуживает сервер, может заболеть. Это увеличит время простоя оборудования. Значит, нужно нанять сменщика или заранее найти стороннего специалиста, готового помочь в случае простоя.

1. Риски в ИТ-проекте — это вероятность наступления негативных событий.
2. Риски могут зависеть от внешних факторов, которые окружают проект или весь бизнес, или от внутренних, которые возникают в команде разработчиков.
3. Управление рисками состоит из оценки, снижения шанса их возникновения и борьбы с последствиями.
4. Риски можно оценить качественно и количественно. Качественная оценка делит риски по вероятности наступления или по опасности для проекта. Количественная оценка измеряет размер ущерба от негативных событий.
5. После определения рисков нужно решить, какие стоит минимизировать, а с какими можно смириться.