Віха

Урок 4 з 4

Реакції, резерви й реєстр

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

Наприклад, у гри ризик «сервер падає в день релізу» загрожує збитком 18 тис. грн. Тест навантаження за 6 тис. грн виправданий. А от орендувати сервери «із запасом» на весь рік за 50 тис. — ні.

Реакції на ризик

Для кожного ризику з реєстру команда обирає реакцію. PMBOK описує п'ять реакцій на загрози:

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

І п'ять реакцій на нагоди: використати, посилити, розділити з партнером, прийняти або ескалювати.

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

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

Реакції на ризики

П'ять реакцій на загрози і п'ять — на нагоди.

Загрози

  • Уникнути (уникнення)

    змінити план так, щоб загроза зникла

    У грі: не писати власний ігровий рушій, а взяти перевірений готовий

  • Зменшити (пом'якшення)

    знизити ймовірність чи збиток; сюди ж — диверсифікація

    У грі: тест навантаження сервера, документація коду

  • Передати (передача)

    наслідки бере на себе третя сторона

    У грі: застрахувати техніку студії

  • Прийняти (прийняття)

    нічого не робити заздалегідь, але тримати резерв і план дій

    У грі: резерв 30 тис. грн на курс долара й податки

  • Ескалювати (ескалація)

    загроза виходить за межі проєкту — рішення ухвалює вище керівництво

    У грі: магазин змінює правила оплати для всіх ігор — вирішують засновники студії

Нагоди

  • Використати (використання)

    зробити все, щоб нагода точно настала

    У грі: магазин бере в добірку «Нове» ігри, що вийшли до 1 грудня, — фіксуємо реліз до цієї дати

  • Посилити (посилення)

    збільшити ймовірність чи вигоду

    У грі: зробити якісний трейлер, щоб підвищити шанс потрапити в добірку

  • Розділити (розподіл)

    залучити того, хто скористається нагодою краще

    У грі: відомий стример отримує частку доходу з покупок за його промокодом

  • Прийняти (прийняття)

    нічого не робити заздалегідь, але скористатися, якщо настане

    У грі: гра раптом стала популярною в соцмережах — швидко підтримати хвилю

  • Ескалювати (ескалація)

    нагода більша за проєкт — рішення ухвалює вище керівництво

    У грі: інша студія хоче купити ігровий рушій — вирішують засновники

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

Скільки коштує захист

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

Якісний аналіз ризиків гри

Три кроки для кожного ризику: назва і причина, наслідки в гривнях, захід і його ціна.

  1. 1. Ризик

    1. Помилка у встановленні ціни

    Причина: не перевірили, скільки гравці готові платити за покупки в грі.

    2. Наслідки

    доходи першого року на 20% нижчі

    −24 тис. грн

    3. Захід

    перевірити дві ціни на частині гравців (A/B-тест)

    5 тис. грн

  2. 1. Ризик

    2. Магазин застосунків відхиляє реліз

    Причина: гра порушує правила магазину.

    2. Наслідки

    реліз на місяць пізніше, а зарплати платимо

    −15 тис. грн

    3. Захід

    перевірити гру за правилами магазину до подання

    2 тис. грн

  3. 1. Ризик

    3. Іде ключовий програміст

    Причина: лише одна людина знає код ігрової механіки.

    2. Наслідки

    два місяці на пошук і навчання нової людини

    −40 тис. грн

    3. Захід

    документувати код, другий розробник переглядає зміни

    8 тис. грн

  4. 1. Ризик

    4. Сервер падає в день релізу

    Причина: не перевірили, чи витримає він наплив гравців.

    2. Наслідки

    гравці не можуть увійти й видаляють гру

    −18 тис. грн

    3. Захід

    тест навантаження і автоматичне масштабування в хмарі

    6 тис. грн

  5. 1. Ризик

    5. Зростає курс долара

    Причина: сервери й ліцензії оплачуємо в доларах.

    2. Наслідки

    витрати на сервери зростають

    −12 тис. грн

    3. Захід

    запобігти неможливо — лише резерв

    з резерву: 12 тис. грн

  6. 1. Ризик

    6. Змінюються податки на цифрові послуги

    Причина: рішення держави, на яке студія не впливає.

    2. Наслідки

    з кожного продажу лишається менше

    −20 тис. грн

    3. Захід

    запобігти неможливо — лише резерв

    з резерву: 20 тис. грн

Неконтрольованим ризикам (курс, податки) запобігти не можна, тому їхню суму покриваємо з резерву.

Резерви

Те, від чого не захиститися заходами, покривають резервом. PMBOK розрізняє два:

  • Резерв на відомі ризики (contingency reserve) — гроші й час на ризики, які вже виявили й оцінили. Він входить у бюджет проєкту, і ним розпоряджається керівник проєкту.
  • Управлінський резерв (management reserve) — на те, чого ніхто не передбачив. Його тримає спонсор поза бюджетом проєкту.

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

Резерв проти ризиків

Резерв — 30 тис. грн, а на захист від усіх ризиків потрібно 53.

Резерв у бюджеті30 тис.

Потрібно на ризики53 тис.

межа резерву

  • Ціна — 5 тис.
  • Модерація — 2 тис.
  • Програміст — 8 тис.
  • Сервер — 6 тис.
  • Курс — 12 тис.
  • Податки — 20 тис.

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

Не вистачає 23 тис. грн. Ризики, які не покриває резерв, перевіряємо кількісно: наскільки вони вдарять по NPV гри.

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

Усе, що ми зробили в модулі, в команді збирається в одному робочому документі — реєстрі ризиків (risk register). Це жива таблиця, де в кожного ризику свій рядок. В аутсорсингових компаніях його часто ведуть як частину RAID-журналу (Risks, Assumptions, Issues, Dependencies — ризики, припущення, проблеми, залежності).

Типові колонки реєстру:

  • ID і назва — конкретна, як у якісному аналізі.
  • Імовірність і вплив — зазвичай за шкалою від 1 до 5. Їхній добуток дає пріоритет.
  • Власник — одна людина, яка стежить за ризиком і запускає реакцію. Не «команда», а конкретна людина.
  • Тригер — ознака, що ризик ось-ось станеться.
  • Реакція і план дій.
  • Статус: відкритий, під контролем, закритий.

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

Одна таблиця, яку команда переглядає щотижня.

  • R-1 Помилка у встановленні ціни

    12 — високий

    Тригер: у перший тиждень покупки робить менше 2% гравців

    Імовірність × вплив
    3 × 4
    Власник
    Product Owner
    Реакція
    Зменшити
    Статус
    Відкритий

  • R-4 Сервер падає в день релізу

    12 — високий

    Тригер: навантаження сервера понад 70%

    Імовірність × вплив
    3 × 4
    Власник
    DevOps-інженер
    Реакція
    Зменшити
    Статус
    Під контролем

  • R-3 Іде ключовий програміст

    10 — середній

    Тригер: програміст повідомив про звільнення

    Імовірність × вплив
    2 × 5
    Власник
    Технічний лідер
    Реакція
    Зменшити
    Статус
    Відкритий

  • R-5 Зростає курс долара

    8 — середній

    Тригер: курс зріс більше ніж на 5% від плану

    Імовірність × вплив
    4 × 2
    Власник
    Проєктний менеджер
    Реакція
    Прийняти
    Статус
    Відкритий

  • R-2 Магазин застосунків відхиляє реліз

    6 — середній

    Тригер: магазин повернув гру з зауваженнями

    Імовірність × вплив
    2 × 3
    Власник
    Проєктний менеджер
    Реакція
    Зменшити
    Статус
    Під контролем

  • R-6 Змінюються податки на цифрові послуги

    6 — середній

    Тригер: законопроєкт про податки ухвалено в першому читанні

    Імовірність × вплив
    2 × 3
    Власник
    Засновник студії
    Реакція
    Прийняти
    Статус
    Відкритий
Пріоритет = імовірність × вплив, обидва за шкалою від 1 до 5. Від 12 — високий, від 6 — середній. Тригер — ознака, що ризик ось-ось станеться.

Як реєстр живе в проєкті

  1. Поповнюють. Перші ризики дає якісний аналіз на старті. Нові додають щоразу, коли вони з'являються: на плануванні спринту, ретроспективі, після розмови із замовником.
  2. Переглядають регулярно — зазвичай раз на тиждень або раз на спринт. Оновлюють імовірність, вплив і статус. Ризики з найвищим пріоритетом обговорюють першими, а топ-ризики потрапляють у звіт для замовника.
  3. Перетворюють на проблеми. Якщо ризик стався, це вже не ризик, а проблема (issue). Її переносять у список проблем і вирішують.
  4. Не видаляють. Закриті ризики — досвід для наступних проєктів. Пригадайте метод аналогій з першого уроку.

Реєстр ведуть там, де вже працює команда: окремий тип задач у Jira, сторінка в Confluence чи звичайна Google Таблиця. Головне не інструмент, а регулярність.

Підсумок модуля

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