Скільки часу триває розробка MVP: реальні терміни й що їх затягує

Коротка відповідь

Це орієнтир для зосередженої команди, яка будує один продукт, а не обіцянка. В EVA-X до MVP зазвичай минає близько чотирьох тижнів; простий прототип в AI Build буває швидшим, платформа з кількома ролями — довшою.

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

Куди насправді йдуть тижні

1. Обсяг робіт: від ідеї до погодженого списку модулів

Від кількох днів до двох тижнів. Саме тут продукт ділять на модулі, записують головний сценарій і виносять за межі першої версії все, що «було б добре мати». Перша оцінка може зайняти секунди — наша готова приблизно за 15 секунд, — але погодження обсягу триває рівно стільки, скільки відповіді на запитання команди. Найшвидші проєкти — ті, де одна людина може відповісти того ж дня.

2. Договір і перший платіж

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

3. Дизайн

Від одного до трьох тижнів, часто паралельно з початком розробки. Продукту на перевіреній системі компонентів досить прототипів і кількох ключових екранів; продукту, що конкурує досвідом користувача, потрібен повний візуальний дизайн ще до того, як почнуть верстати екрани. Якщо у вас уже є фірмовий стиль, дизайн іде швидше; якщо його треба створити з нуля, закладіть на це окремий час.

4. Розробка модулями

Найбільша частина календаря. Добра команда не будує «весь MVP», щоб показати його наприкінці. Вона здає модуль за модулем — реєстрацію, головний сценарій, оплату, адмінку, — і кожен потрапляє до вас на перевірку, щойно готовий. Так проблеми з’являються на другому тижні, а не на восьмому.

5. Перевірка й правки

Кожен модуль потребує вашої перевірки. У нас на неї є 7 календарних днів: модуль можна прийняти або повернути з обґрунтованим списком правок; якщо не зробити ні того, ні іншого, модуль вважається прийнятим. Клієнт, який перевіряє за день-два, може заощадити тиждень і більше порівняно з тим, хто щоразу використовує весь термін.

6. Запуск

Домени, робочий хостинг, аналітика, перемикання платіжного сервісу з тестового режиму в робочий, надсилання мобільного застосунку на модерацію. Модерація першої версії в App Store і Google Play зазвичай додає кілька днів, а якщо в модераторів з’являються запитання — більше. Не забудьте про юридичні сторінки: без умов користування й політики конфіденційності ні магазини застосунків, ні платіжні сервіси продукт не пропустять.

Що затримує MVP

Код рідко буває головною причиною. Зазвичай винні:

• Обсяг, що росте під час розробки. Кожне «маленьке» доповнення зсуває модулі, які йдуть після нього. Ведіть список для другої версії й дописуйте туди.
• Повільні рішення. Запитання, яке тиждень чекає на відповідь, коштує тиждень. Призначте одну людину, яка ухвалює рішення, і дайте їй час на проєкт.
• Сторонні сервіси. Підключення платіжного сервісу може тривати від кількох днів до кількох тижнів. Акаунт розробника для організації потребує перевірки компанії — Apple, наприклад, просить номер D-U-N-S, як пояснено на її сторінці реєстрації. API партнерів потребують ключів і тестових середовищ, які контролює хтось інший.
• Контент і дані не готові. Тексти, ціни, юридичні сторінки, каталог для імпорту. Розробники не можуть їх вигадати.
• Нечіткі критерії приймання. Якщо ніхто не визначив, що означає «готово», кожна перевірка перетворюється на торг. Домовтеся, що має робити кожен модуль, ще до того, як його почнуть будувати.

Як дійти до запуску швидше

Багато з того, що пришвидшує MVP, лежить на боці клієнта:

• Зареєструйте акаунти заздалегідь і на свою компанію: домен, хостинг, платіжний сервіс, акаунти розробника в Apple і Google.
• Почніть підключення платіжного сервісу на першому тижні, а не за тиждень до запуску.
• Призначте одну людину, яка ухвалює рішення й відповідає протягом дня.
• Готуйте контент паралельно: тексти, ціни, зображення, умови користування й політику конфіденційності.
• Перевіряйте кожен модуль, щойно він надійшов.
• Ведіть список «для другої версії» й не додавайте нового під час розробки.
• Погодьте критерії приймання для кожного модуля до початку роботи.

Як платформа змінює календар

