Ініціювання та планування проєктів ЦТ у ЗСУ. WBS, діаграми Ганта, дорожні карти

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

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

1. Ініціювання проєкту: статут, цілі, критерії успіху

1.1. Фаза ініціювання

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

1.2. Статут проєкту (project charter)

Статут — короткий документ (1–2 сторінки), що є «точкою істини» щодо проєкту. Склад:

назва та стислий опис проєкту;
мета й очікуваний результат (outcome);
вимірювані критерії успіху;
межі: in scope / out of scope;
ключові стейкхолдери;
керівник проєкту та його повноваження;
орієнтовні строки й ресурси;
ключові ризики й залежності.

1.3. Цілі та критерії успіху

Ціль формулюється як outcome (ефект), критерії успіху — за SMART. Критерій успіху відповідає на питання «як ми дізнаємося, що проєкт вдався».

Приклад. Мета: «частина веде облік майна без паперу». Критерії успіху: час інвентаризації ≤ 1 дня; частка позицій у системі ≥ 95%; розбіжності «облік/факт» ≤ 3%.

1.4. Бізнес-обґрунтування

Статут стисло відповідає, навіщо проєкт: який біль вирішує, яка цінність (ланцюг цінності з Теми 1) і яка вартість зволікання (cost of delay). Це основа для пріоритезації та отримання ресурсу.

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

старт без статуту → різне розуміння цілей у стейкхолдерів;
критерії успіху у форматі завдань, а не вимірюваних результатів;
відсутність out of scope у статуті.

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

2. WBS: принципи декомпозиції та правила побудови

2.1. Означення та призначення

WBS (Work Breakdown Structure, структура декомпозиції робіт) — ієрархічний розподіл усього обсягу робіт проєкту на керовані елементи (робочі пакети). WBS відповідає на питання «що саме треба зробити» і є основою для оцінки строків, ресурсів і контролю.

2.2. Правила побудови

Орієнтація на результат — декомпозиція за результатами (deliverables), а не за діями;
Правило 100% — сума елементів нижнього рівня дорівнює всьому обсягу проєкту — ні більше, ні менше;
Керованість — кожен робочий пакет має бути оцінюваним, контрольованим і мати одного відповідального;
Рівень деталізації — уникати надмірної деталізації (орієнтир — робочий пакет обсягом кількох днів роботи, а не годин).

2.3. Способи структурування

WBS можна будувати за фазами проєкту, за результатами (компонентами продукту) або комбіновано. Для проєктів впровадження ІКС зручний фазово-результатний підхід.

2.4. Приклад WBS (фрагмент)

Проєкт «Система обліку майна» (повний приклад — Додаток 3):

1. Ініціювання (статут, погодження старту);
1. Вимоги і ТЗ (збір вимог, розробка ТЗ, погодження);
1. Розробка / закупівля рішення;
1. Випробування (дослідна експлуатація, усунення зауважень);
1. Впровадження (розгортання, реєстрація в реєстрі ІКС);
1. Навчання й підтримка користувачів.

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

WBS за діями («налаштувати», «зробити») замість результатів;
порушення правила 100% (пропущені або зайві роботи);
надмірна деталізація до окремих дій.

Проміжний висновок: якісна WBS — повна, результат-орієнтована й керована; вона основа для Ганта й оцінки ресурсів.

3. Діаграма Ганта як інструмент планування та комунікації

3.1. Що показує

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

3.2. Типи залежностей

фініш-старт (FS): наступна робота починається після завершення попередньої (найпоширеніший);
старт-старт (SS), фініш-фініш (FF): паралельні роботи з прив’язкою початків/завершень.

3.3. Порядок побудови

Перенести роботи з WBS.
Оцінити тривалість кожної роботи.
Встановити залежності між роботами.
Визначити критичний шлях.
Позначити віхи (у т.ч. нормативні контрольні точки).

3.4. Гант як комунікація

Для командування Гант показує «де ми і що далі» без технічних деталей. Для команди — послідовність і залежності робіт. Одна діаграма слугує обом аудиторіям, якщо не перевантажена деталями.

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

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

Проміжний висновок: Гант перетворює WBS на календарний план із залежностями й критичним шляхом.

4. Дорожня карта (Roadmap) проєкту ЦТ

4.1. Означення та відмінність від Ганта

Roadmap — високорівневий погляд на проєкт по кварталах/етапах: ключові результати та віхи без деталізації задач. На відміну від Ганта (детальний план для команди), roadmap призначений для командування й стейкхолдерів і відповідає на питання «що і коли отримаємо».

4.2. Структура

Roadmap містить: часові горизонти (квартали/етапи), ключові результати кожного горизонту, головні віхи. Формулювання — у термінах цінності для користувача, а не технічних задач.

4.3. Приклад

Приклад. Roadmap проєкту обліку: Q1 — ТЗ і погодження; Q2 — пілот у 1 частині; Q3 — впровадження у 80% частин; Q4 — інтеграція та розвиток.

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

змішування roadmap із детальним планом/Гантом;
формулювання roadmap у технічних задачах замість результатів.

Проміжний висновок: roadmap — мова спілкування з командуванням; Гант — інструмент команди.

5. Практична вправа: розробка статуту, WBS та діаграми Ганта

Мета вправи: для типового проєкту впровадження ІКС слухачі (у парах) розробляють пакет планування: статут → WBS → діаграма Ганта → roadmap.

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

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

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

Скласти статут проєкту: мета (outcome), критерії успіху, in/out scope, стейкхолдери — 20 хв.
Побудувати WBS до 3-го рівня (робочі пакети) за правилом 100% — 25 хв.
Побудувати діаграму Ганта: тривалості, залежності, критичний шлях — 25 хв.
Оформити roadmap на рівні кварталів із ключовими віхами — 10 хв.
Взаємна перевірка в парах і презентація 2–3 робіт із розбором — 10 хв.

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

Статут. Мета: «частина веде облік майна без паперу, дані актуальні». Критерії успіху: інвентаризація ≤ 1 дня; ≥ 95% позицій у системі. In scope: облік, інвентаризація, звіти. Out of scope: інтеграція з фінансовою системою.

WBS. Шість пакетів (ініціювання; вимоги/ТЗ; розробка/закупівля; випробування; впровадження/реєстрація; навчання) з підпакетами (Додаток 3).

Гант. ТЗ (5 дн) → погодження (10 дн) → розробка (20 дн) → дослідна експлуатація (10 дн) → реєстрація (5 дн) → впровадження (15 дн). Критичний шлях ≈ 65 дн. Навчання готується паралельно.

Roadmap. Q1 — ТЗ і погодження; Q2 — пілот; Q3 — масштабування.

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

Під час роботи в парах викладач перевіряє: (1) статут — чи є вимірювані критерії успіху й out of scope; (2) WBS — правило 100%, декомпозиція за результатами; (3) Гант — наявність залежностей і критичного шляху, врахування віх погоджень; (4) roadmap — високорівневість. Для загального розбору обирає один сильний пакет і один із типовою помилкою.

6. Milestone planning з контрольними точками погодження у нормативних процесах МОУ

6.1. Поняття віхи

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

6.2. Нормативні контрольні точки як віхи

У проєктах ЗСУ окремими віхами обов’язково стають нормативні контрольні точки:

завершення погодження ТЗ (юрслужба, орган ЗІ, ФЕО);
готовність до дослідної (пробної) експлуатації;
внесення ІКС до реєстру ІКС;
прийняття системи в експлуатацію.

6.3. Планування із запасом

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

Приклад. Якщо погодження ТЗ реально триває 2–4 тижні, у плані закладають 4 тижні, а не 1, і не починають розробку до завершення цієї віхи.

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

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

Проміжний висновок: нормативні контрольні точки — обов’язкові віхи проєкту ЦТ, які планують із запасом часу.

7. Backlog логіка, sprint / release та релізна логіка у гібридному управлінні

7.1. Backlog

Backlog — упорядкований за пріоритетом перелік вимог/робіт продукту. Верх беклогу — найпріоритетніше й найдетальніше опрацьоване; низ — менш пріоритетне й крупніше.

7.2. Sprint

Спринт — короткий цикл (1–4 тижні), у якому команда реалізує обраний обсяг беклогу до працюючого інкременту з демонстрацією.

7.3. Release і зв’язок з нормативними віхами

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

7.4. Гібридна логіка

Backlog реалізується спринтами (гнучка частина), а релізи прив’язані до предиктивних нормативних віх (керована частина). Це і є практичне втілення гібридного підходу з Заняття 1.

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

8. План підготовки користувачів до впровадження ІКС

8.1. Навіщо

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

8.2. Склад плану

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

8.3. Приклад

Приклад. Для системи обліку: пілот у 1 підрозділі (2 тижні) → доопрацювання за зворотним зв’язком → навчання відповідальних у 80% частин → канал підтримки (чат + інструкції).

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

підготовка користувачів «після запуску», коли система вже відторгнута;
навчання «для звіту» без перевірки засвоєння.

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

9. Release readiness та hypercare після запуску

9.1. Release readiness

Release readiness — перевірка готовності до запуску за чек-листом: пройдені випробування, готова документація й навчання, отримані погодження та реєстрація, забезпечено вимоги ЗІ, визначено план відкату (rollback). Запуск без цієї перевірки — джерело інцидентів і правових ризиків.

9.2. Hypercare

Hypercare — період інтенсивної підтримки в перші тижні після запуску: посилена команда підтримки, швидке реагування на інциденти, збір зворотного зв’язку та оперативні виправлення. Мета — не дати негативному першому досвіду відштовхнути користувачів.

9.3. План відкату (rollback)

Заздалегідь визначений порядок повернення до попереднього стану, якщо запуск виявився невдалим. Наявність rollback-плану знижує ризик критичних наслідків.

