# Заняття 12. Експертна зустріч, RFI/RFC/RFQ і proposal: як розмова про компанію стає розмовою про проєкт

> **20 жовтня 2026 · лекція № 7 · 1 год 26 хв 48 с.** Матеріал підготовлено за автоматичним транскриптом `IgorSikorskyKPI_L7_20102026.mp4`. Це відредагований навчальний конспект, а не дослівна стенограма: очевидні помилки розпізнавання виправлено, терміни уніфіковано з попередніми заняттями. Замовник Отто, його компанія та технічна задача — **навчальний сценарій**. Приклад із промисловою установкою наведено викладачем узагальнено, без деталей, що підпадають під NDA. Заняття переривалося через повітряну тривогу; на зміст конспекту це не вплинуло.

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

У заняттях 10–11 команда пройшла шлях від контакту на виставці до першого follow-up: представила компанію, експертизу, локації та інструменти й почула, що саме «болить» замовнику. Заняття 12 описує **другий follow-up** — експертну зустріч, після якої розмова має перейти від «хто ми» до «який проєкт ми робимо». Головний результат такої зустрічі — отримати від замовника формальний запит: RFI, RFC, RFQ або одразу вимоги.

Викладач підкреслив, що все в курсі — **рекомендації, засновані на власному досвіді** та досвіді колег, а не єдино можливий регламент. Їх варто адаптувати до конкретного клієнта, ринку й культури компанії.

## 0. Організаційне: оцінювання та велике самостійне завдання

- Залік можна отримати автоматично, набравши **60 балів і більше**; хто не набрав, складає залікову контрольну роботу.
- Відвідування занять також дає бали, тому присутність має значення.
- Після другої атестації буде велике самостійне завдання — **імітація інженерної компанії**: статичний вебсайт, умовна поїздка на конференцію чи виставку, отримання ліда, конвертація в клієнта, вимоги, proposal, проєкт у GitHub або Jira, розподіл команди та реліз. Роботу супроводжуватимуть регулярні зустрічі, орієнтовно двічі на тиждень.
- Екзаменаційні питання охоплюватимуть увесь курс; список буде наданий заздалегідь.

## 1. Навіщо другий follow-up

Перша зустріч на конференції створила знайомство. Перший follow-up показав компанію широко: роки на ринку, інженерні потужності, компетенції, інструменти, локації, сертифікації. Його справжня мета — зрозуміти, **що болить замовнику** і яку «таблетку» йому потрібно запропонувати.

У навчальному сценарії замовник Отто хоче **неруйнівну діагностику двигуна внутрішнього згоряння**: без розбирання мотора й без участі людини перевірити, чи не пошкоджені розподільні вали, коромисла клапанів або стінки камер у головці блока циліндрів. Розбирання дороге й одразу тягне заміну запчастин, тому цінність рішення очевидна. Другий follow-up — це зустріч, де компанія показує **вузьку експертизу саме під цю проблему**. Ідеальний результат — конвертувати Отто в клієнта вже на цьому етапі.

## 2. Декомпозиція проблеми: хто потрібен на зустрічі

Навіть короткий опис проблеми одразу розкладається на кілька інженерних напрямів:

| Напрям | Навіщо він потрібен у задачі Отто | Хто представляє |
| --- | --- | --- |
| Computer Vision | Ендоскоп — мініатюрна камера на гнучкому шлейфі, яку заводять у двигун через впускний або випускний колектор | Архітектор або лід з CV |
| AI / Deep Learning | Автоматичне розпізнавання дефектів: потрібен великий набір зображень справних двигунів і пошук аномалій відносно норми | Експерт з машинного навчання |
| Robotics | «Без людей» означає, що ендоскоп має вводити механізм або робот | Robotics Engineer |
| Embedded | Апаратна частина та firmware, що поєднують камеру, привід і обробку в один виріб | Embedded-архітектор |
| System Engineering | Четверо дуже різних інженерів мають працювати під одним спільним знаменником | System Architect |

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

## 3. Домашня робота: адресна презентація і повідомлення замовнику

Попередня презентація покривала всю компанію: web, mobile, cloud, AI, embedded, automotive, robotics, fintech, healthcare, mining. Тепер її треба **переписати під виявлену потребу**. Про кількість офісів і загальний масштаб компанії більше не йдеться. Ключове повідомлення звучить приблизно так: «Як продовження попередньої зустрічі ми хочемо показати нашу експертизу в темах, які, на нашу думку, корисні саме для вас. Ми підготували кілька кейсів і хочемо почути, наскільки вони перегукуються з вашою проблемою».

