Методології управління проєктами. Agile, Scrum, Waterfall та гібридні підходи

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

1. Загальна класифікація методологій управління проєктами

1.1. Поняття проєкту та управління проєктом

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

1.2. Континуум методологій

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

Підхід	Коли доречний	Особливості
Предиктивний (Waterfall)	Стабільні вимоги, жорсткі погодження, закупівлі.	Послідовні фази, повна документація, фіксований scope.
Адаптивний (Agile/Scrum/Kanban)	Мінливі вимоги, потреба швидкого зворотного зв’язку.	Ітерації, ранній результат, гнучкість до змін.
Гібридний	Регуляторне середовище + продукт, що розвивається.	План на рівні віх + ітеративна розробка.

1.3. Критерії вибору методології

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

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

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

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

2. Класичний підхід Waterfall: структура, переваги та обмеження у військовому контексті

2.1. Структура

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

Ініціювання → Вимоги → Проєктування → Розробка → Тестування → Впровадження → Супровід.

2.2. Переваги

чіткість і передбачуваність: відомі фази, строки, контрольні точки;
повна документованість — добре лягає на нормативні процеси погодження й закупівель у ЗСУ;
зручність за фіксованого, стабільного обсягу (scope);
простота контролю виконання за фазами.

2.3. Обмеження

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

2.4. Застосовність у ЗСУ

Waterfall доречний для проєктів зі стабільними вимогами й жорсткими регуляторними умовами: створення документованих ІКС під фіксоване ТЗ, проєкти з обов’язковими послідовними погодженнями та закупівлями. Для продуктів із мінливими вимогами каскадна модель ризикована.

Приклад. Проєкт зі створення ІКС під затверджене ТЗ із фіксованим переліком функцій і обов’язковими етапами випробувань добре лягає на Waterfall.

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

застосування Waterfall для продукту з нестабільними вимогами;
відсутність проміжного зворотного зв’язку до самого впровадження.

Проміжний висновок: Waterfall — про передбачуваність і документованість; його ціна — негнучкість до змін.

3. Гнучкі методології: Agile-маніфест та Scrum-фреймворк

3.1. Цінності Agile

Agile — сімейство гнучких підходів, що ставлять у пріоритет робочий продукт, співпрацю з користувачем і реагування на зміни. Чотири цінності Agile-маніфесту (спрощено):

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

Важливо: «важливіше» не означає «замість». Документація й план потрібні, але не є самоціллю.

3.2. Scrum: ролі

Product Owner — відповідає за цінність продукту, пріоритети беклогу.
Scrum Master — відповідає за процес, усуває перешкоди, сприяє команді.
Команда розробки — крос-функціональна команда, що створює інкремент продукту.

3.3. Scrum: артефакти й події

Артефакти: product backlog, sprint backlog, інкремент.
Події: спринт (1–4 тижні), планування спринту, щоденний стендап, огляд (review), ретроспектива.

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

3.4. Kanban (стисло)

Kanban — гнучкий підхід без фіксованих спринтів: візуалізація потоку робіт на дошці, обмеження незавершеної роботи (WIP), безперервне постачання. Доречний для потоку різнорідних задач (наприклад, підтримка й дрібні доопрацювання).

3.5. Застосовність у ЗСУ

Agile/Scrum доречні для продуктів із мінливими вимогами, де є доступ до користувачів-військових для зворотного зв’язку й потрібен швидкий результат. Обмеження — вимоги погоджень, безпеки та закупівель, які погано вкладаються в чисту ітеративність.

3.6. Scrum чи Kanban: коли що

Scrum	Kanban
Робота планується спринтами (1–4 тижні).	Безперервний потік без фіксованих ітерацій.
Доречний для розробки продукту з планованими цілями спринту.	Доречний для потоку різнорідних задач (підтримка, дрібні доопрацювання).
Ролі PO/SM/команда, набір подій.	Мінімум ролей; фокус на потоці й обмеженні WIP.

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

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

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

4. Гібридні підходи: вибір оптимальної методології залежно від типу проєкту та умов

4.1. Сутність гібриду

Гібрид поєднує предиктивне планування на рівні віх (для погоджень, бюджету, закупівель) з ітеративною розробкою продукту (Agile). Це найчастіший практичний вибір для проєктів ЦТ у ЗСУ.

Waterfall на рівні віх і погоджень + Agile на рівні розробки продукту.

4.2. Як це працює на практиці

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

4.3. Критерії вибору співвідношення

Фактор	Схиляє до…
Стабільність вимог	висока → більше предиктивного; низька → більше Agile.
Регуляторні обмеження	жорсткі → предиктивні контрольні точки.
Доступ до користувачів	є → більше ітеративності й демонстрацій.
Критичність / безпека	висока → більше формальних перевірок.

4.4. Наскрізний приклад: один проєкт трьома підходами

Проєкт «система обліку майна у частині» можна вести по-різному залежно від обраного підходу:

