Діапазон і чому він такий широкий
Діапазон широкий, бо "MVP" описує філософію, а не фіксований обсяг робіт — одну й ту саму ідею можна перевірити п'ятиекранним застосунком або переускладнити до чогось, що виглядає як повноцінний продукт, ще до того, як хоча б один клієнт підтвердив, що йому це потрібно. Різниця у вартості між цими двома підходами — це і є вся розмова про бюджет.
Що насправді визначає ціну
- Кількість ключових воркфлоу. Кожна додаткова "ключова" дія, яку може виконати користувач, приблизно множить обсяг робіт — не додає, а саме множить, бо кожен воркфлоу потребує власних крайніх випадків, станів помилок і тестування.
- Чи потрібно працювати з грошима. Платежі, підписки або виплати додають вимоги комплаєнсу, крайні випадки (невдалі платежі, повернення коштів, спірні транзакції) і рівень тестування, які не потрібні MVP без цього функціоналу.
- Двостороння модель проти односторонньої. Маркетплейс чи платформа потребують побудови й тестування обох сторін воркфлоу — пропозиції та попиту, — що приблизно подвоює обсяг роботи порівняно з продуктом з одним типом користувачів.
- Адмінка та внутрішні інструменти. Засновники часто забувають закласти в бюджет внутрішню панель, яка дозволяє *їм самим* бачити, що відбувається, — інструменти підтримки, базову аналітику, модерацію контенту, — аж поки не минає три тижні після запуску, а відповісти на тикет підтримки нема як.
- Кількість платформ. Лише веб — найдешевший стартовий варіант. Нативні iOS та Android поряд із вебом приблизно потроюють поверхню, яку потрібно підтримувати, навіть якщо крос-платформні фреймворки частково це компенсують.
Пастка, через яку зривається більшість бюджетів на MVP
Це рідко одне погане рішення — це серія окремо цілком розумних рішень. "Раз уже ми будуємо флоу реєстрації, додаймо ще й соціальний логін." "Раз уже ми будуємо дашборд, додаймо сторінку налаштувань, яку поки що ніхто не просив." Кожне доповнення саме по собі здається незначним, а в сумі непомітно перетворюється на інший, більший проєкт, ніж той, що був оцінений і узгоджений.
Перш ніж додавати щось до обсягу MVP, запитайте: "чи дізнаємось ми від реальних користувачів щось нове, якщо запустимо продукт без цього?" Якщо чесна відповідь — ні, це не функція MVP, а функція другої версії, замаскована під MVP, і їй місце у списку на потім, коли з'являться реальні користувачі, у яких можна вчитися.
Фіксована ціна проти погодинної оплати (Time & Materials) — конкретно для MVP
| Фіксована ціна | Time & Materials | |
|---|---|---|
| Найкраще підходить, коли | Обсяг робіт справді зафіксований і добре зрозумілий заздалегідь | Ви очікуєте, що обсяг робіт буде змінюватися в міру навчання — а це стосується більшості реальних MVP |
| Ризик | Будь-яка зміна обсягу стає запитом на зміну — тертя саме тоді, коли ви вчитеся найшвидше | Потребує довіри до оцінок команди та чесної звітності |
| Відповідність для MVP | Працює для вузького, чітко визначеного шматка функціоналу | Зазвичай підходить краще — MVP існують для навчання, а фіксація обсягу суперечить цій меті |
Більшість досвідчених команд скажуть одне й те саме: для справжнього MVP — де вся суть у тому, щоб дізнатися те, чого ви ще не знаєте, — погодинна оплата (Time & Materials) з жорстким лімітом бюджету та щотижневою прозорістю щодо того, що постачається, зазвичай служить засновникам краще, ніж контракт із фіксованою ціною, який штрафує саме за той тип коригування обсягу робіт, заради якого й існує MVP.
Реалістичний приклад обсягу робіт
| Входить | Свідомо виключено (список для v2) |
|---|---|
| Автентифікація, один ключовий воркфлоу користувача від початку до кінця, базовий адмін-перегляд, платежі (якщо продукт має приносити дохід із першого дня) | Соціальний логін, розширені аналітичні дашборди, нативні мобільні застосунки, внутрішні інструменти понад мінімально необхідне, будь-що "було б непогано мати", що не перевіряє ключову гіпотезу |
Хочете реальну цифру для своєї ідеї?
Розкажіть нам про ключовий воркфлоу, і ми дамо чесну оцінку обсягу робіт та вартості — включно з тим, що варто прибрати.
Поширені запитання
Чи варто будувати MVP самотужки, щоб заощадити?
Якщо хтось із засновників справді може швидко це запустити — так, адже швидкість до реального тестування користувачами і є головною метою. Компроміс — це альтернативні витрати: час, витрачений на розробку, — це час, не витрачений на спілкування з клієнтами, а це зазвичай дефіцитніший ресурс до появи доходу.
Скільки часу займає типовий MVP?
Вузький MVP з одним воркфлоу зазвичай займає 6–10 тижнів. Додавання платежів, другого типу користувачів або нативного мобільного застосунку подовжує цей термін — як орієнтир, кожне суттєве доповнення зі списку факторів вартості вище додає реальні тижні, а не дні.
Що відбувається після того, як MVP підтвердив ідею?
В ідеалі значна частина списку для v2 переосмислюється на основі того, що реальні користувачі справді попросили, — а це зазвичай відрізняється від здогадок команди засновників до запуску. Це і є справжня віддача від того, щоб від самого початку тримати MVP вузьким.
Чи є no-code MVP законним варіантом?
Для перевірки попиту ще до написання будь-якого коду — лендинг, ручна або "консьєрж"-версія сервісу — безумовно, і часто це правильний перший крок. Реальні обмеження зазвичай виникають, коли ключовий воркфлоу потребує кастомної логіки або має масштабуватися за межі жменьки користувачів.