Заняття 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. Декомпозиція проблеми: хто потрібен на зустрічі

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

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

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 — загоничі; архітектори, інженери та знайоме обличчя — стрільці. У компаніях 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. Що може надіслати замовник: «питає» чи «каже»

Як і в занятті 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 і аналітичних розрахунків. Після цього замовник подякував і зник: місцеві інженери отримали достатньо, щоб реалізувати рішення самостійно.

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

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

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

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

Число до крапки — номер релізу для замовника; число після крапки — внутрішні ітерації. Скільки б разів документ не повертався всередині компанії, перша відправлена версія завжди 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/