Міні-відпрацювання: слухачі доповнюють свій пакет планування коротким release readiness checklist (Додаток 6).

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

запуск без перевірки готовності (release readiness);
відсутність плану відкату;
згортання підтримки одразу після запуску (без hypercare).

Проміжний висновок: release readiness і hypercare забезпечують, що результат буде не лише «зданий», а й прийнятий користувачами.

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

Що містить статут проєкту і навіщо він потрібен?
Сформулюйте правила побудови WBS. Наведіть типову помилку декомпозиції.
Що показує діаграма Ганта? Як визначити критичний шлях?
Чим roadmap відрізняється від детального плану/Ганта?
Які нормативні контрольні точки МОУ стають віхами проєкту ЦТ і як їх планувати?
Поясніть логіку backlog / sprint / release у гібридному управлінні.
Що має містити план підготовки користувачів і чому він критичний для outcome?
Що таке release readiness, hypercare і план відкату?

Завдання на самостійну підготовку

Тема: Управління змінами у проєкті ЦТ (scope change control).

Опрацювати причини та типи змін у проєктах цифрової трансформації.
Описати процедуру scope change control та її вплив на строки, бюджет і ресурси на прикладі власного проєкту.
Доопрацювати пакет планування (статут, WBS, Гант, roadmap) для проєкту свого підрозділу.

Додаток 1. Шаблон статуту проєкту (project charter)

Розділ	Зміст (заповнити)
Назва проєкту
Мета та очікуваний результат (outcome)
Критерії успіху (вимірювані)
У межах проєкту (in scope)
Поза межами (out of scope)
Ключові стейкхолдери
Керівник проєкту та повноваження
Орієнтовні строки й ресурси
Ключові ризики та залежності

Додаток 2. Заготовка WBS / діаграми Ганта

№	Робочий пакет / робота	Тривалість	Залежить від	Віха / контрольна точка
1
2
3
4
5
6

Додаток 3. Приклад WBS (проєкт «Система обліку майна»)

Рівень 1	Рівень 2 (робочі пакети)
1. Ініціювання	Розробка статуту; погодження старту; призначення команди.
2. Вимоги і ТЗ	Збір вимог; розробка ТЗ; закладення вимог ЗІ/ПД; погодження ТЗ.
3. Розробка / закупівля	Вибір рішення; договір/розробка; налаштування; права на код.
4. Випробування	Дослідна експлуатація; перевірка ЗІ; усунення зауважень.
5. Впровадження	Розгортання; внесення до реєстру ІКС; введення в експлуатацію.
6. Навчання й підтримка	Підготовка користувачів; документація; канал підтримки.

Додаток 4. Шаблон milestone-плану

№	Віха	Планова дата	Погоджувач / умова
1	Погодження ТЗ
2	Готовність до дослідної експлуатації
3	Внесення до реєстру ІКС
4	Прийняття в експлуатацію

Додаток 5. Шаблон плану підготовки користувачів

Група користувачів	Формат навчання	Критерій засвоєння

Додаток 6. Release readiness checklist

Пройдено функціональні випробування; критичні дефекти усунені.
Готова документація користувача та проведено навчання.
Отримані необхідні погодження; ІКС внесено до реєстру (за потреби).
Забезпечено вимоги захисту інформації та розмежування доступу.
Визначено план відкату (rollback) і план hypercare.
Призначено власників підтримки та канал зворотного зв’язку.

Додаток 7. Критерії оцінювання пакета планування

Критерій	Бали	Орієнтир
Статут: чіткі мета, критерії успіху, scope	0–2	Є in/out scope; критерії вимірювані.
WBS: правило 100%, декомпозиція за результатами	0–3	Робочі пакети контрольовані.
Гант: залежності, критичний шлях, віхи	0–3	Враховано нормативні контрольні точки.
Roadmap і release readiness	0–2	Високорівневість; чек-лист заповнений.
Разом	0–10	9–10 «відмінно»; 7–8 «добре»; 5–6 «задовільно».

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

Статут проєкту (charter) — документ, що легітимізує проєкт і фіксує мету, scope, стейкхолдерів.
WBS — ієрархічна декомпозиція робіт проєкту на робочі пакети.
Робочий пакет — керований елемент WBS з одним відповідальним.
Правило 100% — сума елементів WBS дорівнює всьому обсягу проєкту.
Діаграма Ганта — календарний план робіт із тривалостями, залежностями та віхами.
Критичний шлях — найдовший ланцюг залежних робіт, що визначає строк.
Roadmap — високорівнева дорожня карта результатів і віх по етапах.
Віха (milestone) — контрольна точка нульової тривалості.
Backlog — упорядкований за пріоритетом перелік робіт/вимог.
Release readiness — перевірка готовності до запуску за чек-листом.
Hypercare — період інтенсивної підтримки після запуску.
Rollback — план повернення до попереднього стану у разі невдалого запуску.