Заняття 13. Way of work для замовника: фази, gates, конус невизначеності та моделі ціноутворення

27 жовтня 2026 · лекція № 8 · 1 год 26 хв 07 с. Матеріал підготовлено за автоматичним транскриптом IgorSikotskyKPI_L8_27102026.mp4 і схемою draw.io, яку викладач малював під час заняття. Це відредагований навчальний конспект, а не дослівна стенограма: очевидні помилки розпізнавання виправлено, терміни уніфіковано з попередніми заняттями. Усі суми й тривалості — навчальна ілюстрація для порівняння моделей, а не ринкові ставки. Редакторські уточнення позначено окремо.

Місце заняття в курсі: лід став клієнтом — що далі

Після першого follow-up одразу після конференції та другої, експертної зустрічі (заняття 12) лід погоджується працювати: «я бачу, що ви розумієте нашу проблему, давайте спробуємо». Часто на цьому етапі замовник трохи розгублений: він не знає, з чого почати — «з’їсти все одразу чи по шматках». Саме тому він і шукає підрядника: у вас є експертиза, штат і досвід, тож шансів дати правильний вхід у вас більше, ніж у нього — вгадати.

Тому частиною proposal стає модель співпраці: як ви проведете замовника через проєкт від першого до останнього дня, що він отримуватиме і скільки це коштуватиме. Заняття розбирає цю модель у двох вимірах — час (фази) і гроші (моделі ціноутворення).

1. Контактна особа з боку компанії

Замовника однозначно цікавитиме, з ким він говоритиме далі. Доречно вже в пропозиції назвати контакт:

2. Фази проєкту та їхні результати

Викладач розбив весь таймлайн на типові фази. Для кожної фази замовнику треба чітко описати тригер початку і outcome — що саме він забере з собою по завершенні.

R&D: чи це взагалі можливо

Стандартний вихід R&D — технічна досяжність (technical feasibility): чи можна реалізувати задум за поточного стану науки й техніки. Відповідь може бути дуже короткою: «так, можна» або «ні, за будь-яких розкладів не можна». Другий результат — звуження конуса невизначеності (див. розділ 4).

PoC: «спаяти на колінці»

Викладач розрізнив два типи проєктів:

• інноваційні — з великою часткою математики, науки й пошуку; у них зазвичай є і R&D, і PoC;
• технологічні — наукова складова менша, але проєкт насичений готовими компонентами й фреймворками; у них PoC є майже завжди.

Суть PoC — не лише перевірити, що щось могло б працювати (як у ресерчі), а побудувати те, що реально запрацювало. Приклад: треба перевірити, що два пристрої можуть обмінюватися даними через оптичний канал. Будують дві примітивні макетки, ставлять на них ті ключові компоненти, які планують використати у фінальному виробі, пишуть простий комунікаційний протокол і дивляться: працює чи ні. У PoC немає фіч — перевіряється лише функціональність.

MVP: перша фіча з цінністю

MVP (Minimum Viable Product; у курсі — «мінімально корисний продукт») — це вже продукт із користю, тобто з фічами. Першою реалізують фічу, яка:

1. має мінімальну кількість залежностей від інших фіч, тобто може існувати сама по собі;
2. має мінімально достатню цінність для клієнта, тобто вже починає відбивати інвестицію.

Підхід до MVP складніший, ніж здається: треба вибудувати всю екосистему проєкту й засетапити ядро команди. Формула викладача: екосистема + ядро команди + ціль = MVP. Саме по собі MVP грошей не генерує, але генерує потенціал — як потенційна енергія у фізиці: з ним замовник їздить на виставки й конференції, шукає інвесторів, споживачів і партнерів.

Робочі пакети та фіналізація

Після MVP йде цикл робочих пакетів WP 1, WP 2 … WP n — фічі нарізають і реалізують одну за одною, нарощуючи цінність продукту. Остання фаза — фіналізація: передача артефактів і архівація проєкту. Підтримка, нові фічі чи інші продовження — це предмет майбутніх домовленостей, вони не входять у поточний workflow. Варто прямо сказати замовнику, що ви відкриті до продовження співпраці, але рухатися пропонуєте крок за кроком — «їсти борщ ложка за ложкою».

Що замовник отримує в кінці

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

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

3. Gates: умови переходу між фазами

Після R&D і після PoC стоять gates (G1, G2). Gate — це умова переходу, у якої є три валідні результати:

1. Пройшли — рухаємося до наступної фази.
2. Не пройшли, шукаємо далі — новий раунд ресерчу або PoC на інших компонентах, якщо замовник готовий інвестувати час і гроші. Результат PoC може виявитися настільки «крамольним», що відкине проєкт аж на початок і змусить переоцінити весь ресерч.
3. Не пройшли, зупиняємося — hard stop: виходимо з проєкту.

Після MVP gates уже немає: далі йде послідовність фіч. Проте замовник може зупинитися після будь-якої фази — це його гроші і його фінансове право.

Пояснений таким чином workflow — R&D, PoC, два gates, MVP, цикл фіч і фіналізація — для замовника перестає бути «темним лісом». Він бачить, що ви професійно ставитеся до ризиків і керуєте ними. Тому цю схему варто показати вже на першій зустрічі щодо proposal.

4. Конус невизначеності

Уявіть, що ви стоїте на осі часу й дивитеся в майбутнє. На горизонті одного місяця ви досить чітко бачите, як іде проєкт і які будуть витрати — діапазон невизначеності малий. На горизонті чотирьох місяців він уже значно ширший: ви робите більше припущень (assumptions). Що далі в часі, то менша точність оцінки — і за термінами, і за грошима.

R&D дає змогу «перенести» вершину конуса вперед: ви пройшли частину шляху, знання про проєкт зросли, і тепер будуєте конус уже з нової точки — з меншою похибкою щодо того, у що проєкт обійдеться в кінці.

Редакторське уточнення. Поняття сходить до праць Баррі Боема (1981); назву «конус невизначеності» популяризував Стів Макконнелл. У класичному варіанті на стадії початкової концепції оцінка може відхилятися приблизно від 0,25× до 4× від фактичного значення, а конус звужується лише тоді, коли команда ухвалює рішення, що знімають невизначеність. Звуження не відбувається «саме собою» з плином часу — саме тому R&D і PoC такі цінні.

5. Грубий таймлайн для замовника

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

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

6. Ціна: Fixed Price, Time & Material і T&M «з шапочкою»

Замовник уже розуміє, що і коли отримає. Тепер йому треба розуміти, скільки це коштуватиме. Той самий way of work описують кількома моделями.

Суми ілюстративні; на занятті викладач називав їх то в доларах, то в євро. Фіналізацію подано майже за собівартістю доставки, як «шалену знижку» для прозорості.

Чому ціна за одне й те саме так відрізняється

Ключова різниця між моделями — на чиєму боці ризики.

• Fixed Price: ризики на боці виконавця. Ми розпланували, наберемо команду, відповідаємо за інженерів, менеджмент, доставку, вендорів, заводи й будь-які затримки — замовника це не обходить. Він відраховує 100K і чекає місяць. Якщо не встигли — штрафи. Ця відповідальність і коштує різницю: у прикладі R&D це 40K (100K проти 60K).
• Time & Material: замовник платить за фактично витрачений час і матеріали; ризик недооцінки — на ньому.

Викладач відкрив «таємницю» сервісного бізнесу: інженер отримує однакову зарплату незалежно від моделі контракту — різниться лише маржа компанії. Маржа — це різниця між тим, що компанія платить інженеру, і тим, що бере з клієнта за його час. З неї утримуються офіси, адміністрація, юристи, фінансовий відділ, сервісні підрозділи — десятки, сотні й тисячі людей, які супроводжують проєкти. У прикладі реальна інженерна вартість R&D — приблизно 10–30K; у T&M компанія просить 60K, у FP — 100K, і частина цієї різниці існує саме для того, щоб покрити ризики, якщо щось піде не так.

Які ризики лишаються у виконавця за T&M

На занятті цю тему обговорили зі студентами:

Репутаційний ризик найболючіший у роботі з великими замовниками (у прикладах лекції — Volkswagen Group, SpaceX): проваливши проєкт на 100 тисяч, можна потрапити в «чорний список» і назавжди втратити значно більші гроші.

За Fixed Price у разі провалу компанія отримує всі три удари одночасно:

1. недоотриманий прибуток;
2. репутаційну втрату;
3. штраф за договором — зазвичай у кілька разів більший за вартість фази (ілюстрація викладача: близько 400K штрафу за фазу вартістю 100K).

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

Два різновиди T&M

Логіка T&M^: «за нашими оцінками фаза R&D коштуватиме 60K; може вийти 10K, може 60K, але ринок нестабільний, тому ми закладаємо 30 % похибки й точно вкладемося в цей коридор».

Редакторське уточнення. У міжнародній практиці таку модель називають capped T&M або T&M with a not-to-exceed (NTE) limit. Конкретний відсоток допуску — домовленість сторін; 30 % — особиста практика викладача.

7. Комбінована модель за фазами

Моделі не обов’язково застосовувати до всього проєкту одразу. Викладач запропонував підлаштовувати модель під ризик кожної фази:

Виходить «хитра» модель: FP там, де вас захищають gates; T&M^ там, де багато невизначеності; FP на виході, де все під вашим контролем.

8. Коли замовник наполягає на Fixed Price усюди

Буває, що замовник хоче FP на все, і без гнучкості ви його втратите. Другий рівень балансування — розкласти фазу за функціями. Викладач узяв фазу MVP і подивився, що в неї «під капотом».

Ціль MVP у навчальному прикладі: реалізувати дві сторони комунікаційного тракту між двома пристроями — умовно A і B. Кожен із них має власну електроніку, корпус і прошивку, а дані між ними передаються радіоканалом. У першому MVP треба налагодити зв’язок між цими двома пристроями.

Пояснення замовнику звучить так: «Раз ти дуже хочеш Fixed Price, ми йдемо назустріч: увесь інженеринг — fixed price. Ціна й таймлайн інженерної частини будуть рівно такими, як ми домовимося; якщо вийдемо за межі — платимо з власної кишені. А supply і manufacturing — time and material». Причина проста: компанія не виробляє, вона розробляє й надає контроль виробництва. Електроніку робить, наприклад, китайський підрядник, механіку — заводи в Білій Церкві, Харкові, Луцьку, збірку — ще інший завод. Компанія передає креслення, а її інженер здійснює технічний нагляд. Ці підрядники можуть змінити ціну, і нести за них відповідальність компанія не хоче.

Практичні висновки

• Модель співпраці — обов’язкова частина proposal: замовник має бачити фази, їхні тригери й outcomes.
• R&D відповідає на питання «чи можливо», PoC — «чи працює на реальних компонентах», MVP — «чи є перша цінність».
• Gates після R&D і PoC мають три валідні результати: далі, повторити пошук, стоп.
• Замовник може зупинитися після будь-якої фази; продовження після фіналізації — предмет нових домовленостей.
• Різниця між FP і T&M — у розподілі ризиків; ціна FP включає вартість цих ризиків.
• За T&M у виконавця лишаються недоотриманий прибуток і репутація; за FP до них додається штраф.
• T&M^ з допуском (наприклад, ±30 %) — компроміс між гнучкістю та відповідальністю.
• Модель можна змішувати за фазами (FP–FP–T&M^–T&M^–FP) і за функціями (інженеринг FP, постачання й виробництво T&M).

Питання для самоперевірки

• Чому замовнику потрібна модель співпраці вже в proposal?
• Хто має бути контактною особою в компактному і в розгалуженому проєкті?
• Чим outcome фази R&D відрізняється від outcome PoC?
• Чим інноваційний проєкт відрізняється від технологічного з погляду фаз R&D і PoC?
• Які дві умови має задовольняти перша фіча MVP?
• Які три результати можливі на gate?
• Що таке конус невизначеності і як R&D впливає на нього?
• Чому Fixed Price дорожчий за Time & Material за той самий обсяг робіт?
• Які ризики лишаються у виконавця за моделі T&M?
• Чим T&M відрізняється від T&M з верхньою межею?
• Чому PoC можна брати у Fixed Price, хоча гіпотеза може не підтвердитися?
• Як розкласти фазу на частини, щоб піти назустріч замовнику, який хоче FP усюди?

Що заплановано далі

Викладач анонсував: «залізти в прямокутнички» — розібрати, звідки беруться тривалості фаз (1, 3, 0,5, 7 місяців) і чому перші дві фази можуть бути Fixed Price, а третя й четверта — ні. Частину цього розібрано вже на наступному занятті 28 жовтня. Це оголошений план.

Матеріали заняття

• Схема draw.io з заняття: завантажити .drawio (відкривається в diagrams.net / draw.io).

Перевірені посилання

• S. McConnell. The Cone of Uncertainty (Construx, white paper): https://www.construx.com/wp-content/uploads/2019/02/CxWhitePaper_ConeOfUncertainty.pdf