Управління ризиками при розробці ПЗ

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

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

Спекулятивні ризики можна структурувати на ризики фінансових обмежень, ризики зміни кон'юнктури, ризики зміни курсів валют.

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

Мета цього етапу — виявити деяку кількість невідомих ризиків проекту. Вважаємо, що потенційних проблем навколо нас нескінченно багато, тому завдання будемо ставити кількісно. На початку проекту непогано ідентифікувати 50-100 ризиків, у подальшому — по 20-30 штук.

На вході: план проекту, поточний список ризиків (якщо є);

Процес:

• PM збирає мітинг (meeting) з усією командою, повідомляє про його мету та тривалість;
• PM повідомляє про статус проекту, основні поточні ризики і проблеми, відповідає на питання;
• Учасники мітингу озвучують потенційні ризики. Приймаються всі ідеї без винятку, без обговорень і коментарів;
• PM записує результати в форматі «причина-ризик-ефект». Як тільки мета досягнута, або час минув, мітинг завершується;

На виході: оновлений список ризиків у форматі «причина-ризик-ефект».

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

На вході: список ризиків;

Процес:

• PM збирає мітинг (meeting) з тім лідами (Teem Lead), повідомляє про його мету та тривалість;
• PM оголошує ризик, учасники мітингу оцінюють його вірогідність і наслідки;
• PM записує оцінки, як тільки мета мітингу досягнута, або час минув, мітинг завершується;
• PM вираховує істотність ризиків як імовірність * наслідки, сортує список по спадаючій важливості;
• PM позначає ризики, що перевищили межу Важливості в списку;

На виході: список критичних ризиків;

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

• Transfer. Переносимо відповідальність за наслідки ризику на третю сторону (замовника, компанію-партнера, страхову компанію і так далі). Застосовувати цю стратегію є сенс, якщо самі ми не можемо вплинути на ризик і є на кого цю відповідальність перекласти.
• Accept. Приймаємо відповідальність за наслідки ризику на себе, але нічого не робимо, залишаємо все як є. Застосовувати цей підхід є сенс тільки коли з ризиком ми вдіяти нічого не можемо, а робити трансфер на третю сторону невиправдано дорого.
• Mitigate. Боремося з ризиком, приймаючи відповідальність за нього на себе. Для боротьби з ризиком добре мати кілька планів.

  Основний — для того, щоб ризик придушити. Основний план необхідно впроваджувати відразу, до того як ризик трапився. Він повинен знижувати або імовірність, або наслідки ризику. Тут нам допоможе запис ризиків у форматі «причина-ризик-ефект». Щоб знизити імовірність ризику, потрібно боротися з його причиною. Щоб побороти наслідки, потрібно захищати предмет його впливу.

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

На вході: список критичних ризиків;

Процес:

• PM збирає мітинг (meeting) з керівниками інших проектів, повідомляє про його мету та тривалість;
• PM оголошує ризик, учасники мітингу визначають стратегію роботи з ним, основний план і запасний план (для Mitigate);
• PM записує плани в ризик лист, як тільки мета мітингу досягнута, або час минув, мітинг завершується;
• PM оновлює план проекту, додаючи основні плани по ризиках;

На виході: список критичних ризиків зі стратегією і планом на кожен ризик, оновлений план проекту;

Це швидше процес, ніж етап. Його мета — підтримувати список ризиків і план проекту в актуальному стані.

На вході: спланований список ризиків, план проекту, щоденні звіти команди;

Процес:

• PM виконує ревізію списку ризиків, оновлює оцінки, оновлює застарілі плани;
• PM виявляє ризики, що трапилися, приймає рішення про впровадження відхідних планів, оновлює план проекту;

На виході: оновлений список ризиків, оновлений план проекту;