Waterfall: повне ТЗ → проєктування → розробка → тестування → впровадження. Ризик: якщо потреба зрозуміла неточно, це виявиться лише наприкінці.
Agile: спринтами: спочатку мінімальний облік, демонстрація користувачам, доопрацювання за зворотним зв’язком. Ризик: погодження й закупівлі важко вкласти в спринти.
Гібрид: нормативні віхи (ТЗ, погодження, дослідна експлуатація, реєстрація) — предиктивні; розробка між віхами — спринтами з демонстраціями. Це поєднує керованість і гнучкість.

Висновок прикладу: для більшості проєктів ЦТ ЗСУ саме гібрид дає найкращий баланс керованості й швидкості.

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

ігнорування нормативних віх у гнучкій частині.

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

5. Специфіка управління проєктами у військовому середовищі: обмеження, ризики, особливості

5.1. Обмеження

вимоги захисту інформації, ДСК/секретність, обмеження доступів;
довгі цикли погоджень і багаторівневість затвердження;
закупівельні процедури держсектору (строки, формалізм);
залежність від підрядників та зовнішніх систем;
умови воєнного часу: ротація особового складу, зміна пріоритетів «згори».

5.2. Ризики

Найтиповіші ризики проєктів ЦТ у ЗСУ: затримки погоджень і закупівель; зміна вимог у процесі; безпекові ризики; втрата ключових людей через ротацію; технологічна залежність від підрядника. Ці ризики детально опрацьовуються на Занятті 4.

5.3. Особливості, що впливають на вибір підходу

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

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

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

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

6. RAID-log як ключовий управлінський артефакт

6.1. Призначення

RAID-log — єдиний робочий журнал керівника проєкту, що об’єднує чотири категорії контролю: Risks (ризики), Assumptions (припущення), Issues (проблеми), Dependencies (залежності). Це «панель приладів» проєкту, що ведеться постійно.

6.2. Складові

Елемент	Що фіксуємо
Risks (ризики)	Можливі майбутні події з негативним впливом; ймовірність, вплив, власник, реагування.
Assumptions (припущення)	Припущення, на яких будується план; підлягають перевірці й можуть стати ризиками.
Issues (проблеми)	Проблеми, що вже настали; потребують негайних дій і, за потреби, ескалації.
Dependencies (залежності)	Залежності від інших робіт, систем, підрозділів, підрядників.

6.3. Ведення

Кожен запис має власника й статус. RAID-log переглядається на кожній синхронізаційній нараді: нові записи, зміна статусів, закриті пункти. Саме регулярність робить RAID-log інструментом контролю, а не «мертвим» документом.

Приклад. Assumption «підрядник надасть доступ до тестового середовища до 1 числа» не підтвердилося → перетворюється на Issue → фіксується власник і план дій → за потреби ескалюється.

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

ведення RAID-log «для звіту», без регулярного перегляду;
записи без власника й статусу;
змішування ризиків (ще не сталося) і проблем (вже сталося).

Проміжний висновок: RAID-log — основний інструмент контролю проєкту; його цінність — у постійному веденні й перегляді.

7. Scope definition: in scope / out of scope, критерії готовності до старту

7.1. Визначення обсягу

Scope (обсяг) — сукупність робіт і результатів проєкту. Чітке визначення обсягу — захист від «розповзання» (scope creep), коли до проєкту поступово додаються роботи без перегляду строків і ресурсів.

7.2. In scope / out of scope

Обов’язково фіксується не лише те, що входить у проєкт (in scope), а й що явно НЕ входить (out of scope). Явне «out of scope» знімає непорозуміння зі стейкхолдерами й запобігає конфліктам про «а ми думали, це теж буде».

Приклад. Проєкт «система обліку майна»: in scope — облік, інвентаризація, звіти; out of scope — інтеграція з фінансовою системою (окремий проєкт).

7.3. Критерії готовності до старту (Definition of Ready)

Перед стартом реалізації проєкт має відповідати критеріям готовності:

затверджені цілі та критерії успіху;
визначені та доступні ресурси (люди, бюджет);
отримані необхідні погодження;
ідентифіковані ключові ризики й залежності;
визначено обсяг (in/out scope).

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

відсутність явного out of scope → scope creep;
старт реалізації без затверджених цілей чи ресурсів;
мовчазне розширення обсягу без перегляду строків.

Проміжний висновок: чіткий scope і критерії готовності — основа керованості проєкту й захист від «розповзання».

8. Effort estimation та critical path

8.1. Методи оцінки трудовитрат

Експертна — оцінка на основі досвіду фахівців.
Аналогова — оцінка за аналогією з подібними проєктами.
Параметрична — розрахунок за нормативами (наприклад, вартість одиниці × кількість).
Триточкова — оптимістична, песимістична й найімовірніша оцінки, зважене середнє.

Будь-яка оцінка має похибку. Правило — фіксувати припущення, на яких вона побудована, і закладати резерв.

