Что такое проектный риск?

# Проектный риск: определение и управление

Определение

Проектный риск — это возможное событие или условие, которое при возникновении окажет негативное влияние на цели проекта (сроки, бюджет, качество, область). Ключевой момент: риск — это неопределённость с потенциальным влиянием, а не само негативное событие.

По PMBOK риск характеризуется двумя параметрами:

• Вероятность (Probability) — шанс того, что событие произойдёт
• Влияние (Impact) — последствия для проекта, если событие произойдёт

Показатель риска = Вероятность × Влияние

Классификация рисков

По источникам

• Технические: архитектурные ошибки, выбор неправильных технологий, интеграционные сложности
• Ресурсные: нехватка квалифицированного персонала, ротация команды, болезни
• Бизнес-риски: изменение требований, потеря финансирования, конкуренция
• Внешние: политика, законодательство, природные катаклизмы, поставщики
• Управленческие: плохая коммуникация, слабое планирование, отсутствие надзора

По временным рамкам

• Ранние: выявляются на этапе инициации и планирования
• Поздние: могут возникнуть в процессе исполнения

Примеры проектных рисков в IT

1. Нехватка квалифицированных разработчиков на редких языках/фреймворках

   • Вероятность: Средняя (если это нишевая технология)
   • Влияние: Высокое (задержка на месяцы)

2. Изменение требований от стейкхолдеров в середине проекта

   • Вероятность: Высокая (часто происходит)
   • Влияние: Высокое (переделка, задержки)

3. Отказ критичного внешнего API поставщика

   • Вероятность: Низкая (SLA обычно >99%)
   • Влияние: Критическое (проект может быть заблокирован)

4. Недооценка сложности интеграции с legacy системой

   • Вероятность: Высокая (legacy системы часто сложнее, чем ожидается)
   • Влияние: Среднее-Высокое (задержка на 2-4 недели)

5. Уход ключевого специалиста из команды

   • Вероятность: Средняя
   • Влияние: Высокое (потеря знаний, задержка передачи)

Процесс управления рисками (PMBOK)

1. Идентификация (Risk Identification)

• Брейнстормы с командой
• Анализ lessons learned из предыдущих проектов
• Консультация с экспертами
• Документирование в реестр рисков

2. Качественный анализ (Qualitative Risk Analysis)

• Оценка вероятности и влияния для каждого риска
• Ранжирование рисков по приоритету
• Разделение на высокие/средние/низкие

3. Количественный анализ (Quantitative Risk Analysis, опционально)

• Применяется для высокоприоритетных рисков
• Расчёт ожидаемой денежной стоимости (Expected Monetary Value, EMV)
• Анализ сценариев

4. Планирование реагирования (Risk Response Planning)

Для каждого высокоприоритетного риска определяются стратегии:

• Избежание (Avoid): изменить план проекта, чтобы риск не возник (например, выбрать другую технологию)
• Снижение (Mitigate): уменьшить вероятность или влияние (например, обучение команды, PoC новой технологии)
• Трансфер (Transfer): передать риск третьей стороне (например, страховка, аутсорс)
• Принятие (Accept): признать риск и подготовить план B если он произойдёт (contingency plan)

5. Мониторинг и контроль (Risk Monitoring & Control)

• Отслеживание триггеров рисков
• Выполнение планов реагирования при необходимости
• Обновление реестра рисков
• Идентификация новых рисков

Практический пример из моего опыта

Риск: Недостаток frontend разработчиков с опытом в React Native (вероятность: высокая, влияние: высокое)

Стратегия реагирования (Mitigation):

• Провели hackathon за 2 месяца до старта, чтобы team upskill
• Нашли консультанта-эксперта на часовой базе для mentoring
• Выделили 20% времени на обучение в первом спринте

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

Принципы хорошего управления рисками

1. Проактивность: Ищи риски до того, как они станут проблемами
2. Честность: Говори о рисках открыто, не скрывай их
3. Системность: Управление рисками — постоянный процесс, не одноразовая активность
4. Фокус: Сконцентрируйся на высокоприоритетных рисках, не пытайся управлять всеми подряд
5. Коммуникация: Информируй команду и стейкхолдеров о рисках и планах реагирования

В Agile контексте управление рисками интегрировано в спринты, и мы постоянно пересматриваем реестр рисков на планировании и ретроспективах.