---
title: "IgorSikorskyKPI_28102026"
source_video: IgorSikorskyKPI_28102026.mp4
source_audio: IgorSikorskyKPI_28102026.mp3
duration: 01:34:00
language: uk
language_probability: 0.846
model: large-v3
device: cuda
transcribed_at: 2026-10-28T10:25:22
segments: 722
editorial_note: "Фрагменти з описом навчального прикладу вилучено автором; місця позначено квадратними дужками."
paragraphs: 73
status: draft   # draft | reviewed | published
tags: [лекція, транскрипт]
---

# IgorSikorskyKPI_28102026

Тривалість: 01:34:00 · Мова: uk · Модель: large-v3

> Автоматичний транскрипт. Потребує вичитки перед використанням у навчальних матеріалах.

## Транскрипт

**[00:01:44]**

Хлопці, як справи? Все добре. Йаєте ви в Києві чи ви тут десь? Часом не ходите? Куди-куди? В гори, в Карпати. Я сам з Тернополя, то раніше часто їздив. Куди ходили? Останній раз на Петро всій були.

**[00:02:31]**

Це із Квасів чи звідки заходили? Я щось не скажу, не пам'ятаю вже. Ну там 17 км маршрут. Хороше діло, хороше діло. А доки є шанс, скажімо так, доки є час вільний, то ходіть. Штука дуже корисна для всього. Що ж, добре, думаю ще 2-3 хвилинки зачекаємо і розпочнемо. Ви ходили, чи ходите, у вас є якась збита група, чи ви як екскурсія, як це йшло?

**[00:03:27]**

День, просто з товаришами, з керівниками зібралися і пішли. Добрий ранок! Добрий ранок!

**[00:03:52]**

Ще десь дві хвилинки чекаємо, розпочнемо. Я пропоную розпочинати, тож всім доброго дня. Перш за все, знову ж нагадую, що заняття записується, до відео у вас є доступ, також я роблю автотранскрипт для конспекту, у вас до нього є теж доступ, тож користуйтеся. На виході з цього курсу, напевно, я займуся якоюсь металичкою, вона у вас буде теж.

**[00:05:21]**

В якійсь мірі, як мінімум, постараємося, щоб матеріали у вас були достатні. Раптом комусь колись для чогось це буде корисне. Також нагадую щодо ризиків. Ризики пов'язані із повітряними тривогами, тож будьте обачні, будьте пильні. Щось розпочнеться, відповідно, забезпечте максимізацію ваших ризиків бути неушкодженими. Відповідно, наразі в Києві немає тривоги, тож розпочнемо. Я поширю скрин, сподіваюся, вам його видно. І я повернуся до нашого вчорашнього матеріалу, просто щоб пробітися оперативно. До речі, доступ до цього файла у вас також є. Я його також вигрузив на Google Drive, а по закінченню курсу я його вигружу на свій сервер з FTP, Тепер лінк буде на сайті, тож зможете, якщо раптом десь чомусь вам воно буде цікаве, до цього повернутися.

**[00:06:37]**

Отже, ми вчора пройшлися по тому, як представити вашому уже клієнту той way of work, над яким ви збираєтеся працювати, як ви його будете провести через весь проєкт, починаючи з першого дня до його фінального дня. Ви описали йому, що для вас комфортно, для проєкта безпечно розбити весь проєкт на фази. Перша, друга, третя, N-2, N-1, N, N-1 і так далі. Ви також вказали чітко, що ви відкриті для продовження співпраці. Ви поки не знаєте, що буде там, але розумієте, що ви готові перейти до наступних фаз. Наприклад, саппорт або ліквідація, тобто в залежності від. Ви були максимально чимними і вказали, що у вас є як мінімум два гейти. Що таке ці гейти? Це точка виходу. Якщо R&D завершилося успішно, крутяк, йдемо далі на Proof of Concept і так далі.

**[00:07:59]**

Якщо неуспішно, то GATE дозволяє швидко одропнутися з проєкту, зупинити це все діло на ранніх стадіях з мінімальними втратами часу і фінансів, як з сторони клієнта, так і з вашої. Тобто GATE захищає обидві сторони. Також GATE дозволяє прийняти рішення, тобто рухатись далі, зупинити проєкт або знайти іншу концепцію і повернутися на початок з спробою №2, №3 і т.д. Далі. Я вам дуже рекомендую, в залежності від типу проєкту, як мінімум не забути про існування таких фаз, як R&D і POC. R&D або Research and Development або дослідження і розробка полягає у перевірці технічної фісібіліті, тобто технічної досяжності тої ідеї, яку від вас очікує клієнт. В рамках неї ви фактично перевіряєте, що це взагалі технічно можливо при зараженому стані науки техніки чи ні. Якщо так, круто. Якщо ні, значить треба шукати іншу науку, іншу техніку або чекати, коли наука техніка зможе підтримати вашу ідею.

**[00:09:32]**

Далі, R&D також дає можливість звуження конусу в невизначеності. Суть в тому, що на дуже початкових стадіях ви можете оцінити ваш проект не дуже точно. Особливо, чим далі це від вас, тобто, чим далі в часі від вас ця подія, тим тяжче її оцінити. Якщо казати, що ви стоїте тут і ви хочете оцінити, наприклад, оцей горизонт, то, відповідно, конус на визначеності досить скромний, все достатньо визначено. Якщо ви дивитеся трошки далі, на якісь наступні фази, то конусної визначеності виріс. Тобто, оця довжина явно більша ця. Тобто, у вас більше припущень. В проєкті це є більше і більше припущень. Чим далі ви від себе, тим збільшується кількість цих припущень. І, відповідно, значно тяжче оцінити, а що, власне кажучи, ви зможете реалізувати, скільки це буде коштувати, скільки це займе, власне, часу.

**[00:10:58]**

Оці речі потрібно також прокомунікувати на стапі R&D. Після того, як R&D пройшла успішно, допустимо, вона пройшла успішно, то запропонуйте вашому клієнту зробити Proof of Concept. Що він отримує на виході? По-перше, він перевірить, що та компонентна база, вибрана для проєкту, вона така, як слід, що ви точно можете рухатися з нею далі. В цей proof of concept в ньому акцент не на красу, не на, як сказати, фіналізацію виробу. Ні, абсолютно. Просто перевірити, що, наприклад, обраний вами чіп точно працює з AI, наприклад. Або якийсь DSP точно встигає без великих надмірних лейтенсів обробляти 10 відео скрімів, 10 відеокамер у паралель. Вам треба це перевірити, бо потім від цього буде залежати, чи можете ви взяти цей чіп в проєкт, чи ви його зараз закладете, купите, розробите під це електроніку, корпус, систему охолодження.