**Очікуваний результат зустрічі** — глибоке розуміння проблеми та можливих варіантів її вирішення. Потрібно точно з’ясувати, що вже є в замовника. Можливо, у нього готові hardware, firmware і механіка, а бракує лише інженерів. Можливо, немає нічого, і тоді пропозиція має описати повну візію: від системного рівня до реалізації.

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

## 4. Запрошення: слоти, інструмент зв’язку та agenda

Запрошення на експертну зустріч має три обов’язкові складові.

1. **Часові слоти.** Запропонуйте близько трьох варіантів із кроком в один день і розкидайте їх на ранок, обід і вечір. Обов’язково залиште можливість запропонувати власний час.
2. **Інструмент зв’язку.** Перша зустріч проходила в зручному для вас середовищі, наприклад Google Meet. Тепер варто запитати, де зручніше замовнику: Google Meet, Microsoft Teams, Slack чи інше. Якщо він обере Teams, організуйтеся так, щоб генерувати запрошення саме там. Адаптація до бізнес-інструментів клієнта демонструє гнучкість і повагу.
3. **Agenda.** Людина має розуміти, куди її кличуть. Перелічіть п’ять–шість пунктів, наприклад: коротке нагадування контексту, декомпозиція задачі, кейси за напрямами, обговорення проблеми замовника, наступні кроки.

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

## 5. Один ланцюжок листів від першого контакту до договору

Усю комунікацію — перший лист після конференції, домовленості, запрошення, презентації та follow-up — варто вести **в одному email-ланцюжку**. Після підписання договору цей ланцюжок закривають і починають новий, уже інженерний.

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

## 6. Ціна експертної зустрічі

Із цього моменту pre-sale починає реально коштувати грошей. Чотири–п’ять архітекторів і лідів високої кваліфікації — найдорожчі люди компанії. Щойно вони беруть участь у зустрічі, їхній час треба оплачувати, хоча проєкту ще немає. Тому заздалегідь вирішіть, **кого саме брати, скільки людей і якої тривалості буде зустріч**. Це інвестиція, яку потрібно усвідомлено обмежити.

## 7. Ролі на зустрічі: знайоме обличчя, Engagement і експерти

| Роль | Функція на зустрічі | Чого не робить |
| --- | --- | --- |
| Знайоме обличчя | Людина, яка познайомилася з Отто на конференції, потиснула руку; має «квоту довіри» й присутня на всіх зустрічах до підписання договору | Не керує процесом і не мусить бути експертом у темі |
| Engagement Manager | Організовує всі follow-up, листування, запрошення; відкриває зустріч, представляє учасників, веде презентацію, передає слово й стежить, щоб замовника не ізолювали | Не пише найперший лист після конференції — його пише знайоме обличчя |
| Експерти (архітектори, ліди) | Презентують по два кейси свого напряму, ставлять уточнювальні питання, читають реакцію замовника | Не перетворюють виступ на монолог |
| Замовник і його люди | Представляються, описують проблему, приносять власні документи | — |

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

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

## 8. Сценарій зустрічі

1. **Розігрів.** Engagement Manager вітається, запитує, як справи в Отто та його бізнесу, ставить кілька заздалегідь підготовлених питань, які, за його відчуттям, цікаві замовнику. Камери ввімкнені в усіх: Отто має побачити знайоме обличчя.
2. **Кругове представлення.** Якщо часу мало, Engagement швидко називає кожного учасника й роль. Якщо часу більше або він упевнений, що колеги вміють себе подати, кожен представляється сам.
3. **Представлення замовника.** Engagement просить Отто представитися — не тому, що його не знають, а щоб проявити повагу. Якщо з ним прийшли колеги, вони теж представляються.
4. **Вступні слайди.** Engagement показує agenda та декомпозицію системи: robotics, computer vision, AI, embedded.
5. **Кейси експертів.** Engagement передає керування показом експертам по черзі: двоє — computer vision, двоє — robotics тощо. Після кожного блоку він запитує: «Отто, як тобі це? Чи відгукується це з твоєю проблемою?»
6. **Запит до замовника.** Після останнього блоку не чекайте, що замовник заговорить сам. Прямо попросіть: «Розкажіть, будь ласка, яка у вас проблема і що саме ви вирішуєте. Ми хочемо зрозуміти, як можемо допомогти».
7. **Вільна дискусія.** Приблизно 10–15 хвилин експерти обох сторін говорять напряму.
8. **Підсумок і наступний крок.** Engagement підсумовує розмову й пропонує підготувати proposal.

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

## 9. Вільна дискусія з диригентом: другий екран і внутрішній чат

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

Це оркестр, а внутрішній чат — диригентська паличка. Відкрито суперечити замовнику на цьому етапі ризиковано; підтримка й уточнення працюють краще.

## 10. Завершення: обіцянка запиту та «важіль» нагадування

На виході Engagement каже приблизно так: «Інтенсивність розмови показує, що ми говоримо однією мовою і розуміємо, як це зробити. Давайте ми підготуємо вам proposal». Замовник відповідає, що надішле RFI, RFQ чи RFC. Команда, у свою чергу, обіцяє **надіслати презентацію як follow-up**.

Ця обіцянка — важіль. Якщо замовник забуде надіслати запит, лист із презентацією стане ще однією природною нагодою нагадати: «Ось обіцяна презентація; чекаємо на RFI». Документ запиту в замовника часто ще не написаний: він не скаже цього на зустрічі, але витратить день-два на таблицю з питаннями. Після кількох нагадувань запит зазвичай надходить.

**Головна зміна після цієї зустрічі:** до неї говорили про компетенції, компанію, команду — про що завгодно, крім проєкту. Після неї вся розмова стосується проєкту, який цікавить замовника.

## 11. Що може надіслати замовник: «питає» чи «каже»

| Що надходить | Режим | Що це означає | Відповідь компанії |
| --- | --- | --- | --- |
| RFI — Request for Information | Замовник питає | Хоче виміряти вашу спроможність за внутрішньою шкалою компетенцій | Заповнена таблиця відповідей |
| RFC — Request for Clarification (термін курсу) | Замовник питає | Просить описати ваше бачення рішення його проблеми | Proposal |
| RFQ — Request for Quotation | Замовник питає | Хоче знати строки й вартість | Оцінка часу та коштів із припущеннями |
| User stories | Замовник каже | Описує очікувану поведінку з погляду користувача | Аналіз, уточнення, оцінка |
| Requirements (system, hardware, software) | Замовник каже | Знає, що хоче; очікує оцінки | Командна оцінка кожної вимоги та RFQ |

Як і в занятті 04, **RFC тут — Request for Clarification у термінології курсу**. У широкій практиці закупівель запит «опишіть ваше рішення» частіше називають RFP (Request for Proposal), а в програмній інженерії RFC зазвичай означає Request for Comments. Тому в реальному процесі назву документа варто розшифровувати при першій появі.

## 12. RFI: таблиця з питаннями та «подвійним дном»

Типовий RFI — це Excel-таблиця: одна колонка з питаннями, друга для відповідей. Приклади питань з лекції:

- Чи маєте ви компетенцію Model-Based Development? Уточнення: які інструменти використовуєте для model-based development і для model-based testing? Можлива відповідь: MATLAB/Simulink, OpenModelica; для тестування — Simulink Test, для покриття моделей і коду — Simulink Coverage.
- Чи маєте ви експертизу в Embedded Engineering? Уточнення: з якими мікроконтролерами працюєте? Відповідь — перелік родин, наприклад STM32 (STMicroelectronics), NXP, Xilinx (тепер AMD).
- Чи маєте ви практику роботи із System on Chip (SoC)?
- Чи сертифіковані ваша компанія або інженери, залучені до проєкту, за стандартом функціональної безпеки? Якщо так, то за яким?

Уточнювальні питання не потребують відповіді, якщо на основне ви відповіли «ні». Обсяг RFI — від однієї сторінки до 10–20 сторінок. Такі анкети часто мають **«подвійне дно»**: одне й те саме питання повторюється в різних місцях під іншим кутом, щоб перевірити узгодженість. Тому відповіді мають не суперечити одна одній.

Будьте певні, що замовник може проаналізувати ваші відповіді за власним шаблоном, зокрема за допомогою AI, і оцінити технологічну відповідність. Це не причина прикрашати: **неправда рано чи пізно спливає**. Якщо ви не відповідаєте вимогам, це просто не ваш клієнт.

## 13. RFC і proposal: скільки розкривати

Буває, що після зустрічі замовник розуміє: ви знаєте процес краще за нього. Тоді він не надсилає ні вимог, ні user stories, а лише короткий RFC із двох речень: «Привіт. Чи не могли б ви описати у Word, Markdown чи іншому форматі ваше бачення вирішення нашої проблеми, яку ми обговорили на зустрічі?»

