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

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

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

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

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

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

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

| Перевірка | Дефект | Наслідок | Приймальна умова |
|---|---|---|---|
| Назви й домени | `.ua` на постері, `.com` на картці | Неможливо зрозуміти, яка контактна адреса канонічна | Одна узгоджена доменна ідентичність |
| Візуальна система | Різні палітри або логотипи | Бренд виглядає зібраним із фрагментів | Один дизайн-контракт |
| Ролі | Lead без зрозумілої команди | Невідповідність заявленої ієрархії реальній | Ролі відповідають організації |
| Кейси | Неправильний знак партнера | Ризик хибної презентації | Перевірені і дозволені референси |
| Технічна ілюстрація | Fixed-wing підписаний квадрокоптером | Сумнів щодо експертності | Зображення відповідає твердженню |
| Контакт | Сайт є, пошти/телефона немає | Зацікавлений лід не може швидко звернутися | Прямий канал комунікації |

## 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 стане завданням наступного етапу.