Ризик-Менеджмент та оцінка ризиків. На сторожі захисту Вашого проекту

Кожен проект, незалежно від того, чи є він простим або складним, має певну кількість ризиків. Для успішного управління проектами потрібно ці ризики освідомлювати, та вміти ефективно з ними впоратись. У цій статті я опишу деякі найпоширеніші ризики управління проектами, які можуть виникнути під час реалізації, та способи їх уникнення.

- Лікарю, у мене така нервова робота ...

- А чим ви займаєтеся?

- Я сортую апельсини: великі - в один ящик, середні - в інший, маленькі - в третій.

- І що тут такого нервового?

- Лікаре, ви не розумієте. Я весь час приймаю рішення, рішення, рішення!

Прийняття рішень в умовах невизначеності завжди пов'язане з ризиками

Творці фотосервісу Picturelife точно розуміли, що потрібно користувачам. Всі ми були в ситуації, коли накопичилась величезна кількість фотографій і деякі з них ми вже не те що не будемо переглядати, ми навіть ніколи не згадаємо про їх існування. Команда зробила свій продукт максимально корисним і зручним, і користувачі це оцінили. Вони подбали про зручну організацію знімків по роках і датах, автоматичний вибір найбільш якісних фото з серії, нагадування про фото за датою в минулому, безлімітний обсяг сховища. У серпні 2013 року продукт назвали кращим в категорії вибору користувача за версією авторів The Verge 1.

Але, на жаль, факти - річ уперта. Відсутність стратегії просування та монетизації працює проти будь-якого продукту та може знищити навіть дуже якісний та актуальний сервіс. Творці були змушені закрити програму, і сьогодні на їх сторінці тільки сумне послання: We gave it our all. Thank you, again. We'll miss it dearly.

Найдорожчою помилкою ПЗ в історії вважається аварія ракети-носія «Аріан-5» - і навіть в такій відповідальній галузі, як ракетобудування, трапляються прорахунки. Вірогідних причин аварії згадують декілька. Однією з основних є програмний модуль, який тестувався для попередньої моделі, «Аріан-4», і повторно використовувався в новому середовищі. А там умови роботи були зовсім іншими. Модуль не проходив тестування ні на рівні обладнання, ні на рівні системної інтеграції.

Якщо повернутися до більш приземлених питань, то можна згадати відкриття п'ятого терміналу Лондонського аеропорту Хітроу 3. Всі чекали на цю подію з нетерпінням. Кілька днів нескінченних проблем та хаосу для співробітників і гостей аеропорту, звичайно, були викликані не однією помилкою. Але важливу роль зіграла відсутність інтеграції між старою і новою автоматизованими системами. Проблема полягала в тому, що передача ідентифікаторів сумок зі старої багажної системи в нову не була забезпечена. Ви тільки можете уявити, що може означати блокування роботи багажної системи для сьомого по завантаженості аеропорту в світі.

Управління ризиками визнано невід’ємною складовою ефективного управління. Це ітераційний процес, що складається із етапів, які, здійснюючись послідовно, дозволяють постійно контролювати та вдосконалювати процес прийняття рішень.

Управління ризиками - це термін, який використовують у відношенні до логічного та систематичного методу встановлення контексту, виявлення, аналізу, оцінки, реагування, моніторингу та передачі ризиків, пов’язаних з будь-якою діяльністю, функцією чи процесом. Цей метод дозволяє організаціям мінімізувати збитки та максимізувати потенціал.

Що таке ризик

Але давайте почнемо з найпростішого, а що ж таке ризик? Навіть у самому понятті ми маємо дуже багато визначень, наведу вам приклади:

РМІ - [Ризик є] Ймовірність змін у виникненні події, що може мати як позитивні, так і негативні наслідки.

PRINCE2 - [Ризик - це] Невизначена подія або сукупність подій, які у разі їх виникнення матимуть вплив на досягнення цілей.

ITIL - [Ризик - це] Можлива подія, яка може завдати шкоди чи втрати або вплинути на можливість досягнення цілей.

Особисто мені більше до вподоби визначення від РМІ, воно дещо ширше та дає нам можливість замислитися, що ризики бувають не лише негативними, а й можуть вносити позитивні зміни у наш проект.

Як правильно визначати ризики

Альтернативный текст для этого изображения не предоставлен

Як ми бачимо з ілюстрації, ризики завжди мають одну або декілька причин, а також один або декілька наслідків. Хочу звернути вашу увагу, що ризики завжди мають відношення до майбутнього. Якщо негативний ризик таки відбувся, то далі нам варто працювати саме над виправленням проблеми (issue). Іншими словами проблема – це ризик, який на 100% вже відбувся. Якщо ризик має ймовірність 99%, то він іще ризик.

Наші проектні ризики в першу чергу впливають на наші проектні обмеження, які нам необхідно визначити. Варто згадати проектний трикутник (scope-schedule-cost). Сюди окремим пунктом я додала би вплив на Quality – якість нашого проекту.

Простий приклад: мої знайомі займались розробкою певної Біткоїн платформи. За допомогою неї ви можете перевірити баланс свого гаманця та надіслати платіж на інший гаманець лише одним викликом командного рядка. Вона працює чудово, але всі свої операції виконує через стороннє Product API over HTTP. Це означає, що якщо API буде змінено, платформа перестане працювати. Це ризик. Але наразі це ще не проблемою, оскільки зараз API працює саме так, як того очікує платформа. Проте проблема вже знаходиться на поверхні, ми її передбачаємо. Коли це станеться, платформа припинить роботу, її користувачі не розумітимуть, чому так сталося та мабуть відмовляться від цього продукту взагалі. Вони вважатимуть моїх знайомих творцями сміття, якому не надається належна підтримка і воно не працює. Не дуже добре для їх репутації, згодні?

«Робота менеджера проекту не повинна зосереджуватися на вирішенні проблем; вона повинна зосередитись на запобіганні їх ”, - так Рита Мулкахі розпочала главу про Управління ризиками у своїй чудовій книзі PMP Exam Prep.

Як і Рита Мулкахі, нам не варто чекати, поки дуже розчарований користувач надішле нам гнівний електронний лист. Ми повинні взаємодіяти з ризиком ще до його появи. Як? Ми можемо зробити певні кроки.

По-перше, девелопер може створити кілька інтеграційних тестів, щоб перевірити, чи підтримує API той протокол, який ми очікуємо. Далі, переконатися, що CI запускає збірку, скажімо, раз на день. А вже одразу як збірка стане червоною, девелопер повинен отримати електронний лист і зреагувати відповідним чином: виправити код на платформі, ще до того, як її користувачі помітять проблему.

По-друге, девелопер може робити щотижневу перевірку репозиторія, щоб переконатися, що все в належній формі та працює з API.

Причина №1: Платформа використовує продукт за допомогою Product API

Ризик №1: API може бути змінений без попередження

Ефект №1: Користувачі та розробники будуть розчаровані

Ризик - це передбачувана подія, яка може відбутися, а може і не відбутися. Ефект - це те, що станеться, якщо виникне ризик. Чому нам потрібно розділити його на три частини? Якщо ми об’єднаємо три частини, ось як це звучатиме: «Оскільки платформа використовує стороннє Product API, і API може бути змінений без попередження, користувачі будуть розчаровані». Але краще чітко визначити компоненти причини / ризику / наслідку. Так ми можемо мати різні комбінації ризиків, наслідків та причин.

Наприклад, як щодо виявлення додаткового ризику для існуючої причини.

Ризик №2: Продукт, який користувачі не будуть використовувати за призначенням.

Це інший ризик. API не зміниться, але повністю зникне з ринку. Це можливо? Вірогідно. Яким буде ефект цього ризику? Таким самим - користувачі і розробники будуть розчаровані, оскільки продукт зупинить роботу. Можливо, будуть ще додаткові ефекти? Давайте спробуємо уявити. Якщо продукт припинить роботу, девелоперам доведеться витратити час на пошук альтернатив, вивчення їх, розуміння того, як вони працюють, і внесення великої кількості змін у нашу платформу, щоб вона зрозуміла новий API. Але можлива і така ситуація, що нові продукти взагалі не сумісні з очікуваним АРІ.

Ефект №2: Потрібен час, щоб підключитися до нового API

З іншого боку, як тільки продукт вийде з ринку, на ринку можуть з’явитися альтернативи. Якщо ми знаємо про це в потрібний момент, ми могли б навіть використати цю можливість і створити подібний продукт з потрібним АРІ для інших користувачів. Таким чином, ризик №2 має додатковий ефект.

Ефект №3: Буде можливість створити подібний API

Це вже позитивний ефект, в той час як ефекти, які ми мали раніше, були негативними.

Робота керівника проекту передбачає не тільки виявлення негативних наслідків, але і в знаходженні подібної кількості позитивних наслідків для більшості ризиків та причин.

Підводячи підсумок, ось що ми маємо зараз:

П1 → Р1 → Е1

→ Р2 → Е2

→ Е3

Причина П1 призводить до ризиків Р1 і Р2, які мають три наслідка: Е1, Е2 та Е3. Для того, щоб мати можливість визначити таку багаторівневу діаграму та уникнути дублювання тексту, нам потрібно розділити кожну передбачувану подію на три частини.

Є декілька правил, які я визначила особисто для себе щодо цих трьох частин (причина-ризик-ефект).

Робить (Do). Причину завжди варто формулювати як висловлювання у теперішньому часі, оскільки в ньому йдеться про факт, який існує на даний момент, наприклад "Ми використовуємо Hibernate", "Java 6 більше не підтримується", "70% наших користувачів працюють на Android", "Платежі надсилаються через PayPal", "GitHub є єдиним супроводжувачем нашого сховища" тощо.

Може (May). У заяві про ризик варто використовувати слово «може», оскільки ми говоримо про те, що ще не сталося, але лише передбачається, наприклад "Ми можемо втратити клієнта", "Архітектор може вийти", "Apple Store може затриматися з переглядом нашого додатка", "Інвестор може зникнути" тощо.

Буде (Will). Ефект повинен відбутися в майбутньому часі, чітко вказуючи на результат, який ми зазнаємо в майбутньому, якщо виникне ризик, наприклад «Ми збанкрутуємо», «Нам доведеться переписати весь модуль», «Ми витратимо ще 10 000 доларів на обладнання» тощо.

Що й казати, чим коротші висловлювання, тим ефективніше. Правильно визначена причина, ризик та наслідок повинні містити до 20 слів у кожному. Довгі висловлювання можуть означати лише одне: автор не розуміє, що відбувається, і йому варто було б витратити більше часу на розслідування ситуації.

Альтернативный текст для этого изображения не предоставлен

Якісний аналіз

Як бачите, не всі ризики та наслідки мають однакову ймовірність. Навряд чи весь Product API зникне, але його зміна протоколу (HTTР на НТТРS) є достатньо вірогідною. Було б не зовсім розумно приділяти однакову увагу всім ризикам, оскільки деякі з них є первинними, а інші - вторинними. як нам може бути відомо, з яким саме ризиком маємо справу? Можемо надавати їм номери. Алгоритм дії такий:

По-перше, ми робимо аналіз всіх ризиків та присвоюємо ймовірність кожному з них. При цьому 1 означає, що ризик, швидше за все, ніколи не виникне, а 9 означає, що ризик, безсумнівно, відбудеться:

П1 → Р1: 7 → Е1

→ Р2: 2 → Е2

→ Е3

Я поставила 7 та 2 до вищезазначених ризиків. Це було моє експертне судження. Тут ніякої математики. Я просто подивилась на ризики та прийняла суб'єктивне рішення, як менеджер проекту.

Потім таким же чином ми призначаємо номер кожному ефекту, знову в межах [1..9]. У цьому випадку 1 означає, що очікувані нами наслідки нікому не зашкодять і нікому не допоможуть, тоді як 9 означає, що ефект має вирішальне значення (негативний чи позитивний ефект):

П1 → Р1: 7 → Е1 ↓: 3

→РR2: 2 → Е2 ↓: 8

→ Е3 ↑: 3

Знову ж таки, я вибрала цифри виключно відповідно до свого суб'єктивного експертного судження. Зміна платформи відповідно до трохи зміненого API - це одне (вплив - 3), тоді як переписання її для абсолютно нового API - це зовсім інший обсяг роботи (отже, вплив - 8).

Останній крок - їх множення: ймовірність × вплив. Ми отримаємо такий список ризиків:

П1 → Р1: 7 → Е1 ↓: 3 ⇢ 7 × 3 = 21

П1 → Р2: 2 → Е2 ↓: 8 ⇢ 2 × 8 = 16

П1 → Р2: 2 → Е3 ↑: 3 ⇢ 2 × 3 = 6

Тепер ви можете побачити, чим є кожен компонент в нашому списку. Незважаючи на те, що наслідки другого рядка у списку є більш серйозними, ймовірність є нижчою, і на загальній карті ризиків цей рядок менш важливий.

Те, що ми щойно зробили, називається якісним аналізом ризиків: ми визначили, які ризики є більш важливими і потребують негайного вирішення, а які менш важливі і їх протягом певного часу можна просто ігнорувати.

Все наведене вище взято з мого особистого досвіду роботи з якісним аналізом ризиків. В інтернеті ви знайдете мільйони додаткових способів, як це робити. Наприкладу, шкала може бути не від 1 до 10, а від 1 до 5, або шкала Very High-Very Low.

Головне, що потрібно зрозуміти, якісний аналіз ризиків - це процес пріоритезації ризиків для подальшого аналізу чи визначення дій. Пріоритети розставляються з використанням визначених ймовірностей ризиків та впливу ризиків. Звісно, такі оцінки є суб’єктивними, бо вони базуються на особистому сприйнятті ризику командою та іншими стейкхолдерами.

В результаті якісного аналізу ризиків ми отримуємо:

  • Відносне ранжування та категоризацію або перелік пріоритетів ризиків проекту
  • Перелік ризиків, які потребують додаткового аналізу
  • Списки ризиків з низьким пріоритетом (Список спостереження)
  • Список ризиків для негайного реагування
  • Причини ризиків або напрямки проекту, котрі потребують особливої уваги

Альтернативный текст для этого изображения не предоставлен

Дам певні поради як поводитися з пірамідою ризиків. Якщо у вас виникає загальний проектний ризик – вам необхідно якнайшвидше звернутися до спонсора проекта. Хто ця людина? Ваш Lead PM, Program Manager, Delivery Manager чи СЕО. У випадку термінових ризиків – потрібно діяти також негайно.

Нижче ми розглянемо всі можливі стратегії роботи з ризиками. Важливі та найважливіші ризики потребують готових планів реагувань. В той час коли ризики з площини спостереження, як можна здогадатися, потребують лише спостереження (але будьте уважні, можлива ситуація, коли вони піднімуться в рейтингу і стануть потребувати планів реагувань).

Кількісний аналіз

Я не буду зупинятися на цьому розділі в деталях. Кількісний ризик аналіз - це процес чисельного аналізу сукупного впливу визначених ризиків на цілі проекту в цілому. За словами Ріти Мулкахі: "Як менеджер проекту, ви завжди повинні робити якісний аналіз ризиків, але кількісний аналіз ризиків не потрібен для всіх проектів або для всіх ризиків і може бути пропущений на користь переходу до планування реагування на ризик".

Кількісний аналіз проводиться щодо тих ризиків, які в процесі якісного аналізу були ідентифіковані як ті, що мають високий і середній ранг. В цьому процесі ми зможемо розрахувати Contingency reserve (резерв на непередбачені обставини, резерв на ризик) для ідентифікованих ризиків.

Як саме виглядає результат кількісного аналізу? Це підрахунок витрат на ризик в розрізі бюджету чи графіку (гроші чи дні).

Якщо говорити простими термінами, кількісний аналіз ризиків надає чисельне значення наявним ризикам - ризик А має 40% шансів виникнути на основі кількісних даних (коливання витрат ресурсів, середній час завершення завдань, тощо) та 15% шансів спричиняючи затримку на X кількість днів. Таким чином, це повністю залежить від кількості та точності ваших даних.

Виходячи лише з цього опису, може здатися, що кількісний підхід є більш надійним із двох. Але це не так. Класифікуючи ступінь ймовірності і впливу в більш широкому плані, якісний аналіз ризику ідеально підходить для оцінки ймовірності та визначення пріоритетів ризику таким чином, щоб його зрозуміли усі зацікавлені сторони, навіть ті, хто звик працювати лише з цифрами.

Це також полегшує виявлення областей, що вимагають особливої уваги - наприклад, ризикова подія, яка має велику ймовірність і здатна завдати катастрофічного впливу. І може бути використаний на будь-якій стадії проекту для управління ризиками в режимі реального часу.

Загальновизнано, що якісний аналіз ризиків є більш старою формою управління ризиками, ніж його кількісний аналог.

Як ми вже встановили, кількісний аналіз ризику покладається на точні статистичні дані, щоб отримати реальну інформацію - таку, яка була недоступна нашим предкам. Тому натомість вони застосували більш суб’єктивний, якісний підхід до управління ризиками, який мав одну ключову перевагу: його було швидше і легше впровадити. До речі, це одна з основних причин, чому якісний аналіз залишається таким популярним і до нині.

На відміну від кількісного аналізу ризиків, який спирається на надійні моделі ризиків, великий обсяг даних та, в деяких випадках, спеціалізоване програмне забезпечення (аналіз Монте-Карло), якісний аналіз ризиків може бути виконаний у будь-який час або на етапі проекту. Це дозволяє вам адаптуватися до змін динамічного середовища нашого проекту і завжди мати свіжі результати.

Також варто зазначити що, кількісний аналіз ризику є життєво важливим в певних галузях. Зокрема, галузі високого ризику - гірничодобувна промисловість, нафтогазова галузь, будівництво та все, що представляє цілком реальну загрозу безпеці працівників - в значній мірі покладаються на кількісний аналіз ризиків.

Планування відповіді на ризик

Планування реакції на ризик - це процес розробки варіантів/вибору стратегій/узгодження дій стосовно ризиків проекту.

Після ідентифікації, аналізу та пріоритизації ризиків призначений risk owner має запропонувати

  • план роботи з важливим для команди ризиком.
  • Менеджер проекту також має враховувати, як слід краще реагувати на поточний рівень ризику.

Реагування на ризики має

  • відповідати рівню важливості ризиків,
  • бути економічно ефективним у вирішенні проблеми,
  • реалістичним в контексті проекту,
  • узгодженим з усіма залученими сторонами,
  • мати власника, який бере на себе відповідальність.

Для кожного ризику необхідно вибрати стратегію чи комбінацію стратегій, яка буде найбільш ефективною. В такому випадку необхідно розробити конкретні заходи по реалізації обраної стратегії. Можна визначити основну та додаткову стратегії. Якщо вибрана стратегія виявиться недостатньо ефективною або настане випадок ризику, можна розробити fallback plan (резервний план). Також необхідно ідентифікувати secondary risks (вторинні ризики) – ризики, які виникли в результаті реагування на ризики. Досить часто доречно виділяти contingency reserve (запас на ризики, резерв на можливі втрати по часу чи вартості). Contingency reserve може включати в себе певні умови, які є тригером для його використання.

Стратегії відповіді на ризики

На негативні:

Альтернативный текст для этого изображения не предоставлен

На позитивні:

Альтернативный текст для этого изображения не предоставлен

Як це виглядає покроково:

Альтернативный текст для этого изображения не предоставлен

Стратегії реагування на негативні ризики

Ескалація (Escalate) – передача відповідальності за ризик на вищий рівень управління доречний у випадках, коли загроза виходить за межі проекту.

Ухилення (Avoid) – усунення загрози чи захист проекту від її наслідків:

  • Зміна частини проекту для усунення загрози.
  • Зміна цілі, якої стосується ризик (наприклад, продовження термінів).
  • Ліквідація причини загрози.

Передача відповідальності за ризик третій стороні (Transfer) — виплата нагородження за ризик стороні, яка його приймає (страхування, гарантійні зобов’язання, договір підряду, FixedPrice контракт).

Зниження (Mitigate) - зменшення ймовірності або пом'якшення впливу ризику:

  • Простіші процеси.
  • Вибір додаткового постачальника.
  • Розробка прототипу.

Прийняття (Accept) – визнання ризику і рішення припинити дії до настання ризику:

  • Пасивне - тільки спостереження та документування.
  • Активне – виділення contingency reserve.

Стратегії посилення позитивних ризиків

Ескалація (Escalate) – передача відповідальності на рівень Програми, Портфелю чи іншого підрозділу організації, у випадках, коли можливість ризику виходить за межі проекту.

Використання (Exploit) – забезпечення залученності найкращих фахівців, нових технологій, усунення невизначеності.

Розділення (Share) – передача частини чи всієї відповідальності за можливість третій стороні, розділення частки нагород в майбутньому (партнерські угоди, спеціальні чи спільні підприємства, інвестор).

Підсилення/збільшення (Enhance) – підвищення ймовірності виникнення позитивного впливу або можливості (додаткові ресурси, лобіювання).

Прийняття (Accept) – готовність використати потенціал можливості без активних дій.

  • Пасивне - тільки спостереження та документування;
  • Активне – виділення contingency reserve.

Стратегії реагування

Тепер настав час розробити свої плани реагування.

Уникати. Я можу щось зробити, щоб зменшити ймовірність ризику. Повернувшись до Р2, чи можу я щось зробити, щоб переконатися, що Blockchain API довше залишиться на ринку та не помре? Я можу робити про це пости в твіттері, рекламувати або, можливо, навіть виділити на це кошти. Але я маю великі сумніви, що щось із цього може бути ефективним. Тож уникнення тут не є правильною стратегією. Просто мої дії не можуть знизити ймовірність. Така ж сама ситуація з ризиком Р1.

Пом'якшити. Друга можлива стратегія реагування на ризик - зменшення впливу ефекту. Зверніть увагу на ефект Е1. Як було зазначено вище, було б доречно зробити дві речі. По-перше, створити інтеграційні тести та налаштувати CI, щоб він надіслав девелоперам електронне повідомлення при зміні API. По-друге, важливо регулярно перевіряти репозиторій на узгодженість і мінімізувати кількість часу, коли репозиторій не синхронізується з API.

Є й інші варіанти, такі як прийняття (нічого не робити і просто чекати) або передача (знайти жертовне ягня), але вони менш практичні.

Існує також два варіанти якісного ризику (Е1 / Р2 / Е3):

Експлуатувати. Я можу зробити щось, щоб смерть Blockchain API відбулася найближчим часом, тим самим пришвидчивши ризик R2, правда? Що ж, зараз це схоже на жарт, але дуже часто ми можемо вирішити просунути справи з позитивним ризиком. Ця стратегія називається експлуатацією.

Покращувати. Я можу зробити щось для посилення позитивного впливу ефекту Е3? Наприклад, я можу підготувати аналогічний API і зробити його готовим до продажу. Коли Blockchain API вмирає, я негайно запускаю свій і починаю просувати його за стратегією "Погляньте, цей АРІ помер, перейдіть сюди зараз!" Знову жартую, але ви зрозуміли напрямок моїх думок.

Отже, простіше кажучи, можливо розробити план, прив’язаний або до ризику, або до ефекту. Ми можемо зробити щось із ймовірністю або з впливом.

Також я можу усунути весь перелік ризиків, якщо просто видалити свою платформу і вбити проект, так? Немає проекту - немає клопоту. Ніяких розчарованих користувачів, ніяких ризиків, але й ніяких можливостей. Це також може бути рішенням у деяких випадках (хоча не в цьому).

Суть полягає в тому, що план може бути розроблений до причини, ризику чи наслідку. Я б визначила три плани, які пом’якшують вплив Е1:

Пл1 → Е1: Створення інтеграційних тестів (один раз)

Пл2 → Е1: Налаштування CI (один раз)

Пл3 → Е1: Перевірте репо на відповідність API (щотижня)

Перші дві - це разові дії, які девелопер повинен виконати якомога швидше. Після здійснення вони зменшують вплив Е1. План Пл3 варто виконувати регулярно щотижня, щоб також зменшити вплив Е1. Ось як виглядає мій список ризиків разом із планами:

1 → Р1: 7 → Е1 ↓: 3 ⇢ 7 × 3 = 21

Пл1, Пл2, Пл3

П1 → Р2: 2 → Е2 ↓: 8 ⇢ 2 × 8 = 16

Ніяких планів

П1 → Р2: 2 → Е3 ↑: 3 ⇢ 2 × 3 = 6

Ніяких планів

Додаткові приклади

Для того, щоб усі стратегії максимально вкладались у ваше розуміння, пропоную додати ще 2 приклади і на кожному застосувати всі без винятку стратегії.

Ризик 1. Імплементація програмного продукту не усвідомлюючи повного списку вимог до нього. Це призводить до необхідності робити велику кількість доробок продукту (що означає «розповзання» рамок проекту та зростання обсягів робіт – scope creep).

Ризик 2. Зміна вимог до програмного продукту в процесі імплементації. Призведе до «розповзання» рамок проекту та збільшення обсягів робіт по ньому - scope creep.

Стратегія ухилення передбачає повне виключення ризику з проекту. Нам необхідно знайти спосіб реагування, який забезпечить нам відсутність ризику. Це найбільш «дорога» стратегія, тому що стосовно деяких ризиків необхідно відмовлятися від певних робіт, змінювати цілі проекту або, в найрадикальнішому випадку, відмовлятися від проекту взагалі.

Спробуємо ухилитися від ризику неповного списку вимог (ризик 1).

Чи можна бути впевненим на 100%, що ми зібрали всі вимоги? Я вважаю, це неможливо. Навіть якщо ми будемо вважати, що зібрали все, на етапах реалізації проекту може виникнути нова вимога.

В умовах змін вимог до програмного продукту з ходом проекту впровадження (ризик 2), ми можемо уникнути ризику матеріалізації, якщо заздалегідь пропишемо в контракті, що вимоги змінювати не можна ні в якому разі і ні за яких обставин. Погодьтеся, це звучить як мінімум дивно.

Стратегія передачі перекладає наслідки матеріалізації ризику і відповідальність за реагування на третю сторону, при цьому сам ризик не усувається. Ця стратегія практично завжди передбачає фінансові витрати на передачу та отримання фінансової компенсації в разі матеріалізації ризику.

Чи можливо ми передати комусь ризик, пов'язаний з неповними вимогами? Як варіант, ми можемо передати роботу, пов'язану зі збором та вивченням вимог, консультантам «під ключ». Важливо попередньо прописати в контракті штрафні санкції за помилки (це буде непросто, але можливо).

Можна передати і ризик, пов'язаний зі зміною вимог. Але важливо визначити, кому саме його передавати. Замовник зазвичай виступає ключовим джерелом зміни вимог. У статуті проекту (або контракті на проект) керівник проекту прописує, що при будь-якій зміні вимог потребується перегляд первинного розкладу проекту і базового бюджету. В цьому випадку, якщо ризик відбувається, команда отримує додатковий час і додатковий бюджет.

Стратегія зниження є найпоширенішою і може застосовуватися до будь-якого ризику, тому що має на меті зменшення ймовірності або впливу ризику на проект. Застосуємо цю стратегію для наших ризиків. Спочатку опрацюємо ризик з неповними вимогами.

Чи можна знизити ймовірність того, що перелік вимог виявиться неповним? Я думаю, якщо ми виведемо збір вимог в окремий проект або етап проекту, при цьому до цього процесу залучимо професійного бізнес-аналітика (або групу), і залучимо в проект представника замовника, який буде відповідати за утвердження вимог, тоді кординально знизимо ймовірність пропущення важливих вимог. Але в цьому випадку ми тільки знизимо ймовірність, а не повністю усунемо цей ризик.

Як можна знизити вплив ризику, пов'язаного з неповним переліком вимог? Один з варіантів - врахувати ймовірність пропуску певний статей вимог при опрацюванні архітектури продукту. Однак не для всіх випадків він спрацює. Деякі нові вимоги будуть доволі трудомісткими в реалізації без серйозних переробок архітектури.

Вірогідність ризику, пов'язаного зі змінами вимог, можна знизити, розробивши і впровадивши спеціальну процедуру роботи зі змінами вимог. Мета такої процедури - внесення ясності і розуміння того, як обробляються запити на зміни. Процедура буде спонукати до дій тих, хто хотів би внести зміни до вимог, дозволить замислитись наскільки складно це буде зробити. І, можливо, призведе до бажання краще пропрацювати вимоги спочатку.

Один з варіантів - включити алгоритм оцінки впливу змін на термін і бюджет проекту. Замовник принаймні буде розуміти вартість можливих змін і від деяких змін, можливо, відмовиться. Тобто ми запроваджуємо процеси Change management, зокрема Change Control Board.

Ну і четверта стратегія - це прийняття ризику. Як зрозуміло з назви стратегії, до настання ризику передбачається «нічого не робити». З нашою ментальністю це часто улюблена стратегія роботи з ризиками. Однак тотальна бездіяльність - це не управління ризиками. Є два варіанти для четвертої стратегії - активне і пасивне прийняття.

Активне - формується резерв часу і грошей на усунення наслідків матеріалізації ризику.

Пасивне - припускає наявність плану Б (усунення наслідків проблеми) на випадок, якщо ризик матеріалізується.

Розглянемо стратегію активного прийняття для ризику неповних вимог.

У разі якщо деякі вимоги будуть пропущені, нам потрібно мати запас часу і бюджету на їх усунення. В якому обсязі закласти цей запас? Відповідь залежить від кількості пропущених вимог і складності їх реалізації. Без прогнозу на цей рахунок, ми можемо закласти резерв, на який погодиться замовник проекту. Зрозуміло, що для керівника, чим більше резерв часу і грошей - тим краще, а для замовника проекту - навпаки. Тому розмір резерву стане предметом переговорів.

Для ризику зміни вимог стратегія активного прийняття та додатковий обсяг часу і грошей так само стає предметом переговорів.

Аналіз використаних стратегій

Альтернативный текст для этого изображения не предоставлен

Давайте визначимо, які стратегії є найбільш доречними для ризику, пов'язаного з пропуском вимог:

1. Стратегія ухилення від ризику неможлива.

2. Передати роботу, пов'язану зі збором вимог, консультантам «під ключ», прописавши в контракті штрафні санкції за помилки в зборі вимог. Дуже доречна стратегія, особливо якщо у вас в штаті немає своїх бізнес-аналітиків або вони зайняті на інших проектах.

3. Збір вимог виділити як окремий проект або етап проекту - це можливий варіант і в разі вибору «Водоспадної» моделі життєвого циклу проекту так і буде відбуватися.

Залучити професійного бізнес-аналітика (або групу) - ця стратегія відрізняється від передачі збору вимог консультантам «під ключ» рівнем відповідальності. В цьому випадку важливо не припущення, що бізнес-аналітики виплатять штраф, якщо пропустять певні вимоги. Найважливіше те, що може постраждати їхня репутація.

Залучити в проект представника замовника, який буде відповідати за утвердження вимог, - це дуже правильний крок.

Врахувати ймовірність пропуску вимог при опрацюванні архітектури продукту - якщо ми купуємо box-product, тоді здійснити це вже неможливо.

4. Закласти додатковий час в розклад проекту і резерв в бюджет проекту - я б постаралась це зробити.

Отже, з чотирьох стратегій для ризику, пов'язаних з неповними вимогами, я б насамперед спробувала віддати роботу зі збору вимог «під ключ» компанії, що спеціалізується на цьому виді послуг. Якщо замовник відмовляється від цього варіанту, то використовувала би можливі заходи для стратегії зниження ризику і стратегію активного прийняття.

Для другого ризику підхід абсолютно аналогічний.

Після визначення стратегій для роботи з ризиками керівнику проекту необхідно закласти антиризикові заходи в план проекту, додати резерви часу і коштів для тих ризиків, за якими була прийнята стратегія активного прийняття, розрахувати термін і бюджет проекту з урахуванням ризиків. І тільки після цього можливо погоджувати з замовником плановий термін проекту та його бюджету.

Проект з визначеними термінами і бюджетом з урахуванням антиризикових заходів, має значно більше шансів стати успішним.

Мені після отриманих уроків стало зрозуміло, що управління ризиками - це одна з головних галузей знань, в якій повинен розвиватися керівник проекту.

Ще зупинюсь на резервному плані і плані Б.

Деякі способи реагувань призначені для використання тільки у випадку настання певних подій.

  • Необхідно визначити та відстежувати події (тригери), які приводять в дію реагування на можливі втрати (contingency response).
  • Плани реагування на ризики, визначені цим методом, часто називають contingency plans or fallback plans (планами на випадок можливих втрат або планами відступу).

Contingency Plan: розробляється, щоб виконуватися, коли подія ризику настала:

  • Для активно прийнятих ризиків,
  • Для ідентифікованих ризиків (known unknowns),
  • Розробляються під час планування реагування (проактивно).

Fallback Plan: розробляються, коли попередня стратегія виявилася неефективною:

  • Після Contingency Plan,
  • Для ідентифікованих ризиків (known unknowns),
  • Після провалу попереднього плану.

А зараз ми зрозуміємо різницю між профілактичними заходами та між планами Б:

Альтернативный текст для этого изображения не предоставлен

Останній приклад

Вже багато років ми знали, що 31 грудня 2020 Flash Player перестастане супортитися, простими словами помре. 12 січня 2021 року Adobe повністю заблокувало роботу контенту, який містив Flash Player. Давайте розглянемо реальні приклади боротьби з таким ризиком.

Отже, уявімо що ще декілька років назад ви прописали ризик того, що саппорт Flash Player припиниться. Як він правильно звучить? Якщо Adobe припинить саппорт Flash Player наші клієнти не зможуть використовувати певні модулі аплікації, що призведе до переходу на інші продукти.

Стратегія Avoid. Тут все дуже просто. Нам потрібно випиляти Flash Player з усіх модулів нашої аплікації і замінити його аналогами. Це абсолютна вірна стратегія якою мали скористатися усі без винятку виробники програмного забезпечення.

Стратегія Transfer. Давайте подумаємо чи можемо ми перекласти цей ризик на когось? Ми можемо перекласти випилювання Flash Player з продукту на сторонню організацію і перекласти абсолютно усі ризики пов'язані з цим на них.

