Моніторинг, контроль та звітність у проєктах ЦТ

Тема 2: Управління проєктами у військовому середовищі · Заняття 3

Теоретична довідка (питання 1–7)

1. Система ключових показників ефективності (KPI) для проєктів ЦТ

1.1. Поняття та призначення KPI

KPI (Key Performance Indicator) — вимірюваний показник, що відображає хід або результат проєкту й підтримує управлінське рішення. Добрий KPI прив’язаний до цілі (outcome), має чітке джерело даних, базове й цільове значення.

1.2. Вимоги до якісного KPI

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

1.3. Категорії KPI проєкту ЦТ

Категорія	Приклади
Строки	Відхилення від плану, дотримання віх, залишок до завершення.
Обсяг / якість	Частка виконаних робіт, кількість критичних дефектів.
Результат (outcome)	Рівень використання рішення, скорочення часу процесу.
Ризики	Кількість активних критичних ризиків, прострочені реагування.

1.4. Ритм моніторингу проєкту

Контроль ефективний лише як регулярний процес із визначеним ритмом. Різні рівні контролю мають різну періодичність:

Ритм	Формат	Мета
Щоденно	Короткий стендап команди.	Синхронізація, виявлення блокерів.
Щотижня	Статус-огляд, перегляд RAID-log.	Контроль прогресу й ризиків.
Щомісяця / на віхах	Статус-звіт командуванню.	Рішення рівня командування, ескалації.

Ритм важливіший за формальну повноту: краще короткий регулярний огляд, ніж детальний, але епізодичний.

Типові помилки:

показники «для звіту», що не підтримують жодного рішення;
KPI без базового значення (неможливо оцінити зміну);
занадто багато показників — губиться головне.

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

2. Leading vs lagging indicators

2.1. Визначення

Lagging (запізнілі) показники фіксують уже досягнутий результат — вони точні, але «дивляться назад» (наприклад, рівень використання системи за минулий місяць). Leading (випереджальні) показники сигналізують заздалегідь про майбутній результат (кількість навчених користувачів, темп усунення дефектів).

2.2. Навіщо обидва типи

Керувати можна переважно leading-показниками — вони дають час на реакцію. Lagging-показники підтверджують результат. Система контролю має містити обидва: leading — щоб діяти, lagging — щоб оцінити.

Приклад. Lagging: «рівень adoption 40%». Leading: «за тиждень навчено 15 із 50 користувачів» — сигналізує, чи вийдемо на цільовий adoption вчасно.

Типові помилки:

опора лише на lagging-показники (реакція завжди із запізненням);
плутанина leading/lagging при побудові системи контролю.

Проміжний висновок: leading-показники дозволяють керувати майбутнім, lagging — підтверджують минуле.

3. Операційна аналітика та Dashboard

3.1. Призначення дашборда

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

3.2. Принципи побудови

мінімум показників — лише ті, що впливають на рішення;
актуальність даних — застарілий дашборд шкідливий;
наочність — статуси (світлофор), тренди, відхилення від плану;
один погляд — одна відповідь на питання «де ми і що робити».

3.3. Типова структура дашборда проєкту

Блок	Зміст
Статус проєкту	Загальний світлофор, найближча віха, ключові ризики.
Строки	Прогрес за віхами, відхилення від плану.
Результат (outcome)	Ключові outcome-метрики (adoption, час процесу).
Ризики та проблеми	Активні критичні ризики й issues з RAID-log.

3.4. Звітність різним аудиторіям

Один набір даних подається по-різному залежно від аудиторії. Це не «прикрашання», а адаптація рівня деталізації.

Аудиторія	Що показувати	Формат
Командування	Статус, найближча віха, ризики, потрібні рішення.	Короткий статус-звіт (Додаток 3).
Команда	Деталі робіт, залежності, дефекти, доручення.	Робочий дашборд, action log.
Стейкхолдери-користувачі	Строки впровадження, що зміниться для них.	Roadmap, повідомлення.

Типові помилки:

дашборд-«вітрина» без показників, що підтримують рішення;
перевантаження десятками метрик;
застарілі дані.

Проміжний висновок: добрий дашборд дає керівнику відповідь «де ми і що робити» за один погляд.

4. Управлінські журнали: RAID status, decision / action / issue / change log

4.1. Призначення журналів

Журнали — «пам’ять проєкту» й основа звітності та контролю. Крім RAID-log (Заняття 1), керівник веде:

Журнал	Що фіксує
Decision log	Ухвалені рішення: що, хто, коли, підстава.
Action log	Доручення: завдання, відповідальний, строк, статус.
Issue log	Проблеми, що вже настали, та їх вирішення.
Change log	Зміни обсягу/строків/бюджету та їх наслідки.

4.2. Зв’язок із RAID-log

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

Типові помилки:

усні домовленості без фіксації у журналах;
записи без відповідального й строку;
зміни обсягу без відображення у change log.

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

5. Earned Value та Burn-down chart

5.1. Earned Value (освоєний обсяг)

Earned Value (EV) порівнює три величини: заплановане (скільки мали виконати), виконане (скільки реально зроблено) та витрачене (скільки ресурсу спожито). Зіставлення дає ранні сигнали відхилень за строками й бюджетом.

Сигнал 1: якщо виконано менше запланованого — відставання за строками;
Сигнал 2: якщо витрачено більше, ніж «зароблено» обсягом — перевитрата бюджету.

5.2. Burn-down chart

Burn-down показує залишок робіт до завершення спринту чи релізу в часі. Лінія, що йде вище плану, сигналізує про відставання. Це наочний і простий інструмент контролю в гнучкій частині проєкту.

Приклад. Якщо на середині спринту виконано лише 30% обсягу, burn-down одразу покаже загрозу невиконання — час перерозподілити роботи або переглянути обсяг.

5.3. Приклад розрахунку Earned Value

На середину проєкту (план — 100 умовних одиниць обсягу, бюджет — 100 тис. грн):

Показник	Значення	Тлумачення
Заплановано (PV)	50	Мали виконати половину.
Виконано (EV)	40	Реально виконано 40%.
Витрачено (AC), тис. грн	55	Спожито 55% бюджету.
SPI = EV/PV	0,8	< 1 → відставання за строками.
CPI = EV/AC	0,73	< 1 → перевитрата бюджету.

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

Типові помилки:

контроль лише за фактом витрат без порівняння з виконаним обсягом;
реакція на відхилення лише наприкінці, коли виправити вже дорого.

Проміжний висновок: EV і burn-down дають ранні сигнали відхилень, поки їх ще дешево виправити.

6. Definition of Done для управлінських і технічних deliverables

6.1. Поняття DoD

Definition of Done (DoD) — узгоджений перелік умов, за яких результат вважається завершеним. DoD прибирає суперечки «готово / не готово» і є основою приймання.

6.2. Приклад DoD

Для технічного результату (функції ІКС) DoD може включати: розроблено, протестовано, задокументовано, перевірено на відповідність вимогам ЗІ, розгорнуто в тестовому середовищі. Для управлінського результату (звіту): підготовлено, погоджено, доведено до стейкхолдерів.

Типові помилки:

відсутність DoD → нескінченні суперечки про готовність;
DoD «на словах», не зафіксований і не узгоджений.

Проміжний висновок: DoD робить приймання об’єктивним і однозначним.

7. Протоколювання рішень та контроль виконання після нарад

7.1. Протокол наради

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

7.2. Контроль виконання

Доручення з протоколу переносяться в action log і контролюються до виконання. Без окремої регулярної дії з контролю (наприклад, на початку наступної наради) домовленості не виконуються — це типова причина «буксування» проєктів.

Приклад. Правило «наступна нарада починається з перевірки виконання доручень попередньої» різко підвищує дисципліну виконання.

Типові помилки:

нарада без протоколу — рішення забуваються;
доручення без відповідального й строку;
відсутність контролю виконання доручень.

Проміжний висновок: цінність наради вимірюється не обговоренням, а виконанням її рішень.

8. Практична вправа: розробка Dashboard, системи KPI та ведення RAID-log

Мета вправи: для проєкту ЦТ слухачі розробляють систему з 4–6 KPI, макет дашборда та заповнюють RAID-log і decision/action log.

Вихідні дані: опис проєкту (з Заняття 2 або новий кейс); шаблони (Додатки 1–3).

Форма роботи: у парах, з подальшою взаємною перевіркою та презентацією 2–3 робіт.

Порядок виконання

Визначити 4–6 KPI із поділом на leading/lagging: метрика, джерело, базове й цільове значення — 25 хв.
Спроєктувати макет дашборда: які блоки, які рішення вони підтримують — 20 хв.
Заповнити RAID-log (мінімум 2 записи кожної категорії) та decision/action log — 25 хв.
Взаємна перевірка та презентація 2–3 робіт із розбором — 10 хв.

Еталонне проходження (зразок для викладача)

KPI. Строки: відхилення від плану віх (lagging). Результат: adoption системи, % (lagging); час інвентаризації, дн (lagging). Leading: % навчених користувачів; темп усунення дефектів. Кожен — з базою, ціллю, джерелом.

Дашборд. Блоки: статус (світлофор + найближча віха); строки (прогрес віх); outcome (adoption, час процесу); ризики (критичні з RAID). Кожен блок підтримує конкретне рішення.

