Заняття 15. Від плану епіку до повної оцінки проєкту: діаграма Ганта, оцінка задач і ризиків, кошторис команди

3 листопада 2026 · підготовлений конспект заняття · ≈ 1 год 30 хв (план). Цей матеріал не є конспектом за транскриптом. Його підготовлено до заняття на прохання викладача: це продовження логіки занять 01–14, насамперед 05, 12, 13 і 14. Наскрізний приклад — роботизована комірка з маніпулятором, комп’ютерним зором і AI, що працює on-premise на NVIDIA Jetson і ROS 2. Усі тривалості, ставки й суми — навчальна ілюстрація, а не ринкові дані. Їх пораховано в Excel-моделі та скрипті Monte Carlo (див. «Матеріали заняття»). Після проведення заняття фактичний виклад буде додано окремим датованим блоком; цей текст не переписуватиметься. Редакторські уточнення позначено окремо.

0. Місце заняття в курсі

Заняття 14 завершилося детальним планом EPIC 1 із 29 етапів і gates G1–G4. Там же прозвучало, що в embedded-проєкті з механікою та hardware одного епіку не буває, — мінімум три. На це заняття було анонсовано EPIC 2 і наступні епіки, діаграму Ганта, формування команди та специфікації інженерів. Сьогодні замикаємо ланцюжок, який курс будував із вересня:

Маршрут заняття: кейс → епіки й WBS → оцінка задач → діаграма Ганта → ризики → команда та її вартість → повна оцінка й повний таймінг → лайфхаки.

1. Кейс: роботизована комірка з CV+AI, on-premise, Jetson, ROS 2

Ми продовжуємо лінію заняття 06 (робот-маніпулятор із кастомним end effector), але беремо інший, більш «виробничий» запит. Умовний замовник — виробник металевих і пластикових деталей. Він хоче пілотну комірку:

• колаборативний 6-DoF робот (готовий, купується) бере деталі з лотка;
• камери й CV/AI-модель розпізнають тип деталі, її положення й видимі дефекти;
• робот розкладає деталі по тарах, брак — окремо;
• оператор бачить на HMI завдання, тривоги й звіти;
• усі дані лишаються на заводі: жодного cloud, навчання моделей — на власному сервері замовника (on-premise);
• інференс виконується на NVIDIA Jetson поруч із камерами;
• інтеграційна платформа — ROS 2: замовник уже має інші комірки на ROS 2 і хоче єдиний стек.

Обмеження — це не вимоги

Заняття 06 застерігало: назва технології сама по собі не є вимогою. Тут Jetson, ROS 2 і on-premise висуває замовник, і має на це причини: політика даних, наявний стек, сервісна команда. Тому фіксуємо їх як design constraints (обмеження проєктування) з обґрунтуванням, а не як функціональні вимоги:

Редакторське уточнення. Оцінку ризиків машини проводять за ISO 12100; вимоги безпеки до промислових роботів і роботизованих застосувань містять ISO 10218-1:2025 і ISO 10218-2:2025 (третє видання, лютий 2025 року). Функції безпеки систем керування оцінюють за ISO 13849-1. Конкретний перелік стандартів визначає safety-інженер для конкретного застосування; у курсі вони — лише reference basis (заняття 05), а не готовий висновок.

Редакторське уточнення щодо ROS 2. Чинні LTS-дистрибутиви — Jazzy Jalisco (травень 2024) та Lyrical Luth (22 травня 2026, підтримка до травня 2031). Платформа Tier 1 для Lyrical — Ubuntu 26.04. Базова версія Ubuntu в JetPack вашого модуля Jetson може не збігатися з Tier 1 платформою обраного дистрибутива. Тоді доводиться вирішувати: контейнери, збирання з вихідного коду чи інший дистрибутив. Це класичне питання PoC: заняття 14 формулювало його так — «чи є під цю ОС нормальний компілятор».

2. Від списку етапів до WBS і трьох епіків

На занятті 14 план EPIC 1 був списком етапів. Щоб отримати діаграму Ганта й кошторис, кожен рядок має стати робочим пакетом (work package) з п’ятьма атрибутами:

1. ID і назва — що саме робимо;
2. тривалість — три оцінки O / M / P (розділ 3);
3. залежності — після чого задача може початися;
4. ролі та завантаження — хто й на яку частку ставки (FTE) працює;
5. тип — робота (work), очікування (wait) або контрольна точка (gate).

