Застосування CLD для оптимізації Lead Time

Нос, Аліна Андріївна

Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/7036

Title:	Застосування CLD для оптимізації Lead Time
Authors:	Прокопенко , Тетяна Олександрівна Нос, Аліна Андріївна
Keywords:	CLD модель;Lead Time;ІТ проєкт;розробка;оптимізація
Issue Date:	17-Dec-2025
Abstract:	В умовах швидкої еволюції IT-індустрії та високої конкуренції на ринку розробки програмного забезпечення одним із ключових показників ефективності проєктів стає Lead Time — загальний час від моменту ініціації задачі до її реалізації в готовий продукт. Оптимізація Lead Time безпосередньо впливає на швидкість виведення продукту на ринок, гнучкість команди та рівень задоволення клієнтів. Традиційні підходи до скорочення Lead Time, такі як збільшення кількості розробників, прискорення окремих етапів чи запровадження додаткових контрольних точок, часто дають лише короткостроковий ефект. Вони не враховують складних взаємозв’язків між елементами системи — комунікаціями, якістю, навантаженням, помилками, навчанням персоналу тощо. Як наслідок, такі рішення можуть призводити до зворотного ефекту — зростання часу узгодження, кількості дефектів або втрати мотивації команди. Для вирішення цієї проблеми необхідний системний підхід, який дозволяє виявити кореневі причини затримок, а не лише їхні зовнішні прояви. Одним з ефективних інструментів такого аналізу є Causal Loop Diagram (CLD) — причинно-наслідкова діаграма, що візуалізує взаємозалежності між факторами у вигляді зворотних зв’язків. Її застосування дозволяє не лише описати, а й пояснити поведінку складних систем, зокрема процесів розробки в IT-проєктах.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/7036
Appears in Collections:	126 Інформаційні системи та технології (IT Project Management)

Files in This Item:

File	Description	Size	Format
РЕП_МАГ_Нос_МІТ-2411.pdf Restricted Access		1.36 MB	Adobe PDF	View/Open Request a copy

Show full item record

Extracted text

1

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ ПРОЄКТУВАННЯ

ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи магістра
на тему: Застосування CLD для оптимізації Lead Time.

Виконала здобувачка другого
(магістерського) рівня вищої освіти
__2___курсу, групи МІТ2411
Спеціальності 126 Інформаційні системи та
технології
ОП «IT Project Management»
Нос Аліна Андріївна
Керівник: завідувач кафедри ІТП, д.т.н.,
проф. Прокопенко Тетяна Олександрівна
Рецензент: Директор ТОВ «Андерсенлаб»
Алесін О.В.

Черкаси 2025 року

2

ЗМІСТ

ВСТУП 3
РОЗДІЛ I Теоретичні основи управління Lead Time та системного аналізу 7
1.1. Поняття та значення Lead Time у процесах розробки продуктів 7
1.2 Фактори, що впливають на Lead Time у IT-проєктах 9
1.3. Системний аналіз як інструмент аналізу динаміки процесів 13
1.4. Причинно-наслідкові діаграми (CLD) як засіб виявлення кореневих причин
затримок 14
РОЗДІЛ II Аналіз процесу розробки та побудова CLD-моделі досліджуваного IT-
проєкту 17
2.1. Характеристика досліджуваного проєкту та об’єкта моделювання 18
2.2. Аналіз поточного процесу: типові вузькі місця та симптоми затримок 19
2.3. Виявлення основних причин затримок за допомогою CLD-моделі поточного
стану 21
2.4. Роль когнітивних викривлень у формуванні управлінських рішень та
важливість колективного моделювання CLD 24
2.5. Типові системні архетипи як інструмент побудови гіпотез для первинної
діагностики поведінки Lead Time 29
2.6 Проєктний контекст та підготовка до системного аналізу 38
2.7. Побудова базової CLD-моделі поточного стану досліджуваного IT-проєкту 42
РОЗДІЛ IІI Оцінювання ефективності та оптимізація системної моделі Lead Time 49
3.1. Побудова оптимізованої CLD-моделі Lead Time 49
3.2. Аналіз сценаріїв розвитку системи: поточний стан vs оптимізована модель 52
3.3. Порівняння поведінки двох команд у реальних умовах 54
3.4. Виявлення точок важеля для зменшення Lead Time 59
3.5. Рекомендації щодо впровадження оптимізованої моделі (з інтеграцією моделі
Коттера) 61
ВИСНОВКИ 67
3

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 70
4

ВСТУП
В умовах швидкої еволюції IT-індустрії та високої конкуренції на ринку
розробки програмного забезпечення одним із ключових показників ефективності
проєктів стає Lead Time — загальний час від моменту ініціації задачі до її реалізації
в готовий продукт. Оптимізація Lead Time безпосередньо впливає на швидкість
виведення продукту на ринок, гнучкість команди та рівень задоволення клієнтів.
Традиційні підходи до скорочення Lead Time, такі як збільшення кількості
розробників, прискорення окремих етапів чи запровадження додаткових контрольних
точок, часто дають лише короткостроковий ефект. Вони не враховують складних
взаємозв’язків між елементами системи — комунікаціями, якістю, навантаженням,
помилками, навчанням персоналу тощо. Як наслідок, такі рішення можуть
призводити до зворотного ефекту — зростання часу узгодження, кількості дефектів
або втрати мотивації команди.
Для вирішення цієї проблеми необхідний системний підхід, який дозволяє
виявити кореневі причини затримок, а не лише їхні зовнішні прояви. Одним з
ефективних інструментів такого аналізу є Causal Loop Diagram (CLD) — причинно-
наслідкова діаграма, що візуалізує взаємозалежності між факторами у вигляді
зворотних зв’язків. Її застосування дозволяє не лише описати, а й пояснити поведінку
складних систем, зокрема процесів розробки в IT-проєктах.
Отже, актуальність теми визначається необхідністю застосування в
проєктному менеджменті системного аналізу та інструментів моделювання для
глибшого розуміння динаміки Lead Time і вибору оптимальних рішень з метою
скорочення без порушення стабільності всієї системи.
Мета дослідження – розробити та продемонструвати застосування причинно-
наслідкової діаграми (CLD) для аналізу та оптимізації Lead Time у процесах розробки
програмного забезпечення з урахуванням системних взаємозв’язків між ключовими
чинниками.
Для досягнення поставленої мети були сформульовані та вирішені такі завдання
дослідження:
5

1. Проаналізувати сутність поняття Lead Time та основні чинники, що
впливають на його тривалість у IT-проєктах.
2. Дослідити обмеження традиційних методів скорочення Lead Time і
визначити потребу в системному підході.
3. Ідентифікувати ключові змінні та взаємозв’язки, які формують динаміку Lead
Time.
4. Побудувати базову CLD-модель поточного стану системи управління часом.
5. Розробити оптимізовану CLD-модель для зменшення Lead Time без
зростання навантаження чи погіршення якості.
6. Провести порівняльний аналіз ефективності традиційних і системних
підходів.
7. Сформулювати рекомендації щодо впровадження системного підходу до
управління Lead Time у практиці IT-проєктів.
Об’єкт дослідження – процес управління часом (Lead Time) у життєвому циклі
IT-проєкту.
Предмет дослідження – причинно-наслідкові зв’язки між ключовими
факторами, що впливають на динаміку Lead Time, та методи їх оптимізації за
допомогою CLD-моделювання.
Методи дослідження.
У роботі застосовано методи системного аналізу, системної динаміки,
моделювання причинно-наслідкових зв’язків (CLD), аналіз метрик поставки цінності
(Actionable Agile), а також порівняльний та логіко-аналітичний аналіз. Для побудови
моделей можуть використовуватися інструменти Miro або draw.io.
Наукова новизна отриманих результатів полягає у використанні системного
аналізу при моделюванні причинно-наслідкових зв’язків, що дозволяє системно
оцінити вплив управлінських рішень на всіх ланках на Lead Time, виявити нелінійні
зворотні зв’язки між змінними та довести, що прості рішення не завжди призводять
до зменшення тривалості розробки.
6

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

7

РОЗДІЛ I Теоретичні основи управління Lead Time та системного аналізу
1.1. Поняття та значення Lead Time у процесах розробки продуктів
У сучасних ІТ-проєктах ключовими метриками, що характеризують швидкість
та ефективність розробки, є показники, пов’язані з часом виконання процесів. До
найпоширеніших належать Lead Time, Cycle Time, Time to Market та Value Flow.
Незважаючи на їхню схожість, кожен із цих показників має власну аналітичну роль і
застосовується для різних рівнів оцінки ефективності.
Lead Time визначається як проміжок часу від моменту ініціації замовлення або
створення запиту до моменту його повного виконання та доставки кінцевому
користувачу [1]. Це комплексний показник, який охоплює весь ланцюг створення
цінності — від першої взаємодії із замовником до моменту, коли продукт або зміна
стають доступними користувачу.
У загальному вигляді Lead Time складається з трьох основних частин:
● підготовчої (pre-processing time), що включає узгодження, планування,
постановку задачі;
● виробничої (processing time) — безпосереднє виконання роботи;
● завершальної (post-processing time), що охоплює тестування, впровадження,
доставку або приймання результатів [2].
Показник Lead Time застосовується для оцінки ефективності процесів на рівні
всієї системи. Його скорочення безпосередньо впливає на швидкість поставки
цінності клієнтам, конкурентоспроможність організації та стабільність процесів
розробки.
Lead Time часто використовують як ключовий показник ефективності процесу
від запиту до доставки кінцевого результату. Він дозволяє бачити загальні затримки,
“вузькі місця” не лише в межах одного етапу, а в межах усієї системи. Також
скорочення Lead Time — одна з цілей підвищення гнучкості,
конкурентоспроможності та задоволеності клієнтів.
Cycle Time — це середній час, необхідний для виконання однієї одиниці роботи
від моменту її початку до завершення [3]. На відміну від Lead Time, Cycle Time
8

вимірює лише активний період розробки без урахування часу підготовки рішення
перед розробкою, а іноді і після, коли рішення вже готове, але ще не є доступним для
кінцевих користувачів. Наприклад, коли рішення вже поставлене на середовище,
проте ще не включене за допомогою feature flags.
У виробничих і сервісних системах Cycle Time є показником операційної
ефективності — він демонструє, скільки часу команда витрачає на виконання
конкретного етапу процесу, наприклад розробки. Високе значення Cycle Time
зазвичай свідчить про перевантаження, недостатню автоматизацію або неефективний
розподіл ресурсів [4].
Таким чином, Cycle Time використовується переважно для локального аналізу
процесів, тоді як Lead Time відображає повну динаміку системи від запиту до
результату.
Термін Value Flow (потік цінності) описує шлях, який проходить запит або
потреба клієнта до моменту створення кінцевої цінності. У методології Lean цей
процес моделюється за допомогою Value Stream Mapping — інструменту, що
відображає послідовність дій, включаючи матеріальні та інформаційні потоки, з
метою виявлення втрат і неефективностей [5].
Потік цінності дозволяє візуалізувати, де саме в системі виникають затримки,
дублювання дій чи непотрібні очікування. Таким чином, Value Flow створює основу
для аналізу Lead Time як інтегрального показника всієї системи поставки.
Порівняння цих термінів представлене в Таблиці 1.1.

Таблиця 1.1 – Порівняння показників і обґрунтування вибору Lead Time
Показник Що вимірює Охоплення Переваги Обмеження
процесу
Lead Повний час від Від початку і до Дає змогу Складно
Time запиту до кінця бачити системні визначити межі
доставки затримки, вимірювання
результату охоплює
9

зовнішні
фактори
Cycle Активний час Окремий етап Добре підходить Не враховує час
Time виконання процесу для локальної очікування та
роботи оптимізації узгоджень
Value Потік Від початку і до Допомагає Не є прямою
Flow створення кінця знаходити часовою
цінності втрати в системі метрикою
З огляду на наведене, Lead Time обрано основним показником у цьому
дослідженні, оскільки він дає змогу охопити повний ланцюг створення цінності — від
моменту формування потреби до її задоволення. Саме такий підхід є необхідним у
системному аналізі, коли причини затримок можуть перебувати за межами окремих
операцій або підпроцесів, які вимірюються через Cycle Time.
Таким чином, дослідження Lead Time дозволяє виявити глибинні
закономірності, які впливають на загальну ефективність поставки цінності, і створює
підґрунтя для побудови причинно-наслідкових моделей (CLD), що відображають
поведінку всієї системи.
1.2 Фактори, що впливають на Lead Time у IT-проєктах
Тривалість Lead Time у проєктах розробки програмного забезпечення залежить
від безлічі взаємопов’язаних факторів. На практиці це не лише питання кількості
людей або ресурсів, а ціла система взаємодій між командою, процесами, технологіями
й організаційною культурою. Розглянемо основні групи факторів, які найчастіше
впливають на швидкість поставки цінності в IT-проєктах.
Ресурсні фактори визначають доступність та ефективність використання
засобів, необхідних для виконання проєкту. До них належать:
● кількість і кваліфікація персоналу, що безпосередньо впливає на
продуктивність та швидкість виконання завдань;
10

● наявність фінансових ресурсів, які забезпечують безперервність процесів
розробки, тестування та впровадження;
● доступність технічних засобів, середовищ розробки, серверних потужностей та
ліцензійного програмного забезпечення;
● ефективність розподілу ресурсів між паралельними задачами та командами, що
часто визначає рівень перевантаження системи.
Недостатність будь-якого з цих елементів створює затримки у ланцюгу «запит
– результат», подовжуючи загальний Lead Time [6].
Фактори стану та взаємодії команди, а саме людський фактор є одним із
ключових у формуванні загальної тривалості розробки. Основними чинниками тут
виступають:
● мотивація і психологічний клімат у команді, що впливають на продуктивність і
стабільність темпу роботи;
досвід спільної роботи, наявність узгоджених комунікаційних практик (модель
Такмана [7]);
● рівень комунікації між учасниками різних ролей (розробники, тестувальники,
аналітики, менеджери);
● рівень залученості команди у процес прийняття рішень;
● ступінь текучості кадрів, що часто викликає втрату знань і затримки під час
адаптації нових працівників.
Команди з високим рівнем довіри, зрілими процесами взаємодії та чітким
розподілом ролей зазвичай демонструють менший Lead Time навіть за умов
обмежених ресурсів [8].
До організаційних чинників належать аспекти структури управління та культури
прийняття рішень у компанії:
● тип організаційної структури (матриці) — функціональна, проєктна або
матрична;
● ступінь централізації управління: надмірна ієрархія подовжує цикли ухвалення
рішень;
11

