Что реально можно построить как MVP за 2 недели
Две недели звучат коротко для ПО, и это так — но этого достаточно времени, чтобы протестировать реальную, конкретную гипотезу, если объём работ честно соответствует срокам.
Первый вопрос: что конкретно вы тестируете?
MVP, построенный за 2 недели, нуждается в одной ясной задаче: протестировать конкретное предположение. «Будут ли люди реально использовать этот рабочий процесс» тестируемо за 2 недели. «Построить всё видение продукта» — нет — это разные цели, требующие разных сроков, и их смешение — самый частый способ провала MVP за 2 недели.
Что реалистично вписывается в 2 недели
- Один основной рабочий процесс от начала до конца — не каждая функция, один полный путь, по которому пользователь реально может пройти.
- Минимальная или поддельная аутентификация, если реальные многопользовательские аккаунты не тестируются — единственный захардкоженный тестовый логин часто достаточен.
- Реальный (пусть минимальный) слой данных, если сама логика бэкенда — то, что неопределённо — подделка данных здесь означала бы не тестирование рискованной части на самом деле.
- Намеренно неотполированный UI — функциональный, не красивый. Полировка — инвестиция более позднего этапа, как только основная идея валидирована.
Что не вписывается и не должно предприниматься
- Полное управление аккаунтами (сброс пароля, верификация email, несколько провайдеров аутентификации), если это конкретно не то, что тестируется.
- Всеобъемлющая обработка ошибок для граничных случаев за пределами основного счастливого пути.
- Админ-панели, дашборды отчётности или что-либо, поддерживающее продукт, а не являющееся основным тестом продукта.
- Продакшн-уровень усиления безопасности за пределами базовых ответственных практик — это важно перед реальным запуском, а не перед внутренним или ограниченным тестом на 2 недели.
Разумная форма 2 недель
| Дни | Фокус |
|---|---|
| 1-2 | Основная модель данных и минимальная настройка |
| 3-8 | Один основной рабочий процесс, построенный от начала до конца |
| 9-11 | Тестирование рабочего процесса самостоятельно, исправление того, что явно сломано |
| 12-14 | Небольшой реальный плейтест/пользовательский тест, и реакция на то, что вы узнали |
Почему срезание объёма работ, а не срезание углов, — реальный навык
«Срезание углов» (пропуск обработки ошибок на реальном основном пути, игнорирование явного бага) производит нечто, выглядящее готовым, но недостаточно надёжное даже для теста. «Срезание объёма работ» (вообще не строить систему аккаунтов, подделывать второстепенные функции) производит нечто более узкое, но честное о том, что это такое. Второе — реальный навык, требуемый MVP за 2 недели.
Что происходит после 2 недель
Задача MVP за 2 недели заканчивается реальным ответом на вопрос, ради которого он был построен для тестирования — не запуском. Что происходит дальше (правильное построение или остановка из-за провала теста) — отдельное решение, основанное на том, что вы узнали, а не продолжением того же темпа спринта на 2 недели.
Есть идея, которую вы хотите протестировать с реально определённой по объёму сборкой на 2 недели, а не открытой? Свяжитесь со мной.
Частые вопросы
Что чаще всего срывает сроки MVP за 2 недели?
Объём работ, растущий в середине сборки, а не недооценка изначального списка — MVP за 2 недели, честно определённый по объёму и оставленный в покое, вполне достижим; тот же объём с ежедневно накапливающимися дополнениями «раз уж мы здесь» редко переживает дедлайн.
Должен ли MVP включать учётные записи пользователей и аутентификацию?
Только если основная тестируемая вещь реально их требует — если цель — валидировать основной рабочий процесс, единственный захардкоженный тестовый аккаунт часто достаточен на две недели, с реальной многопользовательской аутентификацией, отложенной до валидации концепции.
Стоит ли строить реальный бэкенд для MVP за 2 недели, или подделывать данные?
Зависит от того, что тестируется — если сама логика бэкенда является рискованной, неопределённой частью, стройте реальный (пусть минимальный). Если цель — тестирование UI/UX или концепции рабочего процесса, поддельный или захардкоженный слой данных может быть законным и более быстрым, пока вы честны насчёт того, что он не готов к продакшну.