Відповідь на RFC — **proposal**, структуру якого розглядали в попередніх заняттях: summary, architectural view, design view, план реалізації, ризики, комерційна частина. Обсяг — від двох сторінок до сотні; найбільший proposal у практиці викладача мав близько ста сторінок. Пишуть його архітектори, а команда інвестує в нього власний час. RFC одразу після зустрічі — дуже хороший знак: замовник не знає, як розв’язати задачу, і хоче, щоб ви проявили креативність.

**Небезпека**, яку на занятті точно назвав один зі студентів: команда безкоштовно створює документ, який фактично розв’язує проблему, а замовник дякує й зникає. Викладач навів приклад зі своєї практики (без деталей через NDA). Велике підприємство мало установку, з якої відбувався небезпечний витік; виміряти його напряму було неможливо. Знадобилася математична та комп’ютерна модель витоку в зовнішнє середовище. Викладач описав у proposal метод визначення обсягу витоку на основі моделювання в MATLAB/Simulink і аналітичних розрахунків. Після цього замовник подякував і зник: місцеві інженери отримали достатньо, щоб реалізувати рішення самостійно.

| Тип складності | Ознаки | Як писати proposal |
| --- | --- | --- |
| Технологічна (наукова, математична) за простої реалізації | Ідея складна, а реалізація проста — у прикладі вистачило б наручного годинника, щоб засікати спрацювання аварійних клапанів | Загально й обережно: показати компетенцію, не розкриваючи методу |
| Технічна (складна реалізація) | Механіка, electronics, firmware, desktop, cloud, AI; потрібні команди на тривалий час | Детально: явні ризики, часовий буфер на неявні ризики, аналіз — це доводить експертність |

Межа між «замало» й «забагато» дуже тонка. Замало — і замовник не повірить, що ви це зробите. Забагато — і він зробить це сам.

## 14. Формат і версіонування proposal

Історично proposal пишуть у текстовому редакторі (Microsoft Word, LibreOffice, OpenOffice), бо він поєднує текст, ілюстрації, формули й таблиці. Обов’язкові атрибути такого документа:

- **автор** — людина, яка створила початкову версію; лишається автором назавжди;
- **last changed by** — хто вніс останні зміни;
- **історія змін** на початку документа — що саме змінилося між релізними версіями й у яких розділах.

| Подія | Версія |
| --- | --- |
| Перші внутрішні рецензії колег | 0.1, 0.2 … 0.7 |
| Перша відправка замовнику | 1.0 |
| Внутрішні правки після коментарів замовника | 1.1, 1.2 … |
| Повторна відправка замовнику | 2.0 |

Число до крапки — номер релізу для замовника; число після крапки — внутрішні ітерації. Скільки б разів документ не повертався всередині компанії, перша відправлена версія завжди 1.0.

Викладач віддає перевагу **Excel**: кожна вкладка працює як окремий розділ (вступ, архітектура тощо), дані структуровані, а фінансову частину — кількість, тривалість і вартість — можна рахувати прямо в документі прозоро для обох сторін. В епоху AI поширився **Markdown**: це зручний формат для спільної роботи людини й мовних моделей, і невеликі сучасні компанії його охоче приймають. Великі консервативні компанії мають власні правила щодо використання AI, тому з ними на першому етапі варто працювати традиційно, у Word або Excel, а Markdown пропонувати пізніше, якщо така практика в них є.

## 15. RFQ: частина першого proposal і квартальний запит

Перший proposal завжди містить комерційну частину: кількість і ціну — вартість інженерного часу й матеріальних ресурсів. Тому на старті RFQ тісно пов’язаний з RFC.

Окремим документом RFQ стає **після старту проєкту**: приблизно раз на квартал замовник просить оцінити витрати на наступний квартал. У цей час уже є Jira, GitHub Project або інший інструмент відстеження, але прогноз майбутніх витрат усе одно оформлюють документом. Він охоплює інженерні роботи, матеріали та суміжні витрати, наприклад кур’єрські й поштові послуги.

Ще один поширений шлях: замовник ітеративно вичитує ваш proposal і повертає коментарі («цей фрагмент перепишіть інакше»). Фактично він будує архітектуру майбутньої системи вашим коштом. Це хитрий підхід, але, за досвідом викладача, такі історії зазвичай конвертуються в контракт.