Стратегія Accept. Дана стратегія взагалі і повністю не буде можлива для нашого ризику. Якщо ми просто нічого не робитимемо з 13 січня наш саппорт отримає мільйон дзвінків з тим, що клієнти не можуть скористатися тим чи іншим функціоналом. Якщо ж ми скористаємось стратегією активного прийняття, тобто наприклад, поліземо до нашого резерву після 13 січня для того, щоб почати випилювати Flash Player, ми також отримаємо абсолютно негативні результати. Адже ми втратимо дорогоцінний час і втрачену задоволеність наших клієнтів буде важко повернути

Стратегія Mitigate. Чи є змога зменшити наш ризик? Нажаль ні. Адже не можна випиляти Flash Player на половину. Не можна випиляти Flash Player з половини модулів. Не можна домовитися з компанією Adobe продовжити період саппорту Flash Player. Ітд.

Який висновок ми можемо зробити з цих усіх прикладів. Є ризики до яких можна застосувати усі стратегії і вже обрати пізніше, яка для нас дієвіша. А є ризики для яких певні стратегії не діють взагалі. Моя вам порада прокручуйте усі стратегії в голову і обирайте саме ту, яка найкраще лягає саме на ваш ризик.

Впровадити відповіді на ризики

Тепер настав час виконати заплановано та здійснити задумане. Перетворити плани на завдання в необхідний час. Завдання - це чіткі інструкції для вас, керівника проекту. Потім ви робите їх самостійно або делегуєте учасникам проекту.

Чесно кажучи, я вважаю такий спосіб управління своїм обсягом роботи дуже продуктивним і орієнтованим на результати. Спочатку я визначаю, які найважливіші ситуації трапляються у моєму проекті (вони можуть бути пов'язаними з людьми, ресурсами, банківськими рахунками, програмними продуктами, активами тощо), потім я думаю про ризики. Важливо робити це регулярно, створюючи щоденно кілька нових ризиків, разом з ефектами. Потім я розробляю план дій, щоб мінімізувати їхні ймовірності та реагувати на їх вплив.

Ще хочу згадати залишкові та вторинні ризики.

Згідно з 6-м виданням Керівництва PMBOK, «вторинними ризиками є ті ризики, які виникають як прямий результат реагування на ризик». Відбувається це коли ви розробили план реагування на ризик, а це спричинило новий. Це відоме як вторинний ризик.

Ви визначили ризик і розробили план реагування на управління цим ризиком. Однак цей план реагування не усуває ризик повністю. Решта лишається так званим залишковим ризиком.

Згідно з 6-м виданням Керівництва PMBOK, «залишкові ризики - це ті ризики, які, як очікується, залишаться після прийняття запланованих реакцій на ризики, а також ті, що були свідомо прийняті».

Наприклад, керівник проекту, який навчається на одному з курсів, щоб отримати офіційну сертифікацію РМР. Коли майбутній РМР планує навчальну програму для іспиту, основними ризиками, які можуть на це вплинути, є:

  • він може повністю поринути у новий проект, який не залишить достатньо часу для навчання
  • він захворіє під час підготовки до іспиту

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

Залишковим ризиком для такої реакції на ризик буде те, що протягом підготовки до іспиту додатково з’явиться несподіваний масштабний проект. У цьому випадку може знадобитися перенести іспит, щоб знайти достатньо часу для навчання в майбутньому. Це може вимагати додаткових витрат, які можна покрити завдяки резерву на випадок непередбачених ситуацій.

У другому випадку дії щодо реагування на ризик, щоб залишитись здоровим під час підготовки до іспиту, полягала б у проведенні вакцинації від п’яти найпоширеніших заразних хвороб на момент підготовки до іспиту.

Вторинним ризиком такої реакції на ризик буде той факт, що самі вакцини можуть викликати побічні ефекти або навіть викликати інфекції.

Найчастіше залишкові та вторинні ризики ігноруються, і керівники проектів не працюють над планом реагування. Вони концентруються лише на первинних ризиках та уникають витрат часу на вторинні та залишкові ризики. Такая стратегія дуже неефективна, уникайте її. Ці ризики мають велике значення. Ігнорування їх поставить під загрозу успіх вашого проекту.

Давайте ще раз повернемось до ризику з завершенням саппорту Flash Player компанією Adobe. Чи є у нас тут вторинні чи залишкові ризики? Наприклад, ваша компанія застосувала стратегію Avoid і повністю випиляла Flash Player зі своєї аплікації починаючи з версії 7.2. Але певні консервативні клієнти і далі продовжують користуватися старими версіями програми. Для них є залишковий ризик того, що 13 січня 2021 року вони не зможуть використовувати весь функціонал. Тут уже буде іти мова про Fallback план - автоматично оновити їх на новіші версії.

Отже, слово «ризик» може викликати напруження у вашій свідомості, але ми сподіваємось, що ця стаття, додасть впевненості та зробить цей процес більш керованим. Пам’ятайте, що вам варто створити перелік непередбачених ситуацій навколо свого проекту, використовуючи кроки, які ми вище зазначили. Такі дії додадуть вам впевненості рухатися вперед зі своїм планом.

Курси та події

Публікації

Відео