---
title: "2026-09-16 08-30-23"
source_video: 2026-09-16 08-30-23.mp4
source_audio: 2026-09-16 08-30-23.mp3
duration: 01:21:12
language: uk
language_probability: 0.844
model: large-v3
device: cuda
transcribed_at: 2026-09-16T10:17:19
segments: 576
paragraphs: 66
status: draft   # draft | reviewed | published
tags: [лекція, транскрипт]
---

# 2026-09-16 08-30-23

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

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

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

**[00:00:01]**

Так, запис пішов. Скажіть, чи мене чути, чи мене видно, бо якесь трошки декуди є збої з мережею.

**[00:00:11]**

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

**[00:00:26]**

Добре. Окей, тож, давайте, напевно, зачекаємо одну хвилину. Хтось, може, ще з колег доєднається і розпочнемо потрохи. Щось у нас тут поки небагато виходить. Ну, да, є таке. Ну, нічого. Знову ж таки, у нас буде запис, який я викладу. У нас буде конспект, який я викладу. Десь ближче до атестації я згенерую щось типу методички і цільного конспекту. В принципі, я вже підготував під садіво такий собі як набір правил для яйця. Зробіть, я викладу, буде комфортно вам по ньому йти. Ну і глянемо, може, в режимі ще звукового супроводу зробимо, щоб можна було просто готуватися. Глянемо. Ну це про майбутнє. Що ж, давайте розпочнемо. Розпочнемо ми з нагадування, що було вчора. Вчора була в нас тема, коли ми перейшли від RFI, тобто Request for Information, коли наш лід скинув нам якусь або ексельку, або Word з переліком запитань,

**[00:02:02]**

який хотів би знати про нашу компанію, ми відповіли на ці питання, після цього він нам скинув, наприклад, уже RFC, Request for Clarification, на основі якого ми почали активно працювати по пропозолу, Оце буде, власне, тема нашого проговорення. І після пропозиву, або навіть по таку деяку частину, може йти Request for Quotation. Грубо кажучи, запит на кількість. Ну, кількість це є і затрата часу, і затрата коштів. А якщо йдеться про якісь матеріальні речі, які напряму передаються вже майбутнім замовникам, то і, відповідно, за трата цих коштів. Це щодо послідовності, яка йшла у нас вчора. І, відповідно, я реально оцінюю, що нам в рамках цих зустрічей, які в нас є, в рамках цього курсу, нам вже буде критично необхідно почати проводити практики.

**[00:03:17]**

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

**[00:04:31]**

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

**[00:04:58]**

Отже, як уже озвучилося, пропозов насправді досить формалізований в Embedded, в силу того, що від Embedded особливо в таких нішах, як автомотів, аероспейс, house care, mining, robotics, aviation, military і т.д. від надійності і передбачуваності роботи вбудованих систем, і програмних, і апаратних, і механічних, і їхніх комплексів, Залежить життя, здоров'я, досягнення цілі і цілісність устаткування обладнання Тобто йдеться про ризики Ризики різного рівня Відповідно, це що де є ризики, там йде поняття відповідальності І цю відповідальність ніхто не хоче на себе взяти Для того, щоб її успішно ніхто на себе не брав Існує ціла низка захистів компаній, виробників, посередників, інтеграторів і так далі Ці методи захисту полягають у сертифікації

**[00:06:12]**

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

**[00:07:15]**

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

**[00:08:22]**

До прикразців, особисто в мене є досвід аж одного клієнта з України, а всі інші замовники наших послуг були або європейці, або, відповідно, Сполучені Штати Америки, або Канада.

**[00:08:41]**

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

**[00:09:41]**

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

**[00:10:14]**

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

**[00:11:29]**

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

**[00:12:29]**

Що вам мішає сказати, що ваша компанія вже на шостому рівні?

**[00:12:34]**

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

**[00:13:34]**

фактично рости в цьому. І тим далі, тому подібне. Це, власне, дає вам можливість, підтверджену можливість надавати сервіс у цих напрямках і брати на себе задачі відповідних класів складності. Далі.

**[00:13:58]**

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

**[00:15:21]**

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

**[00:16:23]**

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

**[00:17:33]**

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

**[00:18:41]**

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

**[00:20:02]**

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

**[00:21:07]**

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

**[00:22:16]**

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

**[00:23:29]**

