Ризик-менеджмент

Карта ризиків: сім груп

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

1. 1.Бізнес-ризики (Business Risks)

   1. 1.1Невизначеність ринку: зміни у попиті, конкуренція, тренди.
   2. 1.2Фінансові ризики: перевищення бюджету, нестача фінансування.
   3. 1.3Стратегічні ризики: неузгоджені цілі між бізнесом і технічними командами.
   4. 1.4Зміни в керівництві: втрата ключових осіб, зміни стратегії компанії.
   5. 1.5Нереалістичні очікування: переоцінка швидкості розробки або окупності проєкту.

2. 2.Технічні ризики (Technical Risks)

   1. 2.1Проблеми архітектури: неправильний вибір технологій, моноліт vs. мікросервіси.
   2. 2.2Слабка кодова база: технічний борг, застарілі технології.
   3. 2.3Масштабованість і продуктивність: система не витримує навантаження.
   4. 2.4Інтеграційні ризики: зовнішні APIAPIApplication Programming Interface — контракт між програмамиПравила, за якими одна програма звертається до іншої: які запити можна надіслати, у якому вигляді й що прийде у відповідь. Для того, хто звертається, це контракт — усе, що за ним, лишається чорною скринькою, і саме тому другий бік можна переписати, не зламавши вас.Докладніше в статті →Усі терміни, складнощі з інтеграцією з іншими сервісами.
   5. 2.5Безпека: витік даних, уразливості, відсутність аудитів.

3. 3.Процесні ризики (Process Risks)

   1. 3.1Затримки у розробці: невірна оцінка часу, затримки у залежностях.
   2. 3.2Зміна вимог: часті pivot-и, відсутність стабільного беклогу.
   3. 3.3Проблеми з якістю: відсутність тестування, баги в продакшені.
   4. 3.4Відсутність документації: недостатня деталізація технічних рішень.

4. 4.Командні ризики (Team Risks)

   1. 4.1Брак компетенцій: відсутність критичних навичок, недостатній рівень інженерів.
   2. 4.2Втрата ключових співробітників: вигорання, звільнення.
   3. 4.3Проблеми комунікації: неузгодженість між командами, конфлікти.
   4. 4.4Низька продуктивність: відсутність мотивації, проблеми з менеджментом.

5. 5.Операційні ризики (Operational Risks)

   1. 5.1Збої у продакшені: відмова серверів.
   2. 5.2Залежність від сторонніх сервісів: відключення API, проблеми з постачальниками.
   3. 5.3Прогалини в безпеці: відсутність бекапів, слабка автентифікація.

6. 6.Юридичні та регуляторні ризики (Legal & Compliance Risks)

   1. 6.1Проблеми з ліцензуванням: використання сторонніх бібліотек, патенти.
   2. 6.2Регуляторні обмеження: GDPRGDPRGeneral Data Protection Regulation — закон ЄС про персональні даніЄвропейська регуляція про персональні дані: що можна збирати, на якій правовій підставі, скільки зберігати і чого людина може від вас вимагати щодо своїх даних. Вона застосовується за місцем перебування людей, а не компанії, — тому дістає до софту, збудованого будь-де.Усі терміни, HIPAA, фінансові регуляції.
   3. 6.3Конфіденційність даних: захист персональних даних користувачів.

7. 7.Стратегії управління ризиками (Risk Management Strategies)

   1. 7.1Уникнення ризику: не братися за високоризикові технології.
   2. 7.2Пом’якшення ризику: запровадження тестування та аудитів безпеки.
   3. 7.3Передача ризику: страхування, використання SaaS-рішень.
   4. 7.4Прийняття ризику: свідоме прийняття ризиків із резервними планами.

Ризик — це ще не проблема

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

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

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

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

Чому список перестає рости

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

Як оцінити ризик без вдаваної точності

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

Шаблон, яким користується більшість організацій, оцінює ймовірність від одного до п’яти, вплив від одного до п’яти, перемножує їх і сортує за добутком. Це відчувається як аналіз і є радше арифметичним театром. Оцінки — це здогади, вбрані у вимірювання; множення двох порядкових шкал дає число без змісту; а впорядкування, яке з цього виходить, нестійке: ризик на 12 і ризик на 15 отримають ту саму відповідь, а різницю між ними вирішить той, хто в кімнаті був найупевненішим.

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

Порог встановлюють до оцінювання

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

Коли числа варті зусиль

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

