# Заняття 09. Симуляція виставки: від першого контакту до інженерного проєкту

> **6 жовтня 2026 · лекційно-практична симуляція · 1 год 32 хв 22 с.** Джерело: транскрипт L5. Імена клієнтів, компанії, угоди, партнерства, географія бізнесів і частина технічних кейсів у рольовій грі є **вигаданими студентськими сценаріями**, а не повідомленнями про фактичні контракти. Суб'єктивні культурні й ринкові спостереження викладача не є перевіреними закономірностями.

## Місце заняття в курсі: перехід від знання до виконання

Після підготовки візитівок, one-pager і розбору структури proposal студенти відпрацьовують реалістичну професійну ситуацію. Викладач виконує роль потенційного замовника інженерних сервісів (у сценарії — **Otto**, представник компанії автоматизації виробництва), а студенти — представників власних embedded-компаній. **Мета заняття — здобути кваліфікований контакт і погодити follow-up**, а не імітувати негайне підписання великого контракту.

Навчальний маршрут, описаний на початку заняття: **до першої атестації — залучення клієнта**, далі — структура проєкту, команди й архітектура, після цього — реалізація **MVP**. Це організаційний план, сформульований на занятті, а не свідчення про фактичне завершення цих стадій.

## 1. Підготовка виїзної команди як інженерна операція

У сценарії квартальний бізнес-огляд (QBR) визначає ціль: відвідати галузеву виставку в Європі. Команда включає **engagement/delivery представників та інженерів**, здатних говорити про технології й домовлятися про продовження діалогу. Travel-функція планує маршрут, ночівлі та робочий календар, але учасники мають **перевіряти**, чи план залишає час на відпочинок, зустрічі й підготовку.

Конференційні стенди вимагають попередньої логістики: доставка експонатів, монтаж, електроживлення, монітори, презентаційні матеріали, кабелі та резервні варіанти зв'язку. У записі рекомендується **не покладатися лише на перевантажений Wi-Fi** і заздалегідь передбачити дротову мережу, якщо технічне демо критично залежить від підключення. Замість механічного повторення переліку потрібен **чек-лист ризиків для конкретного стенда**.

## 2. KPI зустрічі: лід, а не контракт

На виставці перший результат — **lead**: особа/організація, яка висловила інтерес. Далі потрібна кваліфікація: чи є реальна проблема, компетенція постачальника, спроможність домовитися про зустріч і конкретний наступний крок. **Погоджений follow-up** є кращим результатом навчальної симуляції, ніж велика кількість випадкових візитівок.

Навчальна модель конверсії (не емпірично оцінені коефіцієнти):

**N_follow-up = N_contact × p_relevant × p_meeting**, де **N_contact** — кількість змістовних контактів; **p_relevant** — частка контактів з релевантною потребою; **p_meeting** — частка релевантних контактів, з якими погоджено наступну розмову; **N_follow-up** — очікувана кількість follow-up. Ця схема дозволяє думати про якість воронки, але не замінює CRM-дані.

## 3. Перші 30 секунд: дайте клієнту говорити

Відвідувач підходить до стенда. Невдалий варіант — мовчати або одразу читати загальний рекламний монолог. Кращий підхід — **привітатися, коротко пояснити суть демонстрації, поставити відкрите запитання** про галузь і проблему співрозмовника. Мета — встановити контекст, а не перемогти в суперечці.

У першому сценарії студент представляє послуги виробництва медіаконтенту, тоді як «Otto» очікує industrial production. Це демонструє **семантичну пастку:** слово production може означати виготовлення фізичного виробу або медіапродукцію. Правильне уточнення предметної галузі швидше відкриває доречну розмову.

## 4. Технічна спільність важливіша за гучний бренд

У рольових діалогах студентські компанії позиціюють себе в **автомобільних ECU, програмному забезпеченні, ADAS, embedded safety, UAV, механіці й автоматизації**. «Клієнт» постійно повертається до перевірки: *що ви конкретно робите; яка ваша компетенція; де вона перетинається з моєю проблемою; чи можете ви це показати?*

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

## 5. Vendor, client, partnership — визначити власну роль

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

| Модель зустрічі | Що пропонуємо | На що спрямовані запитання | Результат контакту |
|---|---|---|---|
| Ми — **vendor** | Інженерний сервіс або продукт | Проблема клієнта, критерії успіху, бюджетний контекст | Технічний follow-up / RFI |
| Ми — **buyer** | Потенційне замовлення | Потужності, виробництво, сертифікація, можливість постачання | Vendor qualification |
| Ми — **partner** | Спільне створення продукту | IP, ризики, вклад, ринок, governance | Переговори про модель співпраці |

## 6. Відмовитися від поганої угоди — теж результат

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

Інший персонаж, «Udo», у сценарії представляє структурний підрозділ відомого OEM. Спільна технічна тема і **можливість перевірюваного внутрішнього представлення** дають підстави домовитися про наступну зустріч. Однак реальні імена й контакти інших клієнтів не можна розкривати без належного дозволу.

## 7. Культурний контекст без стереотипів

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

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

## 8. Контакт збережено: що зробити протягом дня

Одразу після розмови записати: особу, компанію, профіль, конкретну проблему, демонстровані компетенції, ризики/заперечення, обіцяні матеріали, час наступного контакту. Залежно від правил організації передати дані **engagement team** у CRM. Важливо відділити «людина взяла візитівку» від «погоджена follow-up зустріч».

Якщо відвідувач знову проходить повз стенд наступного дня, **повторно агресивно продавати** може бути контрпродуктивно. Достатньо привітання: подальша комунікація вже повинна йти узгодженим командним каналом.

## 9. Від презентації компанії до наступного інженерного кроку

Після симуляції кожна команда готує **до десяти змістових слайдів** до follow-up: хто ми; яка наша галузь; які технічні компетенції і докази; які ресурси; де працюємо; як організовуємо cooperation; що можемо доставити; які етапи очікуємо. В ілюстративному зразку викладач показує титул, agenda, офіси, обраних клієнтів, партнерства, capabilities, engagement model, технології та польові випробування. Непідтверджених логотипів і реальних NDA-даних не використовувати.

**Наступна стадія курсу:** follow-up meeting → RFI / course-specific RFC / RFQ → proposal → Jira/GitHub Project → MVP. Саме так академічна симуляція переходить у **планування реального інженерного виконання**.

## 10. Завдання для самостійного виконання

1. Для свого бізнесу визначити мету участі у виставці: vendor, buyer чи partnership.
2. Провести 3-хвилинний діалог із «замовником»; зафіксувати **потребу, обмеження, наступний крок**.
3. Оцінити, чи кваліфікований lead: технічна релевантність, контакт, дозвіл на follow-up.
4. Занести зустріч до CRM/таблиці без конфіденційних клієнтських даних.
5. Створити презентацію до 10 слайдів для follow-up; перевірити всі інженерні факти та права на референси.
6. Підготувати **5 discovery-питань**, які ведуть від бізнес-проблеми до майбутнього вимірюваного системного requirement.

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

- Чим лід відрізняється від підписаного замовлення?
- Чому небезпечно, коли vendor мимоволі переходить у роль buyer?
- У який момент демонстрація компетенції стає змістовнішою за бренд?
- Як захистити клієнтські контакти й уникнути конфлікту інтересів?
- Які артефакти потрібні, щоб перейти із follow-up до архітектури й плану MVP?

## Наступні 1–2 заняття — прогноз за джерелом

Наступне заняття планувалося присвятити **follow-up meeting**, збору RFI/RFC та підготовці proposal; далі — переходу до створення Jira/GitHub Project і реалізації MVP. У транскрипті це оголошений план, а не засвідчена вже проведена робота.