---
title: "2026-09-22 08-31-42"
source_video: 2026-09-22 08-31-42.mp4
source_audio: 2026-09-22 08-31-42.mp3
duration: 01:48:42
language: uk
language_probability: 0.964
model: large-v3
device: cuda
transcribed_at: 2026-09-22T18:19:19
segments: 657
paragraphs: 72
status: draft   # draft | reviewed | published
tags: [лекція, транскрипт]
---

# 2026-09-22 08-31-42

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

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

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

**[00:08:18]**

Починаємо ще до 8.45. Народ зможе під'єднатися. До речі, запитання. Хтось є? Фізично з гуртожитку, десь рядом з КПІ хтось проживає?

**[00:12:14]**

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

**[00:13:35]**

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

**[00:14:41]**

Потім інколи на RFI відразу дається пропоза, в якому ми вже говорили, що там є опис бізнес-моделі дуже коротко, як в Summer, потім Introduction, потім опис архітектури, потім опис імплементації, потім опис ресурсів, якими командами, яким сетапом ми розуміємо, що це будемо робити. І потім офипопис фінансів. Такий документик. Обично кидається в Word, інколи кидається в Excel. Останнім часом робиться в MD форматі, бо активно використовується LLM підсидіва, тому MD комфортніше для подальшої обробки цього всього. Ну, і як вихідний є пропозов. По цьому пропозову лід потенційно може зареквестити окремо RFQ, як Request for Quotation, ну, і, відповідно, по цьому RFQ ми прямо от кажемо про те, що там скільки буде коштувати, скільки буде йти, скільки ресурсів нам треба буде для того, щоб це все зав'язати.

**[00:15:49]**

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

**[00:16:57]**

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

**[00:18:08]**

Лігали моніторять, аналізують і потім підписує хтось із C-Level, тобто навіть не директори, тобто є інженери, менеджмент, потім директор є, потім C-Level. Відносно C-Level, це віце-президенти, це президенти, це СІО, СТО, СІФО, оці хлопці мають право автографу, вони підписують відповідно цей документ. І от з цього моменту, коли документ підписаний, ви можете їх називати клієнтом. До цього вони ліди в різних своїх іпостасіях і стадіях. От коли вже ви з ними зустрілися, здебільшого вживу, хоча, чесно кажучи, виникали випадки і коли зустріч йшла онлайн, але вживу воно реально круче. ви зустрілися, ви помітингували, ви сходили разом на обід, ви пожали руки, ви роз'їхалися енгейджери це підхопили і провели через

**[00:19:14]**

legal, legal обмінялися агріментами вичистили ці агріменти, підписали зафіксували, все, після цього це клієнт і от з цього моменту починається робота як я вже і тако ніби згадував трошки раніше клієнт часто каже Ну, тіпа, вперед, понеслась, let's go, лобати проект. І щоб ви не опинилися в шоковому стані, то, тіпа, бляха-муха, як так, який проект, воно в тому людей, нам, ну, тіпа, що робити, ми зовсім не готові. Готуйтеся до цього трохи ранше і, по-перше, наприклад, в пропозалі, який я вже казав минулого разу, опишіть буквально один кісточок тексту або прямо пишіть там нотіс, як зауваження, актуальне, важливе зауваження. Візьміть його в рамочку, поставте там червоним кольором, жирним, великим, що, типу, після підписання агрімента нам потрібно там 2 тижні, 3 тижні, 4 тижні, 5, 6, рік, не знаю, для моменту, від моменту підписання до початку проєкту.

**[00:20:29]**

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

**[00:21:50]**

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

**[00:22:47]**

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

**[00:23:59]**

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

**[00:25:09]**

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

**[00:25:39]**

Суть в чому?

**[00:25:42]**

Ви з ними комунікуєте фізно скільки часу. Ви написали пропозал, зробили естімейт, оцінили, яку треба взяти команду, розписали фічі, пробили таски, сатаски, для вас все прозоро, все класно. А потім клієнти кажуть, пацани, а ми там щось подумали і ми вам вже не могли все відкрити зразу. І коротше кажучи, проект буде не про то. І це часто. Це реально часто. І ви розумієте, що вони вас просто тестили, наскільки ви flexible, і що цей proposal, цей проект, ці всі діла, над якими ви думали досить багато часу, це був просто пробний шар. Вони попробували вас, наскільки ви можете реагувати швидко на процеси, а не передавали вам реально завдання, бо між вами, ну, так, якийсь там NDA був підписаний, очевидно, але вони вам не вірили.

**[00:26:49]**

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

**[00:27:55]**

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

**[00:28:35]**

Ми розуміємо, що він повинен мати 6 степеней свободи, напевно, якийсь стандартний адаптер для корисного навантаження. Він буде працювати в нас в офісі джерела живлення 220 вольт, ну там буде якийсь керуючий комп'ютер через Азернет, хай цей робот буде під'єднаний. Основна розробка буде йти через роботі Call Operational System 2, роз 2. Нам треба комп'ютер Vision, там ще люди ходять, відповідно функціональна безпека, щоб робот їх там не вдарив або вони не вдарили робота. Ну і самі плати, які він буде тестувати, вони дуже різні у своїй номенклатурі, вони суттєво відрізняються по розмірах, кольорах, по кількості слоїв, по компонентній базі, яка розпаяна, по технології виготовлення. Також, відповідно, нам потрібен CV, нам потрібна якась AI, яка зможе швиденько навчитися на еталонних якихось бордах, як виглядатимуть саме ці борди.

**[00:29:38]**

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

**[00:30:49]**

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

**[00:32:04]**

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

**[00:33:30]**

Тобто є оцей спіч, оцей текст, який там цей клієнт видав, а потім бізнес-аналітик повинен розбити це на логічні блоки, що є, однозначно, він так, про що цей чувак казав? Він казав про робота. Добре, є якісь вимоги до робота. Робот-маніпулятор. Він там казав, що це якийсь існуючий робот, 6 степенів свободи, як у людської руки. Добре, ендефектор відсутній, але є стандартний адаптер. Тобто отут замість кісті, отут вона відрізана, в нього є стандартний адаптер, яким можна під'єднувати різні готові ендефектори. Так, так, так, окей, відповідно, оце один модуль, йдеться про робот-маніпулятор стандартний, без ендефектора, але з стандартним, відповідно, інтерфейсом. Живеться із AC 220 Вольт Супер Інтерфейс кооперації з

**[00:34:31]**

Комп'ютером Ethernet Має підтримувати роботі Коопераційного систем 2 Працює в офісі Але сертифікований для взаємодії з людьми Бо вони казали, що там є рядом люди Окей Далі він повинен Зависпечувати оперування З елементами електроніки Тобто його ціль Це тестування виробу електротехнічного виробництва, тобто ось такий BCB, BCBA. Тобто його точність повинна бути співрозмірна з типовим дизайн-профайлом цих плат. Там орієнтовно 0,2 мм, 0,1 мм – це його здвиг в точці оперування. Окей, оце він вицепив з цього спіча, який тільки що ви почули від мене в ролі клієнта. Він витипав, і в нього утворився один чаптер, один розділ, робот-маніпулятор, який описаний таким чином. Поки він з цим нічого далі не робить. Ну, далі він аналізує наступний компонент.

**[00:35:35]**

Наступний компонент – це End Effector. Чому? Тому що клієнт чітко описав, що йому потрібен End Effector, який буде під'єднуватися до консолі робота-маніпулятора через стандартний інтерфейс. Добре, відповідно, є стандартний інтерфейс, з ним треба визначитися. Сам ендефектор точно не існує, його треба розробити. Ендефектор включає в себе наявні одночасно три інструменти, електромагнітний, механічний і тестовий інструмент. Відповідно, вони хочуть, щоб ці три інструменти могли бути задіяні рішенням робота. Тобто має бути якийсь засіб, якесь механічне рішення, яке може провернути інструмент, обрати якийсь один, або гріпер, або електромагніт, або цю тестову матрицю, і відповідно, щоб робот, як консоль, ввела цей інструмент в робочу зону маніпулювання.

**[00:36:32]**

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

**[00:37:35]**

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

**[00:38:38]**

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

**[00:39:29]**

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

**[00:39:46]**

Описуємо, що є наявний цей от лідар. Потім, що там у нас іще? Поживлення ми описали. По комунікації Ethernet-Ethernet, відповідно, нам якесь потрібно задеплоїти свій роутер, який розв'яже цю езернет-комунікацію між окремими модулями, відповідно, дітей-обчислювач, є ендефектор, є цей самий сам робот і можливо відразу якийсь шлюз на зоні. Відповідно, є чотири езернет-точки, які мають бути зв'язані по цьому роботу. Добре, з цим ми розібралися. І так далі. Відповідно, що робить бізнес-аналіз? Він робить слайси з цього монотонного спіча від клієнта. Він його декомпозує на окремі чаптери. Як чаптер №1 – це робот. Чаптер №2 – ендефектор. Чаптер №3 – сенсорна система. Чаптер №4 – система управління. Чаптер №5 – це комунікація, Чаптер №6 – це функціональна безпека і так далі.

**[00:41:01]**

Він це діло нарізав і кидає в ексельку. Воно буде у вас виглядати таким чином. Зараз я заширю скрін. Попробуємо це зробити. Так, зараз drive, відкриємо якийсь drive, просто якийсь ексельчик, і відповідно, давайте так будемо писати, розділ 1, розділ 1 у нас буде робот-маніпулятор. Потім розділ 2, End Factor І так далі Ми їх розбили Good Тепер, в рамках цього розділа №1 Робот-маніпулятор Що робить початку цей фізнес-аналітик? Він описує, що клієнт вказав потребу купити готовий робот робот, що матиме 6 степенів подвижності і т.д.

**[00:42:17]**

Описав він цю штуку у повний рост, як кажуть, потім після цього переходить до наступної частини End Effector. В рамках End Effector що він описує? Описує, що клієнт вимагає розробку Ент ефектора з нуля. Хоче мати там три інструменти і опцію автоматичного вибору інструмента і так далі. Він описує тут все це діло словами, але у вас є вже якась декомпозиція. У вас, відповідно, буде спочатку ось тут, це input, де просто куча тексту, яку він отримав прямо з цього металу в чистому виді. От клієнт щось там не диктував, окей, ми його сюди взяли, скинув.

**[00:43:15]**

Потім отут вже у нас є деяка інша історія, це розділи. Після того, як є розділи, наступний крок, який в темпі робиться, це юзерсторі У рамках цих юзерсторій робиться наступна штука Буквально копіюються оці чаптери Один чаптер, другий чаптер, інші всі чаптери Ми їх взяли І він вказує User Story 1, User Story Chapter 1.1, указав його ідентифікатор і потім тут описує, що це сама така специфічна історія. Він повинен прийняти на себе послідовно ролі всієї системи, кожного компонента у цій системі, кожної людської ролі, яка буде залучена в цю систему. І як ніби від нього, від цього компонента, чи від цієї людини, він повинен уявити, що йому буде потрібно, щоб досягти оцього технічного облазу. Наприклад, як це має виглядати, як система керування ендефектора, як система керування ендефектора,

**[00:45:15]**

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

**[00:47:13]**

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

**[00:48:42]**

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

**[00:50:07]**

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

**[00:51:49]**

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

**[00:53:04]**

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

**[00:54:20]**

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

**[00:56:03]**

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

**[00:57:10]**

Епіки. Епіки, вони фактично, або інженерні сфери, вони фактично визначають структуру рекламентів. І от тут, з цієї історії, ви отримали розділи. Робот-маніпулятор, розділ-ендефектор, розділ-оператор, система керування і так далі. В кожному з них, я вам гарантую, будуть такі частини, як, наприклад, механіка, як hardware, як firmware, як middleware, як application, як testing, як documentation, як manufacturing, як integration і як procurement. Відповідно, оці всі історії, вони будуть присутні тут, вони будуть присутні отут, вони будуть присутні в кожному вашому оцьому маленькому юніті свої. І тому в реквайментах ви робите їх наступним чином. Ви розбиваєте ці ваші всі локальні догадки, ви розбиваєте їх на окремій гаузі інженерії.

**[00:59:15]**

Як вимоги по механіці, вимоги по hardware, вимоги по firmware, вимоги по middleware, вимоги по application, вимоги по виробництву, вимоги по проведенню тестування, вимоги по інтеграції, вимоги по документації, вимоги по прокюрменту і по інтеграції. Інтеграція вже була. От вони. Good. І тепер в рамках кожної з них ви прописуєте, відповідно, їхні значення. І до цього ми вернемось через 10 хвилин у 9.32. Мементи, які після цього всього нашого діла формуються, розбиті на категорії. по тих інженерних сферах, які ви вибудували, відчули, власне кажучи, з ваших юзер-сторій. Які вимоги до вимог? Які вимоги до написання рекламентів? Є така прекрасна стаття від Siemens, вона в перекладі звучить як «Як писати правильно рекламенти?».

**[01:14:32]**

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

**[01:15:53]**

Рекламент завжди лаконічний. Рекламент пишеться вибраною мовою, тобто це може бути англійська, це може бути німецька, це може бути українська і так далі. Ну, вона має бути одна. Понятно, що в рекламентах ви можете використовувати ідентифікатори, які визначені в вашому глосарію. Тобто, наприклад, якщо ви визначили, що у вас є hardware-компонент, end-effector, hardware-компонент, робот-hardware-компонент, communication-interface-hardware-компонент, power-supply-system і так далі, то відповідно ви можете використовувати ці назви, як робот HVC, як ідентифікатор цього компоненту, прямо в реквайменті. Чи можуть використовуватися в реквайменті якісь чисельні значення? Можуть і мають. Якщо у вас є обмеження, наприклад, до механіки, робоча зона робота-маніпулятора визначена напівсферою радіусом 1 метр.

**[01:17:18]**

з похибкою 10%. От ми чітко указали рекламент до дальньої сфери, дальньої сфери робочої зони.

**[01:17:36]**

Тут є чітко чисельний визначик. Є визначена допустима похибка. Вона описана, вона самодостатня. Далі. Механічний реквіемент. Отже, робот оснащується payload адаптером типу якогось. І отепер дивіться, бачите, я тут вжив англіцизм, тому що це взагалі не прийнятий термін, який ми використовуємо в цьому проєкті. Відповідно, так, він іншою мовою, але разом з ним він цей. Далі, у вас може бути така історія, що у вас є два реквайменти, які працюють так. Робоча зона маніпулятора визначається напівсферою радіусом 1 метр. Робоча зона маніпулятора має зону недосяжності радіусом 0,5 метра від базової точки. Тут в цьому рекламенті є деякі нюанси. Для початку зона недосяжності радіусом. Окей. Понятно, що це якась сфера, можливо, а може напівсфера. Тобто трошки непонятно.

**[01:19:39]**

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

**[01:20:45]**

Поохибки механічних складових робота не перевищують 10%. О, бачите, окремий рекламент, який насправді рішає, він живе окремим життям, Тепер оця штука стає більше неактуальна, ми її видаляємо, бо вони потенційно можуть протирічити, особливо, якщо, наприклад, ось тут буде Revision 2, так, якщо буде тут Revision 2, ось так, то, відповідно, і він там, наприклад, стане, при цій Revision 2, стане ось так, а ми ось тут казали погибка 10%, то у нас виходить, ну, все ще окей, бо тут як ніби як не перевищує, тут 10%, що окей. А якщо, наприклад, ми кажемо, що в ревізіон 3 у нас тут стало 9%, а тут 10%, о, у нас є уже класичний конфлікт. У нас є конфлікт між двома реквайментами, що цей каже про погибку в 10%, а цей дуже чітко каже, що механічна погибка не перевищує 9%.

**[01:22:04]**

І оце проблема, яка повинна забезпечуватися через джаджмент, тобто якесь судження. Чому це так? Тому що реквайменти, як такі, завжди сприймаються через оператор і. Тобто, що в нас завжди вони виконуються одночасно. Не може бути так, що там якийсь рек, він просто ігнориться. Ні, таке не буває. Якщо у вас є проблема з тим, що є, ну, скажімо так, там, часові квоти, і ви чогось не втащуєте це все зробити, ну, прямо, от, одночасно і так далі, або, дійсно, є проблема конфлікта реквайментів, таке, ну, таке постійно, насправді, трапляється, Тоді є, наприклад, критерії, як M, як mandatory, а є T, як tentative, тобто, не погано було б мати. M – це must have, ти маєш це діло реалізувати. І тому, відповідно, ми кажемо, що є якісь реквайменти з групою M, а є реквайменти з групою T.

**[01:23:24]**

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

**[01:24:37]**

Колеги, хто підкаже?

**[01:24:46]**

Системні, системні реклайменти А що це за реклайменти? Хто підкаже?

**[01:25:03]**

Окей Системні реклайменти Ще одна велика категорія, головна насправді Системні реклайменти, вони накладаються не до компонента Тобто, це реклайменти, які до категорії механіка, до категорії хардвер, до категорії фірмвейер, а System Requirements – це дещо інше. Вони фактично накладаються на те, як продукт буде працювати як єдине ціле. І, наприклад, System 1, System Requirement 1, він каже, що робот-маніпулятор оснащується End Effector через стандартний Payload Ring. Окей, це є системний рекваймент Там, відповідно, далі System2 Він каже про те, що Endefactor Налічує Налічує Овертальний механізм Для позиціювання Інструменту відповідно до області маніпулювання. Так, є. Далі в системі 3 каже, грубо кажучи, це ще можуть бути категорії,

**[01:26:56]**

що робот-маніпулятор і енд-ефектор взаємодіють між собою Засобами цифрового інтерфейсу Ethernet через проміжний комунікаційний пристрій. Добре, ми це описали. Далі. Систем 4, він каже, ну давайте зовсім іншу категорію, що керування маніпулюванням об'єктами проводиться із застосуванням Керування маніпулюванням об'єктами проводиться застосуванням РОС-2 інтерфейсу через керуючий комп'ютер. Це абсолютно інша категорія. Таким чином ви фактично потрошки-потрошки-потрошки вибудовуєте цю всю структуру. Початку з System Requirements, а потім, в чому самий смак, що ви фактично мусите для повного покриття системи вашими вимогами, Ви проводите це відповідно до тезваної V-моделі, тобто у вас є якась початкова точка ось тут, а це точка опису всієї системи System Description,

**[01:28:47]**

яка в свою чергу йде до реалізації System Requirements, яка в свою чергу йде до Hardware, Software, Mechanical і т.д. Requirements, яка в свою чергу йде до Hardware Component Description, яка в свою чергу йде до Implementation, тобто так, як ви його вже реалізуєте, потім до перевірки згідно з гайдлайном, тобто статичний аналіз, потім Unit Test, Integration Test, performance test, regression test валідація, верифікація відповідно, от ви рухаєтеся по цій от V моделі звідси потім йдете сюди і на кожному кроці маєте змогу поміняти початкові реквайменти і змінити вашу систему таким чином, на що зараз би хотів звернути увагу по цій моделі на оцей маленький кусочок Ви починаєте з опису системи, вона йде там як User Story, потім System Requirements, потім декомпозуєте його на чаптери, там відповідно Software, Hardware, Firmware, дальше Requirements, ви їх декомпозували.

**[01:30:18]**

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

**[01:31:13]**

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

**[01:32:11]**

Відповідно до цього у вас є додатковий компонент, це End Effector HVC. Вони між собою зв'язані через механічний зв'язок, у них є свій механічний зв'язок, це Payload Adapter. Далі, ви знаєте, що на вашому End Factory це буде досить крупний об'єкт. Чому він крупний? Тому що вам потрібно забезпечити його деталізоване подання. Зараз ми цим займемося. Через Payload Adapter ви зістиковуєте робот-маніпулятор із End Effector. І в рамках цього End Effector у вас є окремі складові. По-перше, це Rotation Hardware Subcomponent, тобто цей елемент, який забезпечує обертання інструменту, Для того, щоб вибрати потрібний інструмент, гриппер, як один з них, електромагнітний і тест-пед. Відповідно, у вас є три цих елементи, ви їх описуєте, що вони от у вас є всі три, плюс оця складова, яка забезпечує ротацію.

**[01:34:53]**

Далі у вас на EndFactory однозначно під тест-пед буде якийсь IOControl MCU або FPGA, який фактично забезпечує можливість прокидання на кожну ніжку вашого педу Відповідний керуючий сигнал або їхнє щитування для того, щоб дійсно сформувати змогу, коли ви накриваєте цю матрицю тестування, ваш об'єкт тестування, то ви фактично по кожному піну можете обрати, що туди прокидуєте. Відповідно, у вас буде якийсь IOMCU, FPGA, який буде підсилений якимись High Voltage, High Current Drivers, і відповідно буде керуватися з цього МСЮ. електромагнітна штучка ваша буде також керуватися власним high voltage current driver як і gripper але gripper також у вас буде мати додаткові засоби сенсорної системи це force control force control

**[01:36:27]**

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

**[01:37:07]**

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

**[01:38:21]**

Окремо. Це Computer Vision.

**[01:38:28]**

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

**[01:39:47]**

External IO, це, власне, інтерфейс до зонічного комп'ютера. У нас є, що однозначно є. Вам треба якось цим всім керувати ззовні, вам треба доступ до зонічного компану, яким буде ранитися ваша апка управляюча і так далі. Далі, вам треба якось буде зістикувати робот, в нього є здебільшого в сучасних роботів, в будь-яких, Є своє мікрокомп'ютерне керування, свій процесор, на якому розгорнута своя роз, в ній розгорнуті свої ноди, і ви їх просто колете, ви їх визиваєте, вам треба езернет тут. Далі, оця штука, відповідно, це ваша кастомна історія В неї є свій мікроконтролер, свій Linux, свій ROS Це повністю окремий виріб Він просто механічно зв'язаний з роботом Робот його доводить в робочу зону, і все А потім ви оперуєте із оцим вашим ендефектором

**[01:40:56]**

Керування роботом – це окрема річ Керування ендефектором – це окрема річ Їх навіть між собою не потрібно зв'язувати Далі, CV, LIDAR, RADAR Ніяк не зв'язана з роботом Ні механічно, от механічно вона зв'язана А більше буде навіть зв'язана з ендефектором Ви її фактично будете ставити на цей ендефектор На цей ендефектор механічно Ми його так і візуалізуємо Але з точки зору програмної частини Ці речі, вони, як би так сказати, живуть окремим своїм життям і нам потрібно це буквально інтерпретувати. Є. Так, далі у нас має бути якесь живення. Це живення, окремий компонент, він, знову ж таки, не є частиною ані окремого робота, ані окремого ендефектора, ані окремої вашої сенсорної системи,

**[01:42:21]**

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

**[01:43:20]**

до наступного разу на команди. По-друге, визначить в рамках команд ролі.

**[01:43:33]**

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

**[01:45:05]**

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

**[01:46:25]**

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

**[01:47:49]**

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

**[01:48:32]**

Дякую. До побачення.

## Нотатки

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