Заняття 07. Підготовка інженерної компанії до професійної виставки

29 вересня 2026 · лекційно-практичне заняття · 1 год 24 хв 48 с. Джерело: повний автоматичний транскрипт L4. Матеріал опрацьовано редакційно; наведені реальні приклади, оцінки та спостереження викладача слід відрізняти від універсальних норм і статистично доведених закономірностей.

Місце заняття в логіці курсу

Попередні теми провели нас від сервісної та продуктової моделей бізнесу через організацію команди, пошук клієнтів, RFI/RFQ/RFC, proposal, контракт, discovery та першу архітектуру. Нині потрібно перевірити, чи студенти можуть відтворити цей процес як власна інженерна компанія, перш ніж перейти до наймання, Jira/GitHub Projects і спринтів. Звідси навчальна послідовність: позиціювання → артефакти → зустріч на виставці → follow-up → запит замовника → пропозиція → інженерне виконання.

1. Команда стає компанією, коли вміє себе представити

Кожна з чотирьох студентських груп моделює самостійну компанію в одному з напрямів embedded engineering. Команда мусить визначити назву, спеціалізацію та розподіл відповідальності: засновник/керівництво, інженерія, продажі, маркетинг, технічна експертиза. Не можна записати всіх учасників CEO: відсутність людей, здатних виконати замовлення, робить бізнес-модель внутрішньо суперечливою.

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

2. Три обов’язкові артефакти

Ці артефакти не дублюють один одного. Візитівка створює контакт, цифровий варіант зменшує тертя під час обміну, one-pager відкриває технічну розмову. Короткий опис компанії (1–2 речення) потрібен для усного представлення; його узгоджує вся команда.

3. Фізична й цифрова картка: одна ідентичність, різні канали

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

Професійна адреса електронної пошти у власному корпоративному домені переважно викликає більше довіри, ніж безособова приватна адреса. Але домен, ім’я та сайт слід перевіряти практично, а не лише малювати. Ім'я англійською слід записувати послідовно, бажано за офіційною транслітерацією; змішування мов в одному мінімалістичному макеті знижує якість подачі. QR-код без цільового посилання — декоративний елемент, а не функціональний інструмент.

Інженерна аналогія: візитівка — це зовнішній інтерфейс до людини та організації. Якщо розміщена адреса не існує, інтерфейс має дефект незалежно від якості його графічного дизайну.

4. One-pager як засіб ініціації розмови

Заняття розглядає приклад A5-матеріалу, що використовувався на Auto.AI. Його мета — не вмістити всю презентацію, а дати співрозмовнику 2–3 швидкі точки входу в технічне обговорення. На першому боці доцільні: назва й один виразний меседж; доречний технічний образ; 2–4 ключові напрями компетенції; перевірювані кейси й клієнтські/партнерські референси за наявності права на їхнє використання. На другому — розширена інженерна експертиза, перевірювані партнерства, посилання на сайт та контакти.

Матеріал адаптується до аудиторії: для Automotive показують ECU, V&V, functional safety, HIL; для Industrial Engineering — автоматизацію, керування, сенсори, інтеграцію; для AI — власні релевантні результати. Список гучних брендів без зв'язку з проблемою аудиторії слабший за один переконливий релевантний кейс.

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

5. Довіра як перевірюваний результат

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

Зручна модель редакційної перевірки (навчальна модель, не емпірична формула):

C = I × R × A, де C — умовна цілісність презентації, I — узгодженість ідентичності (0…1), R — релевантність клієнту (0…1), A — перевірюваність заяв (0…1). Нуль будь-якого множника робить презентацію непридатною до використання в професійному контакті. Формула не є статистично каліброваною оцінкою довіри.

6. Від картки до CRM: що стається після обміну контактами

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

7. Розбір першого студентського результату

У кінці заняття викладач переглядає візитівку студента: відзначає логотип і роль Lead Software Engineer, але знаходить особисту Gmail-адресу, непослідовне поєднання української й англійської та QR, який нікуди не веде. Також бракує веб-сайту компанії. Це добра демонстрація різниці між макетом, який «виглядає завершеним», та артефактом, який готовий використовуватися на реальній виставці.

8. Практична робота: критерії приймання

1. Команда визначає назву, embedded-спеціалізацію, цільового клієнта й ролі.
2. Кожен готує паперову й цифрову картку за спільною дизайн-системою.
3. Команда готує один двосторонній one-pager із конкретними компетенціями, доречними зображеннями, доказами та контактами.
4. Учасники звіряють написання імен, ролей, корпоративні адреси, лінки, QR, бренд, локалізацію.
5. Кожен здатен за 30–60 секунд пояснити, чим компанія може бути корисна конкретному інженерному клієнту.

Критерій готовності: артефакти дають змогу наступного дня провести рольову симуляцію виставки й обмінятися контактами, а не лише показати картинки.

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

• Чому однаковий шаблон карток важливіший за індивідуальну декоративність?
• Чим one-pager відрізняється від комерційного proposal?
• Що саме має робити QR-код і як довести, що він працює?
• Який приклад краще презентувати на автомобільній конференції та чому?
• Як зібраний контакт перетворюється на кваліфікований lead, а не просто рядок в Excel?

Перехід до наступного заняття

Після створення артефактів потрібно перевірити узгодженість компанії, реалістичність її структури і готовність до діалогу. Практика 30 вересня переходить від створення матеріалів до їхнього аудиту й демонструє будову технічного proposal, який знадобиться вже після follow-up із замовником.