[Зміст]Показати зміст
MVP за 8 тижнів реалістичний тоді й лише тоді, коли виконані три умови: бізнес-проблема однозначно визначена, реальні користувачі готові тестувати продукт у 4-му тижні, а scope зводиться до одного головного flow. DailyHair виконав усі три: (1) event-менеджери втрачали 6 годин на тиждень на координацію 30+ медіапатронів, (2) три пілотні конференції чекали на тижні 4-7, (3) один flow — затвердження брифу через magic link. Поза цими умовами «MVP за 8 тижнів» — це маркетинг, а не інженерія. За нього платять технологічним боргом, якого ніхто не амортизує в балансі, але який виявляється на третьому місяці після запуску.
Цей текст стоїть на двох перспективах одночасно. По-перше, ми самі запустили 12 власних продуктів як venture builder і знаємо, що вміщається у 8 тижнів, коли це наші гроші. По-друге, у проєктах індивідуального програмного забезпечення для клієнтів ми теж доставляємо MVP і знаємо, що вміщається там, де scope оплачує клієнт. Ці два світи вчать різних речей. Наведений нижче framework є їхнім поєднанням.
Коли 8 тижнів реалістично
Vague brief: «Збудуйте платформу для подій». Реальний: «Медіапатрон затверджує бриф за 3 дні, подія за 2 тижні». Перше — це feature list, друге — bottleneck з годинником. Проблема сформульована на рівні конкретного болю, конкретної людини і конкретної метрики, яку ми хочемо змінити. Якщо команда не може сказати, що перестане боліти після запуску MVP — це не MVP, а прототип без аудиторії.
Друга умова: доступ до реальних користувачів у 4-му тижні. Не гіпотетичні персони з UX-воркшопів, а конкретні люди з іменами та номерами телефонів, які погодилися тестувати рано. MVP без користувачів у середині проєкту тестує припущення команди, а не ринок. У проєктах, де клієнт приходить зі словами «користувачів знайдемо після прем’єри», термін реалізації зсувається до 12-16 тижнів — бо все одно доведеться будувати другу версію, перш ніж перша принесе комусь цінність.
Третя умова: один primary flow. Користувач заходить, робить одну річ, виходить із цінністю. Решта — гарнір: адмін-панелі, налаштування, експорт, сповіщення. Якщо в MVP два рівноправних flow (наприклад, «для event-менеджерів і для медіапатронів одночасно») — це не MVP, це два MVP, що вдають із себе одне. За 8 тижнів можна побудувати один flow дуже добре або два flow посередньо. Посередність у MVP гірша за відсутність MVP, бо спростовує гіпотезу замість її тестувати.
Коли 8 тижнів — червоний прапор
Клієнт хотів SAP-інтеграцію в MVP. Я сказав ні. Знайшов іншого, який сказав так. Через 16 тижнів дзвонили до нас. Ринкове вікно закрилося. Кожна enterprise-інтеграція — SAP PI, Salesforce, NetSuite, ERP на Comarch XL, HL7/FHIR у медицині, SWIFT у банкінгу — це окремий проєкт, а не завдання у спринті. Сама інтеграція з SAP (узгодження з IT клієнта, тестові середовища, mappings) займе 6-10 тижнів без жодного рядка коду застосунку. Якщо MVP стоїть і падає на одній enterprise-інтеграції, це не MVP — це інтеграційний проєкт з UI безкоштовно на додачу.
MVP для 50 персон у 3 вертикалях у 3 країнах одночасно. Це waterfall, що вдає agile. Ми відкотили до однієї вертикалі. У брифі з’являється «платформа має обслуговувати як meetups до 100 людей, камеральні галузеві конференції, так і культурні фестивалі на 50 тисяч учасників, з прицілом на експансію на німецький, український та іспанський ринки». Кожен із цих сегментів має іншу модель патронату, інші процеси, інші регуляторні вимоги. MVP для всіх сегментів означає архітектуру, що не пасує нікому. Правильне рішення: один сегмент у MVP, решта — як v2. Бізнес-архітектура MVP має бути спроектована під розширюваність, але не під усі випадки одразу.
Третій анти-патерн: відсутність механізму тестування на користувачах. «Зробимо тести після запуску» — це не план тестування, а відмова від тестування. Без feedback loop у 4-му тижні MVP перетворюється на 8-тижневий прототип, який починає вчитися лише після деплою. Це найдорожчий момент для виявлення, що проблему було поставлено неправильно — бо бюджет уже витрачено.
Четвертий анти-патерн: compliance-важкі домени з аудиторським workflow. Банкінг (KNF, PSD2, SOX), медицина (HIPAA, GDPR у клінічних деталях), державний сектор (EZD RP, PUW, KRI), фарма (GxP). У цих доменах сам шар аудиту, ретенції даних і прав доступу — це 4-6 тижнів роботи. MVP за 8 тижнів у compliance-важкій домені означає або пропуск compliance (неприйнятний ризик), або скорочення продуктової частини до фасаду. Реальний час MVP у таких доменах: 14-20 тижнів.
DoMoreSoft MVP Scoping Framework
Ця матриця народилася зі спостереження за проєктами. Результат нижче 15? Щось зламається. 15-20? Тісно, але виконувано. 20+? Зелене світло. Ми оцінюємо проєкт у п’яти вимірах за шкалою 1-5. Framework прагматичний — він не замінює scoping-воркшоп, але задає рівень розмови в перші 30 хвилин.
MVP Scope Checklist — що вміщається у 8 тижнів
Конкретний обсяг, який ми доставляємо у прагматичному MVP при framework-скорі 20+:
- Автентифікація та реєстрація користувачів (email/пароль + за потреби SSO)
- Один primary flow end-to-end — від входу до цінності (бронювання, замовлення, подання заявки)
- Одна адмін-панель з базовим CRUD для найважливіших сутностей
- Одна зовнішня інтеграція (платіж, SMS, карти, транзакційний email — вибір залежить від домену)
- Базова продуктова аналітика — хто, коли, що зробив, де відмовився
- Деплой на staging та production, CI/CD, моніторинг помилок (Sentry/GlitchTip)
- GDPR у мінімальному обсязі: політика конфіденційності, експорт та видалення акаунта, згоди
- Технічна документація, що дозволяє іншій команді перейняти код без rescue mission
Не тому, що ми милі. Будь-що поза цим списком має хвіст прихованої складності. Multi-tenant? Три тижні архітектурного боргу. Offline-режим? Окремий проєкт. Повний RBAC? V3, не v2. Якщо хоч один із цих пунктів випадає зі scope, аби встигнути у 8 тижнів, це перестає бути MVP і стає прототипом. Фундамент, на якому можна будувати 18-24 місяці без переписування з нуля, має свій мінімум — і він вищий.
Що не вміщається (і чому це не провал)
- Multi-tenant із повною ізоляцією даних. У MVP достатньо одного tenant або shared database з ключем tenant_id. Повна ізоляція (schema per tenant, database per tenant) — 3-5 тижнів архітектурної роботи, має сенс лише при перших enterprise-клієнтах.
- Offline-режим і синхронізація. Застосунок, що працює offline (PWA з offline queue, CRDT, conflict resolution) — це окремий проєкт. У MVP приймаємо вимогу постійного з’єднання.
- Розширені ролі та права доступу. У MVP достатньо 2-3 ролей (user, admin, опційно manager). RBAC з матрицею прав на рівні полів, ABAC, audit trail кожної зміни — це v2 або v3.
- Дашборди звітності та BI. CSV-експорт і 3-5 ключових показників — достатньо. Повна звітність із фільтрами, когортами та custom queries будується лише тоді, коли відомо, які дані бізнес-команда реально використовує.
- Інтернаціоналізація (i18n). Одна мова у MVP. Додавання другої — мінімум 2 тижні роботи (витяг рядків, плюралізація, дати, валюти, тести). Не варто платити за це у MVP, якщо користувачів із другого ринку ще немає.
Відкладення цих позицій на v2 — це прагматична бізнес-архітектура, яка не платить за функціональність, якої ще ніхто не потребує. Кожна з них повернеться у правильний момент, коли буде обґрунтована конкретною потребою, а не припущенням. Рішення, що перенести у v2, є частиною discovery-процесу — не імпровізації на спринті.
Звідки ми знаємо ці 8 тижнів — робимо це самі
Ми побудували MVP DailyHair — платформи для управління медіапатронатами та комунікацією навколо галузевих подій — за 8 тижнів. Конкретика з нашого журналу:
- Тиж 1: ми були готові на 40% і в паніці. Backlog непропорційний робочим дням.
- Тиж 3: вирізали 30% запланованих фічей. Multi-channel сповіщення, custom-звіти, інтеграція з двома CRM — усе пішло у v2.
- Тиж 6: перша конференція на продакшні, pivot двох flow після фідбеку event-менеджерів. Magic link виграв із паролем.
- Тиж 8: shipped. Три пілотні проєкти підключені, primary flow стабільний.
Це не анекдот про те, які ми розумні. Доказ, що framework працює тоді, коли його застосовують жорстко — до себе й до клієнтів. Ми робимо те саме з 2016 року, вже на 12 власних продуктах, і кожен із них навчав нас, що зі списку «nice to have» справді nice, а що — прихований технологічний борг.
Cost math: 8 тижнів vs. 16 тижнів
Порахуємо TCO двох шляхів для того самого продукту:
| Позиція | MVP 8 тиж. | MVP 16 тиж. |
|---|---|---|
| Бюджет розробки | 30-50 тис. EUR | 80-140 тис. EUR |
| Час до ринкового feedback | 8 тиж. | 16 тиж. |
| Вартість одного циклу навчання | низька | висока |
| Ризик збудувати не те | обмежений scope | великий (більше припущень, більше помилок) |
| Технологічний борг | контрольований при 20+ у framework | низький, якщо команда не поспішала штучно |
Арифметика виглядає однозначно, але є одна умова, яка її перевертає. Поганий MVP за 8 тижнів дорожчий за добрий MVP за 12 тижнів. Вартість будівництва не тієї речі — це не лише бюджет проєкту, а й альтернативна вартість (час команди), вартість довіри (перші користувачі, які тестують поганий продукт, більше не повертаються) і вартість рефакторингу під v2, що нарешті відповідає на реальну проблему. Сума цих витрат здатна перевищити бюджет 16-тижневого MVP. Тільки що вона розподілена в часі й менш помітна у звіті.
Швидко — це не мета. Мета — рано валідовані припущення. 8 тижнів мають сенс тоді, коли скорочують час до навчання, а не коли скорочують час до «маємо щось, що виглядає як продукт».
Червоні прапори з боку клієнта, не лише постачальника
Більшість статей про MVP зосереджуються на тому, що постачальник має зробити добре. На практиці проєкти сходять із рейок і з причин на боці клієнта — і чесність вимагає назвати їх прямо. Три, що перетворюють 8-тижневий MVP на 16-тижневий незалежно від компетенцій команди:
Перша: зміна scope у кожному спринті. Клієнт, який кожні два тижні додає нові функції («це дрібниця, додайте між іншим»), гарантує зрив. Кожна зміна scope — це рішення: чи випадаємо з 8 тижнів, чи щось інше вилітає зі scope. Не можна з’їсти тістечко й мати його. Зрілий клієнт розуміє, що scope freeze після 2-го тижня — це передумова вчасної доставки.
Друга: відсутність доступу до кінцевих користувачів. Клієнт, що каже «користувачів забезпечимо», але на 3-му тижні ще не має домовленого першого пілотного тесту, щойно вимкнув петлю навчання у продукті. Від 4-го тижня команда кодить наосліп — навіть якщо архітектура коректна, продуктові рішення є вгадуваннями. Момент, коли варто зупинити проєкт і зробити reset.
Третя: decision-maker поза проєктом. Клієнт делегує MVP менеджеру середньої ланки, який не має повноважень вирішувати про scope. Кожне значуще рішення потрапляє на стіл CEO, який відповідає раз на тиждень — найчастіше зміною scope. Передумова співпраці у 8-тижневому MVP: decision-maker із реальними повноваженнями, доступний у циклі 48 годин.
Хочеш перевірити, чи твій MVP вміщається у 8 тижнів?
Скористайся framework вище — оціни п’ять вимірів за шкалою 1-5, додай і подивись, у якій категорії ти. Результат 20+ — починай, умови виконані. 15-19 — говоримо про 10-12 тижнів або про обрізання scope. Менше 15 — потрібен discovery-воркшоп, не MVP.
Напиши на office@domoresoft.com з результатом самооцінки. Якщо ти на межі (17-20 балів), 30-хвилинна розмова з архітектором покаже, що залишити у MVP, а що вирізати до v2 — і скільки це справді коштуватиме. Для поглиблення контексту, як оцінити технологічного партнера, який має цей MVP фактично доставити, рекомендуємо framework вибору software house у 2026. Ми не продаємо «MVP за 8 тижнів» як продукт з полиці — продаємо чесну розмову про те, чи ці 8 тижнів реалістичні у твоєму випадку.