Комментарии 4
Спасибо за статью
Ещё было бы интересным порассуждать на тему MVP vs «первая версия».
Очень часто всё первое называют MVP, даже если заранее известно точно, что и почему нужно.
Например, в производственной цепочке участвует простой сторонний сервис, и после определённой стадии роста основного продукта становится выгодным заменить его на внутреннее решение, и избавиться от внешней зависимости.
Естественно, у бизнеса сразу чешутся руки добавить туда с ходу кучу «очень нужных нам фич». Но в качестве первого шага достаточно просто сделать drop-in-replacement.
Но ведь это не MVP? :)
Ещё было бы интересным порассуждать на тему MVP vs «первая версия».
Очень часто всё первое называют MVP, даже если заранее известно точно, что и почему нужно.
Например, в производственной цепочке участвует простой сторонний сервис, и после определённой стадии роста основного продукта становится выгодным заменить его на внутреннее решение, и избавиться от внешней зависимости.
Естественно, у бизнеса сразу чешутся руки добавить туда с ходу кучу «очень нужных нам фич». Но в качестве первого шага достаточно просто сделать drop-in-replacement.
Но ведь это не MVP? :)
Естественно, у бизнеса сразу чешутся руки добавить туда с ходу кучу «очень нужных нам фич»
Но ведь это не MVP? :)
Если речь о том, что "сразу много фич", то это по определению не minimal, да)
Мой акцент был не на этом.
Скорее, на том, что не всякая «первая версия» автоматически является MVP в смысле служения делу проверки гипотез. Иногда бизнес точно знает, что нужно, и «заказчик» гарантированно уже есть.
Скорее, на том, что не всякая «первая версия» автоматически является MVP в смысле служения делу проверки гипотез. Иногда бизнес точно знает, что нужно, и «заказчик» гарантированно уже есть.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как запустить MVP и не превратить его в технический долг