## 16. Найкращий випадок: вимоги та командна оцінка

Якщо замовник добре знає, що хоче, він надсилає **вимоги трьох рівнів**: system requirements (як поводиться система), software requirements і hardware requirements. Тоді від вас очікують RFQ уже на першій стадії.

Одна людина не може оцінити всю систему. Потрібно зібрати команду, попросити кожного оцінити окремі фічі чи вимоги й описати, як він бачить їхню реалізацію. Список очікуваних тривалостей і стає відповіддю на RFQ, наприклад: «функція X — від 2 до 10 днів за ставки 400 доларів на день для інженера певного рівня» (ставку наведено як ілюстрацію). Так замовник бачить, про які кошти йдеться.

## 17. Проблеми, які принесе оцінювання

Етап оцінювання супроводжується внутрішніми проблемами — вони стануть темою наступних занять:

1. **Немає кому оцінювати.** У «золоту епоху» українського IT (приблизно 2016–2018, до COVID-19) компанії тримали інженерів у «пулі» на bench, готових до нових проєктів. Нині така практика майже зникла.
2. **Залучення зовнішніх експертів.** Знайомий фахівець з іншої компанії може допомогти, але йому треба заплатити; потрібна модель оплати.
3. **Фриланс** як джерело ресурсів і його ризики.
4. **Відповідальність за оцінку.** Зовнішній експерт може недооцінити задачу, бо робитиме її не він. Як домогтися вдумливої оцінки і як залучити в проєкт тих людей, які оцінювали?
5. **Вартість інженерії та продукту.** В embedded до інженерного часу додаються механіка, розробка друкованих плат, закупівля компонентів, монтаж, валідація й верифікація, логістика, митне оформлення.
6. **Аналіз ризиків** невчасного виконання для обох сторін.
7. **Fixed Price чи Time & Material** у сучасній європейській embedded-практиці.

## Практичні висновки

- Другий follow-up готується під конкретну проблему замовника, а не під загальний профіль компанії.
- Запрошення містить кілька слотів, вибір інструменту зв’язку та agenda.
- Уся комунікація до договору ведеться в одному email-ланцюжку.
- Знайоме обличчя присутнє завжди, Engagement керує, експерти показують кейси й ставлять питання.
- Мета зустрічі — отримати RFI, RFC, RFQ або вимоги; без них подальша робота — витрата часу й грошей.
- Відповіді на RFI мають бути чесними й узгодженими між собою.
- Глибина proposal залежить від того, де складність: у технології чи в технічній реалізації.
- Proposal має автора, історію змін і зрозумілу нумерацію версій.

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

- Чим другий follow-up відрізняється від першого за метою та змістом презентації?
- Яких фахівців варто залучити до задачі неруйнівної діагностики двигуна і чому не всіх одразу?
- Що має містити запрошення на експертну зустріч?
- Навіщо вести всю переписку до договору в одному email-ланцюжку?
- Яка роль знайомого обличчя і чому найперший лист пише саме воно?
- Хто першим ділиться екраном і хто відкриває зустріч?
- Навіщо команді другий екран і внутрішній чат під час вільної дискусії?
- Чим режим «замовник питає» відрізняється від режиму «замовник каже»?
- Що таке «подвійне дно» в RFI і як не потрапити в пастку суперечливих відповідей?
- Коли proposal варто писати загально, а коли — максимально детально?
- Як змінюється номер версії proposal між внутрішніми рецензіями та відправками замовнику?
- Чому RFQ існує окремо від RFC після старту проєкту?

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

Викладач анонсував для наступних занять: людські ресурси для оцінювання в умовах порожнього «пулу», оплату зовнішніх експертів, фриланс, відповідальність за оцінку, аналіз вартості інженерії й апаратної частини, аналіз ризиків, порівняння Fixed Price і Time & Material. Далі курс перейде до підписання договору, user stories і внутрішніх вимог, декомпозиції команди, найму та визначення управлінських ролей. Окремі практичні заняття буде присвячено написанню proposal і заповненню RFI. Це **оголошений план**, а не вже проведені заняття.

## Перевірені посилання

- ISO/IEC/IEEE 29148:2018, Systems and software engineering — Requirements engineering: https://www.iso.org/standard/72089.html
- Simulink Test (MathWorks): https://www.mathworks.com/products/simulink-test.html
- Simulink Coverage (MathWorks): https://www.mathworks.com/products/simulink-coverage.html
- OpenModelica: https://openmodelica.org/