Управление рисками проекта — это регулярная система, которая заранее находит риски IT-проекта, оценивает их по вероятности и ущербу, назначает владельцев и меры, а потом проверяет, сработало ли. Суть простая: меньше сюрпризов, меньше переделок, предсказуемее сроки и бюджет.

В реальной жизни «риск-менеджмент» в IT часто выглядит так: пока всё зелёное — никто не трогает, как только красное — собирают созвон «что происходит», и выясняется, что происходит давно. Люди, которые приходят в IT из других сфер, обычно верят в чек-листы и дисциплину. Джуны верят в «а вдруг пронесёт». Спойлер: не проносит, просто счёт приходит позже.

Ирония в том, что риски IT-проекта редко про «упал сервер». Чаще — про людей, договорённости, допущения, зависимости и прекрасные фразы вроде «ну это же быстро». Поэтому руководителю (PM/PO/тимлиду — называйте как хотите) нужна не героика, а система.

Что именно считается риском в IT-проекте (и почему это не “проблема”)

Риск — это событие, которое может случиться и ударить по срокам, бюджету, качеству или объёму. Проблема — это риск, который уже случился. Управление рисками в IT-проекте начинается раньше, чем начался пожар.

• Риск: «ключевой разработчик может уйти».
• Проблема: «ключевой разработчик ушёл, доступы у него, документации нет».

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

Подводный камень: путать риск с задачей. «Надо улучшить качество кода» — это не риск. Риск: «из‑за техдолга скорость команды может упасть на 30% к релизу».

Система управления рисками проекта: минимальный рабочий контур

1) Реестр рисков (Risk Register), а не «в голове у ПМа»

Самая приземлённая штука: таблица, где риски IT-проекта записаны человеческим языком. Один риск — одна строка. Без поэзии.

Практический вывод: если риска нет в реестре, его «как бы не существует». А значит, бюджет и сроки под него тоже «как бы не нужны».

Подводный камень: превращать реестр в бюрократию на 200 строк. Лучше 15 живых рисков, чем кладбище из 200 мёртвых.

2) Оценка риска: вероятности в процентах не обязательны, но ущерб должен быть в реальности

Для большинства команд достаточно шкалы 1–5 по вероятности и ущербу. Главное — договориться, что «5 по ущербу» означает в вашей компании. Например: +20% к срокам или +15% к бюджету, или блокер релиза.

1. Оцените вероятность (P): 1–5.
2. Оцените ущерб (I): 1–5 (в идеале привязать к дням/рублям/метрикам качества).
3. Посчитайте рейтинг: P×I.
4. Риски 15–25 — в работу немедленно. 8–14 — план и наблюдение. 1–7 — в бэклог рисков.

Практический вывод: управление рисками проекта — это про выбор, куда тратить внимание. Оно конечное. Даже у вас.

Подводный камень: «высокая вероятность, но маленький ущерб» часто съедает время так же, как «редкий, но catastrophic» — просто по‑тихому.

3) Меры реагирования: четыре стратегии и одна взрослая привычка

• Избежать (avoid): поменять план так, чтобы риск исчез (например, не интегрироваться с нестабильным API, а выбрать другой путь).
• Снизить (mitigate): уменьшить вероятность или ущерб (добавить код-ревью, тесты, прототип, feature flag).
• Перенести (transfer): отдать риск внешней стороне (страховка, контрактные SLA, фикс-прайс — но осторожно, магии нет).
• Принять (accept): осознанно ничего не делать, но иметь план “если случилось” (contingency).

Взрослая привычка: у каждой меры должна быть цена. Если «снизить риск» стоит 2 недели команды, возможно, дешевле принять риск и держать резерв по срокам.

Подводный камень: «перенести риск на подрядчика» не работает, если бизнес-потери всё равно ваши. Да, формально виноват подрядчик. Нет, это не вернёт вам релиз.

Топ‑риски IT‑проекта: что чаще всего ломает сроки и бюджет

Риск №1: расплывчатый объём (scope creep) под видом «ну это же мелочь»

Как выглядит: каждую неделю добавляются «маленькие правки», а дата релиза остаётся той же. Магия календаря, только наоборот.

• Триггеры: рост количества задач без снятия старых, отсутствие ограничений по требованиям, нет Definition of Done.
• Меры: процесс контролируемого процесса изменений (хотя бы лайтовый), MoSCoW/приоритизация, фиксированный план релизов.

Ошибка: бороться с симптомом, ускоряя команду. Это как лечить температуру, разбив градусник.

Риск №2: зависимости и интеграции (внутренние и внешние)

Как выглядит: «мы почти готовы, осталось подключить оплату/SSO/CRM». И это «осталось» внезапно на 3 спринта.

• Триггеры: нет контрактов API, нет тестового стенда, нет владельца интеграции.
• Меры: ранний прототип, контрактное тестирование, интеграция в CI, договорённость по SLA/окнам изменений.

Ошибка: откладывать интеграцию на конец. Конец — самое дорогое место для сюрпризов.

Риск №3: кадровый риск и bus factor

Как выглядит: один человек знает «как оно реально работает». Потом у него отпуск/болезнь/оффер мечты.

• Триггеры: нет документации, нет парного ревью, критические доступы у одного.
• Меры: ротация задач, парное программирование точечно, runbook, доступы через менеджеры секретов.

Ошибка: думать, что документация — это «когда будет время». Время появится сразу после инцидента. Но вам оно не понравится.

Риск №4: качество, которое обнаружили на проде

Как выглядит: «тестировать некогда, мы и так успеваем впритык». Успеваете, да — впритык к катастрофе.

• Триггеры: отсутствуют автотесты на критические сценарии, нет staging похожего на prod, релизы руками.
• Меры: тест‑пирамида минимального уровня, мониторинг, feature flags, canary/blue-green, rollback план.

Ошибка: мерить прогресс «строками кода». Прогресс — это работающая функция в проде без позора.

Коммерческая сторона риска: где проект незаметно начинает “жрать деньги”

Даже если вы не CFO, вы отвечаете за экономику проекта. Типичная ловушка — считать только зарплаты команды, игнорируя скрытую цену.

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

Подводный камень: экономить на контроле качества и наблюдаемости. Это как купить машину подешевле, но без тормозов — да, б/у, зато “выгодно”.

Экспертный вердикт и инструмент: короткий чек‑лист руководителя

Если у вас нет времени «внедрять процесс», внедрите хотя бы этот минимум — он уже даёт управляемость.

1. Есть ли реестр рисков? Не в презентации, а живой документ с владельцами.
2. Есть ли триггеры? По каким сигналам вы поймёте, что риск активировался, без гадания.
3. Есть ли резерв? По срокам/бюджету/объёму. «Резерва нет» означает «мы уже решили провалиться, просто стесняемся это признать».
4. Есть ли правила изменения объёма? Кто может добавлять задачи и что при этом уходит.
5. Есть ли план на кадровые потери? Доступы, документация, bus factor.
6. Есть ли критерии готовности? Definition of Done и минимальный уровень качества до релиза.
7. Есть ли регулярность? Риски пересматриваются раз в неделю/спринт, а не «когда станет страшно».

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

Частые вопросы