Скільки триває розробка MVP? Практичний посібник
Якщо ви вперше створюєте продукт і плануєте термін MVP, інформація в інтернеті зазвичай або надто розмита («це залежить»), або надто конкретна («рівно 12 тижнів»). Цей посібник пропонує середній шлях: практичну схему оцінки власного терміну та кілька запитань, які найбільше змінюють результат.
Почніть із трьох запитань
Перш ніж отримати реальну цифру, дайте відповідь на три запитання:
- Скільки різних користувацьких сценаріїв потрібно першому релізу? Один потік входу та виконання основної дії сильно відрізняється від трьох потоків для різних типів користувачів.
- До чого продукт має підключатися? Платежі, електронна пошта, SMS, карти та CRM додають час на інтеграцію й тестування.
- Які платформи потрібні? Лише веб — найшвидший варіант. Веб плюс нативний мобільний застосунок приблизно вдвічі збільшує роботу над frontend навіть зі спільним backend.
Чесні відповіді допоможуть зрозуміти місце продукту на шкалі термінів ще до розмови з командою розробки.
Практичний діапазон
Для більшості стартапів зі стандартним продуктом — одним основним сценарієм, кількома інтеграціями та однією платформою — 8–16 тижнів від discovery до запуску є реалістичним діапазоном. Складніші продукти з кількома ролями, інтеграціями та двома платформами часто потребують 16–24 тижнів або більше.
На що насправді витрачається час
| Етап | Частка терміну |
|---|---|
| Discovery та визначення обсягу | ~10% |
| Дизайн | ~15–20% |
| Розробка | ~50–60% |
| Тестування та QA | ~10–15% |
| Підготовка запуску | ~5% |
Тестування — не дрібниця: навіть помірний продукт зазвичай потребує повного одного-двох тижнів. Саме цей етап найчастіше скорочують під тиском термінів.
Як зберегти реалістичний термін
- Зафіксуйте обсяг після початку розробки. Додавання функцій у середині роботи — найпоширеніша причина затримок.
- Швидко переглядайте роботу. Повільний feedback між засновником і командою розтягує проєкт сильніше, ніж очікують.
- Відокремте обов’язкове від бажаного. Першому релізу для перевірки основної гіпотези не потрібні всі функції майбутнього roadmap. Дивіться що має увійти до першого релізу.
- Не пропускайте discovery заради тижня. Discovery запобігає значно дорожчій помилці — добре створити не те.
Покроковий шлях від ідеї до плану з визначеним обсягом описано в матеріалі як створити MVP за 7 кроків. Якщо ви ще сумніваєтеся, чи готова ідея до визначення обсягу, прочитайте 10 ознак готовності ідеї до розробки MVP.
Коли «це залежить» — чесна відповідь
Іноді «це залежить» справді є правильною відповіддю, адже точна цифра потребує визначеного обсягу. Мета цього посібника — не дати одну цифру для тиску на команду, а допомогти поставити правильні запитання, щоб отриманий термін ґрунтувався на вашому продукті, а не на загальному середньому.
Отримайте термін, заснований на вашій ідеї, а не на середньому значенні
Обговоріть продукт із MVPHub і отримайте практичний поетапний термін, на який можна спиратися під час планування.
Забронювати безкоштовну консультацію з MVPHubЧасті Запитання
Яке перше запитання поставити для оцінки терміну MVP?
Почніть із кількості окремих користувацьких сценаріїв, які має підтримувати перший реліз. Один сценарій створити значно швидше, ніж кілька, навіть якщо окремі екрани здаються простими.
Чи може нетехнічний засновник оцінити це самостійно?
Приблизно — так, використовуючи розподіл за етапами в цьому посібнику. Точна оцінка все одно потребує думки того, хто створюватиме продукт, адже технічну складність не завжди видно ззовні.
Чи варто довіряти пропозиції з дуже коротким терміном?
Ставтеся обережно до надзвичайно коротких термінів, якщо обсяг справді не мінімальний. Обіцянка, що не враховує тестування або discovery, швидше за все призведе до затримки.