Для ризиків розкладу варто знати дві техніки. Трикрапкова оцінка — оптимістична, ймовірна, песимістична — запитана по кожній задачі й зведена докупи, дає діапазон замість дати, і саме діапазон є чесною відповіддю. Симуляція Monte CarloMonte Carloсимуляція багатьма випадковими прогонамиМетод, що відповідає на питання, проганяючи його тисячі разів із випадково взятими входами й читаючи розподіл результатів. На розкладі він замінює одну дату діапазоном і ймовірністю — чесною формою оцінки, складеної з двадцяти невизначених задач.Усі терміни робить те саме як слід, семплюючи ці діапазони тисячі разів, і її справжня цінність не у виводі, а в розмові: вона робить видимим, що план із двадцяти задач, кожна з яких «зазвичай нормально», має дуже малий шанс бути нормальним увесь одразу.

Чотири відповіді — і п’ята

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

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

П’ята відповідь, яку прямо називають 6-те і 7-ме видання PMBOKPMBOKA Guide to the Project Management Body of Knowledge — довідник PMI з управління проєктамиДовідник Project Management Institute з управління проєктами й основа сертифікації PMP. Видання має значення: 6-те (2017) приписувало 49 процесів, 7-ме (2021) замінило їх дванадцятьма принципами, а 8-ме (2025) має шість принципів, сім доменів і сорок процесів.Докладніше в статті →Усі терміни, — ескалація: ризик справжній, але рішення не ваше. PRINCE2 не має відповіді з такою назвою і доходить до того самого через процедуру винятків, яка передає раді все, що виходить за допуски менеджера проєкту. Ризик, що змінив би бізнес-кейс, порушив би регуляцію чи потребував би грошей поза вашим бюджетом, належить тому, хто володіє цими речами, — і тримати його при собі з почуття власності є найпоширенішим способом, яким проєктний менеджер перетворює керований ризик на невідновний. Ескалація не є провалом; провалом є ескалація без рекомендації.

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

Практики, які справді зрушують число

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

Реєстр, що є контролем, а не документом

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

Прикріпіть перегляд до зустрічі, яка вже існує, замість створювати окрему зустріч про ризики: саме її скасують першою в завантажений місяць. П’ятнадцяти хвилин у наявній щотижневій достатньо, якщо питання конкретні: які рядки змінилися, які тригери спрацювали і що ми відтоді дізналися такого, що належить сюди. У Scrum-команд реєстру в Гайді немає, і вигадувати його не треба: ризики, що потребують роботи, стають елементами беклогу з власниками, а SprintSprintцикл роботи фіксованої довжиниФіксований період, зазвичай від тижня до чотирьох, наприкінці якого є щось достатньо завершене, щоб показати. Фіксована саме довжина, а обсяг рухається: спринт, який подовжили під роботу, втратив єдине, заради чого існував.Докладніше в статті →Усі терміни Review — та точка, де стейкхолдер їх бачить.

Pre-mortem

Pre-mortem із робіт Ґері Кляйна про ухвалення рішень — найприбутковіша година в усій цій статті. Ви збираєте команду до початку роботи й кажете: минув рік, цей проєкт провалився повністю, запишіть чому. Далі всі п’ять хвилин пишуть мовчки, перш ніж хтось заговорить.

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

Купуйте інформацію замість писати пом’якшення

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

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

Репетируйте відновлення, а не збій

Будь-який контроль, який ви ніколи не виконували, — це віра. Відновіть бекап у тимчасове середовище й заміряйте час. Проженіть відкат у вівторок по обіді, коли команда дивиться. Проведіть game day, де хтось навмисне вимикає залежність, а решта команди з’ясовує, що ламається, — це і є вся ідея chaos engineeringchaos engineeringнавмисне ламанняНавмисне спричинення збоїв у робочій системі, щоб дізнатися, як вона поводиться, раніше, ніж збій станеться сам. Суть у часі, а не в хоробрості: той самий інстанс, що вмирає о третій ночі без репетиції, — це інцидент, а о другій дня, коли команда дивиться, — це знахідка.Усі терміни, і вона працює задовго до масштабів Netflix. У кожному з інцидентів наступного розділу контроль існував на папері й ніколи не виконувався.

Ще дві, що окупаються на будь-якому проєкті помітного розміру. Моделювання загроз — прохід фічею з питанням, що з нею зробив би атакувальник, зі STRIDE як чеклістом, якщо він потрібен, — єдиний надійний спосіб виявити ризики безпеки до того, як їх знайде пентест удесятеро дорожче. І blameless post-mortempost-mortemписьмовий розбір після збоюПисьмовий розбір після того, як щось пішло не так: що сталося, чому і що зміниться, щоб воно не сталося так само. Слово «blameless» перед ним — не ввічливість: інженер, який очікує звинувачень, розповідає менше, а розбір, що дає висновок замість зміни в системі, не дав нічого.Усі терміни після кожного інциденту з одним правилом: результатом має бути зміна в реєстрі або в контролі, а не висновок. «Бути уважнішими» не є контролем.

