nmk

Лабораторна робота №11 (2 години)

Тема: Ідентифікація та планування ризиків (Risk Management)

Створення Реєстру ризиків (Risk Register) для IT-проєкту. Проведення якісного аналізу: оцінка ризиків за Матрицею ймовірності/наслідків (Probability/Impact Matrix) та розробка стратегій реагування.

Мета: Навчитися мислити превентивно: ідентифікувати потенційні загрози для проєкту ДО того, як вони стануть проблемами, класифікувати їх за рівнем критичності та мати готовий “План Б”.

Технологічний стек: Google Sheets / MS Excel / Notion (таблиці).


Завдання

Ризик — це невизначена подія, яка може вплинути на проєкт як негативно (загроза), так і позитивно (можливість). Справжній PM не сподівається на удачу, а управляє ризиками. Вам необхідно скласти офіційний документ (Реєстр ризиків) для вашого навчального проєкту.

Перелік завдань:

  1. Ідентифікувати 5 потенційних ризиків для вашого проєкту (технічні, командні, клієнтські).
  2. Оцінити їх за допомогою Матриці ймовірності та наслідків.
  3. Розробити стратегію реагування для кожного ризику (Avoid, Mitigate, Transfer, Accept).

Хід виконання роботи

Крок 1. Ідентифікація ризиків

Подумайте про ваш проєкт. Що може піти не так? Придумайте і запишіть 5 реалістичних ризиків. Вони мають бути конкретними. Погано: “Щось зламається”. Добре: “API платіжної системи LiqPay, яке ми інтегруємо, може змінити документацію під час нашої розробки”.

Можливі категорії для ідей:

Крок 2. Якісний аналіз (Probability, Impact та Risk Exposure)

Не всі ризики однаково страшні. Ми будемо їх оцінювати за 5-бальною шкалою:

Risk Exposure (Рівень загрози) = Ймовірність × Вплив.

Наприклад: Звільнення єдиного iOS-розробника. Ймовірність = 2 (спокійний хлопець), Вплив = 5 (ніхто інший цього не зробить). Risk Exposure = 2 * 5 = 10 балів. Максимальний бал — 25 (це червона зона).

Оцініть таким чином всі 5 ваших ризиків.

Крок 3. Стратегії реагування (Risk Responses)

Для кожного ризику ви маєте обрати ОДНУ із 4-х класичних стратегій:

  1. Avoid (Уникнення): Змінити план так, щоб ризик став неможливим. (Наприклад: відмова від проблемного API).
  2. Transfer (Передача): Перекласти наслідки на когось іншого (страховка, аутсорс).
  3. Mitigate (Зниження/Пом’якшення): Найчастіша стратегія. Зробити щось ЗАРАЗ, щоб зменшити ймовірність АБО вплив потім. (Наприклад: змусити Senior-розробника написати документацію, щоб у разі його звільнення вплив був не 5, а 2).
  4. Accept (Прийняття): Ми нічого не робимо зараз, просто відкладаємо гроші в резерв і вирішуємо проблему, коли вона настане (якщо вигідніше вирішити, ніж запобігати).

Крок 4. Заповнення Реєстру ризиків

Зберіть усю інформацію з Кроків 1, 2, 3 в єдину таблицю у вашому звіті:

ID Назва та опис ризику Ймовірність (1-5) Вплив (1-5) Risk Exposure (Й × В) Стратегія (Avoid/Mitigate/Transfer/Accept) План дій (Що конкретно робимо)
R1 Звільнення єдиного DevOps інженера 2 5 10 Mitigate Написати інструкції (Runbooks) для підняття серверів, щоб інші розробники могли це зробити.
R2
R3
R4
R5

(Відсортуйте таблицю так, щоб ризики з найбільшим Risk Exposure були зверху!)


Контрольні запитання

  1. Чому матриця ризиків завжди використовує перемноження двох показників (Ймовірності та Впливу)? Чому не можна оцінювати ризик тільки за його “катастрофічністю”?
  2. Наведіть приклад ризику в IT-проєкті, для якого єдиною адекватною стратегією буде Transfer (Передача).
  3. У чому різниця між стратегіями Avoid (Уникнення) та Mitigate (Пом’якшення)?
  4. Що таке Positive Risk (Можливість) і які існують стратегії реагування на нього за стандартами PMI (наведіть приклад)?
  5. Як Реєстр ризиків з цієї лабораторної роботи пов’язаний з Кошторисом (Бюджетом) формування резервів (Contingency Reserve), який ми рахували в Лабораторній №9?

Вимоги до звіту

  1. У репозиторії на GitHub додати файл lab_11.md.
  2. В цей файл вставити заповнену таблицю “Реєстр ризиків” з Кроку 4, де проаналізовано мінімум 5 ризиків вашого проєкту, відсортованих за рівнем загрози.
  3. У файлі lab_11.md дати письмові відповіді на всі 5 контрольних запитань.
  4. Завантажити зміни на GitHub та надіслати посилання викладачу.