Заняття 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 — визначити власну роль

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

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. У транскрипті це оголошений план, а не засвідчена вже проведена робота.