Карта ризиків: як знаходити те, що сховане

Це для людей, які знають, що в проекті будуть ризики, але не хочуть платити консультантам за документ “risk register” на 40 сторінок, який потім ніхто не відкриває.

Чому це болить

Найризикованіша фраза, яку можна почути на старті IT-проекту: “у нас ризиків нема, все під контролем”. Її зазвичай вимовляє людина, яка ще не запускала продукт у реальний світ. Тому що ризики є завжди — просто або ми про них думаємо, або вони про нас.

З іншого боку — якщо ми відкриємо стандартний “risk register” від великого консалтингу, то побачимо документ на 40 сторінок, у якому записано все, що теоретично може піти не так: від падіння метеорита до зради ключового співробітника. Цей документ дорого коштує, виглядає вражаюче — і нічого не міняє в нашій повсякденній роботі, бо ним ніхто не користується.

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

Що таке карта ризиків — без магії

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

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

Англійською це називають risk register або risk map. У нас далі — просто “карта ризиків” або “таблиця”.

Чому стандартні шаблони не працюють

Бо вони пишуться для аудиту, не для рішень. У шаблоні від консалтингу буде колонка “Likelihood (1-5)”, “Impact (1-5)”, “Risk Score (1-25)”, “Mitigation Strategy”, “Risk Owner”, “Review Cadence” і ще 8 полів. Це класно виглядає в Excel, але ми ніколи не сядемо вранці, не відкриємо це і не зробимо щось інше через ці цифри.

Натомість працює мінімальна модель — 3 колонки, які можна заповнити за 20 хвилин і вертатись до них коли треба.

| Що може піти не так | Наскільки погано і ймовірно | План Б |

Усе. Якщо колонок більше — табличку перестають заповнювати через місяць.

6 типів ризиків, які бачимо найчастіше

За 8 років роботи в проектах від енергетики до фінтеху, від держсектору до aerospace, у мене склався список з шести типів ризиків, які з’являються у 9 з 10 проектів. Ось вони — з ілюстративними прикладами.

1. Технічні ризики

Те, що може зламатись у самому продукті.

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

Як знайти: запитуємо команду розробників — “які 3 речі найбільше турбують вас у технічній частині?”. Вони знають. Просто не люблять про це говорити, бо це звучить як визнання слабкості.

2. Регуляторні ризики

Те, що пов’язано із законом, ліцензіями, перевірками.

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

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

3. Кадрові ризики

Те, що пов’язано з людьми в команді.

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

Як знайти: запитуємо у керівника проекту — “хто з команди критичний, і що буде, якщо ця людина зникне на тиждень?”. Хороший керівник зразу скаже. Поганий — буде уникати відповіді.

4. Залежностні ризики

Те, що залежить від третіх сторін, на яких ми не маємо впливу.

Дизайнер, від якого ми чекаємо макетів, працює над трьома іншими проектами і всі — пріоритетніші.
Банк, з яким ми інтегруємось, обіцяє API “ось-ось”, але вже 4 місяці не дає документації.
Хмарний провайдер, на якому хочемо хостити продукт, у нашій країні не має офіційного представництва — і у разі санкцій нас можуть відключити.

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

5. Ризики даних

Те, що пов’язано з інформацією, яку ми збираємо, зберігаємо і використовуємо.

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

Як знайти: запитуємо у технічної команди: “де зберігаються дані наших користувачів, як часто бекапимось, хто має доступ?”. Якщо відповіді нечіткі — це і є наш ризик № 1.

6. Ризики бізнес-моделі

Те, що пов’язано не з продуктом, а з тим, чи буде хтось ним користуватись і платити.

Ми будуємо застосунок, а потенційні користувачі не готові за нього платити (це з’ясовується тільки після запуску, якщо не зробити брифінг до контракту).
Ринок змінюється швидше, ніж ми будуємо — і коли ми запустимось через 6 місяців, конкуренти будуть на крок попереду.
Юніт-економіка нашого продукту негативна — на одного користувача ми витрачаємо більше, ніж заробляємо.

Як знайти: перед стартом проекту малюємо найпростішу таблицю: “1 клієнт коштує нам $X залучити, $Y обслуговувати, заробляємо з нього $Z”. Якщо X+Y > Z — у нас не продукт, у нас благодійність.

Як виглядає таблиця по факту

Тепер — як це виглядає в Google Sheets або Notion. На реальному ілюстративному проекті, на який я опирався (фінансовий застосунок з інтеграцією банків — це композит з кількох проектів, без посилання на конкретний):

Що може піти не так	Наскільки погано і ймовірно	План Б
Банк [A] затримає API на 6+ тижнів	Боляче (заблокує 30% функціональності). Середня ймовірність (вони вже зривали 1 раз)	Готуємо інтеграцію з банком [B] паралельно як запасний варіант. Архітектуру робимо такою, щоб додати ще 1 банк за тиждень
Розробник, який знає всю архітектуру бекенду, у відпустці у червні	Дуже боляче, бо запуск планували на 15.06. Висока ймовірність (відпустка вже узгоджена)	До 25.05 пишемо документацію архітектури разом із ним. Тімлід читає, ставить питання. На 5 днів запасу
Регулятор вимагатиме переробити політику обробки даних	Боляче (2-3 тижні правок + повторна реєстрація). Середня ймовірність (правила нещодавно змінили)	Юрист уже консультує. Платимо ще 5 годин на превентивний аудит у травні, а не очікуємо першу перевірку
Конкурент [C] випустить аналог раніше за нас	Помірно (втратимо переваги “першого”, але не критично). Висока ймовірність	Швидше йдемо до запуску — скорочуємо першу версію до 60% функціональності, доставляємо інше після

Скільки рядків? Стільки, скільки реальних ризиків. Зазвичай у живій таблиці 8-15 рядків. Якщо менше 5 — ми думаємо недостатньо. Якщо понад 30 — ми думаємо забагато, частину можемо об’єднати або викинути.

Як часто оновлюємо

Перший раз — на старті проекту, разом із виконавцем, 1-2 години.
Далі — раз на 2-3 тижні, 20 хвилин: переглядаємо, що змінилось, додаємо нові, закриваємо неактуальні.
Перед великими подіями (підписання договору, релізом, інтеграцією) — окрема півгодинна сесія “що ще може піти не так у цій конкретній точці”.

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

Коли пора кликати фахівця

Три trigger-знаки:

У нас регульована галузь. Медицина, фінтех, авіація, енергетика, держсектор, обробка персональних даних. Тут ризики настільки специфічні, що внутрішня команда без фахівця їх не побачить. Хоча б одну консультацію 2-3 години з людиною, яка робила запуск саме в нашій ніші, — обов’язково.
Ми не розуміємо технічну частину. Якщо вище в списку “технічні ризики” ми просто не уявляємо, що питати у команди — це нормально. Це означає, що нам потрібен buyer-side фахівець, який сяде на нашому боці столу і поставить ці питання за нас.
Ризик може коштувати більше, ніж проект. Якщо одна помилка з даними може коштувати штрафу більшого за бюджет проекту — ми не можемо дозволити собі вчитися на цьому. Краще запросити консультанта на 5-10 годин, ніж переживати наслідки самостійно.

Часті помилки на цьому етапі

Робимо таблицю і забуваємо. Зробили, поклали в папку, не відкривали півроку. Тоді краще було не робити. Жива таблиця оновлюється раз на місяць — мертва не приносить нічого.
Записуємо ризики, але не пишемо план Б. Без плану Б це не управління ризиками, а перелік страхів. Кожен рядок без третьої колонки — це психологічна підготовка, не робочий інструмент.
Не показуємо таблицю виконавцю. Це наш спільний документ. Виконавець бачить ризики зі свого боку (технічні, кадрові), ми — зі свого (бізнес, регуляторні). Разом картина повна. Окремо в кожного — половинчаста.
Соромимось писати “ризик: ключова людина в команді”. Це нормальний бізнес-розмов. Хороший виконавець сам перший про це скаже. Якщо ми боїмось його образити — ми вже маємо проблему довіри, а не комунікації.

Що буде далі

Це п’ятий пост серії про артефакти бізнес-аналізу. Попередні — про критерії приймання, брифінг до контракту, user story і оцінку від IT-компанії.

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

Якщо не хочемо пропустити — стежимо за мною у LinkedIn, там анонсую кожен матеріал серії.

Якщо ми зараз стартуємо великий проект у регульованій галузі — варто витратити одну зустріч на карту ризиків з фахівцем, який знає вашу нішу. У Ascend Griffin ми робимо короткі сесії Discovery Sprint — формат, у якому ризики розбираємо разом із вами і вашою командою як частину етапу розвідки.