---
title: "IgorSikorskyKPI_L1_01092026"
source_video: IgorSikorskyKPI_L1_01092026.mp4
source_audio: IgorSikorskyKPI_L1_01092026.mp3
duration: 01:47:43
language: uk
language_probability: 0.989
model: large-v3
device: cuda
transcribed_at: 2026-09-22T18:28:50
segments: 676
paragraphs: 93
status: draft   # draft | reviewed | published
tags: [лекція, транскрипт]
---

# IgorSikorskyKPI_L1_01092026

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

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

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

**[00:00:00]**

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

**[00:00:18]**

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

**[00:01:36]**

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

**[00:03:04]**

Це супер критичні системи, де поняття супер критичні Це супер як дещо за Тобто супер це як після події збою системи як, власне кажучи, система повинна себе вести після того, як уже незворотні ситуації відбуваються і система стала пошкодженою, як би довести процес керування до якогось її фінішу. Це та область, якою я займаюся. Я також зараз навчаюся у постдокторопрограм. Це те, що по завершенню приносить ступінь доктора наук, але це ще питання, як кажуть, чи принесе. Але глянемо. Окрім того, що є академічний цей напрямок, який для мене більше як хобі, є ще інший напрямок, це IT. В IT я працював в Samsung, Global Logic. Наразі я надаю сервіс Intel на позиції C++ архітектор. І також я інженеринг-менеджер в компанії NIX. І от саме роль інженеринг-менеджера для цього курсу, вона буде досить цікава. Поясню, чому.

**[00:04:34]**

Цей курс вибудований як результат співпраці між кафедрою, між КПІ і компанією NIX. Тільки не путайте з харківським NYX, є NYX, так, є N-IX, от N-IX це от моя компанія, який я працюю в підрозділі або в Unity, або в Division, який називається Embedded, Embedded Division. В цьому Embedded є ряд позицій. Одна з них – це Engineering Manager. Тобто той менеджер, який забезпечує якість надання сервісу з точки зору інженерних підходів, методів, методик і так далі. Це то, що я роблю. В Еніксі я працюю 5 років, а на кафедрі, буквально, сьогодні мій перший робочий день. До речі, всіх з 1 вересня.

**[00:05:40]**

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

**[00:06:08]**

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

**[00:06:49]**

сетап команди, створення супровідних документів,

**[00:06:55]**

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

**[00:08:32]**

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

**[00:09:52]**

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

**[00:10:12]**

Далі, як же ми вибудуємо цей курс? Нам з вами є в кінці залік, скажімо так, дуже круто проговорити definition of done, Чим це все завершиться? Завершиться воно заліком. До заліка у нас є дві атестації, які ми будемо проходити, відповідно, в кінці першої дії третини, і другої третини семестру, ну а третя третина, відповідно, закінчиться заліком.

**[00:10:49]**

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

**[00:11:05]**

Всі ми, у нас тут буде деяка кількість, а наразі я даруюся, що у нас 18 людей, Очевидно, що очікується, що у нас буде більше людей В будь-якому разі, маємо наразі скільки маємо Всі ми, всі студенти, які присутні зараз, будуть потрошки з часом розбиті на такі групи І в рамках цих груп ми попрацюємо над процесами створення маркетингового матеріалу Участі у залученні клієнтів, залучення таких клієнтів, побудови деякого процесу, побудови проєкту І, відповідно, пройдемося по цих рутинах, які є Якось так Чи є наразі в когось будь-які запитання щодо цього?

**[00:12:12]**

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

**[00:12:49]**

Ще питання?

**[00:12:54]**

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

**[00:14:20]**

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

**[00:15:56]**

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

**[00:17:15]**

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

**[00:18:22]**

Йдеться завжди про такий виріб. Embedded часто, особливо Михайло дуже правильно сказав, воно описується тим, на чому воно раниться. В даному разі приклад з мікрофільовкою був дуже валідний. У нас є досить вузька задача керування досить вузьким переліком програмного забезпечення. яке у свою чергу раниться на дуже лімітованому мікроконтролері, яке повинне забезпечувати дуже специфічні функції, наприклад, sleep mode, тобто нікому не потрібно, щоб мікрохвильовка фігачила і споживала номінальний потенціал, номінальний рівень енергозабезпечення постійно. Вона заходить в якийсь IDLE або SWEEP і потім переходить в нормальний мод тільки тоді, коли це реально потрібно. Тобто, йдеться про софт, який дійсно, як кажуть,

**[00:19:35]**

з заводу реалізований під конкретний таргет, під конкретне апаратне забезпечення і виконує дуже-дуже лімітований перелік задач. Області використання такого програмного забезпечення є дуже широкі, вони відповідно ще з 50-х років вони отримали розповсюдження однозначно в мілітарі, вони отримали розповсюдження в індастріал інженірінг, у станках, у автоматизованих лініях, в автоматизації в цілому. Вони отримали розповсюдження у аероспейс, вони отримали в автоматів, Вони отримали розповсюдження у Home and Office Use, дійсно, оце порівняння з мікрофільовкою або з правильною машиною і так далі, це дуже валідно. Але це фактично плюс-мінус ті самі підходи в якийсь там степені рідності до того самого програмного забезпечення, яке раниться, яке розробляється для так званих ECU або Electrical Computing Unit у автомобілях, у літаках і так далі.

**[00:20:46]**

Підхід плюс-мінус той самий. Лімітовані ресурси, високий рівень визначеності поведінки програмного забезпечення, ну і відповідно всі наслідки, які спонукають ці речі. Курс присвячений саме Embedded. В системах того я, власне кажучи, підвожу і чому я про це запитував. Отже, ми маємо справу, ми завжди в рамках Embedded маємо справу із чітко детермінованою системою, в якій вимоги до системи визначені. Бізнес-логіка поведінки такого виробу визначена, гнучкість присутня, але обмежена. Основні функції ізольовані в рамках ядра самого виробу. Вони задеплоєні, вони розгорнуті безпосередньо на самому чіпі. як MCU, або DSP, або CPU з якоюсь обгорткою, або SOC, як System of Uncrystal. Особливо немає різниці, але ідея завжди одна і та сама.

**[00:21:59]**

Великою групою різницею між, власне кажучи, такими видами прав на забезпечення Є швидше оці сімейства систем, які з нуля та чистим кодом пишуться напряму на халу бібліотеки, як Hardware Abstraction Layer бібліотеки вашого таргета. наприклад, якщо ви взяли там якийсь STM32, Atma, і що б вам тільки не захотілося, якийсь NXP чіп, то далі ви швидше за все відкриєте їхню ID, їхню студію, візьмете, напевно, їхні або якогось їхнього партнера бібліотеки, їхній HAL, їхній Hardware Abstraction Layer, І напишете свою бізнес-логіку, будете діргати їхню лібу, і з цієї ліби будете безпосередньо використовувати ресурси цього таргета.

**[00:23:09]**

Таким чином, власникаючи, це є один відхід. Він дуже популярний, дуже нормальний, він фінансово дуже доцільний для невеликих систем. Є ще і інший підхід, який ґрунтується на тому, що вам потрібно забезпечити дещо вищий рівень гнучкості, або якщо ви працюєте з абстрактно вищими рівнями периферійного забезпечення, або якщо ви хочете ризнути великий шматок чужого коду. При такому розкладі, це типовий розклад, просто для прикладу, коли ви розробляєте систему на основі Raspberry Pi, коли вам потрібно взяти і розгорнути систему, яка, наприклад, підніме вам ензернет, підніме вам Wi-Fi, Забезпечить вам можливість заранити великі шматки чужого коду Плоть до того, щоб підняти сервіси, мейл-сервіс, веб-сервіс, якісь тунельовані протоколи

**[00:24:25]**

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

**[00:25:26]**

Здебільшого так сталося В цьому світі це якийсь Linux-based операційна система. А він, у свою чергу, вже тригерить HAL, як Harder Abstraction Layer, а в той, у свою чергу,

**[00:25:43]**

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

**[00:27:00]**

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

**[00:27:20]**

Куди мають інженери, так кажемо, менеджмент, найбільше придивити увагу при таких проєктах, щоб, як кажуть, не дати в штангу?

**[00:27:32]**

Може, в певній мірі, в безпеку і захист даних. Безпека, круто сказано, захист даних, це більше... Це ви буквально сказали за SpaceX і НАТО, я буквально недавно дивився випуск про 15-річного чувака, який спокійно більше декількох місяців шарився по, спочатку НАСА, а потім в ЦРУ, і не дали йому співпрацю, а просто на 15 років посадили. Ти, хлопчина, в 25 років з наркоманівся.

**[00:28:32]**

повинна бути достатньо надійною з точки зору власної поведінки вона повинна працювати безпечно а ну а Cyber Security вона повинна бути невразливою для зовнішніх чинників за якими стоїть людини, в даному разі EAI. То як би так узагальнити, яка нова головна біль падає на команду розробників і на менеджмент при розробці от Embedded System? Які ідеї є?

**[00:29:21]**

Давайте, друзі, думайте.

**[00:29:27]**

Друга сторона медалі розробки програмного забезпечення. Що це є? Це тестування. Це тестування. На жаль, як би ми всі його ненавиділи, а це тестування. Відповідно, будовані системи, як от ми всі з вами так уже потрошки обговорили, воно досить ізольоване. Воно реально ізольоване. Воно раниться десь там в себе на якомусь чіпі, особливо якщо йдеться про цей STM стайл, коли у вас є апка, яка раниться прямо на прямо на Abstraction Layer і на залізі. Там взагалі у вас фактично після деплою, коли ви вже розгорнули це все на залізі, коли ви ще, Борони Божа, вже зробили підсидіво заліза, якщо ви зробили там помилку, то ви попали на гроші. Так, відповідно, зробити якісне програмне забезпечення це не написати його, це добре його протестити.

**[00:30:36]**

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

**[00:31:45]**

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

**[00:32:48]**

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

**[00:33:49]**

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

**[00:35:06]**

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

**[00:36:26]**

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

**[00:37:35]**

До чого я тут хотів би привести, що функціональна безпека, вона ренджується на категорії, від самого низького, він називається Quality Assurance, і до A, B, C, D. і, відповідно, ви рухаєтеся по цьому ренджу, і чим вищий він, тим, відповідно, більші ставки. І, як не дивно, для кожного класу такої системи існує свої підходи до тестування. Ми їх трошки-трошки затронемо. Чому трошки, бо, як вам сказати, щоб не втратити суть цього курсу, потрібно по чуть-чуть, а не прямо у деталях. От це все, що я зараз описав, воно стосується до функціональної безпеки, тобто то, де просто по помилці, по некомпетентності, по відсутності достатньої кількості вільного часу помилка пройшла, була задеплоєна і потім стрельнула.

**[00:38:51]**

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

**[00:39:32]**

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

**[00:41:14]**

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

**[00:41:36]**

Чи, може, в мене глюканув інтернет, і ви мене навіть не чуєте? Ми запутали. Круто. Добре, Андрій, дякую.

**[00:41:44]**

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

**[00:43:13]**

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

**[00:45:10]**

Давайте ми в цю гру пограємося, хоча вона тут, звісно, не є валідною. Але цікаво, які ще є думки?

**[00:45:25]**

Колеги, отже, в нас є ідея, що ідея, рух, все. Друге, в нас є, що гроші, потреба, ідея, бажання отримати гроші є рухомим елементом цього. Які є у нас ще ідеї?

**[00:45:50]**

Відмейте ті самі гроші через IT-проєкт.

**[00:46:00]**

Архів, ви мене лякаєте.

**[00:46:08]**

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

**[00:47:39]**

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

**[00:49:40]**

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

**[00:50:51]**

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

**[00:52:15]**

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

**[00:53:28]**

Він залучає, він вам скидає ідею у виді задачі і фінансує вас. Так оце IT-сервіс. Це так, як працює Global Logic, Intel, NAS, SoftServe і так далі. Це відповідно надання сервісу по перетворенні ідеї або фундаментальної теоретичної штуки у технологію для подальшої комерціалізації.

**[00:54:03]**

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

**[00:55:12]**

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

**[00:56:29]**

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

**[00:58:04]**

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

**[00:59:02]**

Відповідно, IP їхнє. І це є золоте правило сервісних компаній. IP залишається за клієнтом.

**[00:59:15]**

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

**[01:00:20]**

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

**[01:01:25]**

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

**[01:02:32]**

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

**[01:03:05]**

Далі, щодо інтелектуальної пропорції.

**[01:03:10]**

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

**[01:04:26]**

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

**[01:05:35]**

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

**[01:23:25]**

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

**[01:23:33]**

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

**[01:25:21]**

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

**[01:26:50]**

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

**[01:27:52]**

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

**[01:28:29]**

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

**[01:29:53]**

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

**[01:31:04]**

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

**[01:32:04]**

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

**[01:33:22]**

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

**[01:34:33]**

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

**[01:35:47]**

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

**[01:37:11]**

Окрім того, дуже вам рекомендую зробити всі від вас залежні речі для того, щоб вас залучали у стадію pre-sale, коли проекту нема, ще клієнта нема, але ви його дуже хочете. І в компаніях є цілі підрозділи. Це Sales Management, це Marketing Department, які вибудовують цілу піраміду дій, щоб конвертнути бажаного клієнта в клієнта. А потім, коли він вже такий, як кажуть, його вже взяли, умочили в тепле молочко, він розплився, йому вже так шикарно з вами, він вас любить і знає прямо от своїх, от тоді, щоб його тако взяти і передати в проєкт в Delivery Department, той, власне, інженерний відділ, який, власне, вже робить продукти. Так от, акцентую, заходите в компанію, початку просто набиваєте досвід, як інженер, як людина, яка має знати процеси, просто от копаєте ці процеси, розбираєтеся в них, робите проекти, починаєте там з джуна, ідете, розвиваєтеся до сіньєра.

**[01:38:40]**

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

**[01:40:01]**

І тоді добрий час для того, щоб переходити власний бізнес.

**[01:40:06]**

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

**[01:41:25]**

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

**[01:42:42]**

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

**[01:43:49]**

Ми розіб'ємося, ну, лекції всі однакові, понятне, вони ідентичні, і я вам рекомендую їх собі слухати. по чуть-чуть, от то, що цікаве. Плюс я вам дуже широко рекомендую використовувати AI для вижимок з цих версій основних матеріалів і їх в анотативному виді почитати чи послухати. Це дуже корисно. Щоб не слухати весь цей об'єм, а саме основні речі.

**[01:44:21]**

По практиках ми працюватимемо в окремих групах, На кожну групу, тобто не академічна група, а в рамках всього потоку, ми сформуємо, наприклад, 6 груп. І кожна оця інженерна група запропонує свій маленький, свою маленьку бізнес-модель, свій маленький проєкт Embedded системи, яка включатиме програмну складову, яка включатиме апаратну складову, механічну складову, тобто ці от три святині Embedded, до яких ми ще вернемося трошки. І вона опише фактично потрошки формування а-ля бізнес-моделі, бізнесу, який ви розгортатимете в рамках цього курсу поступово. Таким чином, атестація №1, я опишу для неї ті definition of done, який бізнес, що він має мати на етапі атестації. Атестація №2, який бізнес, що він має мати, і залік, відповідно, завершена бізнес-модель, яка імітує або дійсно розгорнута,

**[01:45:44]**

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

**[01:46:41]**

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

**[01:47:32]**

Що ж, добре, тоді колеги, вдячний, ви можете від'єднуватися і зустрінемося завтра. Я зупиняю запис.

## Нотатки

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