Кейс 4 Спільна поставка

Спільна поставка

Система контролю доступу для автобусів і тролейбусів — швидкий трек

1. Задача

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

У замовника є потужний внутрішній IT-відділ: аналітики для написання ТЗ та DevOps-команда для самостійного розгортання. Вендор залучений лише для розробки.

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

Питання: який фактичний обсяг вендора, трудомісткість та тривалість поставки?

2. Вибір

Тільки ТРП Вибір №4 — ТЗ та ВП виключені з обсягу вендора

Замовник надає ТЗ і бере на себе ВП, а вендор реалізує ТРП. ТРП об'єднує ТП і РП в одну стадію без проміжної межі приймання.

При 40–60% повторного використання та досвідченій Scrum-команді межа між технічним проєктуванням і реалізацією є плинною. ТРП точніше відображає цю реальність.

3. Цільова стадія

Release Candidate Горизонт H3 — єдиний горизонт в обсязі вендора

Вендор поставляє один горизонт: H3 (Release Candidate). Production Release (H4) — IT-команда замовника після приймання.

4. Примітка до маппінгу

За допомогою FMP обрано 6 функцій. Повний склад — у калькуляторі.

Технічна складністьЖорсткі обмеження реального часу

Апаратна адаптаціяАдаптація до пропрієтарного обладнання

Архітектурна складністьІнтерактивний досвід у реальному часі

ІнноваціяЕволюційна інновація

Повторне використання стандартного ПЗ40–60% — Часткове переінженерування (базова логіка)

Методологія розробкиScrum (чистий) — не впливає на структуру стадій

5. Звіт

Розподіл ресурсів: ТРП=8 | 235 днів/рік на FTE | Модель поставки: Обсяг вендорської розробки

ТЗ: надано замовником (виключено). ВП: виконує замовник (виключено).

Горизонт	Стадія	Продуктова стадія	Трудомісткість (лд)	Команда (FTE)	Час від старту	Обсяг
H0	ТЗ — Технічне завдання	Базис вимог	377	—	—	Замовник
H3	ТРП — Техно-робочий проєкт	Release Candidate (без MVP)	2 288	8	1.22 р.	Вендор
H4	ВП — Впровадження	Production Release	670	—	—	Замовник
Підсумок вендора			2 287 лд	8 FTE	1.22 р.

Порівняння обсягів — той самий проєкт, різні межі відповідальності:

	Повний підряд (вендор робить все)	Кейс 4 — Спільна поставка	Різниця
Загальна трудомісткість	3 335 лд	2 287 лд	−1 048 лд (−31%)
Загальна тривалість	~3.5 р.	1.22 р.	−2.3 р. (−65%)

6. Рішення

Прийняти конфігурацію з однією обов'язковою передумовою: вхідне ТЗ має пройти формальний огляд до початку ТРП. Якщо покриття ТЗ нижче 70% — повернути на доопрацювання. Неповне ТЗ в цій конфігурації не має буфера: ТРП починається з невизначеністю, яку ніхто не може усунути посеред спринту.

ТРП є розрахованим маршрутом: 40–60% повторного використання та досвідчена Scrum-команда означають, що межа між проєктуванням і реалізацією реальна, але тонка.

7. Аналіз інженерної здійсненності

Спільна поставка

Перерозподіл відповідальності між замовником і вендором — це не організаційна перевага, а інженерне рішення з вимірюваним ефектом. Передача ТЗ та ВП замовнику скорочує обсяг поставки вендора на 31% і тривалість — на 65%.

Для спонсора проєкту: обсяг вендора менший, чистіший і швидший. Ризик переноситься на якість ТЗ замовника та готовність DevOps-команди — обидва мають бути перевірені до початку ТРП.

Методологія Scrum, яку команда використовує внутрішньо, не впливає на цей аналіз. Детерміністичний інженерний метод оперує на рівні інженерних стадій і зрілості продукту.

Модель поставки: Обсяг вендорської розробки

^ До початку