Заняття 10. Від контакту на виставці до технічного discovery: follow-up, команда та презентація

13 жовтня 2026 · лекційно-практичне заняття · 1 год 39 хв 02 с. Основа: автоматичний транскрипт IgorSikorskyKPI_L6_13102026.md (позначення L6 належить запису, а не хронологічній нумерації сайту). Конспект відтворює навчальний задум і ключові приклади; не є дослівною стенограмою. «Отто», «Удо» та AutoCircuit — персонажі й компанія навчальної симуляції. Їхні фінансові, технологічні й комерційні твердження не є перевіреними реальними референсами.

Місце в курсі: від lead до змістовного запиту

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

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

1. Повернення з конференції: інформація теж є результатом

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

Зручний звіт відповідає на чотири запитання: що спостерігали; чому це важливо; яку можливість або ризик це відкриває; яку дію пропонуємо. Корисно додати посилання на публічне джерело, назву демонстрації, дату, контакт особи й обмеження щодо використання інформації. Рекламний матеріал постачальника не перетворюється автоматично на підтверджений технічний результат. Наприклад, показана на стенді AI-функція керування батареєю потребує уточнення архітектури, метрик і умов випробування, перш ніж компанія закладе її у власний roadmap.

2. Післявиставкова публікація: перетворити досвід на видимість експертизи

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

Лекція пропонує LinkedIn як приклад мережі для професійного контакту: після особистої зустрічі доречно надіслати запит на зв'язок і підтримувати змістовну комунікацію. Але кількість контактів не дорівнює кількості клієнтів. Публічний матеріал, що називає реальну інженерну проблему й показує самостійне мислення, може сприяти довірі у майбутньому; гарантувати лідогенерацію або продаж він не може.

3. Вебінар як продовження дослідження теми

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

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

4. Чому знайомий з виставки не обов'язково пам'ятає нас

Перехід до follow-up починається з тверезої оцінки ситуації. У сценарії потенційні клієнти Отто й Удо повернулися до власної роботи та можуть не пам'ятати коротку розмову серед десятків інших зустрічей. Тому погано покладатися на ентузіазм, який співрозмовник продемонстрував біля стенда. Йому потрібен простий контекст: де саме відбулося знайомство, про яку тему говорили й для чого пропонується нова розмова.

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

5. Перше follow-up-повідомлення: коротко, адресно, з вибором

Викладач зі студентами формує шаблон: привітання відповідної формальності; нагадування про зустріч; коротко названа мета; три альтернативні часові слоти в різні дні або частини дня; можливість запропонувати власний час; підпис. Тон має бути ввічливим і зрозумілим, але не фамільярним. Вибір між Hi, Hello і Dear залежить від реальних стосунків, культури організації та контексту, а не лише від віку співрозмовника.

Навчальний приклад (не готова реальна переписка): «Привіт, Удо! Було приємно поспілкуватися на конференції про автоматизацію виробництва. Чи було б тобі цікаво провести коротку зустріч і обговорити можливі точки співпраці? Пропонуємо вівторок 10:00, середу 14:00 або п'ятницю 16:00 (час Києва). Якщо ці варіанти незручні, будемо раді підлаштуватися під твій час. З повагою, ...». Запропоновані години є ілюстративними, а не домовленими слотами.

6. Відповідь «не підходить»: не грати в нескінченне вгадування

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

Модель управління контактом: contact → invitation → agreed slot → calendar event → completed follow-up. Це послідовність станів, а не доказ конверсії. Для робочої аналітики корисно вимірювати T_response — час від першого повідомлення до відповіді; T_meeting — час від початкового контакту до фактичної зустрічі; N_confirmed — кількість підтверджених зустрічей. Такі величини набувають сенсу лише за наявності зафіксованих даних і чіткого визначення подій.

7. Хто має прийти на першу зустріч

Для follow-up у лекції запропоновано компактну команду з трьох ролей: особа, яка познайомилася з клієнтом на виставці; engagement-фахівець, який веде розмову; представник delivery, який оцінює можливості реального виконання. Якщо тема вузькоспеціальна, доречно залучити додаткового інженера, наприклад архітектора Computer Vision. Не слід запрошувати пів десятка людей лише «для солідності»: незбалансоване співвідношення учасників може зробити розмову незручною.

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

8. Залучення експерта з іншого підрозділу без зайвої ескалації

Коли потрібен спеціаліст Computer Vision з іншого delivery-напрямку, викладач пропонує спочатку узгодити коротке залучення з його лінійним менеджером. Менеджер знає поточне завантаження фахівця та обмеження команди. Після погодження можна звернутися до самого інженера: пояснити клієнтський контекст, потрібний результат і приблизні часові витрати. Звернення одразу на рівень C-level у такій побутовій ситуації може сприйматися як непотрібна ескалація.

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

9. Підготовка зустрічі: мета, agenda, комфорт співрозмовника

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

Стисле представлення учасника: ім'я → посада → зона відповідальності → релевантний досвід. Титули та академічні ступені можуть бути корисними, якщо доречні до предмета розмови, але не замінюють технічних доказів. Якщо хтось втратив зв'язок, фасилітатор коротко повідомляє про проблему й адаптує порядок виступів без тривалих пауз. Зустрічі потрібні визначена мета й кінцевий результат, а не просто «показати всі слайди».