Для нашого кейсу проєкт розкладається на три епіки, як і прогнозувало заняття 14:

Повна WBS — 34 робочі пакети. Ось її скорочений вигляд (повна таблиця з усіма полями — у робочому файлі Excel):

Скорочення ролей: PM — delivery / engineering manager, SA — system architect, ROS — robotics engineer (ROS 2, MoveIt 2), CV — CV/ML engineer, SW — software engineer (HMI, on-prem, MLOps), FW, HW, ME — firmware, hardware, mechanical engineer, SAF — safety engineer, QA — інженер V&V, TECH — технік-асемблер (заняття 14), PROC — procurement manager.

Три практичні правила побудови WBS:

• Розмір пакета. Робочий пакет оцінюють тоді, коли його можна виконати й перевірити за кілька днів або кілька тижнів. Якщо інженер каже «три місяці», пакет треба дробити далі. Виняток — задачі очікування: виробництво плати триває 3–5 тижнів, і дробити його немає сенсу.
• Очікування — окремий рядок. Виробництво, доставка, розмитнення майже не мають трудовитрат, але мають календарну тривалість. Якщо їх не винести окремо, вони «з’їдять» час, якого в плані немає.
• Інтеграція — окремий рядок. Сума підсистем не дорівнює системі: «склеювання» займає реальний час (у нас — пакет 3.1, приблизно три тижні).

3. Оцінка задач: від «2–10 днів» до PERT

Хто оцінює

Заняття 12 назвало проблему відповідальності за оцінку: зовнішній експерт може недооцінити задачу, бо робитиме її не він. Звідси правило: оцінює той, хто виконуватиме, а перевіряє той, хто вже робив подібне. Якщо команди ще немає, оцінку дають core team із pre-sale (заняття 06) і, за потреби, оплачені зовнішні експерти. Їхні оцінки позначають як припущення, які треба переглянути після найму.

Три точки замість однієї

Інженер, який каже «від 2 до 10 днів», насправді вже дав оптимістичну (O) і песимістичну (P) оцінки. Бракує найімовірнішої (M). Метод PERT поєднує їх так:

E = (O + 4M + P) / 6, σ = (P − O) / 6,

де E — очікувана тривалість, а σ — міра її невизначеності. Приклади з нашої WBS:

Тривалості тут — у робочих днях. Зверніть увагу: E завжди зсунуто від M у бік P, бо ризики «вправо» в інженерії довші, ніж ризики «вліво». Задача не може завершитися швидше за нуль днів, а от затягнутися може як завгодно.

Редакторське уточнення. PERT (Program Evaluation and Review Technique) розроблено наприкінці 1950-х років для програми Polaris ВМС США. Формула E = (O + 4M + P) / 6 — наближення бета-розподілу, а не закон природи. Вона корисна, бо змушує назвати діапазон і робить асиметрію ризику видимою.

Трудовитрати, тривалість і календар — три різні числа

Якщо інженер оцінює в «ідеальних годинах» — без зустрічей, рев’ю й перемикань, — оцінку ділять на фокус-фактор (зазвичай 0,7–0,8). У нашій моделі O/M/P одразу дано в реальних робочих днях.

Як оцінювати AI-задачі

Точність моделі не оцінюється в днях: ніхто не знає наперед, скільки днів потрібно, щоб отримати 99,0 % на відблискових металевих деталях. Тому оцінюють експеримент, а не результат:

• пакет 2.16 — це «датасет v1 + три ітерації дані → навчання → оцінка», обмежені в часі (time-box);
• точність, досягнуту після трьох ітерацій, виносять на рев’ю: або вимогу досягнуто, або це ризик R2 з окремим планом (розділ 5);
• PoC-A (1.6) знімає головну невизначеність раніше: чи вкладається модель у 150 мс на Jetson після оптимізації під TensorRT.

4. Діаграма Ганта: залежності, критичний шлях, gates

Як будувати

1. Розставити залежності. Здебільшого це «фініш → старт»: задача B починається після завершення A.
2. Прямий прохід: ранній старт задачі ES — це найпізніший із ранніх фінішів її попередників; ранній фініш EF = ES + E.
3. Зворотний прохід: від фінішу проєкту назад отримуємо пізній старт LS і пізній фініш LF.
4. Резерв часу (float) = LS − ES. Задачі з нульовим резервом утворюють критичний шлях: будь-яка затримка на ньому зсуває весь проєкт.
5. Позначити gates і приймання (FAT, SAT) як віхи.

Що видно на діаграмі

Критичний шлях іде через hardware і механіку, а не через software:

1.1 → 1.2 → 1.3 → 1.4 → 1.6 → 1.8 → 2.1 → 2.2 → 2.4 → 2.6 → 2.7 → 2.8 → 2.13 → 2.14 → 3.1 → 3.3 → 3.4 → 3.5 → 3.6 → 3.7 → 3.8.

Довжина критичного шляху за PERT — 195,7 робочого дня ≈ 39,1 тижня. Водночас ПЗ комірки (2.15) має 38 днів резерву, датасет і навчання (2.16) — 54 дні, on-prem сервер (2.17) — 65 днів. Це ілюструє тезу заняття 05: Gantt для embedded залежить від речей, які не пришвидшуються додаванням ще одного software engineer.

Редакторське уточнення. Закон Брукса («додавання людей до проєкту, що запізнюється, ще більше його затримує», F. Brooks, The Mythical Man-Month, 1975) тут діє в посиленій формі: виробництво плати у вендора не скоротиться, хоч би скільки програмістів ви додали.

Довгі закупівлі мають резерв, якщо замовити їх вчасно. Пакет 2.3 (кобот, виробничий модуль Jetson, сканер безпеки) стартує одразу після G4 і має 40,8 дня резерву. Якщо ж «за звичкою» замовити кобот після рев’ю механіки (2.7), цей пакет сам стане критичним і зсуне проєкт. Це перший лайфхак (розділ 8).

Gates на діаграмі:

Усе, що праворуч від gate, — умовний план. Заняття 13 нагадувало, що gates змінюють будь-які правила. Тому деталізуємо найближчий горизонт (EPIC 1 — до дня), а далекий — крупними пакетами. Після кожного gate план уточнюють (rolling wave planning — «планування хвилями»). Так на практиці працює звуження конуса невизначеності.

5. Оцінка ризиків проєкту: реєстр, резерв і Monte Carlo

HARA і реєстр ризиків проєкту — різні таблиці

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

Реєстр ризиків кейсу

EMV (expected monetary value) = імовірність × вплив. Наївна сума EMV — 27,3 дня. Але це переоцінка: ризики R1, R4 і R7 б’ють по задачах із великим резервом і фініш проєкту не зсувають. Отже, вплив ризику на дату залежить від того, де він стоїть на діаграмі Ганта. Порахувати це вручну складно, тому застосовують симуляцію.

Monte Carlo: дата як імовірність

Ідея проста: 20 000 разів «програти» проєкт. Щоразу кожна тривалість випадково обирається з діапазону O…P (за розподілом PERT), кожен ризик «спрацьовує» з власною імовірністю, а критичний шлях перераховується. Результат — не одна дата, а розподіл дат.

Сходинки від наївної дати до чесної:

Три висновки:

1. Оцінка за M — найоптимістичніша з «розумних». Навіть без ризиків у неї приблизно 7 % шансів справдитися, у повній моделі — менше 1 %. План за PERT E у повній моделі справджується лише приблизно в 5 % прогонів (рис. 15.3).
2. Паралельні гілки зсувають дату вправо (merge bias). За класичною формулою PERT для одного критичного шляху σ ≈ 7,3 дня, і P80 ≈ 201,8 дня. Симуляція дає 204,1: дату «підтягують» паралельні гілки, які в деяких прогонах стають критичними. Наприклад, PoC-B (1.7) потрапляє на критичний шлях у 36 % прогонів, виробництво механіки (2.9) — у 22 %.
3. Незалежні задачі — ілюзія. Оцінки однієї команди помиляються в один бік: однаковий оптимізм, один ринок, той самий замовник. Спільний множник для всіх робочих задач розширює розподіл. Саме тому досвідчений виконавець закладає коридор ±30 % на T&M^ (заняття 13), хоча «чиста» симуляція незалежних задач дає вужчий.

Редакторське уточнення. У термінах PMI резерв на відомі ризики з реєстру — це contingency reserve, а резерв на невідомі — management reserve; другий зазвичай не входить у базовий план і контролюється керівництвом. Параметри спільного фактора оптимізму (0,95 … 1,25) у нашій моделі — навчальне припущення, а не статистика. У реальній компанії його калібрують за історією власних проєктів: відношення фактичних тривалостей до оцінених.

6. Команда та її кошторис

Формування команди з діаграми Ганта

Склад команди — не список «кого хочеться», а наслідок WBS: кожна роль з’являється тоді, коли її вимагає робочий пакет. Графік завантаження (resource histogram) отримують, підсумувавши FTE усіх задач за кожен тиждень.

Що з цього випливає для формування команди:

• Core team з pre-sale (SA, ROS, CV, PM) потрібна з першого тижня. Саме вони бачили проблему замовника (заняття 06).
• Перший тиждень ролі — це deadline найму. HW-інженер потрібен із 4-го тижня, механік — із 6-го, FW — із 10-го, технік — із 13-го. Якщо найм займає кілька тижнів, вакансію відкривають ще під час pre-sale. Інакше старт проєкту зсувається (заняття 06: «не обіцяти старт у понеділок, якщо команди ще немає»).
• Пік більше 1,0 FTE означає рішення: друга людина, перенесення задачі в межах резерву або зовнішній виконавець.
• Провал завантаження — теж рішення: на час виробництва людей тимчасово переводять на інший проєкт або заповнюють провал роботами з резервом часу (розділ 8, лайфхак 3).

Собівартість і ціна людино-дня

Заняття 13 відкрило «таємницю» сервісного бізнесу: інженер отримує однакову зарплату за будь-якої моделі контракту — різниться маржа. Тому в кошторисі завжди два стовпці:

• собівартість дня (cost rate) — зарплата, податки, обладнання, частка офісу, адміністрації, юристів і фінансів;
• ціна дня для замовника (sell rate) — собівартість плюс маржа.

Ставки — навчальна ілюстрація в тому ж дусі, що й «400 доларів на день» із заняття 12. Співвідношення ціни до собівартості в прикладі — приблизно 1,8. Це число залежить від компанії, ринку й моделі контракту, і його не варто сприймати як норму.

Не лише люди: матеріали й вендори

Заняття 05 нагадувало: embedded-оцінка має щонайменше чотири ресурсні шари — люди, матеріали, зовнішні послуги, час і залежності. Заняття 14 рекомендувало брати вендорську частину в T&M.

Суми умовні; реальні значення беруть із комерційних пропозицій на дату RFQ.

7. Повна оцінка проєкту і повний таймінг

Тепер збираємо все в одну відповідь замовнику: скільки, коли й за якою моделлю.

Сходинки кошторису

1. Трудовитрати за ролями (розділ 6) → собівартість і ціна праці.
2. + матеріали та вендори (pass-through за T&M + плата за закупівельний супровід).
3. + резерв на ризики — через симуляцію, а не через «+20 % на все».
4. Ціна за фазою відповідно до моделі контракту із занять 13–14: FP там, де захищають gates або все під вашим контролем; T&M^ там, де багато залежностей; T&M для вендорів.

Правило ціни: P50 і P80

Monte Carlo дає не тільки розподіл дат, а й розподіл вартості праці для кожної фази: тривалості змінюються — змінюються й людино-дні. Звідси просте правило:

• T&M^: оцінка = P50, верхня межа («шапочка») = P80;
• Fixed Price: ціна = P80 × (1 + премія); премія (у прикладі 10 %) покриває штрафи й репутаційний ризик (заняття 13).

Для внутрішнього контролю: собівартість праці за P50 — ≈ 213 500 €, за P80 — ≈ 228 000 €. Різниця між ціною та собівартістю — маржа, з якої утримуються офіс, адміністрація, юристи й фінанси, а частина якої йде на покриття ризиків (заняття 13).

Редакторське уточнення. Відношення P80/P50 вартості праці у фазах нашого прикладу — від 1,07 до 1,15, тобто вужче за ±30 % із практики викладача (заняття 13). Модель ураховує лише відомі ризики й один спільний фактор оптимізму. Ринкові зміни ставок, зміни scope з боку замовника й «невідоме невідоме» в ній відсутні. Тому ±30 % для T&M^ — розумний захист, а не жадібність. Правило P50/P80 — спосіб обґрунтувати коридор цифрами, а не замінити домовленість.

Повний таймінг

Старт — 11.01.2027; дати пораховано за п’ятиденним робочим тижнем без свят і відпусток. У реальному плані їх додають до календаря проєкту окремо.

Зобов’язання замовнику — P80: 47 тижнів, 6 грудня 2027 року. Порівняйте з грубим таймлайном заняття 13 (12 місяців): розрахунок дав близький порядок, але тепер кожне число має пояснення. Саме цього вимагало заняття 05: «Кожна велика цифра повинна мати пояснення: звідки вона взялася і що її змінить».

Як показати це замовнику

Одна сторінка, у якій немає жодної «голої» цифри:

1. Фази й gates на осі часу (рис. 13.1 із заняття 13, але з розрахованими датами).
2. Діапазон, а не точка: «P50 — середина листопада, P80 — початок грудня 2027 року; ми зобов’язуємося на P80».
3. Ціна за фазами й моделями — таблиця вище.
4. Припущення: старт 11.01.2027; core team доступна; замовник надає зразки деталей і доступ до майданчика до G1; IT-погодження сервера — до 13-го тижня; кобот обирається після PoC-B.
5. Виключення: серійне тиражування комірок, підтримка після передачі, сертифікація поза погодженим переліком.
6. Правило перегляду: після кожного gate оцінку оновлюють, і нова версія proposal отримує новий номер (заняття 12: версіонування).

8. Лайфхаки

1. Довгі позиції — у перший день після gate. Довгі закупівлі (кобот, виробничий Jetson, сканер безпеки) запускаються одразу після G4, а не тоді, коли «все спроєктовано». У нашому плані це дає 40,8 дня резерву; замовлення після рев’ю механіки зробило б їх критичними. PoC-комплект замовляємо ще після G1, паралельно з вимогами: dev kits і камери продаються «з полиці» і не залежать від рішень щодо архітектури. Дорогі позиції варто запропонувати купити замовнику напряму (customer-furnished equipment, CFE): він не платить вам комісію, а ви не тримаєте на балансі 30 000 € чужого робота. Але строк його поставки тоді стає припущенням у proposal, і це треба прямо записати.

2. Буфер — один і в кінці, а не в кожній задачі. Якщо кожен інженер «на всяк випадок» додасть 20 %, проєкт не стане надійнішим. Діє закон Паркінсона: робота займає весь відведений час. Резерв, розмазаний по задачах, витрачається непомітно. Чесніше планувати за PERT E, а різницю до P80 тримати одним проєктним буфером перед датою зобов’язання (сіра смуга на рис. 15.2). Тоді його витрату видно, і нею можна керувати: «з’їли 40 % буфера на 60 % шляху — тривога».

Редакторське уточнення. Ідея проєктного й живильних (feeding) буферів походить із методу критичного ланцюга (Critical Chain Project Management) Еліягу Голдратта (Critical Chain, 1997).

3. Заповнюйте провал завантаження задачами з резервом. На рис. 15.4 у тижні 20–23 команда майже простоює (≈ 1,4 FTE): усі чекають на виробництво. Задача 2.16 «датасет і навчання» має 54 дні резерву. Якщо зсунути її на 25 робочих днів, пік знижується з 6,4 до 6,0 FTE, провал заповнюється до 2,9 FTE, а дата фінішу не змінюється. Бонус: CV-інженер знімає датасет уже на виробничих камерах. Це і є вирівнювання ресурсів (resource leveling) — головна причина рахувати резерв часу.

4. P50 — для T&M, P80 — для Fixed Price. Не вигадуйте ціну з «відчуття ризику», а беріть її з розподілу: P50 — чесна оцінка для T&M^, P80 — верхня межа T&M^ і основа ціни FP. Так розмова із замовником переходить з «чому так дорого» на «яку ймовірність ви хочете купити».

5. Симуляція до заліза й один контейнер на два світи. ROS 2 дає змогу почати ПЗ комірки й MVP на симуляторі (Gazebo, NVIDIA Isaac Sim) задовго до приходу кобота. Це етап «модель / віртуалізація» з плану EPIC 1 (заняття 14). Збирайте один і той самий контейнерний образ для робочої станції розробника (x86) і для Jetson (arm64). Тоді «на моєму комп’ютері працює» перестає бути ризиком інтеграції.

6. Excel → Jira через CSV. Викладач рекомендує планувати в Excel (заняття 14). Якщо одразу тримати в таблиці стовпці Summary, Issue Type, Epic / Parent, Original Estimate, Assignee, план переноситься в Jira стандартним імпортом із CSV без ручного перенабору. Це міст до анонсованої міграції плану в Jira.

Практичні висновки