● чіткість процесів погодження та пріоритезації завдань;
● гнучкість організаційної політики — здатність оперативно адаптуватися до змін
ринку чи вимог замовника;
● наявність зрілої системи управління знаннями.
Неефективна організаційна структура може призвести до бюрократичних
затримок, непорозумінь між підрозділами та дублювання функцій, що прямо впливає
на збільшення Lead Time [9].
Процесні фактори. Ця група охоплює методологічні та управлінські аспекти
проєкту:
● вибір методології управління (Waterfall, Agile, Scrum, LeSS, SAFe тощо) та її
відповідність типу проєкту;
● наявність та якість вимог (quality of requirements);
● частота зміни пріоритетів та обсягу робіт;
● ефективність контролю якості та інтеграційного тестування;
● наявність автоматизації CI/CD-процесів;
● ступінь зрілості процесів управління ризиками.
Процеси з низькою стандартизацією або відсутністю автоматизації призводять
до зростання затримок між етапами, перевірками та узгодженнями, що суттєво
подовжує Lead Time [10].
До технічних факторів належать характеристики інструментів, інфраструктури
та архітектури системи:
● складність архітектури програмного продукту;
● ступінь технічного боргу;
● продуктивність середовища розробки та тестування;
● якість інтеграційних рішень;
● рівень автоматизації розгортання (deployment).
Технічні обмеження часто мають кумулятивний ефект: зниження швидкодії,
помилки інтеграції та неузгоджені інтерфейси створюють зворотні зв’язки, які
поступово збільшують час виконання всього циклу.
12

Окрім внутрішніх чинників, на Lead Time можуть впливати фактори
зовнішнього середовища:
● зміни ринкових умов або політики замовника;
● нестабільність економічного середовища;
● зміни у законодавстві (наприклад, регуляції з кібербезпеки чи захисту
персональних даних);
● залежність від зовнішніх постачальників або інтеграційних сервісів.
Такі фактори є частково або повністю неконтрольованими, але їхній вплив
можна мінімізувати завдяки проактивному плануванню, гнучкому управлінню
ризиками та використанню сценарного моделювання [11].
Lead Time у ІТ-проєктах формується під впливом множини взаємопов’язаних
чинників, серед яких ключову роль відіграють якість процесів, ефективність команди,
тип організаційної структури та технічна зрілість системи. Для системного аналізу
важливо розглядати ці фактори не ізольовано, а як частини єдиної динамічної
системи, у якій взаємодіють прямі та зворотні зв’язки. Саме тому в подальших
розділах буде застосовано причинно-наслідкове моделювання (CLD) для виявлення
впливу цих факторів на загальний Lead Time.
1.3. Системний аналіз як інструмент аналізу динаміки процесів
Сучасні процеси розробки програмного забезпечення стають усе складнішими.
Вони охоплюють не лише технічні етапи, а й управлінські, комунікаційні,
організаційні та людські чинники. Кожен із них впливає на інші, створюючи
заплутану мережу взаємозалежностей. Через це звичайні лінійні методи аналізу, які
спираються на прості причинно-наслідкові зв’язки, часто не дають змоги зрозуміти
справжню природу проблеми. Саме тут стає корисним системний аналіз.
Системний аналіз — це підхід, який дозволяє розглядати будь-який процес або
організацію як цілісну систему, де всі елементи взаємодіють між собою. Він
зосереджується не на окремих частинах, а на зв’язках між ними — на тому, як зміна
одного компонента впливає на інші. Такий підхід допомагає побачити не лише
13

безпосередні наслідки рішень, але й довгострокові ефекти, що часто проявляються
через певний час.
У контексті управління IT-проєктами системний аналіз дає змогу аналізувати
поведінку процесів у динаміці. Наприклад, збільшення кількості розробників у
команді може тимчасово підвищити швидкість роботи, але згодом призвести до
проблем із комунікацією, узгодженням коду чи тестуванням. У результаті загальний
Lead Time не зменшується, а навпаки — зростає [12]. Лише системний підхід дозволяє
побачити такі нелінійні взаємозв’язки.
системний аналіз також допомагає відрізнити симптоми проблеми від її
справжніх причин. Якщо команда постійно не вкладається в терміни, можна зробити
висновок, що слід покращити планування. Але корінна причина часто лежить глибше
— у надмірному навантаженні, нечіткому розподілі ролей або в комунікаційних
бар’єрах між командами. Без системного підходу такі речі залишаються
прихованими.
Одним із найважливіших інструментів системного аналізу є причинно-
наслідкова діаграма (Causal Loop Diagram, CLD) [13]. Вона дозволяє візуально
показати, як змінні впливають одна на одну в межах системи. Наприклад, збільшення
кількості задач підвищує навантаження на команду, що знижує якість роботи, а
більша кількість помилок створює ще більше задач. Так формується замкнене коло,
або підсилювальна петля, яка в системному моделюванні позначається символом R
(reinforcing). Балансуючі петлі (B) мають протилежний ефект — вони стабілізують
систему [14], наприклад, через контроль якості або обмеження WIP (Work in Progress).
Ми розглянемо приклади таких діаграм детальніше в Розділі 2.
Системний аналіз дозволяє:
● бачити повну картину процесів, а не лише окремі етапи;
● знаходити «точки важеля» — місця, де невелика зміна дає великий
результат;
● прогнозувати наслідки управлінських рішень у довгостроковій
перспективі;
14

● уникати типових помилок локальної оптимізації, коли покращення однієї
ділянки шкодить усій системі.
Управління IT-проєктами з використанням системного аналізу допомагає
перейти від короткострокових рішень до стратегічного бачення процесу. Це дає змогу
зосередитись не на «гасінні пожеж», а на усуненні їхніх причин, підвищуючи загальну
стабільність і передбачуваність розробки.
Таким чином, системний аналіз є ефективним інструментом аналізу динаміки
процесів, оскільки дозволяє виявити складні взаємозв’язки, що визначають поведінку
всієї системи, а не лише окремих її частин. Саме завдяки такому підходу можна
будувати більш реалістичні моделі управління Lead Time та прогнозувати наслідки
управлінських рішень ще до їхнього впровадження.
1.4. Причинно-наслідкові діаграми (CLD) як засіб виявлення кореневих причин
затримок
Будь-яка система, зокрема система управління розробкою програмного
забезпечення, складається з багатьох взаємопов’язаних елементів. Зміна одного з них
неминуче впливає на інші, але наслідки таких змін не завжди очевидні. Часто вони
проявляються із затримкою або у зовсім іншій частині процесу [15]. Саме для
виявлення подібних взаємозв’язків використовується інструмент CLD (Causal Loop
Diagram) — причинно-наслідкова діаграма.
Причинно-наслідкова діаграма відображає, як окремі змінні впливають одна на
одну, утворюючи замкнені цикли — петлі зворотного зв’язку [16]. Такий підхід
дозволяє не лише описати певну подію, а й зрозуміти справжню природу її
виникнення та ті довготривалі наслідки, які вона може спричинити. Завдяки цьому
CLD дає змогу виявити приховані механізми поведінки системи, які рідко
проглядаються при використанні лінійних методів аналізу.
У побудові CLD змінні з’єднуються стрілками, що позначають напрямок та
характер впливу.
● Якщо зміна однієї змінної призводить до зміни іншої в тому ж напрямку, то
використовується лише стрілка, або ж знак (+).
15

● Якщо зміна має протилежний ефект — на стрілку додається позначна “О”, від
англійскього “Opposite”, тобто “Зворотній”, або ж знак (-).
Коли ці зв’язки утворюють замкнений контур, виникає петля зворотного
зв’язку [17].
Підсилювальні петлі (R) сприяють накопиченню або прискоренню процесу, тоді як
балансуючі петлі (B) стабілізують систему, зменшуючи різкі коливання або надмірне
зростання [18].
У реальних IT-проєктах затримки рідко мають одну очевидну причину.
Найчастіше це результат взаємодії кількох чинників, що посилюють або компенсують
один одного. Наприклад, коли команда отримує вимогу розробляти швидше,
навантаження зростає, а якість роботи падає. Зниження якості породжує нові
помилки, які збільшують обсяг роботи, створюючи підсилювальну петлю. Спроба
«вирішити» проблему через додавання нових розробників може призвести до
погіршення ситуації через витрати на навчання та координацію, що створює нові
затримки. Візуалізуємо це через CLD на Зображенні 1.1.

Зображення 1.1 - CLD, яка відображає, як тиск на розробників впливає на успіх
бізнесу.
16

CLD дозволяє побачити такі складні взаємозв’язки та зрозуміти, чому деякі
управлінські рішення, які здаються логічними, не дають бажаного результату або
навіть погіршують ситуацію. Завдяки системному підходу стає можливою
ідентифікація саме кореневих причин затримок, а не лише поверхневих проявів
проблеми.
Таким чином, причинно-наслідкові діаграми є важливим інструментом для
моделювання динаміки процесів і прогнозування наслідків рішень. Вони дозволяють
розглядати Lead Time у широкому системному контексті й оцінювати, як взаємодіють
між собою фактори, що впливають на його збільшення або зменшення. У подальших
розділах моделювання на основі CLD буде використано для побудови причинно-
наслідкової структури Lead Time та визначення ключових важелів оптимізації
процесів розробки.
17

РОЗДІЛ II Аналіз процесу розробки та побудова CLD-моделі досліджуваного
IT-проєкту
2.1. Характеристика досліджуваного проєкту та об’єкта моделювання
У межах цього дослідження об’єктом моделювання виступає реальний
програмний продукт, який проходить активну фазу розвитку. Особливість цього
випадку полягає в тому, що первинно продукт мав єдину кодову базу, працював як
цілісне рішення та розроблявся спільною командою. Це створює важливу перевагу
для аналізу — обидві гілки розвитку мають однакову стартову точку, що дозволяє
коректно порівнювати подальші зміни в динаміці Lead Time.
Згодом продукт було розділено на два незалежні підпродукти, кожен з яких
отримав власну команду розробки. Хоча кодова база залишається спільною, кожна
команда відповідає за свою лінійку функціональності та приймає рішення автономно.
Це природно створює різні підходи до організації роботи, планування та управління
навантаженням — а відповідно і різні траєкторії зміни Lead Time.
У межах магістерського дослідження ми пропонуємо порівняти роботу цих
двох команд за різними сценаріями:
● Перша команда використовуватиме підхід системного аналізу. Тобто ми
збудуємо причинно-наслідкову діаграму (CLD), проаналізуємо фактори, що
формують Lead Time, і знайдемо точки впливу, які дозволяють оптимізувати
процес у довгостроковій перспективі.
● Друга команда працюватиме у звичному режимі. Рішення щодо оптимізації
процесів прийматимуться менеджментом на основі практичного досвіду, без
використання системної моделі та без дослідження зворотних зв’язків.
Такий підхід дозволяє створити порівняльну рамку, у якій дві команди з
максимально подібною вихідною позицією демонструють різні результати через
відмінність у методах управління. Це дає можливість оцінити реальний внесок
системного аналізу у скорочення Lead Time.
18

Ще однією важливою частиною початкового аналізу стане фіксація “точки
відліку” — стану продукту та команди до їхнього розділення. Для цього будуть
використані дані з Actionable Agile (плагіну для аналітики в Jira), що відображають:
● середній Lead Time на момент розділення команди,
● час у роботі на різних стадіях.
Таке документування дає змогу не лише порівняти результати двох команд у
майбутньому, а й забезпечити прозорість дослідження — вихідні умови зафіксовані
та однакові для обох сценаріїв.
Таким чином, об’єктом моделювання виступає не лише сам продукт, а й
організаційна динаміка двох команд, що походять від одного початкового процесу
розробки. Це створює унікальну можливість простежити вплив системного аналізу на
реальний процес розробки, порівнюючи його з традиційним менеджерським
підходом.
2.2. Аналіз поточного процесу: типові вузькі місця та симптоми затримок
Перед розділенням команди на два підпродукти було проведено аналіз
поточного процесу розробки. Це дозволило зафіксувати реальний стан системи,
визначити основні затримки та зрозуміти, які чинники найбільше впливають на
формування Lead Time. Аналіз проводився за даними останніх трьох спринтів (кожен
тривалістю два тижні), із врахуванням лише бізнес-днів.
Метою оцінки було не лише визначити середній час проходження задач через
кожен статус, але й виявити ті етапи, які створювали найбільші черги та
уповільнювали загальний потік роботи.
Таблиця 2.1 – Середній час перебування задач у статусах перед розділенням
команди

Статус процесу Середній час (бізнес-дні)
Backlog 10 днів
In Business Analysis 33 дні
19

Ready for Dev 10 днів
To do 7 днів
In progress 2 дні
Code Review 1 день
Ready for testing 1 день
Testing 2 дні
Ready for release 7 днів
Done -

Розрахунок Lead Time
Середній Lead Time до розділення команди становив:
10 + 33 + 10 + 7 + 2 + 1 + 1 + 2 + 7 = 73 бізнес-дні.
Тобто в середньому задачі проходили весь цикл приблизно за 73 дні, або
близько 3,5 місяці реального часу. Це досить великий показник, тому важливо
зрозуміти, де саме виникали найбільші затримки.
Вузькі місця та симптоми затримок:
1. Етап Business Analysis (33 дні)
Це найбільша затримка у всьому процесі. І ключовою причиною є недостатня
кількість бізнес-аналітиків у команді. На проєкті працював лише один бізнес-
аналітик, тоді як за оцінкою менеджменту, оптимальною кількістю для такої команди
та такого обсягу задач були б три аналітики. Це означає, що BA-вузьке місце було
системним та прогнозованим.
Через перевантаження аналітика виникали такі симптоми:
● накопичення великого обсягу задач у BA,
● затримки у деталізації та уточненні вимог,
● необхідність постійно перемикатися між темами,
20

● залежність від зовнішніх стейкхолдерів, яку не було кому розподілити.
У результаті BA етап фактично «визначав» мінімальний можливий Lead Time,
тому будь-які оптимізації на інших стадіях не могли суттєво вплинути на загальний
час поставки.
2. Ready for Release (7 днів)
Затримка на цьому етапі пов’язана з релізною політикою — реліз відбувався раз
на спринт. Це створювало чергу задач, які фактично були завершені, але не могли
бути доставлені раніше. Тут також є місце для оптимізації, але сокільки саме ВА етап
визначає мінімальний можливий Lead Time, було прийнято рішення поки не
фокусуватись на оптимізації цього етапу.
На момент збору даних команда мала такий склад:
● Product Owner,
● 1 Business Analyst (при визначеній потребі у 3),
● розробники та тестувальники.
Саме недостатня кількість бізнес-аналітиків та надмірне навантаження на BA-
етап стали основним чинником, що визначав загальну швидкість проходження задач.
Це створило базис для подальших моделей у розділі 3, де системний аналіз допоможе
показати, як подібні дисбаланси впливають на Lead Time та які петлі зворотного
зв’язку формуються у таких ситуаціях, а також перевірити, чи гапотеза менеджменту
про додавання більшої кількості ВА на проєкт виправить ситуацію.
2.3. Виявлення основних причин затримок за допомогою CLD-моделі
поточного стану
Аналіз часових показників у попередньому підрозділі показав, що найбільші
затримки у процесі виникали на етапі опрацювання вимог, тобто у статусі In BA. Саме
там задачі проводили в середньому понад місяць, що суттєво впливало на загальний
Lead Time. Щоб зрозуміти, чому виникає така диспропорція і як вона впливає на
подальший перебіг задач у процесі розробки, доцільно розглянути систему у
взаємозв’язках.
21

Причинно-наслідкові діаграми (CLD) дозволяють побачити не лише окремі
етапи, а й те, як вони впливають один на одного, формуючи ланцюги зв’язку.
Особливо це важливо у випадках, коли затримки не є прямим наслідком однієї події,
а виникають через взаємодію кількох чинників. Саме такою і є ситуація з BA-вузьким
місцем.
На момент аналізу в команді працював лише один бізнес-аналітик, хоча за
оцінкою менеджменту для стабільного потоку задач потрібно було щонайменше троє.
Це створювало постійне перевантаження, через яке BA-фаза не встигала обробляти
вхідні задачі швидше, ніж вони надходили. У результаті утворювалась черга, яка з
часом лише зростала.
Для того щоб краще показати, як нестача аналітичного ресурсу впливала на
загальну швидкість проходження задач, у цьому підрозділі представлена CLD-модель
поточного стану (Зображення 2.1). Вона демонструє ключові взаємозв’язки між
кількістю нових задач, навантаженням на бізнес-аналітика, швидкістю опрацювання
вимог та загальною швидкістю поставки нових функціональних можливостей
користувачам.

Зображення 2.1 - CLD, яка відображає базове бачення процесу зі сторони
менеджменту.
22

Представлена причинно-наслідкова схема відображає логічний ланцюг, через
який менеджмент команди пояснював собі зростання Lead Time. У цій моделі
збільшення кількості нових задач призводить до підвищення навантаженості на
бізнес-аналітика, що, у свою чергу, знижує швидкість опрацювання вимог. Це
впливає на темп поставки нових можливостей користувачам, а далі — і на рівень
їхнього задоволення. Такий ланцюг виглядає логічним і послідовним, тому він часто
сприймається як повноцінне пояснення того, звідки виникають затримки.
Водночас важливо підкреслити, що цей фрагмент CLD не формує завершеної
петлі зворотного зв’язку. Це скоріше лінійне уявлення про причинність, а не
системний опис поведінки потоку робіт. На цьому етапі модель показує лише те, як
менеджмент бачив проблему, ґрунтуючись на власному досвіді та припущеннях.
У подальших розділах буде розглянуто, чому таке «ментальне моделювання»
може містити упередження (баяси) і чому воно не завжди точно відображає реальну
поведінку системи. Для отримання достовірнішої моделі та виявлення реальних
причин затримок важливо залучати до побудови CLD всіх учасників процесу — від
бізнес-аналітиків до розробників і тестувальників. Лише спільна робота дає змогу
відтворити повну картину взаємозв’язків та виявити ті петлі, які залишаються
прихованими при суто управлінському погляді.
2.4. Роль когнітивних викривлень у формуванні управлінських рішень та
важливість колективного моделювання CLD
Під час аналізу поточного стану процесу та спроб зрозуміти причини затримок
у розробці часто виникає ситуація, коли менеджмент або окремі учасники команди
мають власне уявлення про те, що саме призводить до збільшення Lead Time [19].
Такі уявлення формуються на основі особистого досвіду, суб’єктивного
спостереження або інтерпретації окремих подій. Проте вони не завжди відображають
реальну поведінку системи, адже людське мислення природно схильне до
когнітивних викривлень — так званих «баясів».
Баяс — це систематична помилка мислення, яка призводить до хибних
висновків або неправильних рішень, навіть коли людина впевнена у своїй
23

об’єктивності. В управлінні IT-проєктами такі викривлення виникають дуже часто,
адже команди працюють у складних умовах, де немає прямого та очевидного
причинно-наслідкового зв’язку між подіями [20].
Найбільш характерними для контексту управління IT-проєктами є такі типи
викривлень:
1. Ефект спрощеної причинності (simplicity bias)
Менеджер може припустити, що один фактор є головною причиною проблеми
(наприклад, «низька швидкість розробників»), хоча реальна причина може бути у
зовсім іншій частині системи — у вимогах, комунікації чи незбалансованому потоці
задач. Такий підхід ігнорує складність системи та зводить її до одного лінійного
пояснення [21].
2. Підтверджувальне упередження (confirmation bias)
Люди схильні звертати увагу на факти, які підтверджують їхні початкові
переконання, і не помічати ті, що їм суперечать [22]. Наприклад, менеджмент може
відзначати випадки, коли збільшення кількості розробників «прискорило» роботу,
ігноруючи ситуації, коли це призвело до хаосу чи зростання кількості помилок.
3. Надмірна впевненість (overconfidence)
Рішення часто ухвалюються на основі досвіду чи інтуїції, а не на основі
системного аналізу даних [23]. Це створює ілюзію контролю: «ми вже проходили це
раніше, отже знаємо, як правильно». Але у складних системах однакові на вигляд
ситуації можуть мати різні причини.
4. Помилка доступності (availability heuristic)
Люди переоцінюють значення подій, які добре запам’ятались або сталися
нещодавно [24]. Наприклад, якщо минулого місяця затримка виникла у тестуванні,
менеджмент може «призначити» тестування основним вузьким місцем, хоча
історичні дані показують, що найбільші затримки були у BA.
5. Фундаментальна помилка атрибуції
Тенденція пояснювати проблеми поведінкою окремих людей, а не структурою
системи [25]. У розробці це часто проявляється у фразах «розробники повільно
24

працюють» чи «аналітик не встигає», хоча системні причини можуть бути зовсім
інші: перевантаження, брак ролей, нерівномірність потоку задач.
Початкова причинно-наслідкова модель, яку сформував менеджмент
(Зображення 2.1), виглядала логічною та простою: збільшення кількості задач
створює навантаження на бізнес-аналітика, що призводить до зростання Lead Time.
На перший погляд, така конфігурація відображає очевидний зв’язок між обсягом
роботи та пропускною здатністю ролей. Однак аналіз показав, що модель була
надмірно спрощеною і не враховувала важливих факторів, які визначали реальну
поведінку системи. Це спрощення було зумовлене низкою когнітивних викривлень,
що вплинули на те, як менеджмент інтерпретував дані та формував гіпотези про
природу затримок у процесі.
Нижче надано ключові викривлення та те, як саме вони проявилися в
управлінському мисленні при досліджуванні IT-проєкту, демонструючи чому CLD-
модель повинна будуватись з усіма учасниками процесу.
1. Підтверджувальне упередження (confirmation bias). Одним із найпомітніших
викривлень у побудові початкової моделі був ефект підтвердження —
схильність шукати та інтерпретувати дані таким чином, щоб вони
підтверджували вже існуючу гіпотезу [26]. Менеджмент виходив із
припущення, що тривалий етап Business Analysis є прямим наслідком браку
BA-ресурсу. Тому будь-які дані, які вказували на завантаження аналітика,
сприймалися як доказ правильності цього припущення. У результаті інші
можливі пояснення — наприклад, недостатня участь розробників у
декомпозиції, погано структуровані вимоги, велика частка повернень через
неясності або загальна відсутність прозорих стандартів аналізу — залишалися
поза увагою. Наявність черги в BA не аналізувалася як структурне явище, а
лише як недостатність одного ресурсу. Це визначило лінійну форму початкової
моделі, яка відображала не поведінку системи, а попередні очікування
керівництва.
25

2. Ефект спрощеної причинності (Simplicity Bias). Менеджмент прагнув подати
процес у максимально простій формі, що призвело до використання
спрощуючих евристик. Через це складний процес аналізу був зведений до
кількох змінних: «кількість задач», «завантаження BA» та «Lead Time». Хоча
така модель є зручною для комунікації, вона ігнорує динаміку зворотних
зв’язків, накопичення помилок та вплив компетентностей команди [27].
Спрощення спричинило те, що процес розробки розглядався як лінійна
послідовність, де кожен учасник передає роботу наступному. Сама природа
нелінійності — наприклад, повторні уточнення, зворотній зв’язок між етапами
або накопичення технічного та аналітичного боргу [28] — не була включена в
модель. Внаслідок цього рішення «додати ще одного BA» стало видаватися
логічним і достатнім кроком, хоча насправді воно змінювало лише локальну
пропускну здатність і не впливало на фундаментальні проблеми потоку.
3. Хибна причинність (Illusory Causation) — це когнітивне викривлення, за якого
людина помилково сприймає кореляцію або одночасність подій як доказ
прямого причинно-наслідкового зв’язку між ними [29]. Менеджмент
спостерігав, що задачі довго перебувають у статусі In BA, і робив висновок, що
саме цей етап є причиною затримок. Це типове викривлення хибної
причинності — коли кореляція сприймається як прямий причинний зв’язок
[30]. Фактично ж довгий час у статусі In BA був не причиною, а симптомом
поведінки системи: задачі передавалися на аналіз у недостатньо готовому
стані, розробники не брали участь у структуруванні вимог, а симптоматичні
рішення створювали повторні цикли уточнення. Хибна причинність призвела
до того, що маніпуляції з пропускною здатністю BA-ролі сприймалися як
стратегічне рішення. Це не лише обмежило пошук альтернатив, а й відвернуло
увагу від глибинних причин, пов'язаних зі структурою потоку та рівнем
компетентності команди.
4. Сліпа зона щодо ролі компетенцій (Skill Neglect Bias) — це когнітивне
викривлення, за якого люди недооцінюють або зовсім не враховують вплив
26

навичок і компетентності учасників на результат, вважаючи, що проблема
полягає лише в обсягах роботи чи ресурсах, а не в самому рівні спроможності
команди [31]. Менеджмент розглядав аналітичну роботу як спеціалізовану
діяльність, яку може виконувати лише BA, і не враховував, що здатність
розробників уточнювати вимоги, ставити уточнювальні запитання та
декомпозувати задачі суттєво зменшує навантаження на цей етап. Це
викривлення створило ситуацію, у якій компетентність команди в аналітиці
сприймалася як незмінна величина, а роль BA — як єдиний носій цієї здатності.
У результаті розвитку навичок розробників не розглядали як потенційний
інструмент стабілізації Lead Time. Як наслідок, управлінська модель
залишалася незбалансованою: вона враховувала лише пропускну здатність
ролей, але не можливість розподілу відповідальності та підвищення
компетентності.
5. Евристика доступності (Availability Bias) — це когнітивне викривлення, за
якого людина робить висновки, спираючись переважно на інформацію, яка
швидко пригадується або є найбільш помітною, навіть якщо вона не є
репрезентативною чи повною [32]. Менеджмент будував уявлення про процес,
покладаючись переважно на найбільш помітні або найсвіжіші випадки —
наприклад, коли BA «не встигає» або «затримує задачі на тижні». Ці конкретні
сценарії, будучи емоційно насиченими і доступними в пам’яті, ставали
визначальними для всієї моделі причинності. У той же час менш очевидні, але
структурно важливі проблеми — нечіткі вимоги, слабка декомпозиція,
неузгоджений потік задач — лишалися у тіні. Евристика доступності сприяла
тому, що менеджмент зосереджувався на окремих, яскравих прикладах, а не на
системному аналізі всієї історії даних. Це підсилювало хибну впевненість у
правильності простих рішень.
6. Оптимістичний сценарій (Planning Fallacy) — це когнітивне викривлення, за
якого люди систематично недооцінюють час, зусилля або складність
виконання завдань, очікуючи швидших і легших результатів, ніж це можливо
27

в реальності [33]. Менеджмент недооцінював тривалість задач, вважаючи, що
додавання ще одного BA суттєво скоротить час проходження ранніх фаз.
Такий оптимізм часто характерний для оцінювання систем, у яких не
враховуються внутрішні фідбек-петлі. У реальності ж збільшення BA-команди
лише частково зменшило чергу і не вплинуло на проблеми повернення задач,
які й формували значну частину затримок. Оптимістичний сценарій посилював
ідею, що зміни ролей можуть швидко вирішити проблему, хоча модель CLD
показала, що структурні зміни завжди мають часову затримку й не дають
«миттєвого» покращення.
Усі зазначені викривлення призвели до побудови початкової моделі
Зображення 2.1), яка виглядала логічною, але неправильно відображала взаємодію
зворотних зв’язків у системі. Це вплинуло на вибір управлінських рішень, які
орієнтувалися на симптоми, а не на кореневі причини.
Системний аналіз передбачає, що модель має бути не поглядом одного
менеджера, а колективним відображенням реальності, яку бачать учасники процесу з
різних сторін. Кожна роль має свою частину інформації та власну перспективу:
аналітики бачать одні проблеми, розробники — інші, тестувальники — треті. Лише
поєднавши цей досвід, можна побудувати модель, яка наближена до реальної
поведінки системи [34].
Будування CLD разом із командою дозволяє:
● виявити невидимі взаємозв’язки, які неможливо побачити зі сторони
менеджменту;
● зменшити вплив когнітивних викривлень, адже кожне припущення
перевіряється іншими учасниками;
● знайти справжні кореневі причини, а не їхні симптоми;
● підвищити прийняття рішень командою, адже люди бачать логіку та
причини змін;
● краще зрозуміти зворотні зв’язки, які формують поведінку Lead Time.
28

Під час моделювання учасники не лише діляться спостереженнями, але й
узгоджують терміни, структуру процесу та точки взаємодії. Це дозволяє уникнути
ситуацій, коли одні й ті ж події трактуються по-різному різними членами команди.
Оскільки CLD, побудована лише на основі управлінського бачення, може
відображати лише частину системи або містити викривлення, важливо залучати до
моделювання всю команду [35]. Це робить модель більш точною, дозволяє врахувати
повний спектр факторів, які впливають на Lead Time, та допомагає уникнути рішень,
заснованих на хибних припущеннях.
2.5. Типові системні архетипи як інструмент побудови гіпотез для первинної
діагностики поведінки Lead Time
У процесі дослідження динаміки Lead Time важливо не лише зафіксувати
окремі причини затримок, а й зрозуміти, які структурні закономірності лежать в
основі поведінки системи. У складних процесах розробки одна й та сама проблема
може проявлятися по-різному, але мати спільну логіку — набір взаємопов’язаних
змінних, що утворюють характерний тип поведінки. Саме такі повторювані шаблони
й описуються у вигляді системних архетипів.
Архетипи допомагають пояснити, чому локальні оптимізації інколи лише
погіршують стан системи, чому деякі рішення працюють короткостроково, але
провалюються в довгостроковій перспективі, та чому різні команди стикаються з
подібними труднощами навіть за різних умов [36].
Перш ніж перейти до побудови деталізованої CLD-моделі поточного стану
(підрозділ 2.6), важливо сформувати початкове розуміння того, який тип системної
поведінки ми спостерігаємо у процесі розробки. Мета застосування архетипів на
цьому етапі була в тому, щоб сформулювати первинні гіпотези про те, які структурні
механізми можуть пояснювати спостережувану динаміку Lead Time.
Першим було розглянуто архетип «Limits to Success» (Межі успіху), який
описує ситуацію, коли початкове покращення зупиняється через внутрішні або
зовнішні обмеження. Система зростає лише до того моменту, коли стикається зі
«стелею» — ресурсною, інфраструктурною або процесною [37].
29

Зображення 2.2 - Системний архетип «Limits to Success» (Межі успіху)
Джерело: Systems Archetypes I, Daniel H. Kim.
Потенційною гіпотезою було те, що команда могла досягти «стелі»
продуктивності через обмеження пропускної здатності BA або якості початкової
аналітики. Навіть якщо процес на певний час покращився (наприклад, за рахунок
збільшення швидкості розробки), обмеження у підготовці вимог могли блокувати
подальше зростання. Було припущено, що структура петель у моделі може мати
«обмежувальний» характер. Накладення гіпотези на потенційну CLD-структуру
архетипу «Limits to Success»:
● Петля R1 (Reinforcing) могла би демонструвати зростання навантаження:
«Більше задач → Більше навантаження на BA → Більше невизначеностей
→ Більше повернень → Ще більше навантаження».
● Петля B1 (Balancing) у цьому архетипі відповідала би обмеженню:
«Перевантаження BA → Зниження якості аналізу → Гальмування
процесу → Стабілізація на новому, нижчому рівні продуктивності».
За цією логікою система сама досягає межі, і Lead Time перестає покращуватися
— ми розглядали це як можливе пояснення. Це відображає момент, коли система
досягає свого природного або структурного обмеження [38].
30

Наступним було розглянуто архетип «Fixes That Fail» (Виправлення, що
провалюються), який демонструє, як швидкі, поверхневі рішення можуть тимчасово
полегшити проблему, але водночас створюють довгострокові негативні наслідки, які
лише посилюють початковий симптом [39].

Зображення 2.3 – Системний архетип «Fixes That Fail» (Виправлення, що
провалюються)
Джерело: Systems Archetypes I, Daniel H. Kim.
Була побудована наступна гіпотеза: поведінка Lead Time може відповідати
архетипу «Fixes That Fail», оскільки в команді вже існували спроби «підсилити» етап
Business Analysis шляхом збільшення ролі BA або передачі більшої кількості завдань
саме на цей етап. Це давало локальне і короткострокове покращення, але не
вирішувало кореневої проблеми — якості початкової підготовки задач і залученості
розробників. Ми висунули гіпотезу, що симптоматичні рішення могли приховувати
фундаментальну проблему і формувати негативний зворотний ефект. Накладення
гіпотези на CLD-структуру:
● Петля B1 (Balancing) у цьому випадку могла би демонструвати
короткострокове полегшення: «Додати більше BA → Зменшити чергу →
Тимчасово знизити Lead Time».
● Петля R1 (Reinforcing) відповідала би довгостроковому погіршенню:
«Більше BA → Менше участі розробників у аналізі → Погіршення Dev
31

Skill → Більше повернень → Більше навантаження на BA → Ще більший
Lead Time».
Таким чином, структура процесу виглядала так, що короткострокові
«виправлення» могли посилювати початкову проблему — типова риса архетипу [40].
Третім було розглянуто архетип «Shifting the Burden» (Перекладання тягаря),
який описує ситуацію, коли система віддає перевагу швидким, короткостроковим
рішенням, що лише приглушують симптоми, замість того щоб інвестувати у
фундаментальні зміни. З часом симптоматичні рішення стають «костилями», від яких
дедалі складніше відмовитися, а їхні побічні ефекти погіршують загальний стан
системи [41].

Зображення 2.4 – Системний архетип «Shifting the Burden» (Перекладання
тягаря)
Джерело: Systems Archetypes I, Daniel H. Kim.
Основною гіпотезою було те, що симптоматичне рішення — передача
відповідальності за аналіз BA — створює короткострокове покращення, але водночас
послаблює базові компетенції команди, формуючи довгострокову залежність від
вузької ролі. Це виглядає природною логікою затримок, які ми спостерігали у даних:
велика частка повернень, черга у BA, нерівномірність потоку задач. Це типовий
випадок Shifting the Burden: замість інвестування у фундаментальне рішення —
32

розвиток компетенцій команди та побудову зрозумілих стандартів — обирають
симптоматичне рішення («найняти більше ВА»). У короткостроковій перспективі
воно зменшує час, необхідний на аналіз, але з часом підсилює залежність від однієї
людини та збільшує Lead Time через штучно створене вузьке місце [42]. Накладення
гіпотези на CLD-структуру:
● Петлі B (Balancing): «Делегування аналізу BA → Швидше розвантаження
команди → Тимчасове зменшення Lead Time».
● Петля R1 (Reinforcing): «Менша участь розробників у аналізі →
Зниження Dev Skill → Більше повернень → Зростання черги BA →
Зростання залежності → Ще більше делегування».
Ця структура — єдина, яка одночасно пояснює і короткострокові покращення,
і довгострокову деградацію процесу.
Четвертим було розглянуто архетип «Tragedy of the Commons» (Трагедія
спільного ресурсу), який описує ситуацію, коли кілька учасників користуються одним
обмеженим ресурсом, і кожен індивідуально прагне максимізувати свою вигоду. У
короткостроковій перспективі це може давати позитивний результат, але у
довгостроковій — спільний ресурс виснажується, і всі учасники втрачають [43].
У системах розробки це часто проявляється там, де є один «спільний» вузький
ресурс — спеціаліст, середовище, інструмент або процес, яким користуються всі.

33

Зображення 2.5 – Системний архетип «Tragedy of the Commons» (Трагедія
спільного ресурсу)
Джерело: Systems Archetypes I, Daniel H. Kim.
Діаграма складається з двох підсилювальних петель (позначені R), що
описують активність сторін A та B. Обидві сторони збільшують свою активність (A’s
Activity, B’s Activity), бо це приносить їм індивідуальну вигоду (Net Gains for A/B). У
центрі показано змінну Total Activity, яка відображає спільне навантаження на
загальний ресурс. Після затримки (Delay) зростання загальної активності знижує Gain
per Individual Activity, адже ресурс має природну межу (Resource Limit). Цей ефект
породжує балансуючі петлі, які намагаються стримати систему. У підсумку кожен
учасник прагне отримати більше, але саме це колективно руйнує спільний ресурс.
Оскільки після розділення на два продукти Business Analyst фактично став спільним
ресурсом, виникла гіпотеза, що обидві команди могли «конкурувати» за доступ до
обмеженого аналітичного часу. У такій ситуації кожна команда окремо прагне
скоротити власні затримки, але це спільно виснажує ресурс, знижуючи ефективність
для всіх.Накладення гіпотези на CLD-структуру:
34

● Петлі R (Reinforcing) могли би демонструвати взаємне підсилення
навантаження: «Більше задач у одній команді → Більше навантаження на
BA → Менше часу для іншої команди → Зростання затримок → Стимул
передавати більше задач BA → Ще більше навантаження».
● Петлі B (Balancing) могли би відображати «виснаження ресурсу»:
«Перевантаження BA → Падіння якості → Більше повернень →
Накопичення задач → Примусове зниження темпу всіма командами».
Ця динаміка є типовою для сценаріїв зі спільним вузьким місцем [44].
Останнім було розглянуто архетип «Success to the Successful» (Успіх —
успішним) описує ситуацію, коли обмежені ресурси розподіляються таким чином, що
ті, хто вже успішний, отримують ще більше можливостей, тоді як інші сторони
деградують. Чим більше успіху демонструє одна сторона, тим більше ресурсів їй
надають — і тим важче іншій стороні підтягнутися [45].
У результаті утворюється самопідсилювальна нерівність, що здатна зруйнувати
баланс системи.

Зображення 2.6 – Системний архетип «Success to the Successful» (Успіх —
успішним)
Джерело: Systems Archetypes I, Daniel H. Kim.
35

Була побудована наступна гіпотеза: у разі, якщо одна підкоманда
демонструвала би кращі результати взаємодії з BA, могла сформуватися асиметрія:
BA інвестує більше часу й уваги саме в ту команду, яка здається «ефективнішою». Це
могло створити позитивний цикл для однієї команди й негативний — для іншої. Ми
розглядали це як потенційний механізм, що частково пояснює різницю в середньому
Lead Time між командами після розділення. Це класичний випадок «успіх —
успішним»: одна частина системи отримує все більше можливостей, а інша втрачає
шанси на покращення. Накладення гіпотези на CLD-структуру:
● Петля R1 у цьому архетипі могла відповідати: «Більша продуктивність
команди → Більше підтримки BA → Ще кращі результати → Ще більше
уваги BA».
● Петля R2 могла би показувати тиск на іншу команду: «Менше уваги BA
→ Гірші умови для аналізу → Зростання Lead Time → Ще менше уваги».
Цей архетип добре пояснює асиметрію, але не повністю структуру затримок.
Розглянуті системні архетипи дозволяють побачити, що поведінка Lead Time не
є випадковою чи хаотичною — вона формується під впливом типових структур, які
повторюються в різних командах та проєктах, і в рамках досліджуваного IT-проєкту
було побудовано первинні гіпотези за допомогою зазначених вище архетипів. У
кожному архетипі підсилювальні та балансуючі петлі зворотного зв’язку створюють
передбачувані сценарії розвитку подій: від зростання навантаження до появи вузьких
місць, деградації продуктивності, ескалації конфліктів або виникнення побічних
ефектів швидких рішень. Таким чином, архетипи допомагають ідентифікувати
приховані механізми, що можуть впливати на збільшення Lead Time у команді, навіть
якщо ці механізми не помітні на рівні окремих етапів процесу [46]. Проведений аналіз
типових системних архетипів дав змогу структурувати первинні гіпотези щодо того,
які механізми могли формувати поведінку Lead Time у досліджуваному процесі.
Використання архетипів на цьому етапі дозволило не обмежуватися описом окремих
проблем чи локальних симптомів, а перейти на рівень системної діагностики, де
ключову роль відіграють взаємозв’язки, фідбек-петлі та накопичувальні ефекти.
36

Такий підхід був критично важливим, оскільки спостережувані затримки не мали
характеру разових збоїв — вони виникали повторно, демонструючи стабільний
патерн, що зазвичай є ознакою прихованої системної структури [47].
Розглянуті архетипи дозволили оцінити різні потенційні сценарії розвитку
процесу. «Fixes That Fail» описував би ситуацію, за якої короткострокові рішення
могли створювати довгострокові побічні ефекти; «Limits to Success» — середовище,
у якому процес досягає «стелі» продуктивності через обмеження пропускної
здатності; «Tragedy of the Commons» — гіпотетичну конкуренцію між командами за
спільний аналітичний ресурс; «Success to the Successful» — можливу асиметрію в
розподілі уваги та підтримки з боку BA. Попри те, що кожен із цих архетипів частково
перегукувався зі спостережуваними подіями, жоден із них не давав цілісного
пояснення того, чому Lead Time демонстрував тенденцію до зростання навіть за умов
номінального збільшення «аналітичної місткості» або стабільного складу команди.
Найближчим до реальної динаміки процесу виглядав архетип «Shifting the Burden»,
структура якого відповідає ключовим елементам поведінки: короткостроковому
полегшенню через делегування аналізу BA, поступовому зниженню аналітичних
компетенцій розробників, збільшенню кількості повернень задач та формуванню
підсилювальних петель залежності від вузької ролі. Така конфігурація приводила до
зростання черги, втрати керованості потоку та прогресивного збільшення Lead Time
— саме такої поведінки, яку ми спостерігали у даних.
У наступному підрозділі 2.6 буде побудовано детальну причинно-наслідкову
діаграму поточного стану, яка інтегрує результати цього аналізу та дозволяє чітко
ідентифікувати ключові зворотні петлі, що визначають динаміку Lead Time у
досліджуваному процесі і визначить, чи дійсно архетип «Shifting the Burden» є
архетипом, який можна спостерігати при побудові CLD-моделі досліджуваного IT-
проєкту.
2.6 Проєктний контекст та підготовка до системного аналізу
Для практичної демонстрації можливостей системного моделювання та
застосування причинно-наслідкових діаграм (CLD) було обрано реальний
37

комерційний проєкт, пов’язаний із створенням і підтримкою платформи з купівлі-
продажу CS:GO кейсів. До моменту початку дослідження команда вже мала
працюючий продукт, орієнтований на український ринок, однак у межах
стратегічного рішення материнської компанії проєкт був розділений на дві
підкоманди. Перша продовжувала підтримувати та розвивати напрям для України, а
друга — мала адаптувати продукт для входу на ринок США.
Мета та загальна концепція проєкту: ціль американського відгалуження
проєкту полягала у створенні локалізованої версії платформи, здатної відповідати
вимогам американського законодавства, фінансових інструментів, очікувань
користувачів та локальної інфраструктури платежів. Очікуваним результатом було
отримання повністю функціонального MVP-продукту, який можна вивести на ринок
США протягом шести місяців. Проєкт має тип бізнес-орієнтованої ініціативи,
фінансування якої забезпечує материнська компанія-венчур-білдер. Стратегічною
метою венчур-білдера є перевірка гіпотези масштабування бізнес-моделі на інші
країни та підготовка продукту до подальшої комерціалізації.
Загальні характеристики та оточення проєкту: веб-платформа на Node.js +
React, монолітна архітектура, без мобільних застосунків.
Особливості середовища:
– необхідність інтеграції з міжнародними платіжними сервісами (Stripe, PayPal,
Apple Pay);
– відповідність вимогам американського законодавства для virtual items, age
restrictions та loot-box disclaimers;
– висока конкуренція у ніші, що вимагає швидкого time-to-market;
– потреба в локалізації інтерфейсу, UX/UI та оновленні цінової логіки.
Учасники проєкту до поділу на дві команди:
Product Owner - 1 людина
Business Analyst - 1 людина
Full-stack Developers - 8 людей
QA Engineers - 3 людини
38

Designer - 1 людина
Project Manager - 1 людина
Після поділу (детальніше описано в 2.1):
Product Owner - 1 людина
Full-stack Developers - 3 людей
QA Engineer - 1 людина
Designer - 1 людина
Project Manager - 1 людина
У рамках дослідження важливо, що американська команда працювала без
Business Analyst, що дало змогу протестувати системну гіпотезу щодо зменшення
залежності від BA та розвитку аналітичних навичок у розробників.
Таблиця 2.2 – WBS (Work Breakdown Structure) проєкту
Елемент роботи Оцінка, год Учасники
Аналіз вимог 160 Розробники + тестувальник
UX/UI локалізація 120 Дизайнер
Інтеграція Stripe 200 Розробники
Інтеграція PayPal 160 Розробники
Інтеграція Apple Pay 180 Розробники
KYC/AML 150 Розробники + тестувальник
Loot-box disclaimers 80 Розробники
ToS/Privacy adaptation 60 Розробники + продакт оунер
Цінова логіка 140 Розробники + тестувальник
Аналітика і маркетинг API 100 Розробники + тестувальник
Тестування всіх інтеграцій 200 Тестувальник
39

Регресія + стабілізація 180 Розробники + тестувальник
MVP реліз 40 Вся команда
Підтримка після релізу 80 Вся команда
Разом WBS: 1850 годин.
Кошторис проєкту побудована базуючись на оцінці роботи, що представлені в
Таблиці 2.2, а також з урахуванням погодинної ставки зазначених вище спеціалістів.
Таблиця 2.3 – кошторис проєкту
Роль Години Ставка Сума
Full-stack Dev #1 600 $38 $22,800
Full-stack Dev #2 600 $38 $22,800
Full-stack Dev #3 600 $38 $22,800
QA Engineer 350 $25 $8,750
Designer 120 $28 $3,360
PM 150 $32 $4,800
PO 90 $40 $3,600
Загальний бюджет проєкту: $89,110
Проєкт фінансується материнською компанією-венчур-білдером, яка інвестує у
нові цифрові продукти та перевіряє гіпотези масштабування бізнес-моделі на інші
країни. Збереження однієї кодової бази при розділенні команд дозволяє зменшити
витрати й прискорити запуск у США.
2.7. Побудова базової CLD-моделі поточного стану досліджуваного IT-проєкту
Під час аналізу діаграми, запропонованої менеджментом (див. підрозділ 2.3),
стало очевидно, що вона відображає лише частину причинно-наслідкових зв’язків, які
впливають на динаміку Lead Time. Попри свою логічність і простоту, початкова
40

модель описувала систему з надто вузької перспективи — зосереджуючись на
кількості нових задач, навантаженні на бізнес-аналітика та швидкості опрацювання
вимог. Така структура дозволяла побачити загальну тенденцію, але не розкривала
механізмів, що призводили до накопичення затримок та стрімкого зростання часу
перебування задач у статусі Business Analysis.
У процесі колективного моделювання було з’ясовано, що для реалістичного
відтворення поведінки системи потрібно врахувати додаткові змінні, які
відображають внутрішні риси команди, її компетентність, здатність адаптувати
процеси та спосіб реагування на зростання навантаження. Саме ці змінні часто
залишаються непомітними у високорівневих управлінських моделях, але в реальності
суттєво впливають на загальний Lead Time [48].
Ключові змінні, необхідні для точнішої моделі:
1. Навантаження на бізнес-аналітика (BA Load)
Статус In BA у даних Actionable Agile показав середнє значення у 33 дні, що є
найбільшим внеском у загальний Lead Time. Це свідчить, що саме пропускна
здатність BA є центральною змінною. Але навантаження на BA залежить не лише
від кількості задач, а й від того, які саме дії передаються аналітику — і як часто
команда делегує йому роботу, яку потенційно могла б виконати сама.
2. Симптоматичне рішення: делегування декомпозиції на BA (Use_BA)
Під час інтерв’ювання команди стало зрозуміло, що типова реакція на
збільшення складності задач — це передавати їх у Business Analysis повністю,
замість того щоб виконувати попередню декомпозицію на рівні розробки. Це
створює ілюзію «оптимізації», але фактично збільшує чергу перед BA-вузьким
місцем. Тому ця змінна є обов’язковою частиною моделі.
3. Позитивний та негативний вплив практики аналізу у розробників (Dev
Practice і Dev Skill)
У базовій управлінській моделі не враховувалося, що розробники можуть (і
повинні) брати участь у формуванні вимог на ранніх етапах — через уточнення,
41

декомпозицію, прототипування та попередній аналіз.
Ця здатність прямо впливає на:
● швидкість підготовки задач,
● зменшення циклів повернень,
● зниження навантаження на BA,
● стабільність Lead Time [49].
Включення змінних, які ми назвали Dev Practice (пратика в аналізі) і Dev Skill
(вміння аналізувати самостійно) дозволяє відобразити фундаментальне рішення, яке
приносить користь із затримкою, але створює довгострокове покращення у системі.
4. Побічний ефект симптоматичного рішення: втрата навичок розробників
(Skill Atrophy)
Будь-яке постійне делегування аналізу викликає деградацію компетенцій у
розробників — типову системну динаміку [50]. Далі ми детальніше розберемо,
якому архетипу це відповідає. Це рішення зменшує навички команди працювати із
складними задачами, що, у свою чергу, збільшує залежність від BA, посилює чергу
та формує підсилювальну петлю (побічний ефект → зменшення компетенцій → ще
більше делегування → ще більше навантаження). Без цієї змінної модель була б
неповною та надто оптимістичною.
5. Симптом проблеми: довгий час у Business Analysis / Lead Time
Це основний показник, який ми намагаємося пояснити. У моделі він виступає
вузлом, до якого входять різні впливи: як симптоматичні, так і фундаментальні. Для
коректної динаміки ця змінна використовується як центральний елемент
балансуючих петель.
Кожна з цих змінних відповідає за частину поведінки системи, яку не можна
побачити, якщо дивитися лише на поверхневі показники (кількість задач чи видимі
затримки). Управлінська модель показувала лінійну залежність: більше задач →
більше навантаження → більше затримок. Однак реальна поведінка є нелінійною і
містить підсилювальні та балансуючі петлі, а саме:
● повторювані цикли делегування, які формують симптоматичні покращення;
42

● поступову втрату компетенцій, яка довгостроково погіршує систему;
● різні типи затримок у впливі рішень, які змінюють форму Lead Time;
● стійкий зворотній зв’язок між навантаженням і швидкістю аналізу.
Саме тому для формування реалістичної CLD-моделі потрібно відійти від
спрощеної структури керівництва і перейти до повної системної схеми, яка включає
як симптоматичні, так і фундаментальні рішення, їхні побічні ефекти та часові
затримки. Це дозволяє не лише описати поточний стан, але й виявити точки важеля
для скорочення Lead Time [51].
Враховуючи необхідність включення як симптоматичних, так і
фундаментальних рішень, а також їхніх побічних ефектів, базова CLD-модель
поточного стану була побудована з урахуванням усіх змінних, описаних вище. Вона
відображає ключові взаємозв’язки, які формують затримки у Business Analysis, а
також показує, як локальні рішення можуть довгостроково впливати на Lead Time.
Представлена діаграма включає дві балансуючі та одну підсилювальну петлю, що
разом створюють складну динаміку, притаманну аналізованому процесу.

Зображення 2.7 – CLD модель, яка демонструє наявний процес
Пропоную детальніше розібрати модель. Петля B1 – Симптоматичне рішення
через делегування роботи на BA. Петля B1 є балансуючою та відображає найбільш
43

типову реакцію команди на зростання складності задач: передати аналіз та
декомпозицію бізнес-аналітику. Логіка петлі наступна: зростає навантаження на BA
(BA_Load). Через це збільшується симптом проблеми — довгий час у Business
Analysis / Lead Time. Як короткострокова відповідь команда делегує більше
попереднього аналізу на BA (Symptomatic Solution / Use_BA). Це ще сильніше
збільшує BA_Load, що замість покращення створює більшу чергу. Ця петля
демонструє, що команда намагається «збалансувати» систему, застосовуючи
рішення, яке діє швидко й виглядає логічним, але фактично поглиблює кореневу
проблему. Це класичний архетип Shifting the Burden: замість інвестицій у навички
команди — передача роботи на вузьке місце.
Петля B2 – Фундаментальне рішення через розвиток навичок розробників
Петля B2 також балансуюча, але працює у протилежному напрямку — вона
представляє фундаментальне, довгострокове рішення. Логіка петлі наступна: довгий
час у BA створює потребу залучати розробників до аналітики та декомпозиції. Це
стимулює розвиток їхніх навичок (Dev_Skill) та практик аналізу (Dev_Practice). З
часом (із затримкою) зростання навичок дозволяє зменшити складність задач, які
потрапляють у BA. Це знижує BA_Load та скорочує час у BA. Ця петля демонструє,
що фундаментальні зміни потребують більше часу, але саме вони створюють
стабільне скорочення Lead Time. B2 — це механізм природного самовідновлення
системи, який стає можливим лише тоді, коли команда вкладає зусилля у власні
компетенції.
Петля R1 – Побічний ефект: поступова втрата навичок розробників. Петля R1 є
підсилювальною і відображає негативний довгостроковий сценарій, який виникає
тоді, коли команда систематично обирає симптоматичні рішення (B1), а не
фундаментальні (B2). Логіка петлі наступна: часте делегування аналізу на BA
(Use_BA) зменшує кількість ситуацій, у яких розробники практикують навички
аналізу та декомпозиції. Через це з часом (із затримкою) зменшується їхня
компетентність (Skill Atrophy). Зниження навичок робить розробників ще більш
залежними від BA, і вони ще частіше передають йому складні задачі. Це збільшує
44

Use_BA → знову збільшує BA_Load → погіршує симптом. Це негативна
підсилювальна петля, яка створює «спіраль погіршення»: чим більше команда уникає
фундаментального рішення, тим менш здатною вона стає до самостійного аналізу —
і тим сильніше перевантажує BA. Це і є прихований механізм, що робить
симптоматичні рішення небезпечними.
Ця CLD-структура показує, що довгий час у Business Analysis та загальний Lead
Time зумовлені не лише обсягом задач, а насамперед вибором типу рішення, який
послідовно застосовує команда:
● симптоматичне рішення → короткострокове полегшення → довгострокове
погіршення;
● фундаментальне рішення → вищі витрати часу зараз → стале покращення
системи.
Модель також демонструє наявність часових затримок, «зворотних» ефектів та
поведінкових причин, які лишаються невидимими в лінійних управлінських моделях.
Запропонована CLD-модель демонструє, що поведінка Lead Time у досліджуваній
команді формується не лише обсягом задач чи кількістю доступного аналітичного
ресурсу, а насамперед структурою взаємодій усередині процесу. Симптоматичні
рішення знімають гостроту проблеми в короткостроковій перспективі, але водночас
підсилюють залежність від бізнес-аналітика та послаблюють компетентність
розробників, створюючи ефект накопичення затримок. Фундаментальні ж рішення
мають довший горизонт впливу, але саме вони здатні змінити загальну динаміку та
стабілізувати Lead Time [53]. Модель показує, що вибір між цими двома підходами
формує різні траєкторії розвитку системи: одні ведуть до поглиблення вузьких місць,
інші — до їх поступового усунення. Такий системний погляд дозволяє зрозуміти,
чому поверхневі управлінські інтервенції не давали очікуваного ефекту, і створює
основу для подальшого моделювання та оцінювання ефективності змін у наступному
розділі.
Висновки до розділу 2.
45

Аналіз поточного процесу розробки, доповнений системним підходом і
побудовою CLD-моделі, дозволив зафіксувати кілька ключових закономірностей, які
визначають динаміку Lead Time у досліджуваній команді. Дані з Actionable Agile
засвідчили наявність суттєвого вузького місця на етапі Business Analysis, де задачі
накопичувалися і формували значну частину загального часу доставки. Проте
важливо, що це вузьке місце не є статичним — його інтенсивність та вплив зумовлені
рішеннями самої команди та структурою процесу. Порівняння початкової
управлінської моделі з результатами колективного моделювання показало, що лінійне
уявлення про причинність не охоплює реальних механізмів, які формують затримки.
Попередня модель зосереджувалася на кількості задач та завантаженості бізнес-
аналітика, але ігнорувала динаміку компетенцій, побічні ефекти симптоматичних
рішень та часові затримки у впливі фундаментальних змін. Саме ці елементи стали
критичними для пояснення того, чому Lead Time зростав навіть за умов, коли
управлінські інтервенції здавалася спрямованими на «прискорення процесу».
Розглянуті системні архетипи дали можливість впізнати типові шаблони
поведінки, що проявилися у процесі команди: перекладання тягаря, виправлення, що
провалюються, межі успіху, конкуренція за спільні ресурси тощо. Кожен архетип
відобразив характерну петлю зворотного зв’язку, яка підсилювала або стримувала
роботу системи. Їхня присутність у реальних даних команди підтвердила, що
проблеми з Lead Time мають системне походження, а не є наслідком індивідуальних
дій чи випадкових подій. Побудована CLD-модель інтегрувала ці спостереження в
узгоджену структуру та дала змогу побачити, як симптоматичні й фундаментальні
рішення взаємодіють між собою. Симптоматичне делегування аналізу аналітику
тимчасово зменшувало навантаження на розробників, але призводило до поступової
втрати їхніх навичок, що, у свою чергу, збільшувало потребу в подальшому
делегуванні. Фундаментальні рішення працювали зі значною затримкою, але
дозволяли відновити баланс та стабілізувати Lead Time.
Таким чином, результати цього розділу показують, що динаміка Lead Time
визначається не лише об’єктивними умовами, а й тим, як саме команда реагує на
46

зміни у процесі та які петлі вона активує своїми рішеннями. Системне моделювання
дозволило виявити базову логіку поведінки системи, яка стане основою для розробки
оптимізованої моделі та оцінювання сценаріїв її покращення у наступному розділі.

47

РОЗДІЛ IІI Оцінювання ефективності та оптимізація системної моделі Lead
Time
3.1. Побудова оптимізованої CLD-моделі Lead Time
Однією з ключових відмінностей оптимізованої CLD-моделі є трансформація
ролей у команді: замість збереження бізнес-аналітика як окремого вузького місця,
модель передбачає розвиток здатності команди виконувати аналітичні функції
самостійно. У базовій моделі ця функція була пов’язана з підсилювальною петлею
R1, де делегування аналізу BA з часом зменшувало компетентність розробників і
поглиблювало залежність від аналітика. Оптимізована модель замінює цю петлю
протилежною динамікою: розвитком навичок аналізу всередині команди.
Замість симптоматичних рішень, представлених у петлі B1, що тимчасово
зменшували навантаження за рахунок передачі складних задач на BA, у моделі
вводиться фундаментальне рішення з петлі B2: інвестування у навички команди. Цей
процес реалізується через серію регулярних воркшопів, практичних сесій та парного
аналізу, на яких розробники навчаються працювати з вимогами безпосередньо — від
первинного уточнення до декомпозиції й формування необхідного контексту для
розробки. Завдяки цьому змінюється структура самої системи: розробники більше не
сприймають бізнес-аналіз як зовнішню функцію, а включають його в свій робочий
цикл. Це знижує кількість задач, що потребують глибокого аналізу поза командою,
зменшує варіативність якості підготовлених задач і суттєво скорочує навантаження
на вузьку ланку, яка раніше визначала поведінку Lead Time. У моделі це відображено
зменшенням показника Use_BA та нівелюванням петлі R1, яка формувала деградацію
навичок. Натомість з часом посилюється балансуюча петля B2, яка стабілізує систему
через підвищення Dev_Skill і Dev_Practice. У результаті команда отримує
можливість працювати більш автономно, скорочувати час уточнення задач і значно
швидше проводити їх через початкові етапи потоку.
Таким чином, відмова від ролі BA як окремої позиції не є просто зміною
організаційної структури — це фундаментальна зміна конфігурації зворотних зв’язків
у системі, яка переводить її із залежної, реактивної моделі у саморегульовану, більш
48

стабільну структуру. Це дозволяє зменшити величину та варіативність Lead Time,
оскільки система більше не концентрує навантаження в одному місці, а розподіляє
його відповідно до компетенцій команди, які зростають.
Це досягається шляхом одночасного впливу на кілька ключових змінних.
1. Розвиток аналітичних навичок розробників та зміцнення практик
декомпозиції. У моделі другого розділу було показано, що низький рівень
аналітичних компетенцій у розробників створює підсилювальну петлю залежності від
BA. Оптимізована CLD-модель вводить довгострокове рішення — системне
підвищення навичок аналізу, валідації та уточнення вимог на рівні команди. Цей
компонент створює позитивний балансуючий вплив, оскільки:
● зменшується кількість задач, що вимагають залучення BA;
● скорочується кількість повернень на доопрацювання;
● зменшується збільшення Symptomatic Load у BA статусі.
У моделі це представлено через збільшення змінних Dev_Skill та Dev_Practice,
які діють як ключова точка важеля.
2. Контрольоване делегування та скорочення симптоматичних рішень
У поточному стані симптоматичне рішення (делегування на BA) було
домінуючим і формувало підсилювальну петлю негативних побічних ефектів.
Оптимізована модель вводить механізм, який обмежує використання Use_BA та
переводить його у статус виняткового рішення, а не стандартної реакції на складність.
Це дозволяє:
● зменшити інтенсивність петлі R1 (Skill Atrophy),
● уповільнити накопичення черги перед BA,
● стабілізувати навантаження на аналітичну ланку.
3. Збалансований розподіл потоку задач
Модель також передбачає більш рівномірне планування та розподіл задач за
принципами:
● обмеження WIP на етапах аналізу та розробки;
● узгодження темпу роботи BA і розробки;
49

● уникнення накопичення «важких» задач у ранніх фазах.
Такий підхід зменшує різкі коливання навантаження (Load Variation), які у
базовій моделі підсилювали поведінку підсилювальних петель.
4. Зниження затримок у фундаментальних рішеннях
Важливою зміною є скорочення часової затримки (Delay) між розвитком
навичок і відчутним ефектом у процесі. Це досягається:
● регулярними воркшопами з аналізу вимог;
● рев’ю вимог усередині команди;
● впровадженням шаблонів для декомпозиції.
Скорочення затримок підсилює балансуючу петлю B2 та пришвидшує
стабілізацію Lead Time.
5. Корекція навантаження на BA як системна змінна
Оптимізована модель передбачає контрольоване зменшення BA-Load за
рахунок:
● перенесення частини аналізу на розробників,
● раннього уточнення вимог у Discovery фази,
Це усуває причину формування надмірної черги та послаблює ризики появи
нових підсилювальних петель.
Загальна логіка оптимізованої моделі:
У сукупності ці зміни формують більш збалансовану систему, у якій:
● фундаментальні рішення проявляються раніше;
● симптоматичні рішення використовуються рідше;
● зворотні зв’язки працюють на стабілізацію та зменшення Lead Time;
● навички команди стають частиною структури, а не випадковим фактором.
Оптимізована CLD-модель є не просто «покращеним варіантом» базової, а
цілісним сценарієм майбутнього стану процесу. Вона окреслює умови, за яких
система здатна перейти від реактивного управління затримками до стабільного,
передбачуваного та саморегульованого потоку поставки цінності.
50

Зображення 3.1 - Оптимізована CLD модель

3.2. Аналіз сценаріїв розвитку системи: поточний стан vs оптимізована модель
Для оцінювання ефективності запропонованих змін були розглянуті два
сценарії розвитку системи:
● Поточний стан, у якому аналітична функція зосереджена на ролі бізнес-
аналітика, а команда переважно делегує йому роботу з уточнення та
підготовки вимог.
● Оптимізована модель, у якій аналітична робота інтегрована в діяльність
розробників, а BA як окрема роль не виступає вузьким місцем процесу. У
цьому сценарії команда свідомо переходить від симптоматичного
рішення до фундаментального — розвитку власних компетенцій.

Аналіз обох сценаріїв проводився на основі побудованих CLD-структур, що
дозволило оцінити поведінку системи не лише за статичними показниками, а й через
очікувану динаміку зворотних зв’язків.
Сценарій 1. Поточний стан: домінування симптоматичного рішення
51

У поточному сценарії ключовим драйвером затримок була підсилювальна петля
R1, у якій періодичне делегування аналізу бізнес-аналітику зменшувало навички
розробників та посилювало залежність від BA. Ця петля мала дві важливі
особливості:
1. ефект накопичення: чим більше команда делегує аналіз, тим складніше їй
працювати без BA;
2. часова затримка: негативні наслідки проявляються поступово, тому
симптоматичне рішення здається ефективним у короткостроковій
перспективі.
Взаємодія між петлями B1 (симптоматичне рішення) та R1 призводила до
циклічних коливань Lead Time з довготривалою тенденцією до зростання. Навіть у
періоди стабільності система залишалася вразливою через концентрацію
навантаження на одному спеціалісті. У практичному вимірі ця структура зумовлює
системну нестійкість: Lead Time сильно реагує на зміни контексту, відпустки BA,
притоки задач або зміну пріоритетів.
Сценарій 2. Оптимізована модель: інтеграція аналітичних функцій у команду
В оптимізованому сценарії домінуючим зворотним зв’язком стає балансуюча
петля B2, яка підтримує стабілізацію системи через розвиток аналітичних навичок
розробників. Відмова від делегування BA (зміна поведінки у змінній Use_BA)
трансформує систему у кілька ключових способів:
● Зникає вузьке місце, яке формувало більшу частину Lead Time.
Навантаження розподіляється між членами команди, і вузьке місце
перестає бути структурним компонентом системи.
● Підсилювальна петля R1 нейтралізується, оскільки команда більше не
уникає аналітичної роботи. Навпаки — кожна задача стає джерелом
практики та розвитку.
● Зменшується варіативність процесу. Оскільки аналітика відбувається
безпосередньо у команді, зменшується кількість блокерів, залежностей і
повторних циклів повернення задач.
52

● Скорочується час реакції на зміни. Затримки у петлі Delay між
фундаментальним рішенням і його ефектом зменшуються завдяки
регулярним воркшопам та парному аналізу.
● Покращується прогнозованість Lead Time. Дані більше не залежать від
пропускної здатності окремої людини — натомість поведінка системи
визначається колективною спроможністю команди.
Таким чином, у оптимізованій моделі провідну роль відіграє внутрішній
розвиток компетенцій як структурний важіль впливу на всю систему. Це дозволяє
сформувати стійку, саморегульовану динаміку, де Lead Time зменшується не за
рахунок локальних прискорень, а завдяки зміні структури процесу.
Порівняння двох сценаріїв показує, що:
● у поточному стані Lead Time визначався коливаннями навантаження та
поведінкою вузького місця;
● у оптимізованому сценарії Lead Time визначається рівнем компетенцій
команди та якістю потоків задач.
Замість нестабільної системи зі зростанням Lead Time оптимізована модель
формує передбачуваний, рівномірний потік, у якому зменшується як середній Lead
Time, так і його дисперсія. Це критично важливо для продуктових команд, у яких
стабільність прогнозів є не менш значущою, ніж сама швидкість доставки.
3.3. Порівняння поведінки двох команд у реальних умовах
Поділ початкової команди на дві окремі — одна з яких залишилася працювати
у традиційній конфігурації з бізнес-аналітиком, а інша перейшла до оптимізованої
моделі без BA та з розвитком аналітичних навичок розробників — створив унікальну
можливість оцінити вплив структурних змін на поведінку Lead Time. Обидві команди
стартували з однаковою кодовою базою, подібним складом розробників і тотожною
вихідною точкою процесу, що дозволяє мінімізувати вплив зовнішніх факторів та
сконцентруватися на відмінностях у внутрішніх структурних рішеннях.
Пропоную проаналізувати дані цих двох команд, зібрані протягом наступних 3
спринтів. Традиційна команда з двома BA, має більше аналітичної «потужності», але:
53

● черга в BA все одно залишається,
● кількість повернень на доопрацювання значно вища,
● варіативність Lead Time велика,
високий контекстний шум через різну якість декомпозиції.
Таблиця 3.1 - дані команди з БА
Статус Середній Time in Status Коментар
(дні)
Backlog 7 Пріоритизація швидка
через двох BA
In BA 18 Удвох легше розбирати
задачі, але потік
нестабільний
Ready for Dev 6 BA швидко вивантажують
задачі
To Do 5 Часто накопичуються
задачі на старті спринту
In Progress 3 Нормальний темп
Code Review 2 Зростає через повернення
задач
RFT 1 Без змін
Testing 4 Багато дефектів через
слабку декомпозицію
Ready for Release 5 Стабільні релізи
Загальний Lead Time 51 Висока варіативність +
54

повернення задач
Додаткові метрики традиційної команди:
● Повернення задач у Discovery/декомпозицію: 27%
● Повернення задач у Dev після рев’ю: 18%
● Кількість багів на задачу: 0,7
● Варіативність Lead Time (σ): ±19 днів
Команда без BA (інтегрована аналітика) не мала затримок у BA немає,
проте:
● спочатку аналітика «сповільнює» розробку, бо команда вчиться,
● з часом кількість повернень різко падає,
● Lead Time стає більш передбачуваним,
● загальна швидкість зростає після кількох тижнів.
Таблиця 3.2 - дані команди без БА
Статус Середній Time in Status Коментар
(дні)
Backlog 8 Команда сама уточнює
задачі
In BA - Немає BA
Ready for Dev 4 Декомпозиція робиться на
воркшопах
To Do 4 Менше мікрозадач, нижча
варіативність
In Progress 3 Стабільно
Code Review 1 Менше повернень,
рівномірний потік
55

RFT 1 Норма
Testing 2 Менше дефектів, краща
якість постановки
Ready for Release 5 Реліз раз на спринт
Загальний Lead Time 32 Значно нижчий і
стабільний
Додаткові метрики команди без BA:
● Повернення задач у Discovery/декомпозицію: 8%
● Повернення у Dev після рев’ю: 6%
● Кількість багів на задачу: 0,3
● Варіативність Lead Time (σ): ±7 днів
Таблиця 3.3 - порівняння двох команд
Показник Команда з 2 BA Команда без BA
Lead Time 51 день 32 дні
Варіативність Lead Time ±19 днів ±7 днів
Повернення задач 27% / 18% 8% / 6%
Баги на задачу 0,7 0,3
Якість декомпозиції Низька, залежить від BA Висока, колективна
Ризики Вузьке місце ВА Немає вузьких ролей
Команда, що працювала у традиційному підході з BA, продовжила
демонструвати знайому динаміку, хоч і найняла ще одного аналітика: черги у
статусах попереднього аналізу, періодичні піки навантаження, затримки у фазі
уточнення вимог та повернення задач на доопрацювання. Ця поведінка виявилася
структурно обумовленою: збереження вузького місця у вигляді аналітика
56

продовжувало активувати підсилювальну петлю R1, у якій делегування аналізу
зменшувало компетентність розробників та збільшувало залежність від аналітичного
ресурсу. У процесі команда демонструвала значну варіативність Lead Time,
чутливість до змін пріоритетів і збоїв у доступності BA, а також помітні коливання
продуктивності під час збільшення або зменшення потоку задач. Натомість команда,
яка перейшла до моделі без бізнес-аналітика, досить швидко продемонструвала іншу
траєкторію розвитку. Регулярні воркшопи, раннє уточнення вимог, парний аналіз та
спільна декомпозиція дали змогу створити стійку балансуючу петлю B2, у якій
розвиток навичок розробників безпосередньо вплинув на зниження навантаження на
ранні фази потоку. За рахунок цього зменшилися цикли повернення задач,
скоротилися блокери між етапами та підвищилась якість початкової постановки
задач, що є критичним для формування стабільного Lead Time. Відсутність вузького
місця усунула залежність потоку від однієї ролі, і система стала менш чутливою до
коливань обсягу робіт.
Порівняння двох команд показало, що структурні зміни мають більший вплив
на поведінку Lead Time, ніж індивідуальна продуктивність або кількість залучених
фахівців. Команда з BA могла виконувати ті ж обсяги робіт, але асиметрія в розподілі
аналітичної відповідальності створювала значно більшу варіативність часу доставки.
Водночас команда з інтегрованою аналітикою показала плавніший,
передбачуваніший потік: задачі швидше проходили стадії уточнення, розробка рідше
блокувалася, а загальний Lead Time стабілізувався на нижчому рівні. Таким чином,
реальні дані підтвердили висновки системного моделювання: поведінка Lead Time
визначається не кількістю людей у команді та не інтенсивністю роботи окремих
ролей, а структурою зворотних зв’язків всередині процесу. Команда, яка виключила
роль BA та інвестувала у розвиток навичок розробників, змогла зменшити залежності,
уникнути симптоматичних рішень та створити більш стійку систему, ніж команда, що
залишила традиційну конфігурацію процесу.
57

3.4. Виявлення точок важеля для зменшення Lead Time
Аналіз двох сценаріїв та порівняння поведінки команд після поділу дозволили
визначити ті елементи системи, вплив на які забезпечує найбільший ефект у
скороченні Lead Time. У системному аналізі такі елементи називають точками важеля
— місцями, де відносно невелика зміна призводить до суттєвої трансформації всієї
системи. Важливо наголосити, що ці точки рідко знаходяться в очевидних лінійних
елементах процесу, таких як швидкість реалізації чи кількість виконаних задач.
Натомість вони розташовані у структурі зворотних зв’язків, які визначають
довгострокову поведінку потоку. Пропоную розглянути точки важеля на систему.
1. Першою та, безумовно, найбільш впливовою точкою важеля став розвиток
аналітичних навичок розробників. У побудованій CLD-моделі ця змінна
відіграє ключову роль у балансуючій петлі B2, яка протидіє підсилювальній
петлі R1, відповідальній за деградацію навичок та зростання залежності від
бізнес-аналітика. Як показав експеримент з другою командою, навіть помірні,
але системні інвестиції у розвиток декомпозиції, роботи з вимогами та
уточнення контексту задач приводили до зменшення кількості повернень,
покращення якості постановки задач та стабілізації потоку у ранніх статусах.
Це, у свою чергу, зменшувало навантаження на розробку, запобігало
накопиченню черг і забезпечувало суттєве зниження варіативності Lead Time.
Таким чином, розвиток навичок став не просто інструментом покращення
якості — він перетворився на структурний важіль, що змінив конфігурацію
всієї системи.
2. Другою точкою важеля стала відмова від ролі бізнес-аналітика як окремого
вузького місця. У поточному стані саме делегування аналізу на BA було
каталізатором підсилювальної петлі R1: з кожним циклом делегування
команда втрачала здатність самостійно працювати з вимогами, завантаження
BA зростало, а черга у Business Analysis збільшувалася незалежно від
інтенсивності роботи. Додавання другого BA лише тимчасово пом’якшувало
проблему, але не впливало на її природу. Оптимізована команда, яка
58

працювала без аналітика, навпаки, ліквідувала саму можливість виникнення
цієї петлі. Таким чином, відмова від BA у поєднанні з розвитком навичок
створила нову структуру, де зникає залежність від однієї ролі, а
відповідальність за якість вимог розподіляється всередині команди. Це
зменшило ризики, усунуло можливість появи черги у BA і забезпечило
стабільнішу та прогнозованішу поведінку Lead Time.
3. Наступною точкою важеля стало скорочення затримок у фундаментальних
рішеннях. У CLD-моделі часові затримки мали вирішальний вплив на
поведінку системи, оскільки саме вони визначали, як швидко команда відчує
ефект від розвитку своїх навичок. Регулярні воркшопи, парний аналіз та
колективна декомпозиція задач зробили фундаментальні рішення не просто
частиною процесу, а його системною нормою. Це дозволило різко скоротити
затримку між навчанням і застосуванням навичок у реальному потоці. Вплив
цієї точки важеля проявлявся в тому, що команда майже одразу почала
виробляти якісніші задачі, краще формулювати очікування та попереджати
проблеми на ранніх етапах. Завдяки цьому балансуюча петля B2 почала діяти
швидше та ефективніше, а система стала менш чутливою до пікових
навантажень.
4. Важливою також виявилася точка важеля, пов’язана з розміром задач та
практиками декомпозиції. У традиційній команді задачі потрапляли в аналіз у
великому та різнорідному вигляді, що збільшувало як складність аналізу, так і
ризик помилок. У команді без BA декомпозиція була інтегрована в робочий
процес, а задачі поступали до розробки у структурованому й однорідному
вигляді. Це суттєво зменшувало коливання часу у статусах Ready for Dev, To
Do та Testing. З точки зору системної моделі, правильна декомпозиція
зменшувала вплив негативних зворотних зв’язків у петлях R1 і B1, створюючи
більш плавний та передбачуваний потік.
5. Не менш значущою точкою важеля стала відмова від симптоматичних рішень
у моменти пікового навантаження. Традиційна команда часто вдавалася до
59

поверхневих покращень — прискорення розробки за рахунок зменшення уваги
до вимог, передача задач BA без уточнення, швидкі виправлення, що
збільшували технічний борг. У термінах CLD це проявлялося як активація
петлі B1, яка тимчасово зменшувала тиск на систему, але в довгостроковій
перспективі підсилювала петлю R1 і зростання Lead Time. Команда без BA,
навпаки, запровадила принцип «без швидких рішень», який дозволив уникнути
повторних циклів повернення, зменшити кількість дефектів і стабілізувати
темп розробки.
6. Останньою суттєвою точкою важеля стало вирівнювання потоку задач. Коли
команда навчилася краще управляти розміром задач, раніше уточнювати
контекст і уникати мікроскопічних черг перед окремими статусами,
навантаження стало більш рівномірним. Це зменшило «системний шум» та
стабілізувало поведінку всіх петель у моделі. У традиційній команді різкі
стрибки в обсязі надходжень та неспівставні блокери у BA створювали
нерегулярний потік, роблячи Lead Time дуже варіативним. В оптимізованій
моделі система працювала як єдиний збалансований механізм.
Узагальнюючи, можна сказати, що найбільш сильними точками важеля стали
розвиток аналітичних навичок команди, відмова від ролі BA як вузького місця та
зменшення затримок у фундаментальних рішеннях. Саме ці змінні забезпечили
трансформацію поведінки системи — від реактивної, нестабільної та залежної до
більш автономної, структурно збалансованої та передбачуваної. Саме тому вони є
ключовими у зменшенні Lead Time та формуванні стабільної динаміки потоку задач.
3.5. Рекомендації щодо впровадження оптимізованої моделі (з інтеграцією
моделі Коттера)
Аналіз двох команд і результати системного моделювання дозволили
сформувати цілісне бачення того, які структурні зміни необхідні для зменшення Lead
Time. Проте важливо підкреслити, що впровадження оптимізованої моделі — це не
одноразова зміна, а послідовний процес трансформації, який вимагає конкретної
динаміки впровадження. У цьому контексті доцільно звернутися до моделі змін
60

Джона Коттера [54], адаптувавши її під особливості інженерних команд та специфіку
роботи без ролі бізнес-аналітика.
Зображення 3.2 - Модель Коттера
Першим кроком у моделі Коттера є створення відчуття необхідності змін. У
нашому випадку це природно виникає з аналізу даних: наявність вузького місця,
зростання Lead Time, втрата компетенцій та висока варіативність результатів.
Демонстрація структури зворотних зв’язків (підсилювальної петлі R1 та
симптоматичної B1) допомагає команді не просто побачити проблему, а зрозуміти її
системне походження. Таким чином, усвідомлення необхідності змін базується не на
емоційних аргументах, а на системній логіці.
Другим важливим кроком у моделі є формування коаліції змін — невеликої
групи учасників, які здатні підтримати перехід до нової моделі. У нашому випадку
такою коаліцією виступають не менеджери чи окремі спеціалісти, а група
розробників, які вже пройшли частину аналітичних воркшопів або беруть участь у
декомпозиції. Саме вони можуть слугувати прикладами практичної роботи в новому
процесі та допомагати іншим членам команди адаптуватися.
Наступний етап — формування бачення змін. Для оптимізованої моделі це
бачення полягає в переході від структури, де аналітика зосереджена в одній ролі, до
61

структури, де аналітична спроможність є частиною компетентності всієї команди.
Відповідно, бачення змін складається не з управлінських гасел, а з чіткої схеми
зворотних зв’язків, у якій делегування на BA замінюється розвитком аналітичних
навичок розробників, а фундаментальні рішення набирають перевагу над
симптоматичними.
Комунікація цього бачення є наступним критичним кроком. Важливо, щоб
команда не сприймала зміни як спробу «зекономити на ролі BA» або «перекласти
додаткову роботу на розробників». Комунікація має ґрунтуватися на даних: аналіз
варіативності Lead Time, порівняння поведінки двох команд, розуміння архетипів, які
виникають у поточному процесі. Такий підхід дозволяє підсилити довіру до змін та
зменшити опір.
П’ятий крок — усунення бар’єрів. У традиційних змінах бар’єрами можуть
бути люди, але в нашому випадку головними бар’єрами виступають поведінкові
звички: звичка делегувати складні задачі BA, уникати аналітичної роботи,
використовувати симптоматичні рішення в пікові моменти. Усунення цих бар’єрів
можливе лише через створення системи підтримки, у якій воркшопи, парний аналіз
та стандарти декомпозиції дозволяють команді безпечно переходити до нових
поведінкових патернів.
Шостим етапом у моделі Коттера є створення короткострокових перемог. У
контексті оптимізованої моделі це можуть бути навіть невеликі, але помітні успіхи:
зменшення повернень задач у розробку, скорочення часу в статусі «Ready for Dev»,
зниження кількості дефектів або більш рівномірні спринти. Короткострокові
перемоги підтримують балансуючу петлю B2, пришвидшуючи появу позитивних
ефектів і зменшуючи затримки в системі.
Наступний крок — масштабування змін. Після того як команда починає
стабільно працювати з інтегрованою аналітикою, можна поступово розширювати
практику: виносити воркшопи на рівень продукту, вводити єдині стандарти
декомпозиції на декількох командах або формувати внутрішніх фасилітаторів аналізу
62

серед розробників. Масштабування відбувається природно, коли фундаментальні
практики стають частиною культури.
Останнім елементом моделі Коттера є закріплення змін у культурі. У нашій
моделі це означає формування стійкого переконання, що аналітика — це не зовнішня
функція, а невід’ємна частина інженерної роботи. Закріплення змін відбувається тоді,
коли команда більше не розглядає делегування на BA як «легший» варіант, а навпаки
— бачить ризик у поверненні до старої структури. Саме на цьому етапі система
досягає стадії саморегуляції, де поведінкові та структурні зміни починають
підтримувати одна одну.
Застосування моделі Коттера у поєднанні з системним аналізом дозволяє
розглядати впровадження не як лінійний проєкт змін, а як еволюційний процес, у
якому кожен крок впливає на структуру зворотних зв’язків. Оскільки основною
метою оптимізованої моделі є не просто скорочення Lead Time, а зміна самої
конфігурації процесу, саме такий підхід є найбільш відповідним. Він забезпечує не
лише успішний перехід до нової моделі, а й стійкість цієї моделі у довгостроковій
перспективі.
Висновок до розділу 3
У третьому розділі було проведено комплексне оцінювання ефективності
запропонованої оптимізованої моделі роботи команди, що базується на зміні
структури зворотних зв’язків та поступовому демонтажі ролі бізнес-аналітика як
окремого вузького місця. Аналіз сценаріїв, порівняння двох команд та визначення
точок важеля продемонстрували, що поведінка Lead Time значною мірою
визначається не обсягом задач чи інтенсивністю роботи окремих ролей, а саме
архітектурою процесу та характером прийняття рішень у команді. Поточний
сценарій, у якому основна частина аналітичної роботи була зосереджена у бізнес-
аналітиків, відтворював підсилювальні петлі залежності, що сприяли деградації
навичок команди та створювали невідворотні черги у ранніх фазах потоку. Навіть із
двома BA команда демонструвала значну варіативність Lead Time та високу
чутливість до змін навантаження. Системне моделювання показало, що ці затримки
63