**[00:12:12]**

а він зараз завзяв і не потяг. Розумієте, наскільки колосальний може бути ризик? І потім, який буде фейл, якщо ви це не дослідите раніше. Тобто, фактично, POS дозволяє вам оцінити, чи ви правильно обрали компоненти, чи вони точно подужують вирішити ваші задачі. Чи правильно ви вибрали фреймворк якийсь, чи в ньому є достатній тулінг для того, щоб покрити вашу задачу. Чи правильно ви обрали мову програмування, чи достатньо вона функціонально безпечна, наприклад. Чи достатньо під нею є підтримки. Чи правильно ви обрали операційну систему, чи ви зараз її візьмете, а під нею нема нормального компілятора, і ви потім будете змушені буквально переписувати тони коду, який вже насправді є. Тобто POSC, він фактично це інструмент, який коштує, так, він щось коштує, він потребує інвестицій,

**[00:13:16]**

але він забирає великі ризики майбутнього у виборі інструмента, якщо так грубо одним словом сказати, у виборі інструмента. Відносно цього POSC, я також забув вчора прокомунікувати, а що власне кажучи, ну, от, Проєкт може бути великий, в ньому може бути, допустимо, в проєкті може бути хардверна частина, це наш хардвер або електроніка. В проєкті може бути якийсь фірмбейер, який раниться на цьому хардвері, тобто він десь там всередині стоїть. Далі, воно все разом раниться на якомусь, воно все вбудоване в якусь механіку, тобто в нього є там якийсь корпус, цей корпус він стоїть десь якось так, ну відповідно це все хардверщина, вона буквально, зараз, сюди, сюди, сюди, вона буквально може бути вбудована, цей весь хардвер, він може бути буквально вбудований в нашу механіку.

**[00:14:20]**

Потім оце вседіло, наприклад, може співпрацювати з такою самою історією через якийсь комунікаційний протокол. Він йде аж з фірмвейера через оце вседіло до фірмвейера. Наприклад, у нас є такий виріб, така топологія, що є два фізичних девайси розкинуті в два корпуси. На кожному з них є якась наша електроніка. В ній є якісь чіпи. На цих чіпах ганяє якийсь фірмвейер через якийсь протокол. А окремо там стоїть, наприклад, ще комп, який працює, нехай так, що один фірмер ще стає мастером, і цей комп стає шлюзом, і працює там, прокидає щось з клауда. Така в нас якась топологія. Куча всього є. І код, і код, хардвер, механіка, якісь абстракції, які реалізовані на десктопі, якийсь клауд, якісь комунікаційні протоколи. Тут, тут, тут. Куча всього.

**[00:15:25]**

Що ж ми конкретно маємо взяти у POC і дослідити? Те, що найбільше стрьомне, тобто те, що ми вважаємо, що можемо тут дати в штангу. Тобто, потрібно провести вправу, яка дозволить нам визначити, а що є стрьомне. І оця вправа називається, вона, зараз, останним, HARA, Hazard Analysis Risk Assessment. Оцінка загроз і призначення ризиків. Оцей хара дозволяє вам сказати, що, наприклад, я вважаю, що наш КОМ-протокол являється в зоні ризику. Чому там втрата під лосінг? І, відповідно, нам щось потрібно з цим відробити. Ну, я там класифікую, що ризик цього high, от, добре, ми визначили в рамках хари, а чому я так класифікую, що він high, тому що відмова протоколу убиває все, тобто, скажімо так, імпакт в нього дуже високий, там десятка.

**[00:16:52]**

Частота збоїв, допустимо, є статистично високою, 7, скажімо так, наш попередній досвід за це каже, у ваших інженерах досвід.

**[00:17:04]**

Отже, severity, тобто серйозність, десятка, frequency, скажімо так, 7, і impact, наприклад, 7. О, окей, ми визначили, що ризик є, він високий. Далі, допустимо, наш механік каже, слухайте, чуваки, там термоменеджмент корпуса, я не впевнений, що ваш чіп МСЮ дуже гарячий, нам щось потрібно з цим робити, я вважаю, що буде перегріватися. Відповідно, ми кажемо, добре, як ти його оцінюєш? Я думаю, що він там достатньо стрьомно, постійно відбувається, і середнього теж посередньо. Окей, значить, medium. І так далі. Відповідно, ми асайнемо, ми проводимо зустріч всіх наших інженерів разом і початку офлайн аналізуємо, що ж може бути з нашою системою, те самі стрьомні моменти, те ми не впевнені. Чого ми раніше не робили, де ми

**[00:18:18]**

будемо першовідкривачами. І ми визначили, просто допустимо, що комунікаційний протокол і термоменеджмент корпуса є такі дві великі зони ризику. Зокрема, найвища – це відповідно якийсь бідлозінг у комунікаційному протоколі. От, наприклад, в цьому. От ми тут його скласифікували, що це найбільша зона ризику. Добре. Відповідно, після того, Як ви це описали, з цією HARA ви йдете до клієнта і кажете, що в рамках ПІО-7 ми хотіли б дослідити два питання, одне і друге. Воно уявляється найнебезпечніше, аргументуєте йому це все діло, показуєте вигі слайдів, аналізу, HARA таблиці, презентації. І якщо він розумна людина, він вам дасть добро дослідити всі ті речі, які ви знайшли під час хара. Якщо він має фінансові клопоти, то він відповідно вам скаже, дій тільки за хай рівним.

**[00:19:24]**

Якщо він збалансований, він скаже, візьміть хай і мідіум. Якщо він адекватний, то він скаже хай, мідіум, лоу. всі. Все перевірте, щоб ми точно йшли далі без ризиків. Припустимо, в процесі цього дослідження, от, до речі, хочу швиденько показати зараз, зараз, зараз, це відкрию, хара, хара, хара, хара, на сейфі, от так краще.

**[00:20:03]**