10. Презентація AutoCircuit: від красивого матеріалу до discovery

У практичному епізоді студентка презентує вигадану компанію AutoCircuit: embedded-рішення для автомобільного ринку, ECU, ADAS, сенсори, автомобільні мережі, електромобільні системи, розробку й перевірку. У презентації з'являються CAN, CAN FD, Automotive Ethernet, C/C++, HIL/SIL і приклади функціональної безпеки. Викладач хвалить структуру й упевненість виступу, але критикує головну ваду: презентація перетворюється на монолог, який не перевіряє інтерес клієнта.

Кількість інженерів, назви OEM, нібито впроваджений продукт та заявлене зниження затримки в цьому епізоді є змістом студентського рольового прикладу, а не верифікованою інформацією про реальну компанію. Крім того, технічні абревіатури потрібно застосовувати за змістом: HIL — hardware-in-the-loop, SIL — software-in-the-loop; CAN FD і Automotive Ethernet мають різні властивості, і їхнє просте перерахування не доводить експертизу. Для реальної пропозиції потрібні підтверджені результати, умови вимірювань і права на використання референсів.

11. Інтерактивність: клієнтова реакція — це дані

Після ключового слайду про компетенцію доцільно запитати: «Наскільки ця область збігається з вашою поточною задачею?» або «Які обмеження для вас зараз найскладніші?». Пауза дозволяє клієнту назвати конкретну проблему, а команді — перевірити власні припущення. Якщо клієнт активізується при згадці CAN FD, це гіпотеза інтересу, яку треба уточнити запитаннями; нахил голови чи зміна міміки самі по собі не доводять потреби.

Презентацію варто будувати як цикл короткий факт → питання → відповідь клієнта → уточнення → наступний факт, а не як обов'язкове читання слайдів до кінця. Завдання follow-up — виявити контур задачі, а не одразу запропонувати готову архітектуру або ціну. Тоді змістовний діалог природно веде до окремого технічного discovery і майбутнього proposal.

12. Межі компетенції та правильна передача технічного питання

Студентка виступає як Computer Vision Team Lead, але клієнт може зацікавитися CAN FD або низькорівневими мережевими аспектами. Вимагати, щоб одна людина однаково глибоко відповідала за CV, шину CAN, апаратну інтеграцію, EMC і безпеку, методологічно неправильно. Визнати межі компетенції — ознака професійної відповідальності, а не слабкості. Правильна відповідь: зафіксувати питання, узгодити технічний follow-up і запросити відповідного архітектора/інженера.

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

13. Від discovery до proposal і backlog

Логічний маршрут заняття завершується так: перший контакт → follow-up → технічний discovery → уточнення потреби → proposal → decomposition → виконання. Proposal має узгоджувати проблему, межі роботи, припущення, архітектурні варіанти, верифікацію, ресурси та ризики. Пізніше команда може перейти до backlog у Jira або GitHub Project. На занятті 13 жовтня ці етапи ще не виконані: викладач анонсує їх як подальшу практичну роботу.

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

Практикум: артефакти після заняття

1. Звіт із конференції: сформулювати три спостереження та для кожного відокремити факт, інтерпретацію і запропоновану дію.
2. Персоналізований лист: написати запрошення на 20–30-хвилинний follow-up зі згадкою теми розмови, трьома варіантами часу та часовим поясом.
3. Ролі зустрічі: визначити, хто відповідає за контакт, фасилітацію, delivery-реалістичність і вузьку технологічну компетенцію.
4. Agenda: спланувати 20 хвилин так, щоб клієнт мав можливість представитися, уточнити проблему й погодити наступний крок.
5. Матриця запитань: підготувати п'ять discovery-питань, які відрізняють потребу клієнта від вашої гіпотези про його потребу.
6. Міні-proposal: створити каркас документа: проблема, межі, вимоги/припущення, технологічний підхід, критерії приймання, ризики й наступна зустріч.

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

• Чому повернення з конференції має завершуватися не лише списком контактів, а й інженерним звітом?
• У чому різниця між підписником LinkedIn, lead, погодженою зустріччю та клієнтом?
• Чому запрошення з конкретними слотами зазвичай практичніше за абстрактне «давайте якось зідзвонимося»?
• Навіщо на першому follow-up потрібен представник delivery, навіть якщо розмову веде engagement?
• Коли залучення CV-архітектора виправдане, а коли лише перевантажує зустріч?
• Яка подія в презентації дозволяє сформувати гіпотезу про «біль» клієнта і як її перевірити?
• Як відрізнити студентський приклад з умовними брендами від підтвердженого комерційного кейсу?
• Що повинно бути зафіксовано перед переходом до технічного discovery та proposal?

Наступні 1–2 заняття — прогноз за транскриптом

За словами викладача, наступна практика має початися з короткого перегляду презентацій студентських команд. Далі планується написання міні-proposal у Word, прив'язане до обговореного сценарію, а потім — перший крок до feature decomposition. Поки немає запису про проведення цих робіт, вони залишаються планом, а не виконаною частиною навчального архіву.