---
title: "IgorSikotskyKPI_L8_27102026"
source_video: IgorSikotskyKPI_L8_27102026.mp4
source_audio: IgorSikotskyKPI_L8_27102026.mp3
duration: 01:26:07
language: uk
language_probability: 0.873
model: large-v3
device: cuda
transcribed_at: 2026-10-27T16:12:56
segments: 601
editorial_note: "Фрагменти з описом навчального прикладу вилучено автором; місця позначено квадратними дужками."
paragraphs: 69
status: draft   # draft | reviewed | published
tags: [лекція, транскрипт]
---

# IgorSikotskyKPI_L8_27102026

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

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

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

**[00:01:02]**

Скажіть, чи мене чути, чи не чути, ехо, чи далі?

**[00:01:09]**

Чути. Чути ехо, чи мене, чи нас обох?

**[00:01:14]**

В основному вас ехо не чути, просто чути, що ви в якомусь приміщенні такому. Окей. Доброго ранку.

**[00:01:27]**

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

**[00:03:09]**

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

**[00:04:10]**

з якої там, ну, чи все зразом з'їсти, чи по шматках, ну, відповідно, відповіддю на то, як, ну, він не знає, наприклад, того він, власне, каже, чи є вашим клієнтом, того він і шукає у вас якогось рішення. Ну, а ви й знаєте, ви експертна група, у вас є відповідний там компетенцій, штат і так далі, Тобто у вас більше шансів надати йому якийсь інпут, ніж йому угадати його. Так от під це все діло, як частина пропозиції, виявляється модель співпраці. Прямо у пропозиції ви вказуєте йому ту модель співпраці, яка вказує, що, наприклад, ви розумієте, ви хотіли прозбити цю весь тимлайн на якусь фазу. Фаза якогось ресорча, потім фаза proof of concept, потім якийсь MVP, або мінімально корисний продукт, а потім, відповідно, якийсь ряд Delivery Bus, тобто вже повномасштабної функціональності.

**[00:05:25]**

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

**[00:06:37]**

Якщо йдеться про більш такий компактний проєкт до 10 людей в команді, тоді, власне кажучи, один техліт або технічний менеджер, або просто літ, або архітектор, який зможе закрити собою і заодно всі ці питання про ління команди. Тобто тут прямо це все залежить від сетапу команд. Як ви розумієте, вже йдеться як два виміри. У нас є умовно по січасу довжина проекту, фази, якими ми його розбили. Я це асоціював як якийсь research, якась R&D фаза, потім якийсь Proof of Concept, якийсь MVP, і потім, відповідно, вже якийсь Delivery Boost, тобто це все йде явно в часовій вісі. Понятно, що воно вам створює якийсь Value. Після кожної з цих фаз ви можете і маєте йому щось передати, Раді чого він відповідно компенсує вам це гроші.

**[00:07:48]**

Наприклад, якщо казати якийсь ресерч, то степенчим виходом з ресерчу є так звана техніка візібіліті. Тобто, ви досліджуєте взагалі чи можливо все зробити, що він хоче. І ви це дослідження, чи це взагалі можна надосягти, виносите у окрему фазу. І виходом є просто «да, можна», «ні, не можна». І от може бути дуже коротенький коментар, що «да, можна, якщо ми використаємо такий от підхід», або «ні, при будь-яких розкладах не можна». Відкрию вікно, бо я зараз в чаті у цій фарбі. Кілька хвилин, а голова вже чавунна. От, відповідно, якщо так показати, то стадія №1, це здебільшого є ресерч, це перевірка, чи взагалі технічно реалізуємо це, чи ні. Наступна стадія, яку я описав в проєкті, це стадія Proof of Concept, або B.O.C.

**[00:08:59]**

Proof of Concept – вона теж досить типова фаза, я б сказав, вона і так ресурсна фаза, вона швидше притаманна складним проєктам, навіть не технологічним, а високоінноваційним. Так от, proof of concept, вона більш розповсюджена, вона є наявна в технологічних проєктах, тобто відчуєте різницю інноваційний і технологічний. Інноваційний з великим містом математики, науки, пошуку. Технологічний він не такий насичений науковою складовою, але він насичений готовими компонентами, фреймворками, тобто ви будете вбудовувати його на основі сучасних технологій. Так от, в технологічних проєктах оцей POC, він є майже завжди. А у, власне кажучи, інноваційних, є як Research, так і Proof of Concept, і то, і то. Так от, Proof of Concept, фактично, його суть, це, як кажуть, на колінці спаяти, виготовити щось, що покаже, що воно реально працює.

**[00:10:07]**

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

**[00:11:03]**

Після того, як Proof of Concept пройшов успішно, ми рухаємося далі. Зверніть увагу на те, що я кажу двічі вже після того, якщо. Після того, якщо щось... Я кажу це не просто так. Це називається ґейти. Це ґейти по проекту. Відповідно, у вас після research є ґейт. Тобто, ви переходите далі тільки, якщо ґейт спрацював. Якщо оцей research успішний. Якщо неуспішний, або робите hard stop. Тобто, все, відстрілялися, виходимо з проекту. Або, якщо клієнт не хоче, ми переходимо в інший стрім, тобто ми переходимо в інший ресурс, шукаючи далі. Це вже, якщо він готовий заплатити. Другий гейт відбувається після POC. Тобто, якщо ресурс каже, що все окей, ми цей гейт проходимо, йдемо далі в POC. Вибудовуємо оцю, як я вже сказав, умовний оптичний канал комунікації.

**[00:12:07]**

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

**[00:13:15]**

О, оце якраз є MVP. Реалізується вона, ну, до неї підхід досить насправді вже складний, тобто ви маєте вибудувати всю екосистему вашого проєкту, засетапити кор вашої команди. І от екосистема плюс кор плюс ціль фактично реалізує вам MVP. Ми перейдемо ще до цього. MVP дозволяє клієнту почати їздити на виставки, на конференції, і продавати це, шукати потенційного інвестора, шукати споживача, шукати того, з ким можна заключити контракт на якесь партнерство і заучитися його фінансовою або іншою підтримкою. Тобто MVP саме собою не генерує грошей, але воно генерує потенціал, це як потенційна енергія у філіпсі. Далі, після MVP немає вже гейта, це вже йде як послідовність дій. Якщо після Research або R&D у нас є GATE, після POC у нас є GATE, так от після MVP GATE-у вже немає. Це вже просто перша фіча, в якої немає dependency.

**[00:14:26]**

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

**[00:15:48]**

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

**[00:16:39]**

От це так от загалом, якщо ви це описуєте вашому клієнту, то для нього стає загалом це дуже навіть непогано і дуже навіть прозоро. Давайте ми трошки по екселі по цьому. Let's go. Я поширю скрін. І напевно я розпочну все-таки не з екселя, а з DRAW.io. От із DRAW.io попробуємо в ньому. Якщо буде незручно, то перейдемо в ексель. Отже, відповідно, що в нас відразу є? Чисто від візуалу того самого, що вже озвучив. Після того, як клієнт хоче розуміти, які Deliverables він буде отримувати в часі. Давайте йому за це скажемо. Отже, ми йому чітко кажемо, що перша фаза, яку ми будемо для нього робити, це є фаза, яка називається Research and Development, R&D. Які він отримує на виході неї аутками Це технічна досяжність

**[00:17:50]**

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

**[00:18:58]**

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

**[00:19:16]**

Не буду запитувати, чи знаєте ви, що таке стріла часу. І що в нас стріла.

**[00:19:22]**

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

**[00:21:08]**

Так от, на виході із R&D, колеги, чи зрозуміло, що таке конус невизначеності? Не чути? Спрос на питання? Так, чути. Критяк. Що таке конусної вічності? Плюс-мінус ясно?

**[00:21:33]**

Так, плюс-мінус. Критяк. Дякую, супер. Дякую за фідбек. От, відповідно, у нас є outcome з R&D. Це взагалі оцінка технічної досяжності, включи ясно. і зменшення конусу невизначеності. По суті, тут йдеться про що? Виявіть собі, що ви фактично переноситеся отсюди і будуєте цей конус по вашому ж проєкту, але починаючи вже з відсіля. Тобто, ви пройшли якийсь шлях, Знання про проєкт у вас зросло, і тому ви з меншою похибкою оцінюєте то, в що вернеться вам проєкт в кінці кінців. Оце його основний ауткам. Після нього ви можете спокійно переходити до фази 2. Це POC, Proof of Concept, які в нас виходять від ціля аутками. Outcome Перевірка гіпотез Гіпотез Реальними компонентами Рішеннями Рішеннями О, відповідно Основний Outcome

**[00:23:22]**

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

**[00:24:59]**

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

**[00:26:25]**

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

**[00:28:13]**

В який в нас є цілий цикл так званих VP або Working Package робочих пакетів, VP2, VPN, які по суті націлені на те, щоб інкрементувати, збільшувати цінність продукту для клієнта. Перехід, як завжди, завжди йде сюди, відповідно, перехід, як завжди, воно йде отаким ось чином у нас далі по часу, завжди, завжди клієнт є, у нього є змога стопорнути, це його фінансове право, є. І, відповідно, в кінці кінців, остання штука, яка є, це в нас, давайте ми його поставимо тут, це наша задачка N+, це є фіналізація. Фіналізація передбачає передачу артефактів і архівація проєкту. Він може бути продовжений підтримкою, він може бути продовжений якимись новими фічами і так далі, але всі ці речі – це вже є речі майбутніх домовленостей,

**[00:30:39]**

тобто вони не входять у рамки поточного ворплоу. Розкажіть вашому клієнту буквально на першій зустрічі, на першій зустрічі по цьому вашому пропозову, включіть це як частина пропозова, що як ви бачите роботу над його продуктом. Скажіть, що у вас буде R&D, що у вас буде proof of concept, що у вас будуть ці два гейти. Він оціниться, він зрозуміє, чому ви їх додали і зрозуміє, що ви професійно ставитеся до ризиків, ви їх класно отменжуєте. Під цього ви переходите до NDP, потім до інформатації циклу фічей і відповідно в кінці йде фіналізація. Ви відкриті до продовження співпраці з ним, але це продовження, його форм-фактор і так далі є питанням майбутніх проєктів і майбутніх домовленостей. Також дайте про це знати вашому замовнику, що ви готові, ви відкриті, ну давайте будемо йти, як кажуть, крок за кроком і їсти цей борщ ложкою, ложка за ложкою.

**[00:31:39]**

От, це є, відповідно, нормальний way of work. І, відповідно, ми його будемо слідувати. Якщо ви це передаєте вашому клієнту, супер. Далі, давайте ми розберемося з наступною штукою, дуже критичною. Це як же ви будете фактично продавати цьому клієнту сервіс. Ви описали зараз, це не що інше, як таймлайн. Ви можете сказати, що це вісь часу. Давайте ми поставимо цю стрілочку. Оце наш таймлайн, дуже простий і примітивний, в якому він розуміє, як буде йти, що за чим він буде отримувати по приросту, по його функціональності. Давайте накладемо на це тепер якісь дуже грубі часові рамки. Ось ця стрілочка, оця лінія, перепрошую, оця лінія, ось вона. Це наше сьогодення. Ми кажемо, що шановний клієнт, ми зараз стоїмо тут, ти отримуєш від нас результати R&D в інтервал 1 місяць.

**[00:32:56]**

Тобто, дайте йому оцей шматок, оцей шматок, дайте йому дуже точно, ставимо, чик, кажемо, що оце один місяць, майже, один місяць, все, супер, він розуміє, що оце, взагалі, один місяць Потім, дуже уважно забезпечте йому опряму комунікацію Він має розуміти, що є гейти, що гейти міняють будь-які правила Гейти переглянуть все Він повинен це просто прийняти і пробачити Відповідно, якщо гейт спрацює, а ваша задача його попереконати, але не обманувати Переконати спокійно Якщо ви самі цьому впевнені Якщо Gates працює То відповідно ви переходите У наступний інтервал часу Ось де цей інтервал часу Це створення для нього Proof of Concept І дайте йому оцінку Ми ще вернемось З чого я взяв ці оцінки Ми це уважно розвернемо У деталях

**[00:34:06]**

Дайте йому оцінку Що відповідно Proof of Concept Він отримує плюс ще 3 місяці за умови спрацювання гейтів. Окей. Далі. Скажіть йому, що перший результат і першу value із проєкту, першу цінність проєкту, він отримує буквально, це буде якась коротенька фіча, очевидно, ми спеціально такої взяли, наприклад, ще за два тижні. Два тижні. От, 0,5 місяця Окей, тобто покажіть йому, дайте йому зрозуміти, що в 4,5 місяці він вже матиме щось, що продавати Потім, відповідно, дайте йому змогу, можете розписувати все у деталях Можете себе убезпечити І я вам раджу себе убезпечувати Якщо захоче, він потім уточнить і ви йому потім дасте окремий естімейт, окрему оцінку. Дайте йому, за скільки ви наріжете оці всі речі. Наприклад, ще за 7 місяців ви наріжете всі оці фічі.

**[00:35:32]**

Потім дайте йому фіналізацію, що коли він отримає, вже все повністю закінчить з вами всю співпрацю Це корисно розуміти, що ви, як людина в своєму розумі, розумієте, що все, що починається, має свій кінець Все, що почалося, умре Відповідно, що передача цих артефактів по часу займе ще, наприклад, пів місяця І тому, о, все, клієнт розуміє, що ви будете робити, клієнт розуміє, скільки в нього це займе по часу. Тепер наступне, йому треба розуміти, скільки в нього це займе по грошах. І тут критичним для нас є розділити цей наш way of work, цей наш опис нашого процесу на дві еквівалентності. У нас є варіант описати це двома варіантами. Варіант №1 це Fixed Price . Варіант №2 це Time and Material . Тобто FixedPrice, коли ми йому ставимо, як у магазині, скільки буде коштувати відро картоплі.

**[00:37:21]**

Оце то саме, скільки буде коштувати реалізувати оцю штуку.

**[00:37:26]**

Давайте попробуємо початку описати це з точки зору FixedPrice. Отже, FixedPrice, для нього беремо оцю штучку, ставимо і кажемо, що ось цей от кусок, тобто R&D, буде коштувати, ну от, грубо кажучи, 100К, 100 тисяч доларів, R&D. Далі ми кажемо, що цей самий Fixed Price, частина Proof of Concept, буде коштувати іще 150 тисяч. Далі ми кажемо, що цей самий FixedPrice, частина MVP, буде йому коштувати ще 50 тисяч. От, далі, і ми кажемо, що оця частинка, яка розробка всієї функціональності, вона буде йому ще коштувати 400 тисяч євро. Ну і фіналізація, щоб просто бути прозорим з ним, оцей кусок, ми скажемо, що це буде йому коштувати виключно доставка, що ми робимо йому шалену скидку, і там 5 тисяч євро. Все. Ми йому розписали утворення бюджету по моделі Fixed Price.

**[00:39:23]**

Давайте ми це йому тако виділимо. Є. Так. Бек. О. Все. Він розуміє, скільки буде йому коштувати це по цій моделі. Ми ж крута контора. Ми гнучки, що капець. І можемо забезпечити йому і інший варіант надання сервісу, саме «Diamond Material». Зверніть увагу, що «Fixed Price» має чіткі кости, чіткий шокопець.

**[00:39:54]**

Ми буквально підписуємося під тим, що зробимо це за скільки, це за скільки, це за скільки, це за скільки, при умові, що спрацюють оці гейти. Якщо оцей гейт спрацював, то відповідно ми забираємо наші стока і уходимо. Якщо ми йшли далі до цього, то ми заберемо ще 150 і все. Якщо ви два відпрацювали все добре, то ми йдемо далі по проєктах, допоки він спроможний нам платити. Це наш Fixed Price. Далі. Є темен матеріалу. До речі, його дуже цікава різновидність. Я її хочу використати, якщо знайду правильний символ. Він тут на цій клаві. Темен матеріалу з шапочкою. Його суть наступна. Так, так, так, давайте я зроблю таку штуку Скопіюємо, поставимо Поставимо, поставимо сюди Трошки вище, от сюди І тільки трошки підкоректую

**[00:41:10]**

Наприклад, ось тут я кажу не 100 тисяч, а 60 тисяч Тут не 150 тисяч, а 100 тисяч Далі, тут не 50, а наприклад 40, і тут не 400, а 300.

**[00:41:32]**

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

**[00:41:47]**

Так, о, відповідно, ми переводували цю от модель, у нас тепер є той самий Way of Work, Той самий послідовний дій, але розписано по кастах як Fixed Price і Fixed Entitlement Material обмежений зверху. Що це каже? Чого ціна за одне й те саме наскільки суттєво відрізняється? Хто підкаже, чого наскільки суттєво відрізняється ціна? Ідеї? Одне і те саме. Чого ж така велика різниця в ціні? Колеги? О, Дрогобицький, ідея є. Я розмышляю поки. Добре. Якщо хочете, озвучте вслух. Будемо коригуватися. Я не настільки якісно розмышляю. Ха-ха-ха, клас, добре, добре, так, так-так-так, джувай.

**[00:43:30]**

Чесно кажучи, я так само, як і Володимир Дрогобиський, не вдупляю поки що. Окей, а припущення? Припущення відсутні, на жаль.

**[00:43:52]**

Добре, Вацецький? Можливо, за час оплата одна і за матеріал чи щось інше додаткове. Є корінь істини. Є корінь істини тому, що кажете, розкажу. Таймінг нотіров і фіксед прайс мають одну кардинальну різницю між собою. Це то, на якій стороні ризики. Фіксед прайс каже про те, що ризики на стороні виконавця. Ми оце розпланували, ми оце розписали, ми наберемо команду, ми візьмемо менеджмент, ми відповідаємо за всіх наших інженерів, ми відповідаємо також за доставку, за наших вендорів, ми відповідаємо за ті всі заводи, фабрики, за будь-які затримки, це все клієнта не колиши. Коротше кажучи, ми сказали, що ця штука візьме 100к. Він наготував цих 100к, нам відрахував і все. І він чекає якогось там одного один місяць. І якщо, Боже, ми це не зробимо, це нам буде капець. Там такі будуть фінансові штрафи, що ми офігіємо. Оце фіксит прайс. І оця відповідальність коштує 40к. Тобто ми взяли на себе відповідальність і ризики, вона коштує йому 40к.

**[00:45:20]**

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

**[00:46:37]**

Але разом з тим ціна дуже суттєво відрізняється. І тому навіть отут, навіть в тайм-адматірі, понятне, що всі ці департаменти, вони вже забезпечені за рахунок маржинальності між тим, скільки отримує кінцевий інженер і скільки отримує компанія. Тут то воно вже закладено, тому що до прикладу реальна інженерна вартість, тобто скільки реально потребуватиме, як заплатити інженерам, це буде десь, напевно, 10-30к, десь отак. Ми тут хочемо 60к, а тут ми хочемо за то саме 100к. Тобто отут у варіанті fixed price це 70 тисяч, це навару, який існує для того, щоб взяти і покрити ризики, які понесе компанія, якщо раптом піде щось не так. От, тепер, скажіть, чи цей кусок, понятно, він досить важливий? Так, це я зрозумів.

**[00:47:45]**

Круто, круто, круто, дуже дякую. Тепер, таймінг матеріал. Дивіться, в чому прикол. Таймінг матеріал, він існує в декількох гіпостасіях. Таймінг матеріал з шапочкою і просто. Таймінг матеріал з шапочкою. Він каже про верхню межу, яку по наших оцінках ми можемо захотіти від клієнта. Тобто ми оцінюємо, що оця фаза, яка там у нас R&D, буде коштувати клієнту 60К. Ми не ручаємось, ми оцінюємо. Ми прикинули, що наші інженери будуть тут працювати один місяць Ми кажемо, що швидше за все в кінці цього місяця ми захочемо від вас 60К Або не більше Може бути так, що ми зробимо все в 10К А може в 60 Але може таки бути, що і 90 Ми не гарантуємо ризики на вашій стороні І ми також не гарантуємо, що ми взагалі це зробимо. Оце таймед матеріал. Чи є тут якісь ризики? Є, але вони, скажімо так, вони не прямі, вони опосередковані. Які саме ризики? Та дуже прості. Які? Хто скаже, які ризики є в цьому таймед матеріал?

**[00:49:17]**

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

**[00:50:26]**

Аааа, дивіться, Володимир, якщо ми кажемо про Time and Material модель, якщо ціна проекту зростає, то до певної межі нам це супер, тому що ми отримуємо більше межі. Наш інженер отримує, грубо кажучи, одну копійку, а ми три.

**[00:50:53]**

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

**[00:51:11]**

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

**[00:52:23]**

Прикиньте, у вас може бути клієнт загальною вартістю 100 тисяч євро, а ви його не втащили. І з вами, наприклад, у самій SpaceX ніколи більше, ні за яких умов, не захоче працювати. Він нас поставив у чорний список І ви потенційно З ними не заробили Значно більше грошей Тому що ваша репутація Вона більше Вона втрачена Оце ризик Time and material Чи це ризик fixed price? Так Грубо кажучи, якщо ми Влізли з цими самими клієнтами Fixed price Завалились тут То ми понесли По-перше, ми недозаробили грошей. Це перший удар. Ми їх недозаробили. Ми планували їх отримати і не отримали. По-друге, ми понесли репутаційну втрату, бо цей клієнт, швидше за все, з нами більше не захоче рухатися. А по-третє, ми заплатили штраф. Тобто, в договорі, здебільшого, там декількократно більший штраф. Тобто, якщо ми в них мали отримати 100К, то штраф порядка 400К за цю фазу.

**[00:53:38]**

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

**[00:54:27]**

Подекуди бувають комбінації. які саме комбінації дивіться уважно, яку магію роблю забираю з відсіля цього пацана забираю з відсіля цього пацана цього видаляю геть цього, поки він нам не цікавий от наприклад, ми дивимося що R&D в нас в кінці закінчується гейтом круто ми беремо на R&D і ставимо fixed price що тут, що тут ну, більше як От тут ми кажемо, що ми будемо йти в R&D у моделі Fixed Price. Тобто ми обираємо оцю от модель. Далі ми дивимося POC. POC – стрьомна історія сама по собі. Якби в кінці не було гейта. Гейт, ну чого він стрьомний? ПІОСІ, ну от уявіть собі, що ви робите, робите, робите, а воно геть візьме і не запуститься. Це proof of concept, це перевірка гіпотез, так? І прикиньте, от, ну, сама її назва каже про те, що от воно може не стрельнути.

**[00:55:37]**

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

**[00:56:47]**

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

**[00:58:03]**

Давайте уточню ще раз. Вернемо це на базу. Це вернемо на базу.

**[00:58:13]**

З fixed price все понятно. Ми багато заробимо, якщо все буде йти правильно. Time and Material з шапочкою каже про те, що ми попадаємо в цю оціну. Ми можемо дати косяка. Який цей косяк може бути? Отут, тобто дати штангу. Я вам раджу робити так, плюс-мінус, наприклад, я завжди ставлю, і це моя особиста практика, 30%. Тобто, ви кажете, що по наших естімейтах ми попадаємо в 60к, але так як ринок нестабільний, все міняється, я хочу закласти 30% в похибки. І тому ви кажете, таймінг матеріал з оцінкою в 30%. От, таймінг матеріал Каже, із шапочкою Каже, що ми даємо естімейт Ми можемо На нього не попасти, але ми точно Попадемо в цих 30% Ми точно попадемо в цих 30% Оце Красивий таймінг матеріал з верхньою Межою Так от, таймінг матеріал без цієї

**[00:59:29]**

Межі Він дуже Подібний, давайте я зроблю так, поставити це, поки видавимо, це почистимо, от, відповідно, таймен матеріал без верхній межі, це ті самі осамщини, оцінки, які ми дали в таймен матеріал з межою, ну без допуска в 30%. І ми тут не несемо зовсім ніякої відповідальності. Ми прикинули, що буде 60К у цій фазі, ну і супер. Ми не попали, ну вибачте, ми не попали. У темі матеріалу з межою 38%, ми оцінили, що буде 60К, ми, знаючи поведінку ринку, заклали за обіжник ринку 30% його дрейфу, і тоді ми репутаційно вже прямо сильно залежимо, що ми повинні попасти в цю от суму. Якось так. Чи є по цьому питання зараз?

**[01:00:53]**

Немає. Добре, тоді пропоную 10-хвилинну перерву. Ви питали. Окей?

**[01:01:00]**

Відпишу тут нам 0, 9, 40, 11, 45 і до збору.

**[01:12:01]**

Всі повернулися. Чи хтось ще? Ні. Попробуємо щось на кафедрі. Добре, поїхали далі. Відповідно, у нас є оці чудові накидки моделі. Надання сервісу ми описали, що є стадії, R&D, POC, MVP. І потім, відповідно, WP як Working Package 1, 2, 3, N і т.д. І в кінці фіналізація. Це дуже груба накидка, але вона має велику цінність для переговорів з клієнтом, бо йому понятно, як ми будемо рухатись. Далі ми також визначили, що ми рухаємося в часі по цьому проєкту. І також ми прикинули наразі, ми просто буквально сказали, ну нехай буде один місяць, як фаза R&D. Нехай будуть 3 місяці фаза POC, фаза MVP 05 і так далі. Ми маємо це дуже детально розібрати і це буде зроблено пізніше. Ми також пройшлися по цих трьох моделях фінансування.

**[01:13:51]**

Це Fixed Price, Timing Material з шапочкою, Timing Material просто. І оце хитрий варіант, коли ми робимо різні фази по різних моделях, наприклад, R&D за Fixed Price, POC за Fixed Price, MVP за Timed Material шапочкою, всі інші за Timed Material шапочкою і в кінці фіналізація за Fixed Price. От, виникає питання, а чи можемо ми, наприклад, от якщо клієнт дуже наполягає, що хоче фіксит прайс кругом, от він хоче і все У персі ми розуміємо, що ми втратимо цього клієнта, якщо ми зараз не проявимо гнучкість Нам треба подумати, як ми можемо проявити цю гнучкість, як ми можемо реалізувати таку собі збалансовану модель Ну, по-перше, рівень балансування – це те, що я демонструю, що ми фактично підвлаштовуємо fixed pricing, time and material у тих точках, де це можливо в таймлайні.

**[01:15:01]**

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

**[01:15:49]**

Добре. Тоді, будь ласка, зачекайте, я закінчу свою акцію потім. Дякую. Відповідно, Відповідно, у нас є якась ціль. Ціль цього матеріалу наступна. Він хоче реалізувати дві сторони комунікаційного тракту між [пристроями A і B]. [Фрагмент з описом навчального прикладу вилучено автором.]

**[01:17:47]**

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

**[01:19:00]**

Які в нас тут є однозначно ділянки? Що в нас тут є виділено? Є виділена роль №1 – це хардвер, це електроніка. Нам треба зробити, щоб це почало між собою працювати. Є №2 – це механіка, тобто це електроніка, яка є тут, є тут, [на обох пристроях]. Вона, ну, повинна бути запакована Якісь корпуси От виготовлення корпусних деталей Це є, відповідно, це є задача для механіка Дальше У нас є фірмвєр І там, і там якийсь мікроконтролер Вони одніться по якомусь протоколу Треба, щоб був фірмвєр Дальше, нам треба якийсь Однозначно архітект Який, причому Сістем архітект Бо тут є хардвер, механіка, софтвер Сістем архітект який пропише, як це все виглядає, як воно між собою взаємодіє, і так далі. Потім, це ще ж не все, у нас має бути, відповідно, роль якогось прокюрмент-менеджера,

**[01:20:17]**

тобто людини, яка буде купляти це обладнання, доставляти його до нас, взаємодіяти з поштовими сервісами, і так далі, тому подібне. Тобто тут є закупка, це пай, дальше щіп, щіпмент, сторінг, тобто збереження його десь у нас у складах, оці всі речі робить прокюрмент. Далі, у нас є ще, оце дивіться, оці всі речі, от хардвер, механіка, фірмвейер, архітект, оце все, це інженіринг, це інженіринг, оце рекюрмент, це саплай, вони забезпечують підтримку, вони купують компоненти, роблять, щоб інженерам було що працювати. Окрім того, ще є мануфекторинг, який саме hardware manufacturing, mechanical manufacturing, assembly, збірка. І оці три категорії є мануфекторинг або виробництво. До чого я це все розписую так довго і нудно? Зараз я виключу цю малювалку. До чого я розписую? Що ми можемо в рамках оцієї MVP фази, яка ось тут, в рамках MVP фази, яка в нас, вона присутня аж отут, сказати, добре, чувак, раз ти так дуже хочеш Fixed Price, то ми можемо піти тобі на зустріч і весь інженеринг, весь інженеринг,

**[01:22:07]**

Весь інженеринг реалізувати на fixed price. Що мається на увазі? Що ми як компанія будемо нести відповідальність за те, що ціна і таймлайн по інженерній частині буде рівно така, як ми зараз з тобою домовимося. Вона не перейде вище. Якщо вона перейде вище, то це будуть наші проблеми і ми платитимемо ніби свого карману. Тобто оцей весь шмат, оцей весь шмат, не можу запустити свою отмалювалку, оцей весь шмат, він буде fixed price. Це буде fixed price. А оцей шмат, supply, manufacturing, оцей, це буде time and material. Чому так? Чому ми на це не полягаємо? Тому що ми не та компанія, яка робить виробництво. Ми робимо розробку і ми також надаємо контроль виробництва. Але саме виробництво роблять інші компанії і заводи. Хардвер роблять китайські компанії, ми просто їм замовляємо, їх контролюємо.

**[01:23:28]**

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

**[01:24:39]**

Ми покрили ці моделі переговорів з клієнтом по Fixed Price, Fixed Price з верхньою межею, просто Fixed Price, гнучки динамічні моделі, коли кожна фаза приймає притаманну модель. Це ми можемо на це піти, ми це обговорили. Ми також обговорили модель, коли, наприклад, інженерна робота, вона залишається fixed price, а виробництво стає time and material, тобто така собі гнучкість по реалізації. Наступного разу, що нам потрібно буде зробити? Залізти в ці прямокутнички в глибину І подивитися, з чого я поставив, що тривалість якоїсь фази Йде 1 місяць, 3 місяці, 0,5 місяців, 7 місяців З чого я припускаю, що перша, друга фаза може бути фіксит прайс А третя, четверта – ні Оці речі нам треба уважно роздивитися Ми будемо це робити завтра

**[01:25:44]**

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

## Нотатки

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