не є випадковими, а виникають через структурні взаємозв’язки, описані петлями B1
та R1.
Натомість у оптимізованому сценарії, де аналітична спроможність була
інтегрована в роботу розробників, система набула стійкості та здатності до
саморегуляції. Регулярні воркшопи, колективна декомпозиція задач та відмова від
швидких симптоматичних рішень активували балансуючу петлю B2, яка протидіє
зростанню навантаження та забезпечує довгострокове зменшення Lead Time.
Емпіричні дані другої команди підтвердили ці висновки: зменшилися як середній
Lead Time, так і його варіативність, скоротилась кількість повернень задач та
дефектів, а процес став рівномірнішим і передбачуванішим.
Виявлені точки важеля показали, що найбільший ефект дають зміни,
спрямовані на структуру процесу, а не на збільшення кількості ресурсів або
прискорення окремих етапів. Розвиток аналітичних навичок команди, відмова від ролі
BA та скорочення затримок у фундаментальних рішеннях є стратегічними важелями,
що трансформують поведінку всієї системи. Адаптація моделі впровадження змін
Коттера дозволила описати не лише технічні, а й поведінкові аспекти трансформації,
забезпечуючи можливість її стійкого закріплення.
Результати третього розділу підтвердили, що скорочення Lead Time у складних
продуктових командах досягається шляхом зміни самої конфігурації зворотних
зв’язків процесу. Впровадження оптимізованої моделі створює умови, за яких
команда може підтримувати стабільний, передбачуваний потік робіт, швидше
адаптуватися до змін та уникати системних пасток, характерних для традиційних
підходів. Це формує основу для стійкого розвитку процесу та підвищення загальної
ефективності продуктового циклу.
64

ВИСНОВКИ
У магістерській роботі було проведено всебічне дослідження динаміки Lead
Time у продуктових командах та визначено ключові структурні чинники, які
впливають на стабільність і передбачуваність процесу розробки за допомогою CLD.
Аналіз теоретичних підходів до вимірювання часових метрик, поняття потоку
створення цінності та принципів системного аналізу створив основу для виявлення
системних закономірностей, що визначають поведінку розробницьких процесів у
довгостроковій перспективі.
У другому розділі на основі реальних даних було проаналізовано структуру
процесу команди до поділу та виявлено критичне вузьке місце на етапі Business
Analysis. Дані Actionable Agile показали, що саме цей етап формує найбільшу частину
загального Lead Time. Разом з тим аналіз системних архетипів продемонстрував, що
затримки мають глибинну природу й не можуть бути усунуті стандартними
«локальними» управлінськими втручаннями. Побудована CLD-модель поточного
стану дозволила структурувати ідеї про взаємодію симптоматичних та
фундаментальних рішень, їхні побічні ефекти та роль часових затримок у формуванні
негативних підсилювальних петель.
Поділ команди на два підпродукти в межах єдиної кодової бази створив
можливість для природного експерименту. Одна команда продовжила працювати у
традиційній структурі з бізнес-аналітиком, тоді як інша перейшла до моделі, у якій
аналітичні функції були інтегровані у роботу розробників. Порівняння цих команд
виявило суттєву різницю у поведінці Lead Time: команда зі збереженою роллю BA
демонструвала високу варіативність, більшу кількість повернень задач та значні
затримки у ранніх статусах. Натомість команда з інтегрованою аналітикою досягла
більш передбачуваного й стабільного потоку, зменшення середнього Lead Time та
зниження кількості дефектів.
У третьому розділі було сформовано оптимізовану CLD-модель, яка описує
перехід до системи без бізнес-аналітика та підсилення фундаментальної петлі
розвитку навичок. Модель продемонструвала, що розвиток компетенцій у роботі з
65

вимогами, зменшення залежності від вузьких ролей та вирівнювання потоку задач є
ключовими точками важеля для зменшення Lead Time. Впровадження цієї моделі
було розглянуто через призму теорії змін Джона Коттера, що дозволило врахувати не
лише структурні, а й поведінкові аспекти трансформації.
Загалом робота показала, що скорочення Lead Time є не стільки технічною,
скільки системною проблемою. Зміна конфігурації процесу, розвиток аналітичних
навичок у команді, відмова від поверхневих рішень та впровадження практик, що
мінімізують часові затримки, мають значно більший вплив на стабільність потоку,
ніж збільшення кількості спеціалістів або локальна оптимізація окремих етапів.
Запропонована оптимізована модель дозволяє формувати передбачувану, стійку
систему, яка знижує залежність від індивідуальних ролей та забезпечує більш
рівномірний процес створення цінності.
Результати порівняння двох команд підтвердили практичну ефективність
оптимізованої моделі. Команда, яка інтегрувала аналітичні функції всередині себе та
відмовилася від ролі бізнес-аналітика, продемонструвала стабільніше проходження
задач через усі статуси, скорочення середнього Lead Time з 51 до 32 днів, а також
суттєве зниження варіативності (з ±19 до ±7 днів). Частка повернень задач у ранні
фази процесу зменшилася з 27% / 18% до 8% / 6%, що свідчить про покращення
якості декомпозиції та зменшення кількості повторних циклів обробки. Кількість
дефектів на одну задачу скоротилася з 0,7 до 0,3, що відображає вплив колективної
роботи над вимогами та зниження ризиків, пов’язаних із вузькими ролями. Отже,
оптимізована модель не лише підтвердила свою ефективність у теоретичному
моделюванні, але й продемонструвала суттєві покращення ключових метрик у
реальних умовах роботи команди.
Таким чином, результати дослідження підтверджують, що застосування
системного аналізу до оптимізації Lead Time дозволяє виявити глибинні механізми
затримок і сформувати ефективніші стратегічні рішення. Створена оптимізована
CLD-модель може бути використана як інструмент для удосконалення процесів у
66

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

67

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. Clark K. B., Fujimoto T. Product Development Performance: Strategy,
Organization, and Management in the World Auto Industry. – Boston:
Harvard Business School Press, 1991. – 284 p. – С. 45–58.
2. McManus H. L. Product Development Value Stream Mapping (PDVSM). –
Cambridge, MA: The Lean Aerospace Initiative, Massachusetts Institute of
Technology, 2005. – 35 p. – С. 12–25.
3. Womack J. P., Jones D. T. Lean Thinking: Banish Waste and Create Wealth
in Your Corporation. – New York: Simon & Schuster, 2003. – 397 p. – С.
30–50.
4. Wheelwright S. C., Clark K. B. Revolutionizing Product Development:
Quantum Leaps in Speed, Efficiency, and Quality. – New York: The Free
Press, 1992. – 364 p. – С. 70–92.
5. Hopp W. J., Spearman M. L. Factory Physics. – 3rd ed. – Boston: McGraw-
Hill Education, 2008. – 720 p. – С. 253–268.
6. Sommerville I. Software Engineering. – 10th ed. – Boston: Pearson, 2016. –
815 p. – С. 102–104.
7. Lencioni P. The Five Dysfunctions of a Team: A Leadership Fable. – San
Francisco: Jossey-Bass, 2002. – 229 p. – С. 88–93.
8. Kerzner H. Project Management: A Systems Approach to Planning,
Scheduling, and Controlling. – 12th ed. – Hoboken, NJ: John Wiley & Sons,
2017. – 832 p. – С. 45–52.
9. Schwaber K., Sutherland J. The Scrum Guide: The Definitive Guide to
Scrum. – Scrum.org, 2020.
10. Turner J. R. The Handbook of Project Management. – 4th ed. – London:
Routledge, 2014. – 580 p. – С. 47–50.
11. Senge P. M. The Fifth Discipline: The Art and Practice of the Learning
Organization. – New York: Doubleday, 2006. – 445 p. – С. 68–85.
68

12. Sterman J. D. Business Dynamics: Systems Thinking and Modeling for a
Complex World. – Boston: Irwin McGraw-Hill, 2000. – 982 p. – С. 3–12,
85–98.
13. Meadows D. H. Thinking in Systems: A Primer. – Chelsea Green Publishing,
2008. – 218 p. – С. 11–25.
14. Forrester J. W. Industrial Dynamics. – Cambridge, MA: MIT Press, 1961. –
464 p. – С. 15–30.
15. Риженко О. В. Системний аналіз у проектному менеджменті. – Київ:
КНУ ім. Т. Шевченка, 2017. – 180 с.
16. Василенко В. М. Управління складними системами: теорія і практика. –
Харків: ХНЕУ, 2013. – 264 с.
17. 森田正博 (Morita Masahiro). システム思考入門. 東京: 日本経済新聞出版社
, 2016. – 198 p.
18. 山田秀 (Yamada Shu). システムダイナミクスの基礎. 東京: オーム社, 2014. – 210
p.
19. Таран Т. А. Когнітивні викривлення в управлінській діяльності // Вісник
КНУ ім. Т. Шевченка. – 2019. – №12. – С. 45–52.
20. Morecroft J. D. W. Strategic Modelling and Business Dynamics. – Hoboken:
Wiley, 2015. – 504 p.
21. Weick K. E. Sensemaking in Organizations. Thousand Oaks: Sage
Publications, 1995.
22. Nickerson R. S. Confirmation Bias: A Ubiquitous Phenomenon in Many
Guises. Review of General Psychology. 1998. Vol. 2, No. 2.
23. Koriat A., Lichtenstein S., Fischhoff B. Reasons for confidence. Journal of
Experimental Psychology: Human Learning and Memory. 1980. Vol. 6, No. 2
24. Croskerry P. Critical thinking and cognitive bias in clinical decision-making.
Journal of the Royal College of Physicians of Edinburgh. 2013. Vol. 43, No.
2.
69

25. Ross L. The intuitive psychologist and his shortcomings: Distortions in the
attribution process. Advances in Experimental Social Psychology. 1977. Vol.
10
26. Tversky A., Kahneman D. Availability: A heuristic for judging frequency and
probability. Cognitive Psychology. 1973.
27. Петренко Л. Когнітивні упередження у процесі прийняття
управлінських рішень. Психологія і суспільство. 2020
28. Weinberg G. M. An Introduction to General Systems Thinking. New York:
Dorset House Publishing, 2001.
29. Stemplewska-Żakowicz K. Psychologia decyzji. Warszawa: Scholar, 2011.
30. Fischhoff B. Debiasing. Judgment Under Uncertainty: Heuristics and Biases /
eds. Kahneman D., Slovic P., Tversky A. Cambridge: Cambridge University
Press, 1982. P. 422–444.
31. Козак Л. Групове мислення та помилки колективного прийняття рішень.
Психологія і суспільство. 2021. №1. С. 35–43.
32. Tyszka T. Psychologia ekonomiczna. Gdańsk: GWP, 2010.
33. Buehler R., Griffin D., Ross M. Exploring the “planning fallacy”: Why
people underestimate task completion times. Journal of Personality and Social
Psychology. 1994. Vol. 67, No. 3.
34. Kim D. H. Systems Archetypes I: Diagnosing Systemic Issues and Designing
High-Leverage Interventions. Cambridge (MA): Pegasus Communications,
1994. 48 p.
35. Anderson V. A., Johnson L. Systems Thinking Basics: From Concepts to
Causal Loops. Waltham: Pegasus Communications, 1997.
36. Braun W. The Systems Archetypes. System Dynamics Society Papers. 2002.
37. Senge P. The Fifth Discipline: The Art and Practice of the Learning
Organization. New York: Doubleday, 2006.
38. Goodman M. Drifting Goals: A Systems Archetype. The Systems Thinker.
1998.
70

39. Goodman M. Systems Archetypes I: Diagnosing Systemic Issues and
Designing High-Leverage Interventions. Waltham: Pegasus Communications,
1990.
40. Wolstenholme E. F. System Enquiry: A System Dynamics Approach.
Chichester: Wiley, 1990.
41. Repenning N. P., Sterman J. D. Capability traps and self-confirming
attribution errors in the dynamics of process improvement. Administrative
Science Quarterly. 2002. Vol. 47, No. 2. P. 265–295.
42. Krawczyk-Sokołowska I. Myślenie systemowe w zarządzaniu organizacją.
Warszawa: Difin, 2015.
43. Hardin G. The Tragedy of the Commons. Science. 1968.
44. Kostera M., Śliwa M. Zarządzanie w XXI wieku: wizje, dylematy, wyzwania.
Warszawa: PWN, 2014
45. Рачинська Г. А. Самопідсилювальні процеси в управлінні організаціями.
Вісник Київського національного економічного університету. 2018. №5.
С. 74–82.
46. Ossimitz G. The Development of Systems Thinking Skills Using System
Dynamics Modeling Tools. Proceedings of the International System
Dynamics Conference. 2002.
47. Lane D. C. The Emergence and Use of Diagramming in System Dynamics: A
Critical Account. Systems Research and Behavioral Science. 2008.
48. Stacey R. D. Strategic Management and Organisational Dynamics. Harlow:
Pearson Education, 2011.
49. Hinze J. Requirements Engineering: Fundamentals, Principles, and
Techniques. Berlin: Springer, 2019.
50. Hinze J. Requirements Engineering: Fundamentals, Principles, and
Techniques. Berlin: Springer, 2019.
51. 野中郁次郎・竹内弘高 (Nonaka I., Takeuchi H.). 知識創造企業 (The
Knowledge-Creating Company). 東京: 東洋経済新報社, 1996.
71

52. Repenning N. P., Sterman J. D. Nobody Ever Gets Credit for Fixing Problems
that Never Happened: Creating and Sustaining Process Improvement.
California Management Review. 2001. Vol. 43
53. Kotter J. P. Leading Change. Boston: Harvard Business School Press, 1996.

ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets