Заняття 11. Переговори після першого контакту: discovery, партнерство й перехід до проєкту

14 жовтня 2026 · практичне заняття № 4 · 1 год 38 хв 33 с. Матеріал підготовлено за автоматичним транскриптом IgorSikorskyKPI_P4_14102026.mp4.md. Це відредагований навчальний конспект, а не дослівна стенограма. Компанії, посадові особи, результати та переговори у двох сценаріях — рольова симуляція. Заявлені учасниками комерційні показники й технічні можливості не перевірені. Деталі умовної оборонної розробки та повний сирий транскрипт не включено до відкритої публікації.

Місце заняття в курсі: практикуємо conversion, а не красивий виступ

У занятті 10 студенти розбирали післявиставковий контакт, follow-up та підготовку першої змістовної зустрічі. Заняття 11, яке викладач назвав одинадцятим у хронології та четвертим практичним за форматом, стало продовженням цієї вправи. Головна мета — провести потенційного замовника від знайомства до визначеної потреби й погодженого наступного кроку, а не просто показати корпоративні слайди.

На початку залишалися відкритими окремі студентські артефакти: landing page, презентації та інші завдання попередньої теми. Їхній розгляд і виправлення включено в практику. Основним методом стала керована рольова гра з зупинками, корекцією помилок і повторними спробами. Вихід — не підписаний контракт, а готовність до RFI, планування та пропозиції.

1. Follow-up: від письмової домовленості до календарного запрошення

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

Викладач звернув увагу на зайву бюрократію: після згоди не обов’язково писати окреме «пізніше надішлемо посилання». Доречніше одразу створити календарний захід, додати учасника, часовий пояс, тему і посилання. Запрошення має відповідати погодженій меті. Календарний інвайт — операційне завершення домовленості, а не заміна самої домовленості.

2. Хто йде на зустріч і чому їхні інтереси різні

У першій симуляції команда обрала чотири ролі: Engagement Manager, Partnership Manager, Delivery Manager та Engineering/Technical Lead. Кожна потрібна для різних питань, але надлишкова кількість людей без пояснення ролей може збентежити співрозмовника.

У вправі окремо зіставляються продаж інженерного сервісу та спільна продуктова розробка. Це різні бізнес-моделі; їхні цілі можуть конкурувати. Engagement прагне швидко сформувати оплачувану роботу, Partnership оцінює довшу спільну перспективу, Delivery контролює здатність виконувати обіцянки. Такий конфлікт інтересів не треба приховувати всередині команди — потрібно погодити позицію до зустрічі.

3. Кругове знайомство — частина довіри, а не формальність

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

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

4. Agenda захищає мету зустрічі

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

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

5. Чому стандартна корпоративна презентація не працює

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

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

6. Презентація повинна бути двостороннім інструментом discovery

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

Якщо на слайді показані апаратна, програмна та інфраструктурна компетенції, можна запитати, котрий напрям найближчий клієнтові. Якщо відповідь — software, наступне уточнення стосується рівня: firmware, HAL, middleware, architecture або application. Лише після цього варто уточнювати предметну область. Це звуження простору пошуку, а не спроба вгадати потребу заздалегідь.

7. Від широкого інтересу до конкретного запиту

У першому сценарії рольовий клієнт поступово уточнив інтерес: software engineering → application level → автомобільні системи паркування → складність сприйняття перешкод. Це приклад діалогової кваліфікації, а не опис реального замовлення або перевірена технічна вимога.

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

8. Engagement керує ритмом, експерти — змістом

Engagement Manager у практиці порівнюється з диригентом: він веде порядок зустрічі, надає слово фахівцям і спостерігає за реакцією клієнта. Technical Lead відповідає за глибину технічної відповіді, Partnership — за партнерську модель, Delivery — за реалістичність виконання. Одна людина не повинна за всіх говорити про все.

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

9. Зворотний зв’язок отримують питаннями, а не читанням міміки

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

Тому після кожного змістового блоку доречно запитати: «Що з цього найрелевантніше?», «Яка частина задачі сьогодні болить найбільше?», «Яке обмеження є критичним?». Відповіді фіксуються в meeting notes, а припущення позначаються саме як припущення.

10. Правильний вихід першої симуляції: RFI та наступний discovery

У фіналі першого сценарію співрозмовник погоджується описати очікування до програмного компонента і розглянути наступну технічну дискусію. У виступі використано позначення RFI і RFC. RFI зазвичай означає Request for Information; значення RFC залежить від процесу (наприклад, Request for Change), тому в реальній роботі назву та формат документа необхідно явно погодити. Не слід автоматично вважати RFC універсальною «формою технічного запиту».

Замість продажу наосліп команда може запропонувати: отримати короткий опис проблеми, перевірити здійсненність, підготувати початковий варіант scope та провести наступну зустріч. Це ще не контракт, але вже перевірюваний наступний крок із відповідальними та результатом.

