Этот термин уже давно звучит из каждого утюга имеющего отношение к продуктовой разработке. Ведь как гласит продуктовая мантра – экономь ресурсы, проверяй гипотезы быстро, с минимальными затратами. И тут на выручку приходит очевидное решение – запилить по-быстрому MVP, показать его пользователям и подтвердить или опровергнуть выдвинутую гипотезу о потребностях пользователей. Но у меня есть четкая уверенность, что в большинстве случаев люди прикрывают этим термином сырость своей разработки или неактуальность продукта.
Сама идея MVP звучит действительно здраво. И возможно в разработке крутых b2c продуктов всё так и работает. Хотя если честно, я не могу припомнить ни одного действительно масштабного примера кроме тех, о ком речь пойдет в последнем абзаце. Но если такие кейсы за последние годы действительно есть, то вэлком в комментарии. При этом помню массу примеров неудачных стартов, пивотов, смены курса продукта, его трансформации, и даже распила бюджетов и т.д.
Да и я тут больше про разработку b2b продуктов вещаю. Возможно у меня проф деформация, но похоже в этом царстве интерпрайз-разработки реальность немного другая. Как ни странно, но тут не работают классические примеры от Сазерленда, где клиент хочет автомобиль, а ты ему сначала делаешь велосипед удовлетворяя его потребность в перемещении по пространству и потом итерационно тюнингуешь его до нужного состояния.
Представьте себе намеренно утрированную ситуацию: ты продакт на новом продукте. Стадия разработки, что называется «нулевая». Еще даже нет даже четкого понимания как именно он будет работать, но есть видимая потребность клиентов в нем, и есть бюджет и волевое решение руководства пилить этот продукт сначала для внутреннего использования, а потом и для его дальнейшей продажи. Предположим, это ERP-система. И ты даже четко понимаешь её ценность для клиента. И твоя задача как амбициозного продакта, это сделать настолько крутой продукт, чтобы его юзали в TOP-100 компаний в стране.
А теперь давай представим, как будет строиться диалог с потенциальным клиентом. Пускай это даже внутренний клиент. Ты говоришь «мы сначала сделаем для вас MVP с двумя-тремя основными сценариями, а потом будем наращивать функционал». С какой вероятностью встреча на этом закончится не в вашу пользу? Невозможно сразу зайти на рынок с продуктом драматично уступающим по функционалу условному 1С или SAP. Никто в здравом уме на такое не подпишется.
Ладно, отойдем немного от кейса и перейдем к личному опыту. Сколько раз вы слышали фразы типа «у нас пока нет это функционала, мы же сейчас на стадии MVP» или «вот найдем инвестора и запилим весь функционал, а пока это только MVP», ну коронная - «сейчас все работает криво или вовсе не работает. Мы же еще на MVP»...
Что за этим стоит:
Люди путают (или намеренно подменяют понятия?) «прототип», «первый релиз» с «MVP». Когда мне говорят что команда сейчас запилит MVP, я всегда спрашиваю «какую именно боль клиента \ пользователя решает этот MVP?» Часто в ответ слышу что-то типа «ну у нас сроки разработки поджимают, а нам нужно хоть с чем-то раскатиться в прод, чтобы закрыть OKR \ KPI».
Люди прикрывают яркой вывеской «MVP» явные недоработки своего продукта. Реальный кейс: огромная компания – банк входящий в TOP-3, в нем сотни продуктовых команд пилят неимоверное количество фичей. При этом есть простроены отличные производственные процессы, налажено планирование на год вперед и тд. Но из раза в раз в прод выходят очевидно недоработанные фичи типа возможности посмотреть в приложении данные своей карты (номер счета, CVV-код и тд), но при этом пользователь не может скопировать или даже просто посмотреть номер своей карты. Поправили это спустя несколько месяцев. И все это время на вопросы «почему так?» был ответ – «потому что MVP»
Почему так происходит? Опять же, это сугубо мое мнение, но в большинстве случаев продакту в больших компаниях так проще "продать" результаты своей работы руководству и браво отчитаться на очередном подведении итогов квартала \ года. Что мол это не его продукт не решает проблему пользователя и не перформит, а просто рано еще делать выводы. Сейчас ведь только MVP...
Вторая причина в том, что сейчас пользователь настолько избалован действительно качественными продуктами, что ему незачем пользоваться чем-то сырым и недоделанным. Похоже сам термин MVP потихоньку теряет актуальность. Исключение - сферы, которые только-только проникают в нашу потребительскую жизнь. Как Midjorney ему подобные.
Что, на мой взгляд, поможет в ситуации? Как всегда нужно начать с себя и начать называть вещи своими именами. Пусть это будет моим пожеланием на новый год - чтобы люди перестали подменять понятия и честно говорили - мы пока не готовы выкатить полноценный функционал, поэтому вот вам юзабельная бета хорошего качества :)
Для обсуждения добро пожаловать на мой канал в Tg :)
Комментарии (14)
MonkAlex
01.01.2023 20:46+1Люди прикрывают яркой вывеской «MVP» явные недоработки своего продукта. Реальный кейс: огромная компания – банк входящий в TOP-3, в нем сотни продуктовых команд пилят неимоверное количество фичей. При этом есть простроены отличные производственные процессы, налажено планирование на год вперед и тд. Но из раза в раз в прод выходят очевидно недоработанные фичи типа возможности посмотреть в приложении данные своей карты (номер счета, CVV-код и тд), но при этом пользователь не может скопировать или даже просто посмотреть номер своей карты. Поправили это спустя несколько месяцев. И все это время на вопросы «почему так?» был ответ – «потому что MVP»
А с этим то что не так? Боль пользователя - посмотреть данные о карте. Боль решили.
То, что кому то хотелось бы удобств (скопировать код\данные) не проработали и не сделали сразу. Но, собрали статистику (например, данные смотрят часто) и оценили проблемы на разных продуктах (на части карт например данные не те, потому что в своё время...).
Выглядит именно как MVP.
APervukhin Автор
01.01.2023 21:25Тут ключевое было в том, что пользователь не мог посмотреть в приложении номер карты. Если бы не мог только скопировать, то это ещё полбеды)
Ведь в большинстве случаев пользователь как раз и шел на этот экран в поисках номера карты, чтобы скопировать его для использования в платежах на сторонних сайтах. А тут этот сценарий был заблокирован.
MonkAlex
01.01.2023 21:46+2Возможно, не во всех сценариях? Или вы участник процесса и уверены, что не было таких возможностей ни у кого из клиентов?
Я к тому, что непонятно - какие задачи решали, какие проблемы возникали. Для части сценариев эта ситуация - прямо типичный MVP.
APervukhin Автор
01.01.2023 21:54Конкретно в этом случае это касалось всех клиентов в приложении. Об этом говорил и мой пользовательский опыт, и отзывы со сторов, и внутренняя информация.
Безусловно, могли быть и проблемы в ходе разработки. Например интеграционные или блок от ИБ. Но прикрывать их завесой MVP, на мой взгляд, не очень правильно.
MonkAlex
01.01.2023 22:05+1Судить как пользователь в этой ситуации - бессмысленно.
Окей, предположим номер действительно был недоступен. Как разработчик, я вижу этому приличный набор причин и все они допустимы в MVP:
-
Отдел безопасности запретил показывать полный набор данных, достаточных для оплаты. Согласование затянулось. В релиз пошли как есть, номер карты открыли после согласования.
MVP тут может служить показателем для бизнеса - вот, клиенты пользуются, они заметили новую фичу с отображением данных, но им недостаточно того, что разрешили безопасники. И бизнес договаривается с безопасниками как раз по результатам MVP.
-
Было разделение по продуктам. На части продуктов номер был виден (например на виртуальных карточках), на части - нет. Те кто жаловались - пользовались продуктами с недоступным отображением.
MVP показал, что клиентам нужны полные данные, жалобы вызвали необходимый результат - доработку с отображением номера на всех продуктах.
Это могло быть результатом неудачной раскатки на пользователей, не помню терминологии нормальной. Фичу сделали, открывали медленно, на часть пользователей. Смотрели, как реагируют, как пользуются, не появляются ли новые сценарии мошенничества. Звучит сомнительно с одной стороны, с другой - почему нет?
MVP же про быструю обратную связь. Быстро сделать что-то, что даст вам не просто идею, а даст и данные от клиентов\заказчиков и отзывы и что ещё важнее - реальное использование. Заказчик в разных форматах может озвучивать "мне надо А", а делать на самом деле он может совсем даже вариант "Б". И это тоже очень ярко видно, когда вы запускаете MVP и начинаете смотреть на то, как вашим продуктом\фичей пользуются.
-
AntonLazovskiy
01.01.2023 23:49+1Тут не соглашусь, МВП должен решать ПРОБЛЕМУ для пользователя, тут на лицо просто не проработали и не поняли конечную "работу" у пользователя, то есть наврятли пользователь просто хочет посмотреть 16 рандомных цифр, скорее всего он их "смотрит" во время выполнения работы "заполнить данные карты" в e-commerce, то есть МВП бы тут заключался именно в том, чтобы помочь пользователю скопировать номер/дату/cvv карты, а не просто посмотреть.
MonkAlex
02.01.2023 00:21Я честно не до конца понимаю, какой сценарий закрывали. У банка явно были свои сценарии, раз без номера карты было сделано и открыто на пользователей.
Как пользователь, я ввожу данные с пластика, мне копировать неактуально. Как "идеальный сценарий" я в целом не хочу думать про ввод каких то данных, я хочу кнопку "купить" и всё.
И в этом плане - хз что и зачем делали. А когда хз что и зачем делали - сложно сказать, сделали что хотели или нет. Я допускаю, что сделано было ровно то, что хотели. Но, вполне вероятно, что пользовательские сценарии оказались намного шире, чем то что себе там напридумывал бизнес =)
UPD: два сценария придумал, где номер карты не важен, но данные карты всё ещё полезны. Первый - посмотреть, до какого там числа карта действует. Пластика под рукой нет, а в мобильном приложении быстро глянуть можно. Актуально, когда например в отпуск собираешься и карта где-то там в период отпуска может закончиться. Или когда думаешь поменять карту, из разряда "ну у этой срок истечёт, попробую другую". Не лучшие сценарии, но вполне живые, мелкие и удобные. Второй - CVC код только в приложении по подтверждению смс-кой, а на карте код стёрт или затёрт, как "защита" от кражи данных. Хороший сценарий для параноиков, я местами такое одобряю как человек который не особо следит за данными своих карт.
slavanikolsky
01.01.2023 23:07-1Разрабатываем ЦРМ, она решает основные задачи наших клиентов, но нет мобильных приложений, что не позволяет назвать нашу ЦРМ полноценным продуктом. Но она не MVP и такой не будет.
Продукт должен решать задачи.
MVP же про быструю обратную связь. Быстро сделать что-то, что даст вам не просто идею, а даст и данные от клиентов\заказчиков и отзывы и что ещё важнее - реальное использование.
Не даст. Так не работает.
Любое внедрение зависит от влиятеля, который контролирует внедрение. Если продукт неоконченный, влиятель выдает резюме: доделаете вот тогда и посмотрим.
MonkAlex
02.01.2023 00:26+2Это видимо мне, цитата моя.
Дает и работает, если вы работаете в b2c. Потому что каждый конкретный потребитель не знает, что ему надо, и более того, хотелки отдельных потребителей - неважны. А как себя оно поведёт на массе потребителей - это и есть вопрос к MVP. Выкатываете, смотрите на реакцию (да, важно продумать как собирать реакции\статистики\любые нужные цифры) и решаете что делать дальше - дорабатывать, переделывать, выкидывать, оставить как есть.
Вот с b2b я сталкиваюсь реже. И даже там этим можно пользоваться, но больше на вторичных вещах - выкатить с пометкой "экспериментальное", выдать тем кому оно может пригодиться, собрать отзывы. И как и выше - решать, выкидывать, дорабатывать или оставить как есть.
Возможно, я неправильно понимаю, что вы подразумеваете под "внедрением". Если это какой то большой бюрократический процесс, то да, MVP только усложнит вам жизнь и сожрёт ресурсы, вместо принесения быстрых ответов на вопросы.
akakoychenko
01.01.2023 23:53+5Ты говоришь «мы сначала сделаем для вас MVP с двумя-тремя основными сценариями, а потом будем наращивать функционал». С какой вероятностью встреча на этом закончится не в вашу пользу? Невозможно сразу зайти на рынок с продуктом драматично уступающим по функционалу условному 1С или SAP
Так а зачем идти на голиафов в лоб? Если предполагается, что продукт в стадии зрелости будет +-, как инсталляция 1С для конкретной индустрии, то и начинать не стоит, ибо, даже, если все звезды сложатся, то 1С еще пройдет вперед к тому времени, и так до бесконечности. Да и win-win c внутренним заказчиком не существует тоже. Ибо, либо одеяло перетягивает заказчик, и тогда код наполняется горой хардкода, завязанного на интерфейсы, бизнес-процессы, вендоров заказчика, и, в какой-то момент оказывается, что В2В потенциал выветрился, как идея (хотя, для внутреннего заказчика может выйти решение и неплохим, ведь, оно идеально кастомизированно, хотя, фактически, по затратам оно может выйти дороже любой коробки). Либо перетягивает одеяло продакт, и таки удерживает курс на В2В, и тогда операционка страдает, и, сцепив зубы от ненависти, решает свои задачи эксель макросами, ручной работой, и так далее (ведь, их потребности сбриваются в угоду платформизации и дополнительных слоев абстракции). К слову, вариант может выстрелить при околонулевой вероятности, что продакт гениальный визионер, и сможет таки дотолкать продукт до пригодного для сейлзов состояния.
Но можно же идти и не в лоб, и тогда пазл складывается. Каноническим примером является складской софт Амазона, который бросил вызов ряду фундаментальных принципов работы всего складского В2В софта на тот момент, которые в принципе не позволяли эффективно построить робастные процессы доставки ранородного товара большому количеству мелких покупателей. То есть, в их случае, глючный и неудобный MVP сразу же превосходил проверенный временем складской софт потому, что позволял решить несколько принципиальных проблем, которые считались нерешаемыми до этого.
Или, сфера, близкая мне лично, - антифрод решения. На рынке есть множество вендоров антифрод софта для онлайн бизнеса, и все они представляют практически тоже самое, - конструктор правил с аггрегациями, как правило, выросший из решения по противодействию чарджбекам, и расширивший домен до прозивольных транзакций, а не только фактов оплаты. Но, если взять конкретный онлайн бизнес, посмотреть в суть транзакций, понять логику фродеров, то, как правило, выходит, что за неделю-месяц можно написать MVP, который отловит конкретный паттерн фрода, неуязвимый для любого В2В антифрод решения на рынке. Да, скорее всего, это решение будет неподходящее для перепродажи кому-то еще, и да, оно будет бить по одной категории фродеров, но это будет то, что реально нужно здесь и сейчас, и, возможно, когда-то выйдет продавать, как нишевое решение, которое, в отличии от универсальных конструкторов правил, будет эффективно закрывать потребности своей ниши бизнеса
funca
02.01.2023 00:42+2По-моему, MVP это бизнесовый термин. Это условная точка в роадмапе продукта, когда он начинает приносить вам какую-то минимальную пользу. Понятие пользы зависит от контекста. У кого-то цель впечатлить инвестора, у кого-то - угодить пользователю, кому-то важно закрыть очередной этап по гранту и т.п.
PoC (рабочий прототип) это технический термин. По сути, этап разработки, когда вы начинаете понимать, что в принципе способны решить задачу. Любая фича явно или неявно проходит через эту стадию. Все может начаться и закончиться на машинке разработчика с первым позеленевшим юнит тестом, а может выходить наружу, чтобы проверить гипотезы на реальных пользователях.
Первое отвечает на вопрос какова цель, второе - что за задачу мы решаем. Проблемы качества, удовлетворенности пользователей, сбора обратной связи тоже важны. Но из-за этой разницы формулировки будут отличаться.
В некоторых случаях MVP может быть сделан чисто на бумаге, а PoC ни когда не увидеть реальных пользователей. В других если требуется как минимум SAP, 1С или Google, ваш MVP будет размером со звездолет, создав и угробив на своем пути сотни PoC.
ozzyBLR
03.01.2023 09:33В комменте про самый попсовый термин оставлю такой же попсовый коммент - надо быть гибче)
Действительно, ситуации бывают разные. На первый взгляд идти на давно устоявшийся рынок энтерпрайз приложений с MVP бессмысленно. Но обязательно ли сразу стучаться в двери приёмных топ-компаний? Нельзя ли обкатать MVP на игроках попроще? Ну, здорово, когда это возможно.
Соглашусь, что важной пользой от MVP является реальная обратная связь, возможность проведения полевых исследований. Если не на стадии MVP, то когда? Уже слышу шум водопада.
Последнее, что отмечу, это место MVP в роадмапе продукта. MVP не должен быть последней осязаемой точкой, не должно быть "сейчас запилим MVP, а дальше посмотрим". Если вы так делаете, то тогда это у вас действительно "перый сырой релиз".
PuerteMuerte
Ну как бы вопрос в терминологии. Суть MVP кроется в его названии - это какой-то куцый, малофункциональный, недоделанный, но тем не менее, жизнеспособный продукт. Нечто, решающее какую-то полезную задачу заказчика. Это вполне может быть юзабельная бета хорошего качества, лишь бы она что-то реально автоматизировала, пусть даже частично.
Если ваша штука в бизнесе заказчика (если уж мы говорим про би-ту-би) в текущем её состоянии не применима, а просто показывает, какие вы хорошие пацаны и что если вам дать денег, вы сделаете крутую софтину, которая будет выглядет вот как-то так, то это не MVP, это прототип.
APervukhin Автор
Таки да. Я больше про то, что вещи нужно называть своими именами)