• Вебзастосунок. Найкоротший шлях: без модерації в магазинах застосунків, а оновлення стають доступні, щойно їх розгорнули.
• Мобільний застосунок. Додайте реєстрацію акаунтів розробника, матеріали для сторінки в магазині застосунків — знімки екрана, описи, дані про конфіденційність — і модерацію першої версії; закладіть запас приблизно в тиждень. Згодом, на React Native та Expo, багато виправлень можна доставляти користувачам напряму, без нової модерації. Повний календар мобільної розробки — у статті про терміни розробки застосунку.
• Telegram Mini App. Без модерації в магазинах застосунків і без встановлення, але з ботом, якого треба налаштувати, власними правилами Telegram щодо оплат і тестуванням у застосунках Telegram.
• Веб плюс мобільний застосунок. Якщо потрібні обидва, розгляньте запуск спершу вебверсії, а застосунку — за кілька тижнів на тому самому бекенді. Реальні користувачі раніше перевірять головний сценарій, а застосунок виграє від того, що вони знайдуть.

Ознаки того, що запропоновані терміни нереалістичні

• Одна здача в самому кінці, і до неї нічого перевіряти.
• У плані немає часу на ваші перевірки й правки після них.
• Немає рядка для підключення платіжного сервісу, акаунтів розробника чи модерації в App Store і Google Play.
• Жорстка дата поєднана з обсягом робіт, який ще не погоджено.
• План передбачає миттєві відповіді з вашого боку, але ніхто не запитав, хто саме їх даватиме.

Добрий план читати нудно: модулі, дати, хто що робить і запас часу там, де залежите від сторонніх сервісів.

Чи пришвидшує AI розробку MVP?

AI пришвидшує написання рутинного коду: екранів, форм, типових інтеграцій. Але не пришвидшує ваших рішень, підключення платіжного сервісу, модерації в магазинах застосунків чи підготовки контенту. Тому формати розробки відрізняються не лише ціною, а й темпом: AI Build — найшвидший шлях для прототипів і внутрішніх інструментів, AI + DEV поєднує темп із тим, що архітектуру й QA ведуть інженери, а DEV дає senior-розробникам час, потрібний для систем, які не мають права ламатися. Докладніше — у статті AI Build, AI + DEV чи DEV.

Реалістичний план на шість тижнів

Візьмімо умовний MVP з одним сценарієм у вебі: сервіс запису для приватних репетиторів, де учні бронюють і оплачують уроки, а репетитори керують своїм розкладом.

Такий план тримається, лише якщо тримається права колонка. Коли такий план зривається, спершу дивіться на праву колонку.

Той самий план із мобільними застосунками

Скажімо, репетитори хочуть ще й застосунки для iOS та Android у першій версії. Продукт переходить у рядок «кілька ролей або мобільний застосунок», а план змінюється в передбачуваних місцях:

• Тиждень 0: акаунти розробника в Apple і Google реєструють на вашу компанію; перевірка організації йде паралельно.
• Тижні 1–6: ті самі модулі, але з екранами застосунку, push-сповіщеннями замість частини листів і тестуванням на реальних пристроях.
• Тижні 7–8: матеріали для сторінки в магазині застосунків, перше надсилання на модерацію, відповіді на запитання модераторів.
• Приблизно тиждень запасу на відмову чи запитання щодо оплат, входу або конфіденційності.

Для такої умовної версії реалістичний план — вісім-десять тижнів, у межах діапазону від шести до дванадцяти. Якщо запустити спершу вебверсію, а застосунки — за кілька тижнів на тому самому бекенді, реальні користувачі раніше пройдуть головний сценарій.

Швидкість і те, що не можна пропускати

Буває «швидко», яке потім обходиться дорожче. Пропустити тести оплати, відкласти права доступу «на після запуску» чи запуститися без аналітики — це заощадити дні зараз і втратити тижні після першого інциденту. Швидкий MVP вузький, а не недбалий: він робить менше, але як слід. Якщо дата жорстка — зустріч з інвестором, виставка, сезон, — скорочуйте обсяг, а не якість, і скажіть про дату одразу, щоб план будували навколо неї.

Як ми фіксуємо терміни

Терміни — частина оцінки й договору, поруч із ціною. Відлік починається, коли договір підписано й надійшов перший платіж, і змінюється лише через погоджений запит на зміни або з причин, названих у договорі, — наприклад, через затримки з боку клієнта. Хід кожного модуля ви бачите у своєму кабінеті. Щоб спланувати бюджет разом із календарем, прочитайте скільки коштує розробка MVP; щоб етап узгодження обсягу був коротким — як описати проєкт, щоб його точно оцінили. Більше про наш підхід — на сторінці розробка MVP.