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

Однако для меня применимость MVP здесь даже не под сомнением. MVP - это технически отлично проработанное решение, которое тем не менее закрывает ключевую потребность клиента в самом базовом виде. В решении нет технических изьянов и брака. Мы не доделываем MVP, который был продан клиенту! Если продукт не устраивает клиента настолько, что он его не покупает, то это тоже результат. В любом случае (купил, или не купил - одинаково важный результат), мы учитываем все замечания для того, чтобы улучшить следующую версию продукта, а не для того, чтобы при нём же сразу что-то докрутить, а иначе это просто непрофессионально. Не забывайте, что MVP - это результат эксперимента в безопасных условиях, в массовом производстве такие эксперименты недопустимы. Они должны делаться в разработке.

Основа непонимания концепции MVP, на мой взгляд, заключается в смешении понятий разработка и производство. Уверен, что многие до сих пор считают разработку процессом производства продукта. Однако, где на самом деле происходит производство? Шрирам Нараян в книге "Agile IT organization design" даёт очень любопытный инсайт. Задумайтесь, почему IT-инфраструктура, где работают клиенты, называется продакшн, или по-простому "прод"? Ведь на самом деле производство находится под капотом нагруженного клиентами сервера, а не в конвейере разработки модулей и компонентов. Продукт - это не софт. Продукт - это UX (опыт пользователя), результаты работы софта на проде.

Назначение MVP - проверить гипотезы, лежащие в основе нового бизнеса. Если перенести это на несофтверную разработку, то MVP - это ручное (неавтоматизированное) штучное производство буквально нескольких экземпляров продукции. Основной метод проверки - получения фидбэка от клиента в реальных полевых условиях эксплуатации MVP. Клиент его покупает, и действительно с ним работает. Все неудобства, недочёты, инсайты связаны не с технической составляющей MVP, а с его возможностями: они реализованы настолько минимальными усилиями, чтобы как можно быстрее взять обратную связь. Да, это нерентабельно - выручка навряд ли покроет затраты. Но цель здесь не в рентабельности, а в снижении рисков бизнеса в условиях неопределённости (cynefin complex domain). Да, не каждый клиент согласится купить такое, однако на рынке всегда есть до 16% таких клиентов, вопрос лишь только в том, как определить, чем они отличаются от остальных 84%