MVP за місяць: що реально встигнути

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

Нижче розбір того, що реально встигнути за чотири тижні, що свідомо відкласти, план по тижнях і те, як зрозуміти, чи MVP спрацював.

Почніть з гіпотези

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

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

Чотири формати MVP, від найпростішого

Перш ніж замовляти розробку, подивіться, чи вашу гіпотезу можна перевірити дешевшим форматом.

Лендинг з формою. Сторінка описує продукт і пропонує залишити заявку або передзамовлення. Перевіряє, чи цікава пропозиція, за кілька днів. Продукт за формою поки що виконується вручну.

Ручний сервіс під виглядом продукту. Клієнт бачить форму або бота, а результат готує людина. Перевіряє, чи цінний результат, до того як витрачати гроші на автоматизацію.

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

Робочий веб-застосунок з одним сценарієм. Справжній продукт з мінімумом функцій. Перевіряє, чи будуть люди ним користуватися регулярно і чи готові платити. Саме про цей формат іде мова в плані на місяць нижче.

Часто розумно пройти два формати поспіль: лендинг або ручний сервіс за тиждень, потім робочий застосунок за місяць, коли перший формат показав інтерес.

Що реально зробити за місяць

За чотири тижні командою з дизайнера, одного-двох розробників і тестувальника реально зробити:

• Один основний сценарій від входу до результату. Наприклад: реєстрація, створення замовлення, отримання підтвердження.
• Одну-дві ролі. Користувач і адміністратор, або клієнт і менеджер.
• Адаптивний веб-застосунок, що працює на телефоні і компʼютері.
• Одну-дві інтеграції з документованим API: оплата, CRM, пошта, месенджер.
• Базову аналітику: події основного сценарію, щоб бачити, де люди зупиняються.
• Тестування основного сценарію і запуск на обмеженому колі перших користувачів.

Що зазвичай виходить за місяць

• Кілька ролей зі складними правами (клієнт, менеджер, керівник, бухгалтер, партнер).
• Нативні мобільні застосунки для двох платформ з публікацією в сторах.
• Глибока інтеграція з обліковою системою з двостороннім обміном.
• Складні розрахунки з багатьма правилами і винятками.
• Повноцінна адмінка з ролями і журналом дій.
• Кілька мов і ринків.

Ці речі нормальні для продукту, але для MVP їх варто замінити простішими рішеннями або відкласти.

Чим замінити те, що не вміщується

Адмінку замінює таблиця або пряма робота з базою. Перші тижні дані може правити команда проєкту або ваш співробітник через простий інструмент.

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

Мобільний застосунок замінює адаптивний веб. Посилання відкривається на будь-якому телефоні, оновлення не проходять модерацію сторів.

Інтеграцію з обліком замінює вивантаження. Раз на день менеджер завантажує файл з залишками, а замовлення вивантажуються в облік файлом.

Рідкісні сценарії обробляє людина. Повернення, спірні ситуації, нестандартні запити передаються на пошту або в месенджер відповідальному.

План по тижнях

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

Що потрібно від вас

• Одна людина з правом рішення, яка відповідає на питання в той самий або наступний день.
• Доступи до систем для інтеграцій на першому тижні.
• Перші користувачі, готові спробувати продукт на четвертому тижні: клієнти, партнери, колеги.
• Матеріали у будь-якому вигляді: схеми, таблиці, приклади документів, голосові. Ми самі нормалізуємо.

Як міряти результат

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

Після запуску дивіться і на те, де люди зупиняються. Аналітика основного сценарію показує крок, на якому губиться більшість, і це найцінніша підказка для наступної ітерації.

Де взяти перших користувачів

Перші користувачі MVP це люди, які вже відчувають проблему, яку ви вирішуєте. Для B2B це ваші клієнти, партнери або компанії, з якими ви вже говорили про задачу. Для внутрішнього продукту це колеги з відділу, чию роботу він змінює. Для нового споживчого продукту це спільноти, де обговорюють проблему, і список очікування з лендингу.

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

MVP з ШІ

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

Через що місячний строк зривається

Рішення по прототипу чекають тиждень. Кожен день очікування на першому тижні зсуває запуск на день, а зміна сценарію на третьому тижні коштує кілька днів роботи.

Занадто широка гіпотеза. «Перевірити, чи потрібен ринку наш продукт» не дає зрозуміти, яку дію міряти. Звужуйте до конкретної дії конкретних людей.

Полірування до запуску. Кожен тиждень полірування відкладає момент, коли ви дізнаєтесь, чи продукт взагалі потрібен.

Запуск без перших користувачів. Готовий MVP без людей, які його спробують, нічого не перевіряє. Домовтеся з першими користувачами до старту розробки.

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

Що буде після місяця

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

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

Модель оплати для MVP

MVP добре лягає на фіксацію ціни етапу: перший тиждень (сценарій і прототип) як окремий етап, після нього ціна решти фіксується на основі затвердженого прототипу. Детальніше у статті фікс-прайс чи погодинна оплата.

Наступний крок

Опишіть гіпотезу і дію, яка її підтвердить, у формі заявки. Оцінка після брифу займає робочий день і приходить таблицею по блоках, з позначкою, що вміщується в місяць, а що краще відкласти. Формат робіт описаний на сторінках розробка MVP, розробка веб-застосунків і UI/UX дизайн.