---
title: "IgorSikorskyKPI_P1_02092026"
source_video: IgorSikorskyKPI_P1_02092026.mp4
source_audio: IgorSikorskyKPI_P1_02092026.mp3
duration: 01:36:30
language: uk
language_probability: 0.897
model: large-v3
device: cuda
transcribed_at: 2026-09-22T18:35:15
segments: 755
paragraphs: 84
status: draft   # draft | reviewed | published
tags: [лекція, транскрипт]
---

# IgorSikorskyKPI_P1_02092026

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

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

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

**[00:00:12]**

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

**[00:01:41]**

Вас також, я сподіваюся, вже старости отримали і поширили в групах лінк на чат цього курсу. В цьому чаті я розмістив лінки на відео. Я також буду там розміщати різні цікаві матеріали, які потенційно вам або під час цього курсу, або після нього можуть бути у пригоді. Тож, не соромтеся, заходьте в чат, він розгорнутий в Google-чат, це корпоративний канал, він достатньо якісний, безпечний і відповідає деяким нормам корпоративного стандарту, наприклад, тому самому NX, тому самому Global Logic, також використовується Google як екосистема. Ну, там, в принципі, є дві екосистеми, так, це Google або Teams, ну, відповідно, Google одна з них. Також я перепрошую, якщо ви чуєте якесь нявкання на фоні, це кафедральний кіт, він десь там в коридорі шариться, ну, і, відповідно, утворює мені звуковий супровід, якось так.

**[00:02:53]**

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

**[00:03:13]**

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

**[00:05:00]**

Ми глянули, що є продуктові компанії, сервісні компанії. Ми дуже-дуже коротко поговорили про те, що таке Embedded, розібралися, що є якийсь Application, це відповідно той ваш бізнес-код, ваша бізнес-логіка, яку ви реалізуєте. Це як ціль існування проєкту, оцей бізнес-леєр. Ми також розгляділи два варіанти. Один – це коли у вас є цей бізнес-логіка раниться безпосередньо на абстракціях, драйверах, які передаються вам розробниками мікроконтролера або розробниками студії. Ми його ще називали HAL, як Hardware Abstraction Layer, відповідно, бізнес-логіка HAL і хардвер – це одна топологія виробу. Ну, а друга топологія виробу – це коли йдеться про значно складніші системи, і у вас є, відповідно, бізнес-логіка або аплікейшн.

**[00:06:10]**

потім у вас здебільшого йде різна шорста операційна система, яка може бути досить розвинутою, потім йде відповідно HAL і драйвери. Просто, щоб засвоїти цей матеріал, дозвольте я вам оперативно зашарю свій скрін і я сподіваюся, ви його бачите. І от дуже таким типовим типовим типовим Багато рівновим є архітектура AutoSAR. Вона широко використовується, власне, вона розроблена для автоматів. І вона просто дуже гарно візуалізує те, про що я говорив. От якщо ви звернете увагу на цю ілюстрацію, цю ілюстрацію, то видно, що є якийсь аплікейшн, ось де він, потім є отакий здравецький middleware, який включає у себе тут це явно не вказано, но операційну систему абстракції високорівневих драйверів, потім низкорівневі абстракції драйверів, він же HAL, і потім

**[00:07:29]**

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

**[00:08:34]**

Відповідно, живе воно там не одне. Коли ми щось вбудовуємо, то вже йдеться про те, що ми маємо це вбудувати в щось. Тобто, нам треба чіп, нам треба хардвер. Тому, коли кажеться про embedded, однозначно, просто як закон, йдеться про софтвер і про хардвер. Софтвер, або програмне забезпечення, і хардвер, або апаратне забезпечення. А це хардвер, воно несе в собі багато ярусність. Це також must-have, побачите в embedded, в принципі в IT, поняття абстракцій, воно живе кругом. Абстракція на абстракцію, абстракція на абстракцію. Ви як цибулю розбираєте, в кінці кінців ви доходите до ядра. Ядром є бізнес-логіка. Відповідно, оцей софт, який разом, включаючи application, basic software або middle layer, abstraction, оця вся штука, яка раниться на чіпі, повинна якось забезпечуватися цим чіпом.

**[00:09:43]**

Відповідно, вибір чіпу, вибір його основних характеристик, таких як, власне, периферії по пам'яті, по частоті, по нерозпоживанню, по додаткових функціях, ці всі речі вони обираються разом із написанням програмного забезпечення. Те саме, як і власна архітектура того чіпу, на якому це все буде ранитися. Вибір чіпу – це не єдина задача, з якою стикається команда при розробці програмного забезпечення для обудованих систем. Чіп – це тільки перша річ. Наступна річ, з якою вони стикаються – це периферія по чіпу. Тобто забезпечення перед умов, щоб мікропроцесор, або digital signal processor, або system on crystal, щоб щось з цього змогло запуститися. Відповідно, відразу зі спадає на думку, що ви не можете просто взяти одну мікросхемку, її заживити, дати їй живення, і ця штука взлетить.

**[00:10:53]**

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

**[00:11:53]**

І от створення топології захисту пінів мікроконтролера є дуже вагумою задачею, якою також займається хардверний інженер. Після цього, як оця задача з хардвер-інженером, з його цими пінами завершена, ми вертаємося до ще одного рівня абстракції. Отже, рівень №1 – вибір чіпу. Рівень №2 – забезпечення його базових вимог, тобто живлення, ресет і квантування. Задача наступна Вам потрібно забезпечити захист Його інпут-аутпут Його пінів Ви, відповідно, реалізуєте Цю топологію захисту Після цього Ми можемо сказати, що, окей, чип ніби як Захищений, але ще ні Тому що є ще таке поняття, як Electrostatical Discharge ESD І, відповідно, нам потрібно ще подумати Про ESD леєр захисту, тобто така, як це гру показують, як, знаєте,

**[00:13:00]**

у фільмах про інфанетіану 80-х вдівали таку фольгову шапочку на голову, щоб захиститися від електромагнітного впливу чужинців. Так от, ця сама ідея, вона на справі відшукала своє повне впровадження в електроніці, коли чіп фактично накривається, екранується таким от, таким екраном, він дійсно зроблений із фольгованого матеріалу і захищає чіп від зовнішнього впливу. Так от, конструювання, підбір, розміщення цього екрану для ESD, Electrostatical Discharge, EMC, Electromagnetical Interference захистів, це також задача, з якою доводиться стикатися інженеру. Потім, після цього всього діла, ми кажемо, що сам чіп, на якому раниться цей софт, він захищений і може працювати коректно. Чому так багато роботи просто для того, щоб забезпечити працездатним оцей маленький чіп?

**[00:14:04]**

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

**[00:15:39]**

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

**[00:16:41]**

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

**[00:18:01]**

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

**[00:19:16]**

Тобто це може бути 0,5 вольт, 0,3,3 вольти, 0,1,2 вольти, 0,1,1 вольта. Тобто, насправді, все. Дуже далеко з цим не розбіжися. А в чому тут проблема? Хто підкаже? Чого я підкреслюю, що є проблема в тому, що на пінах контролера ми отримуємо інтерфейс на рівні живлення самого контролера? В чому тут загвоздка? Проблеми в якому плані? У експлуатаційному. Чому ми маємо тут складність для того, щоб просто взяти і потім використовувати цей сигнал для наших задач? Окей, я розкажу. Відповідно, мікроконтролер наш або чіп наш, він формує фактично коректний інтерфейс, в якого коректний таймінг, тобто інтервали між імпульсами коректні, характер сигналу коректний, частоти, все класно. Все те, що треба. Але, скажіть мені на милість, яка специфіка, наприклад,

**[00:20:40]**

якщо ми хочемо, якщо наша ідея була передавати сигнал по Ethernet, або по CAN, або по USB. Специфіка в тому, що ці інтерфейси мають свій фізичний рівень І цей фізичний рівень часто не є просто 3,3 вольти чи 5 вольт Часто в нього досить високий струм, а не тільки одна пруга Тобто контролер сам по собі без обв'язки не здатний підняти фізичний рівень цього інтерфейсу Відповідно, ми із цього вже дуже гарно ізольованого, закритого, безпечного і надійного мікроконтролера виводимо його логічний сигнал по його логічному рівню, так званий OTTL або Transistor-to-Transistor Logic Level, і ми його повинні передати в іншу сторонню інтегральну схему, яка і фактично вже будує інтерфейс. Наприклад, той самий CAN, супер розповсюджений інтерфейс для обудованих надійних систем

**[00:21:52]**

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

**[00:23:18]**

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

**[00:24:33]**

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

**[00:25:59]**

А ми кажемо саме про чіп чи про Evolution Board? Саме про чіп. На втомі чіпі і оперативка встроєна 64 габайти. Окей, добре, але кажу те, що знаю з практик і з тими компаніями, з якими доводилося відпрацювати, що люди бояться таких чіпів, вони бояться їх як щось страшне, бо розуміють, що рано чи пізно почнеться з ними якісь проблеми, чи вони зникнуть з ринку, чи вони спеціально будуть нагнітати ціну. Ну, от, наприклад, ESP32, ви знаєте, це чіп, якого цураються на ринку, от, до речі, але і за його походження. Тобто, це чіп китайського вендора і, ну, відповідно, європейські замовники, американські замовники ставляться до цього як до потенційної небезпеки. І стараються їх не використовувати у себе по декількох причин. Одна з них – це демпінг по ціні. Відповідно, компанія занищує ціну продукту за рахунок того, що отримує державну інвестицію з Китаю.

**[00:27:10]**

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

**[00:28:14]**

Тому практика каже про те, що обходять це чим подальше Ну, якось так Окей, ми трошки відійшли від загальної стезі Отже, ще раз Коли ми кажемо про ролі Чого я так залівся по цій темі З цим сім'єнвайментом, еквіпментом і так далі чи тому подібне, тільки із-за того, що фактично у нас є ситуація, коли є декілька ролей у одному колективі. Роль номер один – це однозначно інженер-розробник програмного забезпечення. Роль номер два – це інженер-розробник апаратного забезпечення. Чи це всі ролі, які є на типових проєктах Fembeded? Ні, це не всі ролі. Є ще декілька ролей, які виникають і які супроводжують процес розробки весь його таймлайн. І що ж це за роль? Хто підкаже? Саме інженерного стеку.

**[00:29:28]**

Можливо, якийсь схематик інженер? Ні-ні. Власне, хардвер інженер здебільшого покриває схематику, PCB, лейаут. Він такий, скажімо так, рідко, коли розмежовують, що там хтось робить схему, хтось робить отрейс, хтось робить там виробництво. Це здебільшого одна роль. Але от що реально, ну це от must have, ну тобто розбити їх можна, але це вже, як кажуть, це якщо у вас жирні проекти і жирні клієнти. А здебільшого це не так. З найбільшого йдеться про те, що у вас є один стрім, це стрім розробки програмного забезпечення, другий стрім – це стрім розробки апаратного забезпечення, третій стрім – це механіка. А про яку механіку Тут взагалі йде мова Ембедед Передбачає, що на виході Клієнт Отримує не тільки софт І не тільки хард

**[00:30:34]**

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

**[00:31:36]**

електромагнітний, електростатичний, механічний, і якщо там є окремі категорії, то там починається радіаційний, хімічний, тепловий, бла-бла-бла, ціла куча. Так от, Всі ці види сертифікації обов'язково передбачають електричний захист, тобто корпус Відповідно, ми обов'язково, якщо ми влазимо в Embedded Колеги, сорі, ви мене чуєте, щось зник з'язок Ну так, ми вас чуємо Дякую Відповідно, коли йдеться про Embedded, йдеться про це тріо Firmware, Hardware, Mechanic І при тому ці хлопці і дівчата, вони працюють реально пліч-о-пліч, весь шлях разом для того, щоб виріб в кінці-кінці запрацював. Окрім... Я перепрошую. Що ж таки можна зустрітися, поспілкуватися? У мене закінчується пара в 10-10. 10-10? Окей. По 501-й? Добре.

**[00:32:43]**

Так, так.

**[00:32:46]**

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

**[00:33:35]**

Немає стоящих зверху, є ролі. Ось дивіться, просто вслухайтеся в цю фішку. Я вам наведу крутий приклад, і він дасть частину відповіді на власне питання. В IT є така крута роль, називається Servant Leader. Тобто лідер, який служить. Лідер, що служить. Або Servant Manager. Менеджер, що служить. Тобто, а давайте вникнемо ще трошки і вийдемо в цю роль Увідь собі, що в даному разі одна з моїх ролей в рамках Enix Це, власне, Engineering Manager І я працюю по концепції Servant Manager Тобто, я служу своїй команді Ну, у мене кілька команд, тому я їм усім служу Але разом з тим, що означає служба команді? Це означає, що, наприклад, якщо в Hardware Engineer вийшла запара Ну, наприклад, він вперся в ситуацію, він не знає, чи варто, чи можна, чи не можна, чи буде місце розмістити на платі екранізації, оцю фольгову шапочку.

**[00:34:52]**

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

**[00:36:00]**

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

**[00:37:10]**

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

**[00:37:25]**

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

**[00:38:28]**

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

**[00:39:35]**

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

**[00:40:34]**

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

**[00:41:34]**

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

**[00:42:43]**

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

**[00:43:30]**

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

**[00:44:42]**

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

**[00:46:31]**

Оці пацани і дівчата, вони просто топлять, як кажуть, за те, щоб продукт був класний.

**[00:46:40]**

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

**[00:47:46]**

і вже можна домовитися з менеджерами, щоб наняти ще робітників і почати переписувати цей гамнокод. Хоча, якби це робив інженер, він би, мабуть, відразу почав би писати нормальний код, але це було б дуже довго. Прийнято. Чесно кажучи, в себе в командах я такого в житті не допускав, але разом з тим, так, я таке чув. Добре, Володимир, прошу. Я просто хотів вам все додавати, що цей код потім надається Легасі і його ніхто не чіпає. Це біда, це біда. Дайте розкажу з власних досвідів, про які випадки, коли, вроді би, як чистий класний продукт, от давайте таку історію. Наш продукт ми розпланували як слід У нас був пропозал Architecture description документ був написаний Design description були написані Hardware software test plan були написані

**[00:48:54]**

Конкурентно вибрані архітектура Визначена топологія, вибрані компоненти Шикарно, прямо топчик Підібрана команда Всі вже, як коні на старті, готові рвати в той спринт, все круто, все потужно.

**[00:49:16]**

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

**[00:50:25]**

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

**[00:51:16]**

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

**[00:52:24]**

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

**[00:53:23]**

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

**[00:54:42]**

Оце ті речі, які робить менеджер. Оце відповідно тих п'ять ролей, які must have у embedded проєкті. Є ще куча додаткових випадків. Просто для прикладу, уявіть собі, ви робите ембедед систему, який в якості актуаторів і сенсорів є лазерний діод і лазерний рецівер, який отримує лазерний пучок. Допустимо, ми робимо якийсь комунікаційний виріб, який там існує, функціонує в умовах якогось пилу, не знаю, додаткового шуму, там якісь стоять додаткові дзеркала, скло якесь, воно все скаржує цей лазерний промінь, воно все накладає якісь шуми додаткові. І нам, відповідно, по-любому в цей проєкт треба залучати експертів. Оці люди, експерти, це в даному разі оптик. Ми будемо точно візьмемо при такому розкладі до себе проєкт оптика. На якийсь час, що він правильно підбере лазери, підбере оптику, визначить умови, прокомунікує з механіком, з хардверником і, відповідно, така додаткова роль.

**[00:56:05]**

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

**[00:57:02]**

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

**[00:58:00]**

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

**[01:08:35]**

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

**[01:09:59]**

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

**[01:11:09]**

навіть ще і не нанятими в неї. І, відповідно, цей архітектор на цій ранній стадії, він вивчає всі, які є доступні матеріали про цього ліда, тобто його LinkedIn, його веб-пейдж, його історії окремих, його облич, його СІО, то далі, ну, подібне. Якщо вже за онлайнений якийсь міт, тобто у нас буде якийсь мітинг з цими людьми, то енгейджери здебільшого приносять лінки, референси тих, хто буде на цьому міті. І архітектор влажно вивчає цих людей, де вони навчалися, їхній профіль, їхній досвід робочий і так далі. Він вивчає про них все, і про компанію, і про них. І він фактично разом з Engagement Management виходить на такий собі як Initial Meeting, на знайомство. Вони знайомляться, він допомагає їм заспічити, розказати про нашу компетенцію в Embedded, показати якісь кейси, які ми робили раніше

**[01:12:28]**

Фактично він є так званим чемпіоном, тобто тою людиною, яка виходить від імені компанії на мітинг для того, щоб показати, хто ми є Такий собі як чемпіон з точки зору, як кажуть, старих віків, який виходив на сцену, на ринг, в колізей для того, щоб показати ху із ху. Відповідно, архітектор виходить і спічить про компетенцію. Він разом з Engagement Management уважно слухає кожне слово, кожен needs цього ліда і як тільки вчують правильні слова, де ми можемо допомогти їм, ми починаємо атаку, ми показуємо наскільки ми сильні там. І от після деяких ітерацій, деяких кількості мітів та далі і тому подібне, якщо все успішно, ми до цього ще уважно будемо вертатися до цієї частини. Відповідно, лід потрошки трансформується в клієнта. Він скидає нам RFQ, або Request for Clarification, або Quantity. Ми аналізуємо, рахуємо і подаємо йому пропозал, тобто як ми бачимо рішення його проблеми.

**[01:13:55]**

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

**[01:15:01]**

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

**[01:16:02]**

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

**[01:17:22]**

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

**[01:18:36]**

По декуди, наприклад, і зараз найбільші, найшвидші, найдешевші виробники друкованих плат – це Китай. І Китай прямо зараз для України вводить прикольні обмеження, що ми не можемо в них замовити так званий PCB-A, PCB-Assembly, тобто друкована плата вже з компонентами. Ми не можемо, ще місяць тому могли, а тепер не можемо, відповідно ми мусимо, наприклад, в них замовити PCB, тобто не PCB-A, а саме PCB, тобто Printed Circuit Board, без компонентів, отримати їх тут, а потім окремо... Секунду, хтось... О, окей. О, тепер Влад. Які саме виробники всіх? Я знаю про те, що JLC, PCB і PCBWay, ми з ними співпрацювали дуже активно. Дуже жаль. Дуже жаль. Я сам спирався, ну добре. Влад, сили вам і натхнення, це проблема.

**[01:19:53]**

Але якщо захочете, сконтактуйте зі мною, я вам підкину на кілька компаній. Добре. От, ну в будь-якому разі, і виникає реально просто на рівному місці. От уявіть собі, реальний мій поточний один з проєктів, дуже жорсткий, такий як клинч, жорсткий проєкт, що ми випустили один реліз два місяці тому, ми вибудували його на PCBWay, і все було ок, все було нормально. Зараз ми пропланували наступний реліз в таймлайні, всі ці справи, все визначено, і ми замовляємо зараз уже новий реліз, а вони нам відписують, ні, ні, хлопці, не можемо, все, вибачте, тільки PCB, не асембли. Щоб ви розуміли всю проблему, ми розпланували бюджет, ми розпланували таймлайн, ми розпланували сетап команди. У нас вже це все діво вибудоване і перевірене на асемблі, на одній інтерації.

**[01:21:00]**

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

**[01:22:00]**

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

**[01:23:05]**

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

**[01:24:20]**

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

**[01:25:43]**

А от хардвер, на жаль чи на щастя, він існує у фізичному також. Він об'єднує у собі одне і друге. Тому от, наприклад, ви шукаєте, окрім того, що ви розробляєте щось, от розробка, вона йде з використанням софтвер. Та сама навіть от механіка. Ви використовуєте там FreeCAD, AutoCAD, SolidWorks, Fusion і так далі. Ну, оцю всю екосистему. Ну, очевидно, що іде розробка на софтвер, так? Але потім ви повинні це виготовити. І тоді ви їдете в Білу Церкву, до заводу в Білій Церкві, чи в Харкові, не знаю, чи в Дніпрі, з ними кому контактуєте, що хлопці, так і так, нам треба такий-то корпус, такі-то кількості, виготовити. І вони починають аналізувати ваші креслення, виготовляють це, а потім вводяться нові речі, які ми не вводили в нашу команду,

**[01:26:40]**

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

**[01:27:52]**

Наразі, я думаю, це все Мене є до вас велике прохання Будь ласка, розбийтеся на групи Мене цікавить, щоб сумарно з потоку було сформовано орієнтовно 6-7 груп Навскрізно по списку Список, ви його зможете відшукати Я вам зараз зашарюю скрін Ось я тут сформував на основі наданих вами матеріалів, я сформував, так, так, кажіть, я не знаю хто. Там ще потрібно, щоб ви до Google Drive надали доступ, бо там немає. Зроблю все, що треба зроблю, однозначно. Актуалі на пошту має прийти. Окей, окей. Ну, в будь-якому разі я наразі надам вам такий супер-крутий, стрьомний доступ, не люблю я такі доступи робити, ну, все ж, як доступ на редагування. І в чатику, ось тут, я відсуваю оцей список групи. Моє прохання буде, в цьому чатику, який ви відкриєте,

**[01:29:17]**

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

**[01:29:30]**

Називаємо його як команди.

**[01:29:35]**

Команди. І копі-пастом сформуйте команда 1, команда, відповідно, 2 і так далі.

**[01:29:48]**

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

**[01:30:57]**

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

**[01:31:35]**

Чи видно вам? Видно, так. Ось, ага, окей, я ще не всіх схвалив.

**[01:31:43]**

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

**[01:32:13]**

Що ж, добре, тоді я сподіваюся, що ви гарно провели час і зустрінемося скоро. Ще раз. Можна виховати, як має бути написано? Точно. Я вам скинув лінк, напевно ви його отримали, ось цей лінк. Попробуйте перейти по ньому, я думаю, що він вам дасть вікно реквесту на доступ. Ви надіслали, так? А, бачу, я схвалюю. Пробуйте. Все йде так. Круто, круто, добре. А можете ще надати дозвіл на редагування, щоб можна було записати команди? А я надав, ну давайте ще раз глянемо. Я відкриваю це посилання і маю все одно тільки перегляд. Дивно, тому що ось плачете, всі можуть редагувати, але давайте... Тут написано переглядати. Ах, чорт побери. Логічно, тепер все стало дуже логічно. Це називається, комусь треба оптику замінити.

**[01:33:31]**

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

**[01:33:40]**

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

**[01:34:04]**

Ну, знаєте... А скільки всього студентів навчається? Зараз глянемо, секунду. Так. Скільки у нас тут? 15 плюс 16, 31 і 47. Але я не впевнений, чи всі, власне кажучи, старости мені скинули ці списки. Я їх, відповідно, закопів пасти собі. Чи це прямо всі, хто будуть, мені навіть тяжко судити. Ну, це актуальні списки, але деякі студенти може просто неактивні, ну, загалом, як такі просто. Це хіба була не вибіркова дисципліна? Це вибіркова, це список проходить зараз у вас всіх просто груп, ті, хто є в групах, але не всі вибрали цю дисципліну, у нас має бути, мені здається, десь до 20 людей. Добре. Чи могли б ви, будь ласка, в рамках своїх груп, підсвітити мені якимось кольором, хто реально є, хто реально ходить?

**[01:35:19]**

А відкрити просто Google Class? Там, скоріше за все, вже всі доєдналися, там будуть учасники. Я гляну, чи в мене є цей Google Class. Знову ж таки, при всій повазі, я просто в КПІ вперше за 10 років, тому в ті часи, коли я тут викладав, були ще папери, відповідно, я глянув відносно Google Class, чи є в мене до нього доступ. Якщо ні, то я його собі організую через кафедру, але наразі дійсно буду вдячним, якщо якось себе просто отут підсвітить. Червоний, жовтий, це абсолютно комфортно.

**[01:36:15]**

Що ж, добре, вдячний за ваш час і бажаю спокійного, хорошого дня. Дякую вам за повернутися. До побачення.

## Нотатки

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