nmk

Лекція №7 (4 години). Управління ризиками, якістю програмного забезпечення та стейкхолдерами

План лекції

Природа ризиків в IT. Ідентифікація та аналіз ризиків (Матриця ймовірності та впливу).
Створення Реєстру ризиків (Risk Register).
Стратегії реагування на загрози: Mitigation, Avoidance, Transfer, Acceptance.
Управління якістю ПЗ: різниця між забезпеченням якості (QA) та контролем якості (QC).
Роль тестування в життєвому циклі. Метрики якості коду.
Ідентифікація стейкхолдерів проєкту (Матриця “Вплив / Інтерес”).
Планування комунікацій у проєктній команді.

Перелік умовних скорочень

QA (Quality Assurance) — забезпечення якості (налагодження процесів з метою запобігання дефектам);
QC (Quality Control) — контроль якості (тестування готового продукту з метою виявлення дефектів);
Risk Register — реєстр (журнал) ризиків;
PI Matrix (Probability and Impact Matrix) — матриця ймовірності та впливу;
Stakeholder — зацікавлена особа (стейкхолдер).

Вступ

“Щось пішло не так” — фраза, яку можна почути на будь-якому IT-проєкті. Сервери падають, ключові розробники звільняються напередодні релізу, клієнт раптово змінює стратегію бізнесу, а в бібліотеці, яку ви використали, завтра знайдуть критичну вразливість.

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

1. Ідентифікація та аналіз ризиків. Матриця PI

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

Перший крок в управлінні ризиками — їх ідентифікація. PM збирає команду (мозковий штурм, інтерв’ю з експертами) і запитує: “Що може піти не так?”. Усі ідеї записуються.

Але не всі ризики однакові. Ризик “Офіс компанії вразить метеорит” має катастрофічний наслідок, але вкрай низьку ймовірність. Ризик “Senior-програміст піде у відпустку в найвідповідальніший момент” має високу ймовірність і середній вплив.

Щоб визначити, на захист від яких ризиків варто витрачати гроші (Management/Contingency Reserves) та час, використовують Матрицю ймовірності та впливу (Probability and Impact Matrix):

Ймовірність (Probability): Оцінюється від 0.1 до 1.0 (або від 1 до 5).
Вплив (Impact): Наслідки для бюджету чи строків, також від 0.1 до 1.0 (або від 1 до 5).

Оцінка ризику (Risk Score) = Ймовірність × Вплив.

Приклад: Ризик звільнення лід-розробника. Ймовірність = 4 (Висока, він давно скаржився на зарплату). Вплив на розклад проєкту = 5 (Катастрофічний, без нього ніхто не розуміє архітектуру). Risk Score = 4 * 5 = 20 (Червона зона). Цим ризиком потрібно займатися негайно.

2. Реєстр ризиків (Risk Register)

Після ідентифікації та оцінки всі дані заносяться у головний “параноїдальний” документ проєкту — Реєстр ризиків. Це не статична таблиця, а живий документ (найчастіше сторінка в Confluence або таблиця Excel), який переглядається на кожному статусному мітингу команди.

Що містить типовий рядок Реєстру ризиків:

ID та Назва ризику: [RSK-01] Падіння стороннього API (наприклад, платіжного шлюзу).
Опис (Причина -> Подія -> Наслідок): Через оновлення системи безпеки Банку, наш платіжний модуль може перестати відповідати, що призведе до неможливості оформлення замовлень клієнтами та втрати 20% місячного прибутку.
Probability (Ймовірність): 3/5
Impact (Вплив): 4/5
Risk Score: 12 (Середній пріоритет).
Trigger (Тригер - подія, що сигналізує про настання ризику): Банк надсилає email про зміну протоколів безпеки.
Власник ризику (Risk Owner): Відповідальна особа (наприклад, Tech Lead Олександр), яка повинна моніторити цей тригер.
План реагування: (Про це нижче). Запасний план дій.

3. Стратегії реагування на загрози

Коли ризик визначено і його пріоритет високий, PM разом з командою приймає рішення, ЯК саме реагувати. В IT існують чотири основні стратегії реагування на негативні ризики:

Avoidance (Уникнення):
- Ми повністю усуваємо причину ризику. Ми змінюємо план проєкту так, щоб ризик взагалі став неможливим.
- Приклад: Ризик, що підрядник не встигне написати складний модуль штучного інтелекту. Стратегія уникнення: ми взагалі скасовуємо розробку цього AI-модуля і видаляємо його з Scope (обсягу), замінивши простою експертною системою.
Mitigation (Зниження/Пом’якшення):
- Найпопулярніша стратегія. Ми не можемо гарантувати, що ризик не настане, але ми знижуємо його Ймовірність або Вплив до прийнятного рівня.
- Приклад: Пом’якшення впливу падіння серверів (ризик) — це налаштування щогодинного бекапу бази даних в хмару AWS. Сервер все ще може впасти, але втрата даних буде мінімальною.
Transfer (Передача):
- Перекладання фінансових наслідків ризику на третю особу. Сам ризик не зникає, просто за його наслідки платимо не ми.
- Приклад: Страхування обладнання в дата-центрі від пожежі. Або укладання контракту Fixed-Price з фрілансером (тепер ризик “не встигнути” — це особиста проблема фрілансера, а не наша).
Acceptance (Прийняття):
- Ми визнаємо, що ризик існує, але свідомо нічого не робимо, тому що вартість захисту вища за потенційні збитки. Якщо ризик настане, ми просто будемо вирішувати проблему по факту (використовуючи Management Reserve).
- Приклад: Затримка виходу нової версії iOS на два дні через внутрішні причини Apple. Ми ніяк не можемо на це вплинути, залишається лише сісти і чекати (прийняти).

4. Управління якістю ПЗ: QA vs QC

Ризики часто виникають через низьку якість продукту (дефекти, баги, архітектурні недоліки). На цьому етапі до роботи підключається відділ якості (часто його загалом називають QA, але це некоректно).

Важливо розрізняти дві концепції:

Quality Assurance (QA) — Забезпечення якості:
- Це про ПРОЦЕС створення коду.
- QA працює до або під час написання коду. Вони створюють стандарти розробки (Code guidelines), обирають фреймворки, запроваджують обов’язкове “парне програмування” (Code Review) та статичний аналіз коду (SonarQube).
- Ціль QA: Зробити так, щоб програмістам було важко написати код з помилкою. Попередити баг.
Quality Control (QC) — Контроль якості (Власне Тестування):
- Це про ПРОДУКТ.
- На жаль, програмісти все одно роблять помилки (людський фактор). Завдання QC-інженера (тестувальника) сісти за готовий (або частково готовий) продукт, натиснути “Оформити замовлення” і побачити, як кнопка вивалюється за межі екрана.
- Ціль QC: Знайти баг у вже написаному коді до того, як його побачить клієнт на Production сервері.

Проста аналогія з фабрикою шоколаду:

QA перевіряє рецептуру, закуповує свіже какао, налаштовує температурні режими печей.
QC бере з конвеєра випадкову шоколадку, кусає її і каже: “Чомусь вона з присмаком солі. Зупиніть лінію!”.

5. Роль тестування в життєвому циклі. Метрики якості

QC-інженери використовують різні типи тестування на різних етапах проєкту:

Unit Testing (Модульне): пишуть самі розробники для перевірки маленьких функцій;
Integration Testing (Інтеграційне): перевіряють, чи працює база даних із сервером;
System Testing (Системне): перевірка всієї програми;
UAT (User Acceptance Testing / Приймальне): клієнт сам перевіряє систему перед виплатою грошей IT-компанії.

Метрики якості коду: PM не просто слухає програмістів “ми зробили круто”, він має дивитись на об’єктивні показники якості продукту:

Code Coverage (Покриття коду тестами): Відсоток написаного програмістами коду, який перевіряється автоматизованими скриптами. Норма вважається вище 70-80%.
Defect Density (Щільність дефектів): Кількість знайдених багів на 1000 рядків коду (KLOC) або на один Story Point. Дозволяє порівнювати якість роботи різних команд (якщо одна команда стабільно робить 20 багів на спринт, а інша - 2, можливо хтось поспішає).
Technical Debt (Технічний борг): “Милиці” та погані рішення, які програмісти тимчасово зашили в код, щоб встигнути до дедлайну, і які обов’язково треба буде переписувати пізніше (через рефакторинг), інакше проєкт у майбутньому стане неможливо підтримувати.

6. Ідентифікація стейкхолдерів проєкту (Зацікавлені особи)

Стейкхолдер — це БУДЬ-ЯКА людина, група людей чи організація, яка може впливати на проєкт, на яку впливає проєкт або яка вважає, що проєкт на неї впливає.

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

Програмісти (хочуть працювати з новими технологіями);
Директор банку (хоче збільшити прибуток, Спонсор);
Клієнти банку, пенсіонери (хочуть великі кнопки);
Відділ безпеки банку (хоче купу перевірок).

Очевидно, що вимоги безпеки суперечитимуть зручності клієнтів. PM повинен зрозуміти, кого слухати в першу чергу. Для цього стейкхолдерів розбивають за допомогою Матриці “Влада та Інтерес” (Power / Interest Grid).

