MVP - это минимально работающая версия продукта, которая решает его ключевую задачу. По сути, это тестовый запуск товара, услуги или сервиса.

Однако за годы применения оно обросло искажениями. Бывает под «минимально жизнеспособным продуктом» часто понимают сырую, недоделанную версию, которую обещают доработать позже, что вызывает недовольство заказчика, подрывает его доверие.

Подмена понятий?

Есть один важный нюанс: MVP по определению нельзя масштабировать. Его задача показать направление. А иногда даже быстро протестировать с минимальными затратами, проверить гипотезу. Поэтому, когда гипотеза подтвердилась, наступает ответственный момент: нужно спланировать расширение.

И вот здесь появляется DoD (Definition of Done). По сути это чёткие договорённости между заказчиком и командой о том, что именно считается готовым на следующем этапе. Какие функции войдут. Как они будут работать. Как будем тестировать. Когда это считать, как «сделано». Без DoD есть риск скатиться в бесконечное «давайте ещё вот это возьмем» или, наоборот, в урезанный продукт без развития.

MVP даёт знание. DoD даёт план.

На этапе MVP не нужно прорабатывать все пользовательские пути и функционал. Достаточно наметить вектор, протестировать основные инструменты, получить обратную связь от целевой аудитории, а далее запланировать расширение.

Но важно понимать: MVP подходит не для всех ситуаций.

Например, в проектах миграции с Legacy на новую систему уже существует определённый набор функций, без которых миграция не будет бесшовной. Здесь можно протестировать концепт интерфейса через интерактивный макет с фокус-группой - это даст ценные инсайты. Но на стадии аналитики переносимых на новую систему процессов лучше сразу приступить к фиксации DoD, не пытаясь упаковать в MVP-эксперимент.

А у вас были на практике искажения понятий в диалоге с заказчиком?

#MVP #DoD #Agile #управлениепроектами #продуктоваяразработка #тестированиегипотез #ProductDevelopment #HypothesisTesting