Как стать автором
Обновить

Как запустить MVP и не превратить его в технический долг

Время на прочтение 12 мин
Количество просмотров 9.5K
Всего голосов 20: ↑20 и ↓0 +20
Комментарии 4

Комментарии 4

Спасибо за статью

Ещё было бы интересным порассуждать на тему MVP vs «первая версия».

Очень часто всё первое называют MVP, даже если заранее известно точно, что и почему нужно.

Например, в производственной цепочке участвует простой сторонний сервис, и после определённой стадии роста основного продукта становится выгодным заменить его на внутреннее решение, и избавиться от внешней зависимости.

Естественно, у бизнеса сразу чешутся руки добавить туда с ходу кучу «очень нужных нам фич». Но в качестве первого шага достаточно просто сделать drop-in-replacement.
Но ведь это не MVP? :)
Естественно, у бизнеса сразу чешутся руки добавить туда с ходу кучу «очень нужных нам фич»
Но ведь это не MVP? :)

Если речь о том, что "сразу много фич", то это по определению не minimal, да)

Мой акцент был не на этом.

Скорее, на том, что не всякая «первая версия» автоматически является MVP в смысле служения делу проверки гипотез. Иногда бизнес точно знает, что нужно, и «заказчик» гарантированно уже есть.

А, ну да, но даже в этом случае я предпочитаю как можно раньше выкатывать в прод и дальше уже наращивать функциональность. С современными CI/CD, Devops, облаками, докерами хоть каждый день релизь. Знай настрой всю автоматизацию.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий