Заняття 08. Практика: аудит бізнес-артефактів та структура технічного proposal

30 вересня 2026 · практичне заняття · 1 год 16 хв 22 с. Джерело: транскрипт P3. Через повітряну тривогу та неповний склад груп заняття частково перейшло у демонстрацію та індивідуальний розбір. Плани повторної практики в джерелі є пропозиціями, а не підтвердженими подіями.

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

29 вересня команди отримали завдання створити корпоративну айдентику, персональні картки й one-pager. 30 вересня настав момент ревізії: чи витримали артефакти єдині вимоги і чи можна з їхньою допомогою почати технічну співпрацю. Друга частина показує, що буде після конференції: request → technical proposal → перевірка концепції → staged delivery.

1. Ревізія командних візитівок: операційні дефекти

Викладач переглядає матеріали двох команд. Позитивний результат: єдина палітра, логотип, ролі, корпоративні контакти, двосторонній макет, QR. Помилки, які виявляються вже під час простого аудиту: прізвище перед ім'ям в англомовному записі; різні кольорові системи візитівки й one-pager; різні домени на картках і постері; некоректний логотип заявленого партнера; неправильна іконка платформи; відсутній спосіб зв'язку в one-pager.

Ці помилки не слід виправдовувати тим, що дизайн є навчальним: вони відтворюють типові інтеграційні дефекти, коли два артефакти створено незалежно, але вони повинні описувати один і той самий продукт / компанію.

2. Хто є хто в інженерній компанії

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

Власники → C-level → директори напрямів → менеджери → інженери та спеціалісти.

Власник володіє компанією; CEO управляє нею за визначеними корпоративними повноваженнями; CTO/CFO відповідають за відповідні напрями; директор веде великий напрям і може мати делегований бюджет; engineering/project/technical manager організує виконання та ескалацію; engineer/lead створює технічний результат. Формальні повноваження й бюджети залежать від конкретної організації, юридичної форми та політик — схема є навчальним прикладом, а не законодавчим правилом.

Senior, Middle, Junior, Trainee — класи кваліфікації, що застосовуються у кадрових та компенсаційних процесах; вони не еквівалентні управлінським посадам і не визначають самостійно право витрачати бюджет. Lead Engineer має відповідати за технічну координацію і зазвичай передбачає командну функцію, яку потрібно пояснити на макеті організації.

3. Чому one-pager повинен мати доказову структуру

Розбір студентських one-pagers показує сильні сторони: зрозумілий embedded-профіль, ECU/ADAS/verification як компетенції, пояснення ролей і невеликих виробничих можливостей. Водночас сторінка може бути занадто текстовою, без достатніх технічних образів. Інша проблема — розмитий перелік сервісів: automotive ECU і зарядні станції можуть бути обидва доречні, але їх слід розвести як напрямки і пояснити зв'язок із компетенцією команди.

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

4. Від RFI / RFQ / RFC до proposal

Після знайомства на виставці й follow-up майбутній замовник може надіслати:

• RFI — Request for Information: запит про компетенції, досвід, інструменти, ресурси, спроможність компанії.
• RFQ — Request for Quotation: запит на оцінку вартості, цінові припущення, ліцензії, обладнання й витрати.
• RFC — Request for Clarification: у цьому курсовому сценарії уточнення способу вирішення технічної проблеми; відповіддю стає proposal. Абревіатура RFC у різних галузях має інші значення; її потрібно тлумачити за контекстом конкретного замовника.

Proposal — це не просто прайс. Це одночасно інженерна модель рішення, спосіб верифікації, план виконання, команда і комерційна рамка. У записі викладач показує анонімізований реальний приклад пропозиції для ECU Switching System, роботу над яким почали після серії технічних зустрічей. Факти й числові приклади подаються як ретроспективний досвід викладача, а не норматив для будь-якого проєкту.

5. Структура сильної технічної пропозиції

1. Executive Summary. Навіщо потрібен проєкт, яка цінність, які стадії, орієнтовний час і бюджет, модель співпраці.
2. Glossary / Abbreviations. Спільна мова для інженерів, закупівель і менеджменту.
3. Introduction & communication history. Контекст, предмет, узгодження і припущення.
4. Requirements baseline. Отримані документи, референси, список вимог і невизначеностей.
5. High-level architecture. Склад системи, інтерфейси, шляхи даних, живлення, керування.
6. Detailed design hypotheses. Потенційні модулі, компоненти, конструктивні схеми, залежності.
7. Validation / Verification. Як доведемо коректність роботи рішення.
8. Stages, deliverables & schedule. PoC, корисний мінімальний виріб, документація, віхи та Gantt.
9. Team and resources. Інженерні ролі, зайнятість, послідовність роботи.
10. Commercial framework. Fixed Price чи Time & Material, винятки та припущення.
11. Appendices & version history. Детальні креслення, великі таблиці, контроль змін між ревізіями.

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

6. Архітектура до контракту: довести, що команда розуміє проблему

На етапі proposal ще немає фінального продукту. Але модульна структура, ескізи в CAD, блок-схема, інтерфейси та частина фізичних доказів дають змогу замовнику оцінити реалістичність рішення. Візуалізація тут працює разом із технічним змістом: фото відповідає на питання «яким це буде», а схема — «як воно функціонує».

У демонстрації ECU Switcher викладач згадує PoC на evaluation board, UART-комунікації, дослідну макетну конфігурацію та тепловізійне спостереження. Це приклад раннього зниження інженерного ризику, а не доказ повної відповідності готового пристрою всім вимогам. Жоден клієнтський конфіденційний файл або комерційна цифра з цього прикладу не переноситься до відкритих матеріалів.

7. PoC → MVP → документація і повторюваність

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

Ілюстративна схема оцінювання (не статистична формула): E = Σ(rᵢ × tᵢ), де E — оцінені людино-години, rᵢ — кількість спеціалістів у ролі i, tᵢ — оцінена зайнятість одного спеціаліста цієї ролі. Це проста перевірка ресурсного плану; фінансова оцінка потребує ставок, резервів, матеріалів і припущень.

8. Комерційна модель і контроль версій

У прикладі обрано Time & Material, оскільки предмет роботи був інноваційним, а обсяг не повністю передбачуваним. Така модель не усуває обов'язку відстежувати бюджет, тривалість, зміни, ризики та погоджувати обсяг. Пропозиція може пройти кілька ревізій, тому після першого обговорення варто вести version/change log: версія, дата, зміни, автор, рішення замовника.

9. Завдання студенту та критерії приймання

1. Провести аудит усіх карток і one-pager за таблицею дефектів.
2. Зробити коротку організаційну схему з відповідальностями й пояснити роль кожного учасника.
3. Визначити одну клієнтську проблему, яку може вирішити компанія; відокремити потребу від бажаної технології.
4. Побудувати зміст майбутнього proposal на основі цього запиту.
5. Вибрати найбільш ризикову гіпотезу та визначити мінімальний PoC, який її перевірить.
6. Підготувати власні перевірювані референси й не видавати рольові вигадки за реальні партнерства.

Результат: команда готова до реалістичної симуляції зустрічі із замовником. Наступне заняття відтворює сам контакт, заперечення й домовленість про follow-up; технічний proposal стане завданням наступного етапу.