• Список етапів стає планом, коли кожен рядок має тривалість O/M/P, залежності, ролі з FTE і тип: робота, очікування або gate.
• Оцінює виконавець; три точки PERT роблять невизначеність видимою; AI-задачі оцінюють як обмежені в часі експерименти, а не як досягнення точності.
• Тривалість, трудовитрати й календар — три різні числа; їх не можна плутати.
• Критичний шлях embedded-проєкту зазвичай іде через hardware, механіку й вендорів; software часто має великий резерв часу.
• Реєстр ризиків проєкту — не HARA; вплив ризику на дату залежить від резерву задачі, тому наївна сума EMV переоцінює вплив, а незалежні задачі недооцінюють розкид.
• Monte Carlo перетворює дату на ймовірність: зобов’язання — P80, а не найімовірніший план.
• Склад команди виводиться з графіка завантаження; перший тиждень ролі — deadline найму.
• Ціна — це собівартість праці плюс маржа, матеріали й вендори; модель контракту обирають для кожної фази: FP із P80 і премією, T&M^ з P50 і межею P80, T&M для вендорів.
• Повна оцінка — одна сторінка з діапазонами, припущеннями, виключеннями й правилом перегляду після кожного gate.

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

• Які п’ять атрибутів має робочий пакет у WBS?
• Чому виробництво й доставку виносять в окремі рядки «очікування»?
• Як із «від 2 до 10 днів» отримати PERT-оцінку і чого для цього бракує?
• Чим тривалість відрізняється від трудовитрат і від календарної дати?
• Як оцінювати задачу «досягти точності 99 %» для CV-моделі?
• Як знайти критичний шлях і що таке резерв часу?
• Чому в нашому кейсі критичний шлях проходить через плату й механіку, а не через ПЗ?
• Чим HARA відрізняється від реєстру ризиків проєкту?
• Чому наївна сума EMV переоцінює вплив ризиків на дату?
• Що таке merge bias і чому симуляція дає пізнішу дату, ніж формула PERT для одного шляху?
• Навіщо в моделі спільний фактор оптимізму?
• Як із графіка завантаження отримати склад команди і графік найму?
• Чим собівартість людино-дня відрізняється від ціни для замовника?
• Як P50 і P80 перетворюються на ціну для FP і T&M^?
• Що має бути на одній сторінці повної оцінки для замовника?

Практичне завдання для команд

Для «компанії», яку ваша команда веде з заняття 06, і для кейсу з експертної зустрічі (заняття 12):

1. Розкладіть проєкт щонайменше на три епіки і 20–35 робочих пакетів; для кожного вкажіть O/M/P, залежності, ролі й FTE.
2. Побудуйте діаграму Ганта (Excel із робочого файлу заняття), знайдіть критичний шлях і задачі з найбільшим резервом.
3. Складіть реєстр із 6–10 ризиків проєкту; позначте, які з них поглинає резерв.
4. Отримайте графік завантаження й таблицю ролей; визначте, з якого тижня потрібна кожна роль.
5. Порахуйте собівартість і ціну за фазами, оберіть модель контракту для кожної фази й обґрунтуйте її.
6. Підготуйте одну сторінку для замовника: фази, gates, P50/P80, ціна, припущення, виключення.

Прогноз наступних занять

Прогноз станом на 03.11.2026, а не опис проведених занять:

• перенесення плану в Jira або GitHub Project: епіки → історії → задачі, оцінки, спринти; зв’язок плану з backlog;
• найм і формування команди: специфікації ролей (job descriptions) за графіком завантаження, onboarding, kick-off із замовником;
• далі — перехід до модуля 06: реалізація, інтеграція, тестування, випуск.

Матеріали заняття

• Excel-модель оцінки пілотної комірки (WBS із PERT, критичний шлях, діаграма Ганта на умовному форматуванні, команда, ризики, матеріали, підсумок): завантажити .xlsx
• Скрипт моделі та симуляції Monte Carlo (Python, без зовнішніх залежностей): завантажити .py

Перевірені посилання

• ROS 2 Lyrical Luth released (Open Robotics Discourse, 22.05.2026): https://discourse.openrobotics.org/t/ros-2-lyrical-luth-released/55021
• ROS 2 documentation (Jazzy): https://docs.ros.org/en/jazzy/
• ISO 10218-1:2025, Robotics — Safety requirements — Part 1: Industrial robots: https://www.iso.org/standard/73933.html
• Jira Cloud — Import data from a CSV file (Atlassian Support): https://support.atlassian.com/jira-cloud-administration/docs/import-data-from-a-csv-file/
• S. McConnell. The Cone of Uncertainty (Construx, white paper): https://www.construx.com/wp-content/uploads/2019/02/CxWhitePaper_ConeOfUncertainty.pdf