План управления рисками проекта

Проект: Создание автоматизированной системы для магазина одежды “1Стиль” Заказчик: ИП Сорокин Г.В.
Исполнитель: ООО «1Стиль»
Период проекта: Август 2025 - Декабрь 2025
Дата создания: Август 2025
Версия: 1.0

Утверждено:
Руководитель проекта: _________________
Дата: _________________

Согласовано:
Заказчик (ИП Сорокин Г.В.): _________________
Дата: _________________

1. Общие положения

Данный план управления рисками определяет подходы к идентификации, анализу, планированию реагирования и мониторингу рисков проекта для магазина одежды «1Стиль».

Управление рисками является итеративным процессом. Реестр рисков пересматривается на каждом спринте/этапе, а также при возникновении значительных изменений.

План распространяется на все этапы проекта от планирования до внедрения системы в эксплуатацию.

Для создания документа использовалась методология управления рисками в соответствии с PMBOK 6-й редакции.

2. Термины, обозначения, сокращения

Термины, используемые в настоящем документе: | Термин | Определение | |———————|———-| | Риск | Неопределенное событие или условие, которое при наступлении оказывает положительное или отрицательное влияние на цели проекта | | Вероятность | Оценка возможности наступления риска, определяемая по качественной шкале: Очень низкая, Низкая, Средняя, Высокая, Очень высокая | | Воздействие | Оценка влияния риска на цели проекта в случае его наступления | | Приоритет риска | Количественный показатель, рассчитываемый как произведение числовых значений Вероятности и Воздействия. Используется для ранжирования рисков и определения приоритетов обработки | | Метод Монте-Карло | Имитационное моделирование, позволяющее оценить диапазон возможных результатов и степень их вероятности путем многократного моделирования случайных событий | | Чувствительность рисков | Показатель, отражающий, насколько сильно изменение одного фактора влияет на результат проекта или финансовое состояние | | Технический риск | Риск, связанный с технологиями, архитектурой, кодом, инфраструктурой, интеграциями, безопасностью и производительностью. | | Внешний риск | Фактор, находящийся вне контроля проектной команды и компании-исполнителя. | | Организационный риск | Риск, связанный с людьми, процессами и культурой внутри организации заказчика или исполнителя, но не в прямой команде проекта. | | Управленческий риск | Риск, связанный непосредственно с процессом управления проектом: планированием, исполнением, контролем содержания, сроков, бюджета, коммуникациями и стейкхолдерами. | | Положительный риск | Неопределенное событие, которое, в отличие от негативного риска (угрозы), может принести пользу проекту, например, позволить достичь целей с меньшими затратами или улучшить качество продукта. |

3. Роли и ответственность

4. Идентификация рисков

4.1 Технические риски

4.2 Внешние риски

4.3 Организационные риски

4.4 Управленческие риски

4.5 Возможности (Положительные риски)

5. Качественный анализ рисков

5.1 Матрица вероятности и воздействия

5.2 Анализ рисков

6. Количественный анализ рисков

6.1 Анализ чувствительности

Критические риски (приоритет >= 3.0):

• T002: Ошибки в алгоритмах расчета (3.0)
• B001: Изменение требований заказчика (3.2)

Высокие риски (приоритет 2.0-2.9):

• T001: Несовместимость обновлений с конфигурацией (2.8)
• Т005: Безопасность данных (2.5)
• P001: Превышение утвержденного бюджета (2.4)
• P002: Превышение сроков (2.8)
• У003: Низкая вовлеченность стейкхолдера (2.8)

Средние риски (Приоритет 1.0 - 1.9):

• T001: Производительность системы (1.5)
• T003: Потеря данных при обновлении (1.5)
• Т004: Масштабируемость (1.2)
• P003: Недостаток ресурсов (1.2)
• Р004: Недооценка сложности бизнес-процессов (1.6)
• У001: Плохое качество коммуникации (1.2)
• У002: Сопротивление изменениям (1.5)
• У004: Потеря ключевого специалиста (1.5)
• ВОЗ001: Раннее завершение этапа (1.2)

Низкие риски (Приоритет < 1.0):

• В002: Изменение законодательства (0.6)
• В003: Проблемы с поставщиками (0.9)
• В004: Экономические факторы (0.6)
• В005: Конкуренция (0.8)
• В006: Природные и техногенные катастрофы (0.5)
• ВОЗ002: Снижение затрат (0.6)

6.2 Анализ методом Монте-Карло

Сценарии бюджета:

• Оптимистичный: 14,650,000 руб.
• Наиболее вероятный: 15,000,000 руб.
• Пессимистичный: 17,120,000 руб.

Сценарии сроков:

• Оптимистичный: 4 месяца
• Наиболее вероятный: 4,5 месяца
• Пессимистичный: 5 месяца

7. Планирование реагирования на риски

7.1 Стратегии реагирования

7.1.1 Критические риски

T003: Ошибки в алгоритмах расчета

• Стратегия: Смягчение
• Действия:
  • Разработка детальных технических требований
  • Проведение модульного тестирования алгоритмов
  • Создание тестовых сценариев для всех уровней клиентов
  • Внедрение системы контроля качества кода
• Ответственный: Ведущий разработчик, ведущий тестировщик
• Срок: В течение всего проекта
• Бюджет: 50,000 руб.

B001: Изменение требований заказчика

• Стратегия: Смягчение
• Действия:
  • Детальное согласование требований на старте проекта
  • Внедрение процедуры управления изменениями
  • Регулярные встречи с заказчиком (еженедельно)
  • Создание прототипа для демонстрации функционала
• Ответственный: Бизнес-аналитик
• Срок: В течение всего проекта
• Бюджет: 30,000 руб.

7.1.2 Высокие риски

T001: Несовместимость обновлений с конфигурацией

• Стратегия: Смягчение
• Действия:
  • Проведение анализа воздействия (Impact Analysis) перед каждым обновлением.
  • Разработка и проведение тестов на совместимость на тестовом стенде.
  • Создание плана отката (Rollback Plan) для каждого обновления.
• Ответственный: Системный администратор
• Срок: Перед каждым обновлением конфигурации
• Бюджет: 20,000 руб.

T005: Безопасность данных

• Стратегия: Смягчение
• Действия:
  • Проведение аудита безопасности внешним специалистом.
  • Внедрение политики разграничения прав доступа по принципу наименьших привилегий.
  • Обязательное шифрование передаваемых данных (HTTPS) и чувствительных полей в БД.
  • Обучение сотрудников основам кибербезопасности.
• Ответственный: Системный администратор
• Срок: Аудит — в течение 1 месяца, остальное — постоянно
• Бюджет: 35,000 руб.

P001: Превышение утвержденного бюджета

• Стратегия: Смягчение
• Действия:
  • Внедрение еженедельного контроля отклонений (Earned Value Management).
  • Жесткое соблюдение процедуры управления изменениями.
  • При приближении к 80% лимита бюджета — проведение анализа оставшихся работ и реприоритизация.
• Ответственный: Руководитель проекта
• Срок: Еженедельно, в течение всего проекта
• Бюджет: 0 руб.

P002: Превышение сроков

• Стратегия: Смягчение
• Действия:
  • Детальное планирование с резервом времени (20%)
  • Еженедельный мониторинг прогресса
  • Приоритизация функций (MVP подход)
  • Создание “буферных задач”, которые можно исключить в случае отставания.
• Ответственный: Руководитель проекта
• Срок: В течение всего проекта
• Бюджет: 0 руб.

У003: Низкая вовлеченность стейкхолдера

• Стратегия: Смягчение
• Действия:
  • Разработка персонального плана вовлечения стейкхолдера.
  • Внедрение цикла коротких (15 мин.) еженедельных синхронизаций.
  • Предоставление отчетности в формате “1 страница” с визуализацией ключевых метрик.
  • Эскалация спонсору проекта после 2 пропущенных подряд встреч. Ответственный: Руководитель проекта Срок: Еженедельно Бюджет: 10,000 руб.

7.1.3 Средние риски

Для технических средних рисков (T001, T003, T004):

• Стратегия: Принятие с усилением мониторинга
• Действия: Включение в чек-листы тестирования, проведение регулярных нагрузочных тестов.
• Ответственный: Команда тестирования

Для управленческих/организационных средних рисков (У002, У004, Р004):

• Стратегия: Принятие
• Действия: Коммуникация, разъяснение, кросс-обучение в команде, ведение документации.
• Ответственный: Руководитель проекта

7.2 Планы действий в чрезвычайных ситуациях

Критические ситуации:

1. Полная несовместимость системы → Откат к предыдущей версии
2. Критические ошибки в расчетах → Временное отключение подсистем
3. Потеря данных → Восстановление из резервной копии

7.3 Стратегии реагирования на возможности

ВОЗ001: Раннее завершение этапа

• Стратегия: Усиление (увеличение вероятности и/или положительного эффекта)
• Действия:
  • Еженедельный review архитектурных решений на предмет избыточности.
  • Создание библиотеки reusable components для ускорения разработки.
  • Внедрение системы бонусов за предложения по оптимизации сроков.
• Ответственный: Ведущий разработчик
• Срок: На каждом этапе
• Бюджет: 10,000 руб.

ВОЗ002: Снижение затрат

• Стратегия: Использование (гарантированное получение выгоды)
• Действия:
  • Ежемесячный мониторинг рынка облачных сервисов и готовых решений.
  • Проведение ежеквартальных встреч с поставщиками для обсуждения условий.
  • Поиск возможностей консолидации серверных мощностей.
• Ответственный: Системный администратор
• Срок: Ежемесячно
• Бюджет: 5,000 руб.

8. Мониторинг и контроль рисков

8.1 Процедуры мониторинга

Еженедельные стендапы команды проекта включают в себя пятиминутную сессию “Обзор рисков”, где любой участник может заявить о новом выявленном риске или обновить статус существующего.

Еженедельные отчеты:

• Статус критических и высоких рисков;
• Новые выявленные риски;
• Эффективность планов реагирования;
• Изменения в вероятности и воздействии;

Ежемесячные обзоры:

• Полный анализ реестра рисков;
• Обновление планов реагирования;
• Анализ трендов рисков;
• Корректировка бюджета на управление рисками.

8.2 Индикаторы раннего предупреждения

8.3 Эскалация рисков

Уровень 1: Руководитель проекта принимает решения по рискам с приоритетом < 2.0

Уровень 2: Руководство компании принимает решения по рискам с приоритетом 2.0-2.9

Уровень 3: Заказчик участвует в принятии решений по рискам с приоритетом > 3.0

9. Бюджет управления рисками

10. Коммуникации по рискам

10.1 Отчетность

Еженедельно:

• Статус критических рисков (Руководство проекта)
• Новые риски (Вся команда проекта)

Ежемесячно:

• Полный отчет по рискам (Заказчик)
• Анализ эффективности управления рисками (Руководство компании)

По требованию:

• Экстренные уведомления о критических рисках
• Обновление планов реагирования

10.2 Хранение информации

• Реестр рисков хранится в системе управления проектами;
• Все решения по рискам документируются;
• История изменений ведется автоматически.

10.3 Управление знаниями

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

11. Обновление планов реагирования

11.1 Триггеры обновления

• Выявление новых критических рисков;
• Изменение приоритета существующих рисков;
• Завершение этапов проекта;
• Изменение требований заказчика;
• Изменение внешних условий.

11.2 Процедура обновления

1. Идентификация необходимости обновления
2. Анализ изменений
3. Обновление реестра рисков
4. Корректировка планов реагирования
5. Уведомление заинтересованных сторон
6. Утверждение обновлений
7. Обновление плана управления рисками