Журнали. RAID: R — затримка погодження; A — доступ до тестового середовища; I — немає доступів у пілоті; D — залежність від міграції даних. Decision log: «обрано готове ПЗ замість розробки, підстава — строк». Action log: «підготувати доступи, відп. — …, строк — …».

Методичні вказівки викладачу

Під час роботи в парах викладач перевіряє: (1) чи KPI підтримують рішення, а не «для звіту»; (2) чи є leading-показники; (3) чи записи RAID/action log мають власників і строки; (4) чи дашборд не перевантажений. Для розбору обирає один сильний і один проблемний приклад.

Контрольні питання

Які вимоги до якісного KPI? Наведіть приклади KPI для проєкту ЦТ.
Чим leading-показники відрізняються від lagging? Навіщо потрібні обидва?
Які принципи побудови корисного дашборда?
Назвіть управлінські журнали проєкту та їх призначення.
Як Earned Value та Burn-down допомагають виявити відхилення раніше?
Що таке Definition of Done і чому він важливий для приймання?
Навіщо потрібні протокол наради й контроль виконання доручень?

Завдання для закріплення

Розробити систему KPI (4–6 показників) і макет дашборда для реального проєкту свого підрозділу.
Запровадити для одного проєкту RAID-log і action log; вести їх протягом двох тижнів.
Підготуватися до Заняття 4: повторити роботу з ризиками у RAID-log.

Додаток 1. Шаблон системи KPI

№	KPI	Тип (leading/lagging)	База	Ціль	Джерело
1
2
3
4
5

Додаток 2. Шаблон RAID-log

№	Тип (R/A/I/D)	Опис	Власник	Статус / реагування
1
2
3
4

Додаток 3. Шаблон статус-звіту проєкту

Розділ	Зміст
Загальний статус (світлофор)
Прогрес за віхами
Ключові outcome-метрики
Критичні ризики та проблеми
Рішення, потрібні від командування

Додаток 4. Критерії оцінювання роботи

Критерій	Бали	Орієнтир
KPI підтримують рішення; є leading і lagging	0–3	З базою, ціллю, джерелом.
Дашборд: наочний, не перевантажений	0–3	Блоки підтримують рішення.
Журнали: власники, статуси, строки	0–2	RAID/action log заповнені коректно.
Розуміння leading/lagging та EV/burn-down	0–2	Пояснює на прикладі.
Разом	0–10	9–10 «відмінно»; 7–8 «добре»; 5–6 «задовільно».

Додаток 5. Шаблон протоколу наради

№	Рішення / доручення	Відповідальний	Строк
1
2
3

Додаток 6. Глосарій ключових термінів

KPI — ключовий показник ефективності, що підтримує рішення.
Leading indicator — випереджальний показник, що сигналізує заздалегідь.
Lagging indicator — запізнілий показник, що фіксує досягнутий результат.
Dashboard — візуальне зведення ключових показників для рішень.
RAID-log — журнал ризиків, припущень, проблем і залежностей.
Decision log — журнал ухвалених рішень.
Action log — журнал доручень із відповідальними й строками.
Change log — журнал змін обсягу/строків/бюджету.
Earned Value — метод контролю відхилень за строками й бюджетом через освоєний обсяг.
Burn-down — графік залишку робіт до завершення спринту/релізу.
Definition of Done — узгоджені умови завершеності результату.

Додаток 7. Приклад заповненого дашборда (розбір)

Дашборд проєкту «Система обліку майна» на середину реалізації:

Блок	Показник	Рішення, яке підтримує
Статус	Жовтий; віха «погодження ТЗ» під загрозою.	Ескалувати погодження.
Строки	SPI 0,8 — відставання.	Перерозподілити ресурс на критичний шлях.
Outcome	Adoption пілоту 45% (ціль 90%).	Посилити навчання користувачів.
Ризики	2 критичні (доступи, міграція даних).	Опрацювати з власниками ризиків.

Кожен блок дашборда веде до конкретної управлінської дії — це і є ознака робочого, а не «вітринного» дашборда.

Додаток 8. Приклад заповнених decision / action log

Decision log:

№	Рішення	Хто ухвалив	Підстава
1	Обрати готове ПЗ замість власної розробки.	DT Lead	Строк, cost of delay.
2	Стартувати пілот у 1 підрозділі до масштабування.	PM	Зниження ризику.

Action log:

№	Доручення	Відповідальний	Строк	Статус
1	Підготувати доступи для пілоту.	Support	.	В роботі
2	Погодити ТЗ з органом ЗІ.	BA	.	Відкрито