Так, Hazard Analysis Risk Assessment непевно найкраще описаний в протоколі ISO 26262, де ось, ISO 26262, відповідно, Я хотів би його вам очукати у типовому вигляді. Зараз попробуємо знайти. От, ні, не ту. Та що ж таке? Ну оце уже щось. Давайте відкриємо, подивимось. Статті, наукова стаття якась є по цьому. Нехай буде. Нехай буде. Тут жахливо, правда, воно от виглядає. Ну ладно. Відповідно, є ідентифікатор азагрози. Він описує, в якій саме функціональності, наприклад, в нас це буде комунікація, одна функціональність, друга функціональність, це буде механіка, бо відповідно воно стосується двох компонентів, комунікації і механіки. Чесно кажучи, це не хара, це більше ектара. Це трет аналіз, тобто аналіз загроз в зоні втручання, це більше по кібербезпеці.

**[00:21:46]**

Сек'юріті ризики, воно у вас, жах, виглядає нормально, це воно, відповідно, у нас є ідентифікатор, у нас є опис, що відбулося, у нас є в якому, ну, власне, в описі або окремо інквебу, в описі описують, в якому компоненті, Далі у нас описується, як ми будемо це контролювати, чи це буде автоматичне виправлення, чи оператор буде щось робити, чи ми просто приймаємо цей ризик. Потім перше – severity, probability і відповідно добуток severity, probability, тобто сила впливу і ймовірність того, що це відбудеться, якщо ви це умножите, у вас отримується рівень ризику. Якщо цей рівень ризику, ви вводите свої границі, як low, medium і high, відповідно, якщо це переходить в high, то ви його мусите взяти і проаналізувати, якщо це medium, то окей, ви знаєте, що він є і ви приймаєте рішення, що ви з цим будете робити, або low, відповідно, ви, ну, власне, теж приймаєте рішення, що ви будете з цим робити, тільки в залежності від того, наскільки це може бути неймовірно.

**[00:23:43]**

Наприклад, падіння метеориту. Його результативність цієї дії дуже висока, але ймовірність дуже низька. Тому ризик був класифікований як низький. Або інша історія. Наприклад, випадок, коли пілот засне за штурвалом, з виключеним автопілотом, все буде виключене. Тобто, при тяжких умовах роботи, тяжкі умови роботи роблять з нього пробабіліті достатньо високу, Севірність буде висока, відповідно, і ризик теж. Тетяна, ви вже сказали? Це, до речі, реальна історія була, буквально, не пам'ятаю, 3 чи 2 роки тому два пілоти Air France так і заснули. Один, що другий. Вони там пролетіли, вони мали в Парижі, вони пролетіли майже до Польщі. Там дитина з судом їх розбудили. Круто! Так, дякую. Відповідно, ми розуміємо, що наслідки цього є достатньо серйозні, імовірність достатньо висока, відповідно, ризик ми асайнуємо дуже високий.

**[00:25:07]**

І відразу треба описати екшн-план, що ми будемо робити для того, щоб зменшити цей ризик. Щось будемо досліджувати, щось будемо міняти, щось будемо буквально переробляти, перебудовувати. І відповідно екшн-план робиться по кожному із них. Або нічого не вказується, якщо ми нічого робити не будемо. що ми просто приймаємо цей ризик, що ми розуміємо, що він є, ну що ж, є то є. От, відповідно, на основі такого аналізу, ви фактично пробудовуєте оцей, ви визначаєте, що, наприклад, ви точно мусите зайнятися оцим комунікейшн протоколом, який вас отут отганяє, бо, ну, скажімо так, імовірність того, що він вам принесе серйозні наслідки є і вам треба його дослідити там імовірність того, що корпуси перегріваються так, ми це визначили

**[00:26:15]**

відповідно ми мусимо це дослідити відповідно і то, і то є об'єктами дослідження ми рекомендуємо його знести у стадії ПОС і дослідити якщо ця проблема підтвердиться, що вона є ми мусимо її розв'язати, аби, як мінімум, знайти шлях вирішення. Знайдений шлях вирішення – це достатня умова переходу по проєкту далі, тобто, от сюди. Якщо, наприклад, ми не знаходимо цього шляху вирішення, то ми або зупиняємо весь проєкт, або повторюємо дослідження. От в цьому фішка є тхара, яку ми от сюди запаркуємо. Далі, відповідно, ідемте просто по фічах, одна за одною, і, відповідно, їх вирішуємо. Аж до кінця. Тепер, ще хочу трошки потоптатися по цій темі, щодо варіантів, як ми можемо розбити якусь окрему фазу на моделі кооперації між нами і між нашим замовником.

**[00:27:44]**

Як ми вчора з вами говорили, є Fixed Price, є Timed Material, є їхні різновиди, в тому числі Timed Material з верхньою оцінкою ціни. Є змога проасайнити, наприклад, на двох перших стадіях Fixed Price, а потім Timed Material з верхньою оцінкою ціни і так далі, яка є таким компромісом. Але практика мені показує існування такого ще одного вигляду проєкту. Давайте ми його окремо дослідимо.

**[00:28:19]**

Для цього я візьму оцей шматочок, я його скопіюю від ціля, перейду з ним сюди, знову. Це мені не потрібно, але це потрібно. От, відповідно, у нас є якась топологія, дуже абстрактна. Просто витвір уяви, в якій існує, однозначно існує два якихось вироби. Кожен з них у своєму корпусі, своєю хардварщиною, тобто наші PCB, які ми там самі розробили, поставили туди нашу електроніку. На ці, в тому числі, якісь чіпи, на цих чіпах храниться наш фірмвейер і на PC-шки теж якась храниться наша апка. Тобто така розподілена, розгалужена, іерархічна штука.

**[00:29:15]**

І припустимо, ми розуміємо, що оцю механіку ми в рамках нашої компанії робити, виготовляти не будемо. Ми її спроєктуємо, але виготовляти – ні. Хардвер – ми її спроєктуємо, розробимо, навіть заревівимо. Але виготовлювати це ми не будемо, ми не заводимо. У нас немає таких можливостей. Далі. Комунікаційний протокол. З точки зору софту, з точки зору протоколу, так, однозначно, все класно. Але жгут, тобто фактично провід, по якому буде ганяти цей інтерфейс, а на інтерфейсі буде ранитися цей протокол, ми не будемо виготовляти жгут. У нас немає ні компетенцій, ні досвіду, ні техніків, які зможуть обжати ці кабелі, запхати їх, відповідно, у ізолятор, запхати цей ізолятор у якісь кабелі-канали. Ми не можемо це зробити.

**[00:30:21]**

