История, которая стоит миллионов

Производственная компания запускала новый цифровой продукт. Выбрали технологию, которую «все сейчас используют». Собрали команду, начали разработку. Через 6 месяцев выяснилось: выбранный стек не тянет нагрузку, база данных падает при 500 одновременных запросах, а интеграция с 1С требует отдельного проекта на полгода.
Команда говорит: «надо переписывать».
Бюджет улетел в 2 раза выше запланированного. Сроки сорваны. Рынок ушёл к конкуренту. Знакомо?

Такое случается не потому, что IT-команда плохая. А потому что риски не были идентифицированы и оценены до старта.
В этой статье система: как бизнесу смотреть на IT-риски, не впадая в технические детали, и что реально работает для их снижения.

Три типа IT-рисков, о которых стоит знать руководителю

Все риски в IT-проектах можно разделить на три вида. Для каждого — свой подход к управлению.

1. Технические риски — «сломается или не потянет»

Связаны с технологиями, архитектурой, качеством кода.
Примеры:

• Выбрали непроверенную технологию — через год некому поддерживать
• Обнаружили критическую ошибку на поздних стадиях — исправление в 10 раз дороже
• Унаследовали систему без документации — каждый апдейт рискован

Главное заблуждение: технические риски — это проблема разработчиков. На самом деле это проблема бизнеса, потому что стоимость их устранения растёт экспоненциально.

Закон Боэма: ошибка, найденная на этапе эксплуатации, стоит в 50–100 раз дороже, чем та же ошибка, исправленная на этапе проектирования.

Переведу на язык бизнеса: сэкономили 500 тыс. на аналитике и проектировании — заплатите 25–50 млн на доработках и простоях.

2. Организационные риски — «команда не справится»

Связаны с людьми, процессами, коммуникацией.
Примеры:

• Ключевой разработчик уволился в середине проекта
• Бизнес и IT говорят на разных языках — требования поняты неправильно
• Подрядчик оказался некомпетентным, а checkpoints не заложены в контракт
• Внедрение системы саботируется сотрудниками, которые не хотят менять процессы

Почему этим рискам уделяют меньше всего внимания: их сложно оцифровать. Но они же — самая частая причина провала IT-проектов (по данным Standish Group (Chaos Report 2020) — выше 50% проектов страдают именно от организационных проблем).

3. Операционные риски — «упало и не встало»

Связаны с эксплуатацией уже работающих систем.

Примеры:

• Сервер лёг в час пик — потеряли выручку за 4 часа простоя
• Слив данных из-за недостаточной защиты — штрафы и репутация
• Зависимость от одного вендора — он поднял цены, а мигрировать некуда
• Обновление стороннего сервиса сломало интеграцию — data loss

---

Матрица рисков: как расставить приоритеты

Главный инструмент для управления рисками — простая матрица. Не нужны сложные методологии, PMBoK и сертификаты. Нужны две оси:

• Вероятность (насколько вероятно, что риск реализуется: 1–5)
• Ущерб (сколько потеряем в деньгах, времени, репутации: 1–5)

Как работать с матрицей

Шаг 1. Составьте список рисков — выпишите всё, что может пойти не так. Привлеките и бизнес, и IT. У каждого своя картина мира.

Шаг 2. Оцените каждый риск по шкале 1–5 по двум параметрам: вероятность и ущерб.

Шаг 3. Определите зону:

• Красная (8–25 баллов): требует немедленных действий. Выделите бюджет, назначьте ответственного, поставьте дедлайн.
• Жёлтая (4–7 баллов): мониторинг и план Б. Зафиксируйте, что будете делать, если риск реализуется.
• Зелёная (1–3 балла): принять. Не тратьте ресурсы на маловероятные и малозначимые риски.

Шаг 4. Назначьте владельца — конкретного человека, который отвечает за мониторинг и реакцию по каждому красному риску.

Шаг 5. Пересматривайте раз в квартал — риски живут, меняются, исчезают.

---

Топ-5 рисков, на которые стоит обратить внимание прямо сейчас

На основе опыта работы с десятками IT-проектов — вот риски, которые чаще всего «выстреливают»:

Риск №1. Неверный выбор технологии

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

Профилактика:

• Требуйте обоснования: «почему существующее решение не подходит именно для этой задачи?»
• Заложите буфер времени на изучение технологии
• При возможности — наймите эксперта, который уже применял эту технологию в проектах

Красный флаг: если аргументация сводится к «это современно» или «мы хотим этому научиться» — это не бизнес-решение, это R&D за счёт проекта.

Риск №2. Устаревшие технологии и legacy-системы

Как проявляется: продукт работает на технологиях, которые никто не обновлял 5–7 лет. Найти специалиста на рынке — проблема. Любое изменение — операция на открытом сердце.

Профилактика:

• Проведите технический аудит (но примите, что после аудита всё равно будут сюрпризы)
• Планируйте поэтапную миграцию, а не «переписать всё с нуля»
• Включите в бюджет регулярное обновление критических компонентов

Из практики: Компания унаследовала продукт «от третьих рук». Документации не было. Провели аудит по методике C4 — через месяц стало понятно, из чего система состоит. Нашли 11 мест, которые могли упасть при первой же нагрузке. Закрыли 3 самых критичных за 2 месяца. Это не решило всех проблем, но сняло 70% операционных рисков.

Риск №3. Позднее обнаружение ошибок

Как проявляется: ошибки проектирования обнаруживаются на этапе тестирования или, хуже, в продакшне. Стоимость исправления взлетает в десятки раз.

Профилактика:

• Коллективное рецензирование требований и архитектуры до старта разработки
• Автоматизированное тестирование на каждом этапе (не только перед релизом)
• Smoke-тесты после каждого изменения

Для руководителя: если команда говорит «мы начнём тестировать, когда всё допишем» — это красный флаг. Правильный подход: тесты пишутся параллельно с кодом или до него.

Риск №4. Зависимость от ключевых сотрудников

Как проявляется: один человек знает, как работает критическая система. Он уходит в отпуск / увольняется / заболевает — и проект встаёт.

Профилактика:

• Документирование архитектуры и ключевых решений
• Кросс-функциональное обучение (каждый критический модуль знают минимум 2 человека)
• Code review — чтобы код понимал не только автор

Риск №5. Вендор-лок и регуляторные риски

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

Профилактика:

• При выборе ПО закладывайте сценарий миграции в TCO
• Для критических систем используйте открытые стандарты и форматы данных
• Мониторьте регуляторную среду: 152-ФЗ, Указ 250, КИИ — требования меняются

---

Чек-лист: оцените уровень риска вашего IT-проекта

• Есть ли у проекта утверждённый бюджет на риски (резерв 10–20% от сметы)?
• Проведён ли аудит архитектуры до старта разработки?
• Назначены ли ответственные за каждый критический риск?
• Есть ли план действий (runbook) на случай сбоя ключевой системы?
• Критические модули документированы и известны минимум 2 людям?
• Тесты пишутся параллельно с кодом, а не в конце?
• Заложены ли checkpoints в контракте с подрядчиком?
• Есть ли сценарий миграции для систем с вендор-локом?
• Проводится ли ретроспектива рисков раз в квартал?
• Бизнес и IT говорят на одном языке (без «фреймворк не тянет» и «архитектура устарела»)?

Интерпретация:

• 0–3 «да» → риски не управляются, проект в зоне высокой неопределённости
• 4–7 «да» → базовый уровень, но есть куда расти
• 8–10 «да» → зрелое управление рисками

---

Резюме

Управление IT-рисками — это не про то, чтобы предусмотреть всё. Это про то, чтобы:

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

Самый опасный риск — не знать о рисках вообще. Или считать, что «IT само разберётся».