11. Вхід Delivery: від ідеї до плану та пропозиції

Коли клієнт просить описати фази проєкту, Delivery Manager збирає потрібні ролі — інженерів з embedded software, hardware, QA, керівника технічного напряму та інших залежно від задачі. Результатом має стати не обіцянка «ми це зробимо», а чернетка здійсненного плану.

У занятті прямо названі артефакти: склад команди, декомпозиція робіт, Gantt chart, фази, deliverables, ризики та кошторис. До них варто додати явні припущення, залежності й критерії приймання. Моделі Fixed Price і Time & Materials мають різні вимоги до визначеності scope, управління змінами й ризиків; комерційну модель слід обирати за характером невизначеності, а не за звичкою.

12. Друга симуляція: коли сильний продукт не збігається з core business

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

Головна проблема виявилася пізніше: продуктова історія майже не перетиналася з основним бізнесом рольового клієнта, пов’язаним із промисловою автоматизацією. Його фраза про core business була підставою не продовжувати рекламний монолог, а уточнити, чи є інші напрями діяльності, де може виникнути співпраця. Ситуація навчальна; твердження про фактичні характеристики демонстраційного виробу не вважаються підтвердженими.

13. Суміжний бізнес як точка входу — без вигаданого fit

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

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

14. Партнерство, підряд і інтелектуальна власність

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

Практичне розмежування: background IP — технології та результати, що існували до співпраці; foreground IP — результати, створені в межах нового проєкту. У договорі потрібно визначити права власності, ліцензування, право повторного використання, межі розкриття та обов’язки за NDA. Для регульованих і оборонних сфер окремо перевіряють експортні, договірні та правові обмеження. З навчального діалогу не випливає універсальна юридична заборона певної моделі партнерства.

15. Переговори треба завершувати артефактами

Для обох симуляцій успішний результат не вимірюється красномовством або кількістю слайдів. Потрібні зафіксовані problem statement, зацікавлена сторона, відомі вимоги, невідомі припущення, відповідальні, термін наступної комунікації та формат пропозиції. Це дозволяє передати discovery у delivery без втрати контексту.

Критично розрізняти досягнуті та лише проговорені результати: домовленість про можливий наступний дзвінок — не виграний тендер, студентський Gantt chart — не погоджений baseline, умовний продукт — не доведена технологічна спроможність компанії.

16. Практичні артефакти для студентської команди

Після вправи команда має підготувати матеріали, які можна перевірити та обговорити на наступному занятті:

• Meeting brief: мета, ролі, agenda, початкові питання, бажаний вихід зустрічі.
• Account research: короткі публічні факти про компанію, окремо — гіпотези про її потреби.
• Discovery log: питання й відповіді клієнта, пріоритети, ризики, нез’ясовані питання та джерело тверджень.
• Tailored deck: стислий вступ, релевантна компетенція, один-два кейси, можливі моделі співпраці, чіткий next step.
• Mini-proposal: проблема, межі, припущення, очікувані результати, фази, команда, ризики й критерії приймання.
• Delivery draft: початкова Work Breakdown Structure, календарні залежності, Gantt chart та грубий кошторис.

Всі ці пункти — завдання і критерії навчальної перевірки, а не твердження, що вони вже виконані студентами на момент запису.

17. Критерії оцінювання практики

Вдале виконання означає, що команда продемонструвала п’ять якостей: релевантність презентації конкретному співрозмовнику; дисципліну представлення й передачі слова; здатність ставити відкриті й уточнювальні питання; коректне розмежування сервісу, продукту та партнерства; оформлення домовленості у перевірюваний артефакт.

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

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

• Чим погоджена зустріч відрізняється від просто надісланого календарного інвайту?
• Чому Engagement і Partnership можуть пропонувати різні бізнес-моделі в одному й тому самому сценарії?
• Як пояснити ролі учасників без надмірних титулів і довгих представлень?
• Яке питання допомагає перейти від загального інтересу до рівня firmware, HAL, middleware чи application?
• Чому реакція на слайд є лише сигналом, а не доказом потреби?
• Які конкретні дані треба записати, перш ніж пропонувати інженерне рішення?
• У який момент варто передати слово Technical Lead, а в який — Delivery Manager?
• Які частини proposal потрібно підготувати після RFI, ще до затвердження контракту?
• У чому відмінність background IP від foreground IP?
• Як не сплутати умовний студентський сценарій із перевіреним комерційним кейсом?

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

Наприкінці заняття викладач анонсував на наступний тиждень нову симуляцію з RFI та RFC: він тимчасово виконуватиме роль Delivery Manager, студенти отримають ролі в робочій команді, сформують фази, Gantt chart, ризики, оцінку вартості та короткий proposal для рольового клієнта. Це оголошений план, а не вже проведене заняття чи готові результати. У подальшому мають з’явитися Jira/backlog та власне інженерна реалізація — після погодження умов.