Как управлять рисками ИТ-проекта
В последнее время персональные данные клиентов и сотрудников крупных компаний периодически оказывались в общем доступе. Это нанесло сильный удар по репутации бизнеса, повлекло крупные штрафы, потерю клиентов и дорогостоящий аудит системы безопасности.
Если крупный бизнес может пережить такие проблемы, для малого и среднего такая утечка может стать фатальной. Нужно заранее думать о подобных проблемах и закладывать ресурсы на их преодоление.
Что такое IT-риски
В любом бизнесе рисками считают шкалу вероятности событий, из-за которых можно получить убытки или недополучить прибыль. В ИТ-проектах риски — это вероятность, что что-то пойдет не по плану и задачи не будут выполнены в срок.
Например, есть риск, что верстальщик не доделает интернет-магазин в срок, сайт сломается или реклама не принесет ожидаемых результатов. Ошибки в коде рабочего сайта могут привести к потере данных.
Какие-то риски оценивают, закладывают на их случай дополнительный бюджет и пытаются предотвратить, а другие просто не замечают и списывают на издержки — все зависит от вида деятельности и сложности проекта. Если перед стартом не оценить риски, есть шанс сорвать сроки или вовсе завалить проект.
«Сломаться может все что угодно, лучше предусмотреть это и заложить деньги и время на ремонт.
Многие ошибочно считают, что высокие риски в ИТ-проектах есть только у крупного бизнеса. Но даже небольшой размер не убережет бизнес от атак на ИТ-инфраструктуру. Если крупный бизнес чаще атакуют с целью украсть конфиденциальную информацию, то малый и средний — чтобы нанести прямой или косвенный ущерб.
Например, конкуренты могут заказать атаку на интернет-магазин, чтобы он „лежал“ на время распродаж или терял посетителей и опускался в органической выдаче».
Мартин Пилька
Тимлид HINTS
Виды рисков в IT-проектах
Риски в сфере ИТ делят на внешние и внутренние.
Внешние риски. Это негативные события, которые угрожают проекту извне. Они могут случиться из-за действий конкурентов, по вине сотрудников других подразделений бизнеса или как непредвиденные события.
Например, к внешним рискам относят атаки на ИТ-инфраструктуру, возможные проблемы у провайдера, санкции, которые затрагивают проект. Сокращение финансирования с точки зрения ИТ-проекта тоже считается внешним риском.
Внутренние риски. Это события внутри проекта, которые мешают завершить его в срок. Например, это может быть болезнь или увольнение сотрудника, проблемы с техническим оснащением или неверный выбор стратегии разработки.
По статистике InfoWatch, утечки данных в российских компаниях чаще происходят по вине сотрудников. Лишь в 13% случаев данные похищают злоумышленники.
«По нашему опыту, малому и среднему бизнесу чаще всего грозят внутренние риски. Самая распространенная проблема — баги в разработке. Руководители хотят сэкономить, нанимают неопытных разработчиков и игнорируют стадию тестирования проекта. Руководствуются принципом „Лишь бы работало“ и пропускают часть важных процессов.
Распространенная проблема, когда за разработку сайта, интернет-магазина или CRM-системы отвечает один программист. Когда он уходит, оказывается, что никто не знает, как все это работает, как можно что-то добавить, изменить или перенастроить.
Часто проблема в устаревшей ИТ-инфраструктуре. В моей практике был случай, когда крупный интернет-магазин захватил большую долю рынка и долгое время не вкладывался в модернизацию ИТ. Внешний аудит предложил модернизацию сайта и CRM-системы. Стоимость доработок оценили в 1 млн рублей.
От обновлений отказались, а через какое-то время начали терять трафик и продажи. За несколько лет бизнес потерял гораздо больше, чем нужно было вложить».
Мартин Пилька
Тимлид HINTS
При более глубоком и детальном анализе применяют классификации для разделения внешних и внутренних рисков на группы поменьше. Например, внутренние риски можно разделить на стратегические, операционные, программные и так далее.
Такой анализ обычно применяют только в крупных проектах, когда сложно оценить степень влияния разных факторов на проект без дополнительного разделения.
Как управлять рисками в IT-проектах
Управление рисками состоит из трех этапов: оценка, снижение рисков и борьба с последствиями.
Оценка рисков. На этом этапе находят и определяют все возможные опасности для проекта. Их разделяют по вероятности наступления или по величине угрозы. Это позволяет определить, с какими рисками надо бороться, а какими можно пренебречь.
Не все риски очевидны и лежат на поверхности, некоторые негативные моменты нужно найти. Например, руководитель может не знать, что у сайта проблемы с безопасностью и данные клиентов могут похитить злоумышленники. Для обнаружения таких рисков нужно заказывать технический аудит.
Снижение вероятности возникновения риска. После оценки нужно принять меры, которые снизят вероятность наступления опасных рисков. Например, чтобы не потерять данные, сокращают интервал между резервными копиями. Чтобы не терять интернет-соединение, проводят резервный канал связи.
Борьба с последствиями. В этом процессе разрабатывают меры, которые помогут преодолеть последствия негативных событий с наименьшими затратами для проекта. Например, в случае атаки на сайт можно предусмотреть переезд на выделенный сервер. Стоимость работ нужно заложить в бюджет, а срок выполнения добавить к общему времени проекта.
Продумывать меры по преодолению негативных последствий и закладывать это в бюджет важно во всех ИТ-проектах. Особенно если деятельность связана с приемом платежей, обработкой персональных данных или хранением пользовательского контента: текстов, фото, видео.
Дальше мы рассмотрим только этап оценки рисков в ИТ-проектах. Остальные стадии управления рисками сильно зависят от специфики бизнеса, размера компании и сроков проекта.
Как оценить риски в IT-проекте
Чтобы понимать, с какими проблемами может столкнуться ИТ-проект в будущем, используют качественную и количественную оценку рисков.
Качественная оценка — более простой способ оценки рисков. Риски делят по вероятности возникновения или по степени влияния на проект, например:
- Риски с высокой вероятностью: баги в коде или болезнь сотрудников.
- Риски со средней вероятностью: утечки данных, отключение интернета, атаки конкурентов.
- Риски с низкой вероятностью: поломки оборудования.
После такой оценки можно понять, с какими рисками нужно бороться, а с какими дешевле смириться. Риски, которые могут возникнуть чаще или которые сильнее влияют на проект, нужно снижать в первую очередь. Подробнее об этом расскажем дальше.
«Проще всего оценить риски, когда есть четко измеримое негативное последствие, например штраф за утечку персональных данных. Многие просто игнорируют этот риск, ведь штраф до 100 тысяч рублей часто оказывается меньше стоимости нужных мер защиты.
Бизнес готов идти на этот риск, чтобы не нанимать отдельного разработчика. Факт утечки сложно установить, штрафуют за это не всех».
Мартин Пилька
Тимлид HINTS
Количественная оценка — более сложный способ оценки рисков, который позволяет оценить влияние негативного события на проект в каком-то числовом выражении.
Чтобы сделать количественную оценку, нужно привлечь опытных экспертов или собрать хорошую статистическую выборку. Например, чтобы понять вероятность простоя сайта из-за отказа сервера, нужно получить данные по отказам у разных хостингов, определить их причины и оценить вероятность события в конкретном случае.
«Некоторые риски сложно оценить силами сотрудников, нужно привлекать сторонних экспертов с опытом.
Например, анализ интернет-магазина показал, что среднее время загрузки страницы — 4 секунды. Это больше показателей конкурентов. По расчетам экспертов, снижение скорости на 2 секунды увеличивает конверсию примерно на 30%.
Для увеличения скорости загрузки можно оптимизировать контент на сайте, перенести его на другой хостинг или применить какие-то плагины. Руководитель должен сопоставить стоимость доработок и прогнозируемую прибыль, чтобы принять решение».
Мартин Пилька
Тимлид HINTS
Иногда количественную оценку можно сделать своими силами. Например, если сайт компании уже отключался, можно оценить убытки в этот период и сделать предположение об убытках из-за возможных будущих отключений.
«Количественную оценку удобно проводить на основе зарплаты сотрудников и стоимости разработки. Так можно понять, сколько стоит реализация проекта в час, сутки или неделю и сколько руководитель потеряет в случае простоя команды».
Мартин Пилька
Тимлид HINTS
Какие риски стоит предотвращать
После качественной и количественной оценок нужно определить, с какими рисками бороться, а с какими нет. Для этого используют три показателя: допустимая величина риска, риск-аппетит и уровень терпимости к риску.
Допустимая величина риска. Это максимальный ущерб от негативных событий, при котором можно продолжать работу без дополнительных вложений. Если ущерб будет выше допустимой величины, придется менять какой-то процесс или увеличивать бюджет.
Допустимую величину риска в разных обстоятельствах определяют по-разному. На запуске проекта бизнес готов уйти в минус, а на длинной дистанции проект должен приносить прибыль или другой положительный результат.
Компания сдает в аренду сервер. Он должен соответствовать одному из классов надежности по общепринятой классификации Tier. Чтобы соответствовать минимальному классу Tier 1, сервер не должен простаивать больше 28,8 часа в год. Значит, допустимая величина риска — технические сбои, которые в сумме будут длиться менее 28,8 часа в год. Если время простоя увеличится, сервер не получится сдавать в аренду.
Риск-аппетит. Это суммарный ущерб от негативных событий, который готов принять руководитель проекта для достижения цели. Этот показатель можно считать плановым.
Владелец хочет, чтобы сервер соответствовал самому высокому классу Tier 4. Такое оборудование не может простаивать больше 26 минут в год. Это позволит брать максимальную абонплату с клиентов.
Риск-аппетит по этому проекту — технические сбои, которые в сумме будут длиться менее 26 минут в год.
Уровень терпимости к риску. Это возможные отклонения от риск-аппетита, которые готов принять руководитель. Показатель можно считать отклонением от плана. На каждом этапе проекта уровень терпимости может быть разным.
Владелец готов к тому, что сервер будет соответствовать классу Tier 3, время простоя в этом случае может составлять до 95 минут в год.
Технические сбои, которые увеличат время простоя с 26 до 95 минут в год, будут уровнем терпимости в этом проекте.
Эти показатели позволяют выделить критичные риски, с которыми нужно бороться, и незначительные, с которыми можно смириться.
В нашем примере можно мириться с финансовыми рисками. Например, если вырастет арендная плата за помещение, где стоит сервер, это не скажется на времени простоя оборудования. Заранее искать новое место и готовиться к переезду не нужно.
Зато есть другой риск: администратор, который обслуживает сервер, может заболеть. Это увеличит время простоя оборудования. Значит, нужно нанять сменщика или заранее найти стороннего специалиста, готового помочь в случае простоя.
Главное
- Риски в ИТ-проекте — это вероятность наступления негативных событий.
- Риски могут зависеть от внешних факторов, которые окружают проект или весь бизнес, или от внутренних, которые возникают в команде разработчиков.
- Управление рисками состоит из оценки, снижения шанса их возникновения и борьбы с последствиями.
- Риски можно оценить качественно и количественно. Качественная оценка делит риски по вероятности наступления или по опасности для проекта. Количественная оценка измеряет размер ущерба от негативных событий.
- После определения рисков нужно решить, какие стоит минимизировать, а с какими можно смириться.
А вы оцениваете риски в своих ИТ-проектах или надеетесь, что ничего плохого не произойдет?