Шість провалів і контроль, якого бракувало

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

Кейси Equifax і Log4Shell — це той самий провал у двох масштабах. Equifax отримала повідомлення про вразливість у широко вживаному Java-компоненті, патч існував, а портал, який зрештою зламали, його не отримав: процес казав «пропатчити», і жодна конкретна людина не відповідала за підтвердження, що конкретну систему пропатчено. Log4Shell через чотири роки показав ту версію цієї проблеми, яку неможливо розв’язати старанністю: вразлива бібліотека потрапляла всередину опосередковано, через залежності залежностей, у софт, власники якого не знали про її існування. Контроль в обох випадках — інвентаризація, SBOMSBOMSoftware Bill of Materials — список того, що всерединіМашиночитний перелік усіх компонентів, з яких зібрано програму, включно із залежностями, що приходять через інші залежності. Він важить у день, коли оголошують вразливість: без нього на питання «чи це нас стосується?» відповідають здогадом.Усі терміни, список того, що справді працює, — бо будь-який інший контроль припускає, що ви можете відповісти на питання «де це?».

Де це перетворюється на театр

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

• Реєстр оновлюють увечері перед керівним комітетом і не відкривають між зустрічами.
• «Пом’якшення: уважно моніторити» — не названо ні дії, ні власника, ні дати; саме так рядок рік лишається зеленим.
• Оцінки домовлені, а не оцінені, бо висока оцінка запускає розмову, якої хтось хоче уникнути.
• Ризик як спосіб сказати «ні» роботі — і всі навколо вчаться більше не приносити вам ризиків.
• Ескалація в групу, що не має повноважень або бажання вирішувати, — це затримка з паперовим слідом.
• Усе визначено на кікофі й відтоді нічого не додано — на проєкті, що йде вісім місяців.
• Контроль, що існує в документі й ніколи не виконувався: неперевірене відновлення, невідрепетируваний відкат, перемикання, якого ніхто не запускав.

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

Відповідь на цей клас — не кращий прогноз, а коротший зворотний зв’язок. Виявляти швидше, відновлюватися швидше й робити зміни оборотними, — і саме тому безперервна поставка, feature flagsfeature flagперемикач навколо нового кодуПеремикач, що під час роботи вирішує, чи активний шматок коду, — тож код може потрапити в продакшен вимкненим і бути ввімкненим для обраної аудиторії пізніше. Він відділяє деплой від релізу й має ціну: кожен живий прапорець — це розгалуження в коді, яке має працювати в обох станах.Докладніше в статті →Усі терміни, поетапне викочування й відрепетируваний відкат належать до розмови про ризики, хоч їх зазвичай відносять до інженерних практик. Це єдині контролі, що працюють проти ризику, якого ніхто не записав. Команда, здатна скасувати зміну за чотири хвилини, купила собі захист від усієї категорії того, чого не зуміла уявити, — а цього не може запропонувати жоден реєстр.

Коли це застосовувати

Пов’язані сторінки

• МенеджментЧекліст PM на новому проєктіПерші дев’яносто днів проєктного менеджера на проєкті, який почав не він, — це діагноз і далі невелика кількість свідомих змін, а не реорганізація. Перший місяць — з’ясувати, як робота тече насправді; другий — домовитися, що саме ви зміните і з ким; третій — приземлити перші зміни й уміти показати, що вони зрушили. Ця сторінка і є тим чеклістом, разом із ситуативним судженням, яке вирішує, які його частини стосуються саме вас.
• МенеджментPRINCE2PRINCE2 — це метод управління проєктами, збудований навколо одного питання, на яке проєкт відповідає знову й знову: чи варто його й далі фінансувати? Він майже нічого не каже про те, як виконується робота, і дуже багато — про те, хто має право вирішити, що вона триває. Сторінка починається з одного проєкту, налаштованого за PRINCE2, у готовому вигляді; далі — що таке цей метод, сім принципів, сім практик і сім процесів, допуски й винятки, два проєкти, які метод існує, щоб зупиняти, і де він вироджується.
• МенеджментМетодики оцінюванняМетодики оцінювання в IT — це одиниці, якими команда прогнозує, скільки роботи займе завдання: story points, людино-дні, години або розміри футболок (T-shirt). Вони не взаємозамінні. Кожна переносить крок, що перетворює зусилля на дату, в інше місце й до іншої людини, і кожна ламається по-своєму, впізнавано. Сторінка починається з усіх чотирьох поруч і таблиці, яка з них пасує до якого рішення, а далі — чому чесна оцінка є діапазоном, а не числом, кожна одиниця детально, шість задокументованих оцінок, що пішли не так, і де оцінювання перетворюється на театр.