Окей, супер. Або там вимога, що при аплодінгу вашого програмного забезпечення на цей чіп вільне місце повинне у пам'яті мати не менше 70%. Окей, ну і так далі. Відповідно, такі правила у вас є і ви їх слідуєте. Як тільки ви їх наслідували, то фактично ви знімаєте з себе відповідальність про те, що збій в системі призведе до якихось наслідків судового характеру для вас, для вашої компанії або для ваших клієнтів. От таким чином існують ці три рівні документів, які є. Тепер уявіть собі проблему, коли RFC у реквесті for clarification, замовник від вас хоче, щоб продукт був сертифікований для Євросоюзу, для Америки, для Японії. Проблема виникає в тому, що стандарт, про який я кажу ISO, він закономірний тільки в ЄС.

**[00:24:43]**

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

**[00:25:44]**

І тут починається головна гра. Головна гра грошей. Як ви всі, очевидно, знаєте, ви дорослі люди, які вже в повній мірі в бізнесі. ІТ-шний бізнес поділяється на дві великі категорії. Це time and material і fixed price. Тобто, зараз я поясню, до чого я так круто скаканув. Time and material йдеться про те, що фактично клієнт оплачує за витрати нашого часу. Чим більше ми витрачаємо часу, то, відповідно, по рейтах, по годинному договорі, скільки ми хочемо за нашу роботу, він просто оплачує нам. Так само і з матеріалами. Наприклад, якщо ми купуємо для його проєкту щось, ми надаємо додаткову маржу, і відповідно він компенсує вже вартість продукту плюс маржу. Так, відповідно, очевидно, що таймінг матеріал для нас дуже в цьому випадку вигідний.

**[00:26:53]**

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

**[00:27:48]**

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

**[00:28:45]**

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

**[00:29:42]**

Інша історія, зовсім інша історія, це випадок Fixed Price Отже, Time and Material, або T&M, і Fixed Price, або FP Fixed price заключається в тому, що фактично ми після домовленості про те, що ми робимо, ми дуже ретельно домовляємося, скільки це буде коштувати і за скільки часу це буде виконано. При такому розкладі всі ризики про те, що є в домовленому скупі, лягає на нас, на виконавців. І ми відповідаємо особисто, репутаційно, фінансово, подекуди юридично, ну завжди юридично, про те, що об'єм роботи, який був домовлений, буде виконаний і буде виконаний вчасно. Якщо він виконаний, скажімо так, з більшими фінансовими затратами, то це наші проблеми, це вже наші затрати. Якщо він виконаний з якимись часовими затримками, то це проблеми, які окремо домовлюються із замовником. І там є система пенальті, яка проговорюється до початку проєкту, що з нами буде, якщо ми затримаємо.

**[00:30:58]**

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

**[00:31:53]**

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

**[00:33:05]**

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

**[00:34:22]**

Ми це йому зробили по точно тому, як він це описав. І він отримав це в якості вихідного продукту. Тобто він займається своїми справами і не хоче займатися вибіну цими проектами. Дуже типовий варіант. Наприклад, якщо ви не любите крутити гайки, якщо вам не подобається це велосипед, а автомобіль часто ламається, то ви швидше за все будете звертатися в СТО, залишите автомобіль, залишите ключі, що типу оцінить, скажіть, який коштує. Він відзвониться, скаже, ви скажете, окей, добре, він зробить, і ви йому дасте гроші. Відповідно, ви домовилися за fixed price. Fixed time – це дещо інша модель, коли вона дуже сильно використовується в випадках, коли клієнт в неповній мірі знає, що він хоче. Коли він хоче залишити за собою право динамічної зміни поведінки вас,

**[00:35:24]**

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

**[00:36:33]**

Якщо його це влаштовує, тоді супер. Відповідно, оці дві форми, про які я озвучив, Fixed Time і Fixed Price, для проєктів Embedded, вони обоє мають місце жити, місце бути. і використовується здебільшого для випадків відповідних проєктів. Часто виникає ситуація, що на етапі домовленості про проєкт, на етапі виговорення про позову, замовник наполягає на якійсь формі. Здебільшого, я ніколи ще не чув, щоб, наприклад, замовник наполягав на таймедматеріал, а виконавець сказав, ні, ні, ні, ми не будемо цього робити. Здебільшого це відбувається інакше, що замовник наполягає на fixed price, а виконавець може включати задню і відмовлятися від цього, коли хоче наполягати на time and material. Тут, як кажуть, кожен відстоює свої інтереси і аналізує власні ризики. До чого ви там уже зійдетеся на цих перемовинах, то буде видно.

**[00:37:39]**

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

**[00:38:38]**

чи хочете ви з своєї сторони перейти з таймінг матеріалу на фіксит прайс. Але якщо ні, то ви можете прямо відстоювати свою позицію, знаючи, що насправді вже втворені деякі передумови, що клієнту буде дуже тяжко від вас піти. На цьому першому пропозалі, умовно кажучи, першого дня, до прикрості у вас не буде шансів диктувати ваш варіант. В пропозалі, особливо там буде окрема частина в кінці, це комерційна пропозиція, в якій описана рейти інженера, погодинні рейти. Потім ви оціните сумарну оцінку вартості проєкту в цілому. Це буде окрема сума, яка буде вказана там 60 тисяч євро, 70 тисяч, 100 тисяч, 200 тисяч. Наразі мій рекорд це 1 мільйон 400 тисяч євро за проєкт. Відповідно це як фінансова складова, яка описує вартість проєкту.

**[00:39:44]**

А потім ви вказуєте, по якій моделі ви хотіли б і пропонуєте працювати. Ви там чітко вказуєте time and material або fixed price, або time and material і fixed price. Ну, а тут є подвійне дно, коли ви кажете, ну, отут, як вам сказати, дуже тяжко вам буде вирулювати, якщо ви скажете і таємниця матеріалу, або і там фіксед прайс. Чому тяжко? А тяжко тому, що вам потрібно буде різні рейти, різні рейт-карти для двох видів співпраці. Шановні колеги, я бачу, у нас почалася жовта повітряна тривога в Києві, тож я прошу вас перейти у безпечні місця. Заодно я пропоную скористатися цим для маленької перерви у 10 хвилин, ну а потім продовжимо. Отже, зустрінемося о 09.22. Добре, давайте розпочнемо далі, продовжимо.

**[00:51:59]**

Отже, щодо вибору моделі, це Fixed Price або Timed Material, відповідно до випадків ризику для вас, для клієнта. Ми плюс-мінус обізначилися. Тепер давайте ще один аспектик тут, щоб закрити це питання. А саме, чи питання розподілу ризиків – це єдине питання, яке є в різниці моделів Fixed Price і Timed Material? Відповідь однозначно ні. А яка ще є складова? Це кошти. Ризик брати його на себе чи ні. Можна взяти фактично будь-який ризик. Питання в винагороді. Фактично, я думаю, що напевно не існує класу ризику, який не може бути оцінений Якось навіть так скажу круто в цьому плані, напевно Тож, питання коштів Якщо ми розуміємо, що взявши на себе fixed price Ми зобов'язуємося, згідно з їхніх вимог, виконати роботу в поставлені терміни, поставлені гроші, але це завжди коштує більше.

**[00:53:40]**

Тобто, ви для себе рахуєте годину залучення інженерів по-іншому, з більшим коефіцієнтом. Друга складова, яка вирізнить Fixed Price і Timed Material. Знову ж таки, чому я зараз про це так активно говорю? Бо модель, яку ви зараз оберете, вона фактично міняє конструкцію пропозову, вона міняє формат співпраці, вона міняє все. Тому зараз такий акцент на це. Коли ви обираєте Attignment Material, то ви у своєму пропозалі повинні бути дуже детальними і розкрити, скільки дійсно, яка фаза роботи, як ви розіб'єте всю роботу на фази, скільки цих фаз буде, який мейлстоун ви будете досягати в рамках кожної з них, якими ресурсами, скільки буде інженерів, Як ви гарантуєте, що ці інженери відповідатимуть відповідній кваліфікації, скільки буде менеджмента, як ви будете якимись власними силами чи сторонніми силами закривати якісь частини проєкту, наприклад, окей, допустимо, якщо це про корпус, ладно, якийсь перший прототип може вдасться роздрукувати на принтері, а може і не вдасться, якщо він якийсь крупний або працює в інших умовах, температурних і так далі.

**[00:55:10]**

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

**[00:56:10]**

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

**[00:57:11]**

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

**[00:58:22]**

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

**[00:59:30]**

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

**[01:00:42]**

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

**[01:01:50]**

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

**[01:03:05]**

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

**[01:04:04]**

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

**[01:05:11]**

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

**[01:06:11]**

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

**[01:07:12]**

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

**[01:08:05]**

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

**[01:08:59]**

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

**[01:09:52]**

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

**[01:10:51]**

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

**[01:11:55]**

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

**[01:13:00]**

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

**[01:14:12]**

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

**[01:16:07]**

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

**[01:17:17]**

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

**[01:18:34]**

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

**[01:19:48]**

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

## Нотатки

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