Що ми можемо зробити, це наш механік і наш електронік зможуть спроєктувати проєкт жгута, а потім передасть це воно зовнішнім вендорам. Таким чином, ми однозначно класифікуємо, що у нас буде якийсь вендор, який робить хардвар мануфекторінг, якийсь інший вендор, який буде робити механічний мануфекторінг, тобто виготовлення корпусів, ще якийсь харнес, тобто виготовлення жгутів. Це окремі компанії. Далі, по-любому, коли йдеться про хардвер, механіку, харнеси або жгути, йдеться про делівері, тобто йдеться про пошту. Якось воно має бути до нас доставлене.

**[00:31:18]**

Тобто є ще один вендор. Вендор – це інша організація, яка нам за гроші надає сервіс. Оці це фактично заводи або інші підприємства, які виготовляють. Це вендор, який по суті забезпечує передачу. А оце, це ми, це фірма, так інакше скажу, софтвер цілому, софтвер девелопмент, це ми. Дальше, архітектур, архітектур, це ми. Дальше, мануфакторинг рев'ю, рев'ю, тобто, and саппорт, і саппорт. Тобто, по суті, технічний нагляд за виробництвом. Це ми. Далі, наприклад, асемблінг. Збірка. Хто знав? Поки непонятно. Давайте поставимо його в стороні. Поки. Далі. Legal Finance Office. Тобто, збереження, оплата, вирішення конфузів. Це точно ми. Відповідно, оце точно не ми. Оці всі хлопаки, це точно не ми. Оці, це точно ми. А цей, ну, поки ще непонятно.

**[00:32:59]**

Відповідно, раз такі діла, то якщо ми ув'язуємося в проєкті Fixed Price, чистий Fixed Price, FP, чистий FP на все, на все разом, на оце все разом, То наш клієнт очікує, що ми відповідаємо за оце все Він хоче ніби сходити в магазин і купити відро картоплі Він хоче піти до нас і купити готовий сервіс Заплатити гроші, почекати час, отримати свою картоплю заплатити гроші, почекати якийсь час і отримати готовий виріб. А ми розуміємо, що оці хлопці, вони нам не підконтрольні, це інші організації. Вони можуть зробити щось некоректне, вони можуть допустити затримки по часу, затримки по якості, збільшити ціну, так от же час, якість, ціна. Вони можуть насправді змінити це все. Так само, як візбудували хардвер, механіка, харнес-мануфекторінг, кожен з них, вони змінюють всі речі.

**[00:34:24]**

Плюс, деліверів. От навіть зараз ми живемо в ситуації, яку тяжко назвати нормальною. У нас йде війна. У світі завжди йде війна. Зараз вона йде у нас.

**[00:34:37]**

Чому я сказав, що у світі завжди йде війна? Тому що виріб рідко коли є продуктом в одній країні. Він залежить від багатьох країн. Навіть зараз сучасна розробка звертається від Китаю, тобто ви по-любому будете замовляти виготовлення електроніки в Китаї, бо це дешевше.

**[00:35:00]**

Механіку ви можете, наприклад, виготовляти в Україні. Це особистий мій досвід, що хардвер в Китаї, механіка в Україні, жгути в Україні. І, відповідно, коли кажеться про хардвер, китайці взяли зараз і обмежують виробництво електроніки для України. Вони накладають обмеження деякі, тобто вони роблять друковані плати, але не запаюють в них компоненти. Це створило додаткові умови, відразу, про які ми навіть не знали, бо їх не було раніше. Які?

**[00:35:36]**

Sources. Тобто, нам тепер треба відчукати ще одного вендора, який забезпечить нас компонентами, електронікою, серими інтегральними схемами, транзисторами, коннекторами, пасивною електронікою і так далі. О, вже проблема. Це проблема збільшення грошей, часу і ризиків. Далі, механіка. Зараз я використовую виробничі потужності в Білій Церкві, Харкові і Києві. І ви знаєте, питання по якості, питання по часу. Старий виробник, з яким я співпрацював, був дуже якісний по якості і адекватний по часу, але він збільшив півтора рази ціну. Тобто він фактично цим вибув з гри. Жгути я роблю в Кам'янці-Подільському. Виникли питання по якості останнім часом. Відповідно, є нюанси Делівері Ну, ви всі знаєте, як зараз відбувається доставка чого завгодно в рамках України

**[00:36:44]**

Величезні затримки, тяжко прогнозувати Неможливо прогнозувати, коли ви це все діло зберете А тепер уявіть, що ці всі одночасно починають грати гру Зміна фінансів, зміна часу, зміна якості Плаштовий сервіс також множить ці всі речі на свій коефіцієнт затримок і зміни ціни. А тепер найгірше. Це фізичний виріб. Ви ж розумієте, що це фізичний виріб, це не код. Це реальне залізо. І якщо ми в процесі от ми його отримали. Допустимо ми це робимо в себе вдома, інхаус. Ми самі збираємо. Якщо у нас збірка в себе вдома, ми це все зібрали, прогнали через контроль якості і бачимо біда. Ми кажемо переробіть, вони переробляють, це збільшує час доставки відразу вдвічі. Хтось із них може, наприклад, спертися і сказати, ні, ми не будемо переробляти.

**[00:37:55]**

Тоді ми залучаємо legal, legal команду оцю. А це що означає? Час. Це час. Тому, як ви бачите, я описав багато проблем, відверто кажучи, які виникають кожен день. А ще, врахуйте, що компоненти можуть просто зникнути з ринку Наприклад, зараз ми маємо великий дефіцит мікроконтролерів, мікропроцесорів на ринку І реально їх треба замовляти за місяць, за два, до того, як вони вам будуть потрібні Біда Тому Fixed Price, оце, бачите, Fixed Price Якщо я його поставлю ось тут, то я уб'ю проєкт Fixed Price в заражених умовах не тільки України, а взагалі Європи з точки зору будь-якого Embedded – це вистрінути собі в ногу.

**[00:38:55]**

Натомість Fixed Price ви можете взяти його з собою в гру, якщо ми кажемо за ваш інженерний сервіс. От бачите, я його ввів, software, архітектура, manufacturing review and support legal finance office management assembly. Добре, ми готові сказати, що оці всі складові ми покриємо, наприклад, fixed price. Але оці речі відразу кажете вашому замовнику, що вибач, друже, нам це не по кишені, ми не можемо дозволити, щоб Fixed Price був для сторонніх організацій. Тому оце ви кажете, що Fixed Price ось тут не є вашою опцією зовсім, або ж воно є опцією при умові, що, наприклад, ви маєте підтверджений лігалом агрімент з Delivery, з компонентною базою, з виробником хардвери, з виробником механіки, з виробником харнесів.

**[00:40:23]**

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

**[00:40:58]**

Але, повірте, виробники сучасні теж розуміють ці ризики. Вони дуже їх добре знають. І дуже мало ймовірно, що вони будуть готові підписати з вами такий вид договору. Майже неймовірно. А якщо і підпишуть, то що вони зроблять? Як ви думаєте?

**[00:41:23]**

Вони взвінтять ціну. А раз вони взвінтять ціну, що ви зробите? Ви взвінтите ціну А раз ви взвінтите ціну Що зробить клієнт? Або взвінтить ціну на власний продукт Або відмовиться від вас Тому Вся історія в тому, що Fixed price дуже малоімовірно Може бути залучений Застосований для Фізичних виробів Значно простіше Заходити туди З time and material Значно простіше Тому, якщо вам вдасться переконати вашого клієнта розбити вашу модель співпраці на дві групи, а саме ваш in-house сервіс, саме software development, architectural development, manufacturing review, legal, finance, office management, assembling, що це буде йти по фіксованому часу і фіксованій ціні, але закупка компонентів, виробництво електроніки, виробництво механіки, виробництво жгутів і доставка і те по моделі таймінг матеріал,

**[00:42:43]**

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

**[00:43:00]**

А тепер, тепер роздивіться, це, оце все, оце є запобіжник, так, він перегорає, якщо щось йде не так. І у вас є ще один запобіжник, це ваші оці гейти, які відбуваються після фази 1, фази 2 і після інших фаз, які ви обачаєте заризикованими. Так от, при такому розкладі, фактично, ми кажемо про те, що проект і ви, і клієнт, і ваші вендори, всі перебувають у балансі між навантаженістю і ризиком того, що щось, чогось піде не в ту сторону. Ось такий досвід. Добре, на цьому пропоную зробити маленьку паузу і повернутися в 9.24. Добре, тепер я хочу трошки більше зупинитися на своїх оцих ваганнях стосовно пункту асемблі. Асемблі, як такий, чого я його не знав вкинути, чи сюди, чи сюди, чи, коротше кажучи, я трошки запутався.

**[00:56:10]**

Тому що це завжди дилема. Ви можете передати асемблі на сторону, наприклад, цього самого заводу, який робить вам механіку, якщо асемблі стосуються тільки механіки. Допустимо, що таке асемблі з точки зору механіки? Припустимо, ви робите виріб, в якому є якась передня частина, основа, рама, корпус верхній, внутрішні якісь елементи жорсткості. Загалом у вас там є, допустимо, в одному виробі механічному, нехай 120 елементів. Реалістична штука, 120 елементів за простором. Ви скидаєте заводу-виробнику механіки, якісь компанії, нехай там з'явимося у Харкові, ви скидаєте їм свою конструкторську документацію, яку ваш механічний інженер їм розробить, скине, і, відповідно, потім їхній технолог і ваш інженер почнуть між собою комунікувати по техпроцесу,

**[00:57:18]**

Скажімо, чи це якесь гнуття, чи це якесь гнуття плюс різка, вазерна різка, фрезування корпусне, ну коротше кажучи, яка там ще буде технологія. Плюс, кожне виробництво, ну кожна навіть інакше скажу, кожна машина на виробництві, вона працює трошки інакше. Кожна механічна, там станок гнуття, от може бути два ідентичні станки, ви дивитеся, це сама модель, вони трошки інакше гнуть. Фарбувальна машина Одна і та сама машина Вона трошки інакше наносить фарбу Трошки інакше відтінок Виробу буде В результаті цього діла Ваш інженер І технолог Повинні не просто обмінятися Специфікацією І культурною документацією Вони повинні буквально проговорити Що треба зробити саме Щоб виріб точно запрацював і був нормально складений, так, і оце, воно називається, ну, ви, напевно, чули,

**[00:58:23]**

ви, ну, все-таки, КПІ, це КПІ, така фраза є, коза, от, коза, це не тільки тваринка, так, коза, це конструкторська записка, тобто, коза, по суті, є спеціфікацією конкретно до цього заводу І от, відповідно, як там будувати цю річ. Цей завод, допустимо, на основі цієї кози і на основі конструкторської документації виготовляє виріб, а потім ваш інженер повинен йому надати ще складальну документацію, яка, по суті, як інструкція по складанню. І на основі цієї інструкції по складанню цей завод, наприклад, може зробити збірку. збірку. От тоді асемблі переходить от на сторону вендора. От сюди міняє колір, нести я таким, і от собі отут живе. Плюси. Плюси – це то, що ви отримуєте готовий виріб, механічний.

**[00:59:25]**

Мінуси – ціна. Ціна росте дуже суттєво, тому що виробник теж розуміє, що це додаткові зобов'язання і додаткові люди, додатковий цех, нехай буде складальний цех. який не завжди є. Тобто, з цієї точки зору, асемблі прикольно мати в них. НО! Ми, як вам сказати, цей курс... Я тут, бачите, до чорта розказую вам про механіку, про що ще, хоча ви Software Development. Ну, ви не просто Software Development, ви, шановні друзі, ви розробляєте систему. Тобто, софт, Він вбудований в чіп. Чіп вбудований в хард. Хард вбудований в корпус. І ви так далеко від цього маєте бути. Або я. Ми з вами тут як рідні по освіті. Але ні. Ми все одно мусимо розуміти, як будується цей процес. Ми його самі не робимо, ніхто з нас не буде супроводжувати виробництво, але розуміти, як це збудоване, дуже важливо.

**[01:00:44]**

Відповідно, коли казати про механічну частину, то прикольно, коли асемблі є частиною їхнього виробництва. Але ми з вами кажемо про те, що ця механіка і потім хардвер повинні жити разом. Тобто, що от механіка і хардвер, як я тут вже отмарював, а в ньому стоїть хардвер, це по суті друковані плати, які ставляться всередину виріб. І вони передбачаються, що є ще одна стадія асемблі. Це асемблі компонентів на плату. І потім ще одна асемблі плати у механіку. Тому ось дивіться, який весь нюанс. Є механіка і є хардвер, і кожен з них передбачає окремо асемблі по механіці, щоб з окремих передніх дверець, нижніх рам і т.д. Потім, коли ви купуєте з вашого соурсера компоненти, їх отримуєте і розпаюєте їх на плату, на голу PCB, і отримуєте в результаті PCB-A, це асембли.

**[01:02:03]**

А потім, коли ви оце все разом берете і ставите ось сюди, то це асемблі. Тобто у вас є фактично асемблі на рівні механіки, асемблі на рівні хардверту, а потім асемблі виробу в цілому. І потім цей готовий виріб, ви починаєте в нього аплодити ваш код, ваш фірмвейер. Тому тут, бачите, є стадія асемблі 1, стадія асемблі 2, стадія асемблі 3. І от саме така багатосадійність асемблі мене спонукало створити в нас роль асембли, тобто окремий цех зборки в нас. І оцей цех зборки, який тут, його фактично закриває така спеціальність як технік або технішен, який фактично має дві експертизи. Одна експертиза – це механічна зборка. Він буквально з корпусних елементів збирає виріб. Його друга експертиза – це зборка PCB плюс компоненти робить PCB Assembly або PCB-A.

**[01:03:10]**

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

**[01:04:08]**

Отаким чином Тому що фактично зборка жгутів це закупка конекторів, закупка ваєр, ну самих одруків, ізоляторів, підтримок І потім фактично зборка їх по вашому проєкту Нормально їх мати в себе вдома Тому асемблі у вас це фактично зменшення дуже суттєвого ризику, а саме помилок на етапі зборки по механіці і відкриває потенціал перетягнути до себе задачі по харднес манефекторинг. От це така історія щодо асемблі.

**[01:04:53]**

Good. Пропоную цей кусток наразі закрити, про нього можна говорити вічно, бо це практика, це досвід, але наразі хватить. Йдемте далі.

**[01:05:05]**

У нас намалювався якась абстракція. У нас є там якісь два механічні вироби, у нас є в ньому якийсь хардвер, там є якийсь фірмвер, тобто є якийсь чіп, є якась комунікація з PC-шкою і, відповідно, там воно ходить, йде в клауд. Є така топологія. Добре, давайте ми її запозичимо звідси. Стягнемо трошки понище. І трошки з нею будемо працювати. Що, власне, кажучи, от після цього, як ви оце розпишете, розкажете вашому клієнту, він і сам зрозуміє, чому ви, власне, наполягаєте на тому, що це має бути фікс-фрайс, а це тайм-метод матеріал, бо це фактично зменшує ризик не тільки для вас, а і для проєкту, бо ваш ризик і проєктний ризик являються тут рідними братами. Якщо щось не фейвиться, або ваш ризик стрельний, або проєктний,

**[01:06:02]**

то відповідно від цього страждають обидві сторони. Тому розпишіть цьому це, розкажіть і побачите, якщо людина у своєму розумі, то він піде вам на зустріч. Тепер тут. От припустимо, ми розібралися вже, як ми будемо розбивати ці всі історії, фази та далі, і тепер давайте попробуємо приклад. [Фрагмент з описом навчального прикладу вилучено автором.]

**[01:07:04]**

[Фрагмент з описом навчального прикладу вилучено автором.]

**[01:08:02]**

Що робимо ми? Ми робимо оце. Тобто оце нам тут поки не потрібно, ми це будемо їм продавати пізніше, чуть-чуть пізніше. [Фрагмент з описом навчального прикладу вилучено автором.]

**[01:09:13]**

[…] Відповідно, от вона, ця топологія. Ми це розібралися і клієнт каже «Ну, слухайте, воно все мені дуже горить, дуже треба вже прямо зараз. Давайте якось чим пошвидше». Ми кажемо «Окей, не проблема». І перше, що ми робимо, це починаємо детальне планування. От нагадуєте оцю штуку, оцю, як ми його розкидали? От тепер нам потрібно це розказати в деталях. Давайте ми це зробимо. Для цього найкращий інструмент це Ексель. Реально. Поки мені чогось веселішого не знадоблялось. Отак. Зараз ми візьмемо наш цей виріб. Він там у нас майорів перед очима. Оп. Майорайт. І перше діло, що ми кажемо, що це якась часова діаграма розбиття проєкту на фази. От ми її так от назвемо, цю штуку, і поїхали. Фаза номер один. Дивимося, аналізуємо, що в нас тут взагалі є.

**[01:10:49]**

Припустимо, ми вже домовилися, що комунікація між цими двома чуваками іде через якийсь радіоканал. Ось трьомний момент, потрібно відповідно розібратися, робити ресерч, які радіоканали можуть бути використані в умовах [місця експлуатації], будуть сертифіковані під це все діло, будуть працювати в режимі різних шумів, дослідити, які саме частоти вже закладені на [об'єкті], щоб не робити між ними якусь інтерференцію. Коротше, зробити так, щоб ми точно розуміли, що цей канал працює. Плюс у нас там є ці всілякі електроніка, непонятно, можна [що] ставити, не можна, плюс там непонятно, які там температури на цьому [об'єкті], рівень забрудненості, коротше, непонятно нічого. Що там в поживленню, ну, взагалі є, капець. Коротше, більше питань, як відповідей.

**[01:11:49]**

І саме це є хороша фаза. І ця фаза називається збір інформації про об'єкт і середовище. Крута фаза. Чому? Тому що без неї ми не матимемо предметної області, про що взагалі далі говорити. Друга фаза. От припустимо, так, я вже роблю помилки, нам це не треба. Давайте зробимо так, так, робимо тут поняття номерів, перша, друга. Забираємо це, забираємо це. Далі, відповідно, після того ми оцінюємо, добре, ми будемо розуміти, про які, власникаючи, специфіки середовища йтиметься. Ми можемо на цьому етапі, після того, як ми будемо розуміти, яка специфіка виробництва, яка специфіка умови сплутації, з'їм, мабуть, ніяких сертифікацій, та далі зробити архітектурний опис системи. Відповідно, на системному рівні тут ми можемо описати, як це все буде виглядати.

**[01:13:06]**

Чи можемо ми описати цю систему без формування вимог до системи? Ні, однозначно ні. Тому перед архітектурою, бачите, я собі ставлю іншу задачу. Це розробка і ухвалення вимог до системи або системні реквайменти. Після системних рекламентів ми можемо зробити архітектурний опис системи. Зібрали дані, потім зробили реки, ухвалили їх з клієнтом і, відповідно, рухаємося далі до опису системи. системи. Зразу кажу, може бути так, що середовище настільки зле, що фактично ми не можемо тут рухатися далі. Тому ставимо, що у нас є гейт, який нам або дозволить, або заборонить рухатися взагалі по цьому проєкту. І далі, відразу після збору даних про це. Далі, рекламенти. Ми їх підготуємо, а клієнт тут упрацює, що він хоче щось інше і все.

**[01:14:07]**

Доки ми їх не вхвалюємо, ми не можемо проєктувати далі будь-що. Тому розробка цих реквайментів на рівні архітектури, на рівні цієї системи, це однозначно буде gate 2. Далі, третє, це архітектура. Архітектура нам дасть декомпозицію. Тобто ми будемо розуміти, про які компоненти буде йтися мова, що є там дві якісь підсистеми, є якісь хардвери, якісь чіпи. Він нам дасть реальний view на проект. Наступний, це аналіз ризиків. Це, відповідно, хара. Можливо, навіть тара. Хара – це як функціональна безпека, тара – це кібербезпека. Тобто, якщо їм потрібно буде, відповідно, ми проведемо ще хару і тару. На основі цієї харатара, що ми будемо робити після цього? Ми проведемо, чи треба нам тут R&D, думаю, ні, а от POC зробити потрібно, тому що R&D тут ніби нічого, тут, в принципі, елементарна якась комунікація, ну, да, в шумі, всі діла, але разом з тим R&D у нас буде як частина R&D, це якась, як типу R&D,

**[01:15:32]**

це, власне кажучи, отут, збір інформації про об'єкти і середовище. Чому я взяв R&D? Тому що збір інформації – це вже є research, це вже є пошук. Далі, POC. Перевірити, чи взагалі оця гіпотеза працюватиме, зокрема, на основі знайдених у HARA і у TARA ризиків. Тобто, на основі HARA і TARA ми робимо POC, і не повірите, Я б хотів, щоб це стало гейтом №3 Бо може бути, що сам Пурхов Концепт Скаже, чуваки, не лізьте туди Там біда Там не працює нічого Там такий рівень електромагнітного шуму Там просто Електромагнітна інтерференція Валить все Не лізьте туди І ми відповідно на цьому рівні зупинимося І не поліземо далі Далі Їдемо після цього На наступну стадію А саме стадія МВП, або Minimal Value in the project. Тобто, мінімальна вагомість

**[01:16:45]**

треба зробити для цього виробу. Мінімальна вагомість, по суті, це реалізація якогось маленького кошматка, який просто вже буде якось детектувати, що це працює. Це якась мінімальна функція, яка дозволить, наприклад, зафіксувати, що [пристрої бачать один одного]. Ніяких інших тестів, нічого такого, ніяких дій, нічого вона не буде активувати. Просто буде підтверджувати, що там загориться десь індикаторчик, що [зв'язок є]. Проста річ. Цей МВП фактично буде жити, він ще без корпуса, там на скотчі примотаний до цього виробу. Примітивна історія. Ну, от вже буде якось функціонувати. Потім, після цього, нам треба на основі цих реклайментів до системи, на основі них, потрібно вже всерйоз думати, що ми будемо робити далі. Тому оце

**[01:17:43]**

продасть MVP, продасть ваш сервіс, а потім після цього можна деталізація вимог до ПЗ, механіки та хардвер. Та хардвер. Та що тут тобі. Тобто отут фактично я спеціально його поставив ніби до того, як прямо вкопуватися вже в реалізації. Чому так? Тому що на цьому етапі ми в принципі вже розуміємо, на що буде йтися отмова. Загалом понятно, є архітектура, є вимоги до архітектури, є сама архітектура. ми провели аналіз стрьомних моментів, ми перевірили, що вони не спрацювали, що все окей, ми зробили якісь мінімальну демку для клієнта, що от дивіться, воно вже якось працює, давай же ми розберемося, що ти конкретно хочеш. Це от вам така коротенька історія про цих сім фаз. От на основі як виход цієї фази ми будемо вже мати вимоги до механіки, до хардвер і до софтвер. І потім отут нам треба розуміти, що насправді тут буде спліт іти, розбиття проєкту на різні частинки, на різні фази.

**[01:19:16]**

І перше, що потрібно почати тут робити, це насправді прикидати, на чому це все буде ранитися. Треба провести оцінку завантаженості хардвер. Оцінка завантаженості хардвер, ресурси, що треба для фірмвейер. Тобто, потрібно глянути, який чіп обрати, яку комунікацію, яку оптику, яку радіо, тобто, що треба підібрати, оцінити, що треба, щоб запрацював наш firmware згідно з цими реквайментами. Ок, після цього ми можемо переходити у стадію, яка буде сплітити, яка буде націлена на пошук компонентної бази на ринку. Йдеться про хардер, тобто нам потрібно очікувати, ми оцінили, що нам потрібно плюс-мінус такий чіп, нам потрібно такий-то RAM, нам потрібно таку-то елементи живлення, такий-то інтерфейс по радіо, от воно все.

**[01:20:31]**

Треба знайти, чи воно реально є на ринку, чи ми його зможемо купити. І оце є Gate 4, тому що якщо ви не зможете забезпечити собі закупку цих компонентів, то відповідно про який подальший розвиток проєкту взагалі може йтися. Далі, ось тут, ви можете зробити і правильно зробити, якщо ви реалізуєте на рівні моделі віртуалізації, віртуалізації моделі віртуалізації і ви зробите фірмвейер інакше софтвер софтвер але замоканий тобто ви накидаєте [імітатори обох пристроїв, їхньої механіки й радіоканалу], і покажете, як воно буде загалом працювати. Ви фактично зробите проєкт, але без реального заліза, до інтеграції із залізом. Така собі рання стадія.

**[01:21:48]**

І під це, яка саме методологія, яку ви там оперете, це вже ваше діло, Тобто, чи там якийсь класичний підхід, чи тест-дрів'яний девелопмент, це вже як у вас вийде це продати. Ну разом з тим, на цьому етапі у вас буде якийсь софтвер, який буде замоканий, який буде достатньо лімітований і фактично буде націлений на аплікейшн. Тобто, фактично ви тут робите апку. Перевіряєте, що воно виглядає так, як хоче клієнт. Паралель з цим, ваш хардвер-інженер може приступити і має приступити до хардвер-девелопмент. Він тут приступає до цього діла і робить схематик PCB і також Bill of Materials, тобто список компонентів. На виході з цієї стадії ви будете мати схематику, ви будете мати PCB, ви будете мати якусь модель, яка буде виглядати якимось таким чином

**[01:23:24]**

і ви будете мати білого матеріалу, тобто список компонентів з їхніми цінами, кількістю, для того, щоб реалізувати цей чудо-проект. О, перетвертаємось назад, де там я його загубив, де там наш, а, ось тут. От, далі, після цього, наступна стадія, яку ви можете зробити, це і треба рев'ю по хардверу, Тобто, інший інженер проводить рев'ю, чи тут все окей. Це, будь ласка, обов'язкова стадія. Після цього, рев'ю Hardware by Firmware, тобто, перевірте, нехай Hardware буде перевірений Firmware-інженером, чи дійсно функціонал, так як було задумано, ляже сюди і все окей. Потім All Hands, тобто оговорити з клієнтом також, чи це таке відбачення, як він хоче Після цього ви можете перейти до Mechanical Development

**[01:24:45]**

Де це про корпус? Замітьте, в виробництво ще нічого не пішло, а механік пішов робити корпус В нього вже є реквайменти, ці реквайменти взяті в роботу, тобто виконуються на основі реквайментів і на основі Hardware Step Models, тобто на основі моделей, які він отримує від хардверника. Після цього, як у вас буде реалізований дизайн, хардверник має зарев'ювати механіку.

**[01:25:34]**

Після цього може бути ріворк, хардвер і механіка. Тобто, поки в мене такого не було, щоб, ви знаєте, щоб прямо два інженери робили паралель, робили, робили, робили, воно все настільки класно стало, що не потребувало якогось ріворку. Не буває такого, по-любому хтось придумав про один підхід, інший про інший, і вийшло так, що хардверт не стане в корпус, або стане і буде грітися. Відповідно, ріворк з якоїсь сторони по-любому буде проведений. Після цього All Hands Meeting, тобто ви як менеджмент, клієнт, інженери, всі стекхолдери, всі, хто цього причасний, збираються на демку. Демка покриває у першому випадку хардвер, в другому хардвер плюс механіка. Після цього йдеться про manufacturing hardware and mechanical. І то, і то відправляється на виробництво.

**[01:26:51]**

І потім буде довгий мутний час, коли ваші інженери фактично проводять постійну комунікацію з виробниками, налагоджуючи, щоб виробництво проходило успішно. Виробництво займає дуже довгий час і це той час, який потрібно використати на прокюрмент and компонент шіпмент. Тобто цей час потрібно використати для того, щоб закупити стандартні компоненти по механіці. Це болти, гайки, шайби, гровери, ножки, ручки. Стандартні речі. Тобто то, що ваш виробник не буде виготовляти, бо воно є наявне на ринку. Ваш прокюрмент-менеджер, окрема роль, повинен забезпечити закупку цих речей і складування у вас його у вашому warehouse, у вашому складі, у вас десь в офісі, в сейфі. Це з точки зору механіки. Цей самий procurement менеджер, тобто менеджер закупки, робить ту саму праву по хардверу. Тобто він шукає виробників, це або якийсь маузер, або якийсь діджікі, шукає, де це діло купити, купляє, забезпечує розмитнення, доставку і збереження компонентної бази електроніки десь у вас, у вашому верхалу з офісу в сейфі.

**[01:28:30]**

Тобто, фактично, цей час, доки йде виробництво, воно може йти, наприклад, механіка, по моєму досвіду, це від 10 днів для корпуса забіжки з мікрохвильовку, від 10 днів до 30 днів. А хардвер від 3 тижнів до 5 тижнів. Це, відповідно, час, який гріх просто стояти. Тому ви на цей час забезпечуєте, щоб компоненти і інструменти були в доступності. Після цього асемблі по механіці. Механіка по-любому прийде раніше, відповідно, очікуйте, що ваш технікальний гай має її зібрати. І потенційно, знайте, що можливий і треба це закласти однозначно ріворк. Зразу ж ріворк, будьте добрі, асемблі ріворк, йдуть разом. Далі прийде десь хардвер, асемблі ріворк. Який же ріворк може бути в хардвер? А дуже простий. На цьому етапі, це перша ітерація, на цьому етапі, якщо допускаються помилки, то ці помилки рішаються прямо на місці. Ріжуться дорожки.

**[01:30:16]**

Грубо кажучи, припустимо, що є якийсь виріб, і допустимо, що ця точка йде не туди. Гріжете її тут, запаяли проводок, кинули в правильне місце. Тобто реворк такого характеру йде на цій стадії. Тому після того, як хардвер прийшов, його зібрали і відповідно відразу закладаєте час для ріворг. Чого тут не вистачає? Де я помилився? Йде асемблі, то є так, йде прокюрмент, асемблі по механіці, рев'ю, потім ріворг. після цього асемблі по хардвер потім, відповідно, йде рев'ю і, відповідно,

**[01:31:18]**

реворк після цього всього як оце діло закінчилося ви можете зайти у фірмвейр фіналізейшн and аплодінг І потім Firmware Testing. Тобто ви отут, нагадуєте, на модельці цю штуку наклипали, а отак отут ви її вже закінчуєте на реальному залізі і тестуєте. І оце все ми на сьогодні закінчимо просто тому, що ми не влізли. Але на цій стадії, дивіться, ми зібрали дані, ми розробили специфікацію до системи, системи, розробили архітектуру, проаналізували ризики, побудували якийсь профілконцепт, зробили мінімальну демку, після цього зробили реквайменти до софтвер, до механіки, до хардвер, оцінили залежності, знайшли компоненти, зробили просту аплікуху в рапорах і макапах на софтвер, потім переходите, відповідно, у хардвер, розробляєте

**[01:32:34]**

його, потім робите механіку, розробляєте, замовляєте компоненти, вони потрошки їдуть, приїхали, ви їх зібрали, перевірили, виправили, так само з хардвером, зібрали, перевірили, виправили, дописали ваш код, зааплодили, протестували. Оце одна маленька, оце один так званий епік, оце все, давайте я його відразу виділю, Це один епік. І в цьому бізнесі, який є Embedded Software Development, включаючи з механікою і хардвер, не буває одного епіка. Буває мінімум три. Тому ми тут фризимо це тіло, ми не закриваємо, я цю штуку збережу, наступного тижня відкрию, і ми підемо до епіку 2. Накидаємо ці тіла, потім зробимо гант-чарти-діаграму, потім створимо команду, пошукаємо яких нам треба інженерів, визначимо їхні спеціфікації цих інженерів, наймемо їх, умовно кажучи, і потім нам треба мігрувати в Jira. Багато роботи. Всім дуже дякую за увагу і гарного дня.

**[01:33:49]**

До побачення.

## Нотатки

<!-- Тут можна фіксувати тези, терміни, завдання для студентів. -->