Ризики проекту: аналіз, оцінка та стратегії управління

Цю статтю ми написали разом з Анастасією Борисюк, керівником проектної групи в Актіон Технології. Ось її телеграм-канал.

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

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

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

Складність: середня

Час читання: 7 хвилин

Що буде у статті:

• Які бувають джерела ризиків

• Шаблон реєстру ризиків

• Як вибрати стратегію управління ризиками

Що таке ризики

Перш ніж зрозуміти, як працювати з ризиками, проговоримо, що це таке і які вони бувають.

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

Якщо негативна подія станеться у будь-якому разі, це не ризик, а завдання. Наприклад, проджект знає, що новому QA-інженеру потрібно вдвічі більше часу на тестування продукту. Його завдання — зважити на факт і закласти достатньо часу на цей етап.

Ризики можна ділити на зовнішні та внутрішні.

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

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

Також можна категоризувати ризики на етапах проекту.

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

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

У статті ви зустрінетеся з термінами, які можуть бути вам незнайомими. Їх використовує у своїй роботі Анастасія Борисюк в Актіон Технології. Введімо визначення, щоб говорити однією мовою.

ДОДінг від Defenition of Done - це зустріч між замовником, проджектом і тимлідом. Мета зустрічі — домовитись, що буде зроблено у фічі, для кого вона, яку проблему вирішує. Це потрібно, щоб можна було грубо оцінити, пріоритезувати та запланувати роботу.

Передоцінка - Це груба оцінка роботи тимлідом. Вона проводиться після ДОДінгу та використовується для планування та виставлення термінів роботи проектної команди. Для цього тимлід бере час на те, щоб ще раз прочитати та продумати технічні аспекти реалізації.

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

Як працювати з ризиками

Робочий тиждень починається з перевірки Google-календаря. На сьогодні у вас стоїть созвон з Олівією — досвідченим проджектом, який давно працює в компанії та буде вашим ментором.

Як аналізувати ризики

Робота з ризиками починається з їхнього аналізу. Він включає три етапи: виявлення проблем, визначення причин виникнення цих проблем та систематизація причин.

Розглянемо докладніше кожен етап.

Як виявляти проблеми

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

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

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

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

Ви вирішуєте розпочати роботу над завданням від Олівії у процесі вивчення документа. Через те, що проект на початковій стадії та команда ще з ним не знайома, ви відштовхуєтеся від старих проблем.

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

Як визначати причини проблем

Щоб запобігти проблемам, потрібно визначити їх тригери — причини виникнення. І тому можна скористатися методом “5 чому”.

Метод "5 чому" у тому, щоб поступово відповідати питанням “Чому це сталося?” Запитань не обов'язково має бути п'ять – їх може бути як більше, так і менше. Головне завдання – дістатися до кореневої причини.

Наприклад, проблема в тому, що команда не потрапила до оцінки:

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

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

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

Як систематизувати причини

Причини, отримані за допомогою методу “5 чому”, слід включити до Реєстру ризиків – документ, у якому зібрані всі ризики. Чим масштабнішими, тривалішими та складнішими стають проекти, тим важче контролювати ситуацію. Без централізованого моніторингу ризиків ви можете щось забути чи упустити.

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

Завдання

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

Ви вносите до Реєстру ризики та їх тригери.

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

Як оцінювати ризики

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

Ризики заведено ділити на три групи: високий, середній та низький:

• До низької групи відносяться ризики з низькою ймовірністю та ступенем впливу.

• До високої — з високою ймовірністю та ступенем впливу.

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

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

З ризиками із середньої групи можна працювати двома способами:

1. Зменшити їх вплив та перемістити в низькі

2. Перемістити у високі та скласти план їх відпрацювання

Ризиками з низької групи можна знехтувати та контролювати їх стан. Їхня ймовірність і вплив на проект не такі суттєві.

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

Наприклад, для однієї команди збільшення бюджету на $10 000 спричинить повну розбудову плану, а для іншої ця сума — вартість лише одного дня роботи команди.

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

Залишилося розібратися з тим, як працювати з цими ризиками.

Як керувати ризиками

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

• Скласти план дій, щоби ризик не стався.

• Визначити що робити, якщо ризик стане проблемою.

Щоб зрозуміти, що робити з ризиком, треба вибрати одну із чотирьох стратегій:

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

Стратегія «Прийняти ризик»

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

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

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

Завдання

Стратегія «Уникнути ризику»

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

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

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

Стратегія «Зменшити вплив»

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

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

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

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

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

Стратегія «Передати іншому»

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

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

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

Ви дочитали документ Олівії, тепер потрібно визначити стратегію для кожного ризику. Але спочатку ви робите невелику перерву, щоб переварити інформацію.

Розробка ризиків для SportLife

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

❌ Стратегія «Прийняти ризик». Всі ваші ризики на етапі оцінки є досить значущими. Ви не можете просто прийняти їх.

❌ Стратегія «Передати іншому». Передати завдання іншому теж не вдасться - за договором всі завдання проекту лежать на вашій проектній команді.

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

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

Щоб запобігти ризику надто великої декомпозиції, потрібно прописати, з яких етапів будуть складатися рішення та роботи. На грумінгу фічі слід порівняти передоцінку та оцінку. Якщо ж ризик стане проблемою, потрібно занести до Реєстру ризиків, які роботи не було враховано. Це допоможе не допустити такого з іншого фічу.

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

Завдання

Резюмуємо

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

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