8.2. Критичний шлях

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

Приклад. Якщо розробка (10 днів) залежить від готового ТЗ (5 днів), а тестування (5 днів) — від розробки, критичний шлях = 5 + 10 + 5 = 20 днів. Паралельна робота (наприклад, підготовка документації), що вкладається у ці 20 днів, критичний шлях не подовжує.

8.3. Практичне значення

Знання критичного шляху дозволяє: правильно визначити реальний строк; зосередити контроль на найкритичніших роботах; свідомо скорочувати строк (додаванням ресурсу саме на критичний шлях). Це прямо застосовується при побудові діаграми Ганта (Заняття 2).

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

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

Проміжний висновок: реалістична оцінка трудовитрат і управління критичним шляхом — основа керування строками проєкту.

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

Що таке проєкт і чим він відрізняється від операційної діяльності?
Наведіть класифікацію методологій управління проєктами та критерії їх вибору.
Опишіть структуру Waterfall; назвіть переваги й обмеження у контексті ЗСУ.
Розкрийте цінності Agile та ролі/події Scrum.
Що таке гібридний підхід і чому він часто оптимальний у військовому середовищі?
Назвіть специфічні обмеження й ризики управління проєктами у ЗСУ.
Опишіть структуру RAID-log і поясніть різницю між ризиком і проблемою.
Що таке scope creep і як його уникнути через scope definition?
Поясніть поняття критичного шляху та методи оцінки трудовитрат.

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

Тема: Ключові ролі у проєктах розробки та впровадження ІКС.

Опрацювати ролі у проєктній команді: Product Owner, Scrum Master, Project Manager, Business Analyst — зони відповідальності та взаємодія.
Побудувати матрицю RACI для типового проєкту впровадження ІКС і показати, як вона запобігає конфлікту ролей.
Підготувати короткий висновок: яка методологія (Waterfall / Agile / гібрид) доречна для проєкту вашого підрозділу і чому.

Додаток 1. Порівняння методологій управління проєктами

Критерій	Waterfall	Agile/Scrum	Гібрид
Вимоги	Стабільні, фіксовані.	Мінливі, уточнюються.	Стабільні на рівні віх.
Результат	Наприкінці.	Регулярно (спринти).	Ітеративно між віхами.
Документація	Повна.	Достатня.	Повна на віхах.
Зміни	Дорогі.	Очікувані.	Керовані.
Придатність у ЗСУ	Фіксоване ТЗ, погодження.	Продукти зі змінними вимогами.	Більшість проєктів ЦТ.

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

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

Додаток 3. Алгоритм вибору методології (для практики)

Оцінити стабільність вимог: стабільні → предиктивний ухил; мінливі → адаптивний ухил.
Оцінити регуляторні обмеження: жорсткі погодження/закупівлі → фіксовані нормативні віхи.
Оцінити доступ до користувачів: є → більше ітеративності й демонстрацій.
Оцінити критичність і безпеку: висока → більше формальних перевірок.
Синтезувати: у більшості проєктів ЦТ ЗСУ — гібрид (нормативні віхи + ітеративна розробка).

Додаток 4. Опорна схема життєвого циклу проєкту

Ініціювання (статут, scope) → Планування (WBS, Гант, віхи) → Реалізація (спринти / фази) → Моніторинг і контроль (KPI, RAID) → Впровадження (release readiness, hypercare) → Закриття (lessons learned).

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

Проєкт — тимчасова діяльність зі створення унікального результату в межах обмежень.
Waterfall — каскадна модель із послідовними фазами й фіксованим обсягом.
Agile — сімейство гнучких ітеративних підходів.
Scrum — фреймворк Agile з ролями, артефактами й подіями (спринти).
Kanban — гнучкий підхід із візуалізацією потоку робіт та обмеженням WIP.
Гібридний підхід — поєднання предиктивних віх та ітеративної розробки.
RAID-log — журнал ризиків, припущень, проблем і залежностей.
Scope — обсяг проєкту; in/out of scope — що входить і не входить.
Scope creep — «розповзання» обсягу без перегляду строків і ресурсів.
Критичний шлях — найдовший ланцюг залежних робіт, що визначає строк проєкту.
Effort estimation — оцінка трудовитрат проєкту.

Додаток 6. Приклад заповненого RAID-log (для проєкту впровадження ІКС)

№	Тип	Опис	Власник	Статус / реагування
1	R	Затримка погодження ТЗ органом ЗІ.	PM	Активний. Ранній старт узгодження, запас часу.
2	A	Припущення: підрядник надасть тестове середовище до 1 числа.	PM	Перевіряється; за невиконання — стане Issue.
3	I	Немає доступів у 2 користувачів пілоту.	DT Lead	Відкритий. Запит доступів надіслано.
4	D	Залежність від міграції даних із паперового обліку.	BA	Заплановано; блокує старт пілоту.