Висока Влада / Високий Інтерес (Manage Closely - Тісно керувати): Ключові фігури (Спонсори, CEO клієнта). Цим людям треба догоджати, їх треба залучати завжди. Вони приймають рішення про виділення бюджету.
Висока Влада / Низький Інтерес (Keep Satisfied - Тримати задоволеними): Наприклад, фінансовий або юридичний відділ клієнта. Їм не дуже цікавий дизайн кнопок, але вони можуть “зарубати” проєкт, якщо ми порушимо закон про захист даних (GDPR). З ними треба спілкуватись рідко, але винятково по суті, виконуючи їхні вимоги.
Низька Влада / Високий Інтерес (Keep Informed - Інформувати): Це кінцеві користувачі або працівники відділу підтримки. У них немає влади звільнити команду, але вони будуть цим застосунком користуватися цілими днями. Їх потрібно “Інформувати” (наприклад, через розсилку “Що нового у версії 2.0”), щоб вони відчували свою причетність.
Низька Влада / Низький Інтерес (Monitor - Моніторити): Ті, на кого проєкт майже не впливає (наприклад, сторонні спостерігачі). Мінімальні зусилля комунікації.

7. Планування комунікацій

Більшість кризових ситуацій виникає не через технічні причини, а через те, що хтось комусь щось вчасно не сказав. PM витрачає 90% свого часу саме на комунікацію.

Комунікації не можуть бути хаотичними. На самому початку проєкту формується Communication Management Plan (План управління комунікаціями). Це проста таблиця, яка відповідає на ключові питання:

Що передаємо? (Щотижневий звіт про статус проєкту / Щоденний мітинг).
Кому передаємо? (Топ-менеджменту клієнта / Лише команді розробників).
Як часто передаємо? (Кожної п’ятниці о 17:00 / О 10:00 ранку будні).
Через який канал? (Email у форматі PDF / Відеодзвінок у Google Meet / Повідомлення в Slack).

Правило комунікації: Завжди спілкуйтеся мовою вашої аудиторії. Директор (з квадрата “Висока Влада”) не хоче слухати про проблеми з міграцією JSON пакетів і докерами. Він хоче бачити три світлофори (Зелений-Жовтий-Червоний) біля показників “Строки” та “Бюджет”. Водночас, на щоденному мітингу розробників розповідати про маркетингову стратегію компанії на 5 років — це марна трата дорогоцінного часу.

Висновки

Ризик-менеджмент складається з ідентифікації, оцінки (відсіювання дрібниць за допомогою PI Матриці) та створення стратегії реагування. Усі ці дані зберігаються в “живому” Реєстрі ризиків (Risk Register).
Чотири стратегії реагування на загрози: Mitigation (зниження впливу), Avoidance (зміна плану для уникнення ризику), Transfer (страхування/аутсорс для передачі фінансового удару) та Acceptance (свідоме бездіяльність і ухвалення ризику).
Quality Assurance (QA) працює з процесами (стандарти кодування), щоб запобігти появі дефектів, тоді як Quality Control (QC) займається пошуком цих дефектів у готовому коді (тестування).
Усі люди та групи, які хоч якось задіяні або зачеплені проєктом є Стейкхолдерами.
PM керує очікуваннями конфліктуючих стейкхолдерів за допомогою позиціонування їх на Матриці “Влада/Інтерес”, що визначає стратегію спілкування з кожним.
Вдалий проєкт — це той, на якому діє чіткий розклад та стандарти комунікації, де інформація доставляється без затримок у потрібному форматі тим, кому вона потрібна.

Джерела

Інститут управління проєктами (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Розділи: Risk Management, Quality Management, Stakeholder Management, Communications Management.
Марк К. Прітчард. Управління ризиками: концепції та підходи.
Рекс Блек. Управління процесом тестування. Концепції та метрики QC.

Запитання для самоперевірки

Запропонуйте реальний приклад ризику в IT-проєкті. Оцініть його за допомогою PI Matrix і запропонуйте для нього стратегію “Mitigation” (Пом’якшення) та стратегію “Transfer” (Перенесення).
Поясніть на прикладі приготування обіду в ресторані, в чому різниця між функціоналом QA (Забезпечення якості) та QC (Контроль якості).
Що таке “Технічний борг” і чому він негативно впливає на майбутні витрати проєкту?
Складіть список стейкхолдерів для проєкту “Створення університетського порталу для студентів”. Розподіліть їх за 4 квадратами матриці “Влада/Інтерес”.
Чому спонсора проєкту (інвестора) відносять до квадрата “Висока Влада / Високий Інтерес” і як саме ви (як PM) будете планувати комунікацію з цією людиною?