Фев. 05

Як створити реєстр ризиків та працювати з ним

Усім привіт! Мене звуть Андрій, і я маю власний досвід з особистого та корпоративного консультування з проєктного й продуктного менеджменту. В ІТ-галузі майже 15 років, 10 з яких — у царині менеджменту. Свого часу працював як PM, PDM, Agile Coach, VP Delivery та СТО.

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

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

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

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

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

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

Імпедимент-беклог

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

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

Відповідно, імпедимент-беклог — дуже спрощена форма роботи з поточними ризиками у скрамі.

Імпедимент-беклог можна зорганізувати різними способами:

Стикерами на окремій дошці (працює для доволі рідкісного випадку, коли вся команда перебуває в одній кімнаті).
Віртуальними стикерами на віртуальній дошці, як-от RealtimeBoard (для повністю розподілених команд).
Окремим проєктом у трекері завдань. Наприклад, TFS Online, Jira дають змогу побудувати окрему канбан-дошку для скрам-майстра. Можна навіть додати окремий лінк для будь-якого члена команди, щоб він міг створити імпедимент на розгляд.
Будь-який інший інструмент, що підтримує списки й уможливлює спільну роботу.

Приклад RealtimeBoard (image sorce)

Я зазвичай створював окрему канбан-дошку (переважно в Jira чи TFS), де були виписані всі ризики та імпедименти, з підзавданнями, що містили конкретні дії для послаблення впливу чи усунення ризиків, проблем і перешкод. Для ліпшої організації я встановлював на дошках WIP (Work in Progress) обмеження для фокуса й пріоритизації та окремий swimlane для ймовірних пожеж. У такий спосіб або прогнозуємо роботу в разі проактивної позиції на випередження, або цілковито фокусуємо увагу, коли потрібні реактивні дії.

Усі наведені підходи дуже схожі за принципом, але якщо ви вже користуєтеся якимось трекером завдань для роботи, то просто створіть окремий проєкт для імпедиментів. Список пріоритетних ризиків / проблем треба винести як окремий елемент на dashboard (а це вже класичний функціонал таких інструментів), який у вас перед очима щодня. Якщо ні, то фізична дошка чи віртуальний інструмент візуалізації — один з основних інструментів еджайлу.

Реєстр ризиків

Якщо є досвід у керуванні ризиками (а також час, що насправді досить важливо), то можна створити цілий реєстр ризиків. Так варто робити кожному менеджерові проєктів, коли щоденна робота охоплює трохи більше обов’язків і відповідальності, ніж у скрам-майстра. Це перехід від реактивного підходу в проактивний. Я зазвичай робив їх у Google Sheets чи Excel. Тут можна просто встановити всі потрібні атрибути ризиків.

Я використовував вбудовані фільтри й Conditional Formatting для увиразнення та зручності роботи. Завдяки цьому можна відсікти, наприклад, watchlist — ризики, що їх переглядають значно рідше через їхню меншу значущість. Ось стовпчики, які я використовую в таких реєстрах ризиків:

назва ризику (до 60 символів);
опис ризику: для простоти роботи з реєстром його можна ховати, коли знаєш, про що йдеться, і відкривати, коли показуєш реєстр тим, хто з ним стикається значно рідше (твітер-статус — 140 символів чи для любителів — 280 символів);
сфера впливу: випадний елемент (time, scope, budget, quality, team satisfaction, customer satisfaction);
опис впливу: аналогічно до опису самого ризику;
імовірність: оцінкова ймовірність за шкалою 1...3, 1...5, 1...10;
вплив: ідеться про вплив ризику на проєкт (як і ймовірність вище);
значущість ризику: добуток і ймовірності на вплив;
статус ризику: можна легко відфільтрувати закриті ризики;
стратегія: стратегія реакції на ризик (mitigate, omit, transfer, accept) — ці реакції варті окремого допису чи навіть статті;
тип: позитивний чи негативний — ризик чи можливість;
дата створення;
дата закриття;
власник ризику: відповідальна особа в роботі з ризиком (так, це не завжди скрам-майстер чи менеджер);
коментарі: тут можна дати волю письму, не обмежуючись 140 символами. Я пишу сюди всі оновлення й новини, які отримую щодо ризику з датами.

Ці атрибути ризиків лише базові, список можна сміливо корегувати, додаючи чи змінюючи самі атрибути. Наприклад, коли я працював делівері-директором для одного спільного шведсько-українсько-шриланкійського продукту, то додав ще Stakeholder Group, бо в продукту були чотири партнерські компанії, які над ним працювали, і чітко треба було розуміти, на чиїй «частині поля м’яч». Оскільки всі компанії мали свої підписки на Google My Business, то все, очевидно, було зорганізовано в Google Spreadsheet. Крім Stakeholder Group, під час обговорення ризиків на дзвінках C-Level мені також дуже допомагали умовне форматування з підсвіткою критичних ризиків, словесне пояснення впливу ризику й графа Notes з повною історією новин і роботи з ризику.

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

Самописні інструменти

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

Свого часу я брав участь в ініціативній групі розробки рішення на основі розширеного фреймворку роботи з ризиками Adriano (сам фреймворк вартий окремої серії дописів) на основі Jira. Здається (але це не точно), нам удалося вийти на Atlassian Marketplace і навіть продати кілька прикладів цього рішення.

В одній компанії, з якою я недавно співпрацював, був свій Project Management Tool, який мав вбудовану систему керування ризиками. Список властивостей ризиків приблизно відповідає тому, який описувався в розділі про реєстр ризиків у таблиці. Але перевагою такого інструменту є, наприклад, те, що активні ризики потрапляють у щотижневі звіти про проєкт автоматично. Відповідно до критичності ризиків можна сказати про ступінь здоров’я проєкту кожної із частин: часу, обсягу роботи, задоволеності команди й клієнта та навіть кошторису. А після закінчення проєкту ризики аналізують під час Post Mortem, а висновки (Lessons Learned) потрапляють до спеціального репозиторію. Їх можна використовувати й під час старту інших проєктів. У такий спосіб виконується остання стадія керування ризиками, про яку часто забувають, якщо користуються простими інструментами на кшталт Spreadsheets.

Готові рішення

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

Risk Gap

У мене був досвід користуватись одним з готових інструментів Risk Gap. Ми послуговувалися ним під час навчального проєкту Expedition PM (про нього я теж колись напишу окрему статтю). Перевагами інструменту було те, що його легко налаштувати, він містив оцінки від 1...10 для ймовірностей і впливів ризиків (зі зручними підказками), давав змогу оцінювати ризики кількісно, якщо встановити вартість у часі, грошах чи обсягу певного ризику. Користувачі оцінювали ідентифіковані ризики незалежно одне від одного, а отже, оцінка ставала об’єктивнішою. Також можна було створювати завдання для уникнення чи зменшення ризику. Якщо треба «підняти систему з нуля», то я раджу цей інструмент.

Image Source

Інші готові рішення

Ось ще кілька інструментів для роботи з ризиками, про які мені розповідали PM-колеги:

Висновки

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

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