Comments 16
Ну как бы вопрос в терминологии. Суть MVP кроется в его названии - это какой-то куцый, малофункциональный, недоделанный, но тем не менее, жизнеспособный продукт. Нечто, решающее какую-то полезную задачу заказчика. Это вполне может быть юзабельная бета хорошего качества, лишь бы она что-то реально автоматизировала, пусть даже частично.
Если ваша штука в бизнесе заказчика (если уж мы говорим про би-ту-би) в текущем её состоянии не применима, а просто показывает, какие вы хорошие пацаны и что если вам дать денег, вы сделаете крутую софтину, которая будет выглядет вот как-то так, то это не MVP, это прототип.
Люди прикрывают яркой вывеской «MVP» явные недоработки своего продукта. Реальный кейс: огромная компания – банк входящий в TOP-3, в нем сотни продуктовых команд пилят неимоверное количество фичей. При этом есть простроены отличные производственные процессы, налажено планирование на год вперед и тд. Но из раза в раз в прод выходят очевидно недоработанные фичи типа возможности посмотреть в приложении данные своей карты (номер счета, CVV-код и тд), но при этом пользователь не может скопировать или даже просто посмотреть номер своей карты. Поправили это спустя несколько месяцев. И все это время на вопросы «почему так?» был ответ – «потому что MVP»
А с этим то что не так? Боль пользователя - посмотреть данные о карте. Боль решили.
То, что кому то хотелось бы удобств (скопировать код\данные) не проработали и не сделали сразу. Но, собрали статистику (например, данные смотрят часто) и оценили проблемы на разных продуктах (на части карт например данные не те, потому что в своё время...).
Выглядит именно как MVP.
Тут ключевое было в том, что пользователь не мог посмотреть в приложении номер карты. Если бы не мог только скопировать, то это ещё полбеды)
Ведь в большинстве случаев пользователь как раз и шел на этот экран в поисках номера карты, чтобы скопировать его для использования в платежах на сторонних сайтах. А тут этот сценарий был заблокирован.
Возможно, не во всех сценариях? Или вы участник процесса и уверены, что не было таких возможностей ни у кого из клиентов?
Я к тому, что непонятно - какие задачи решали, какие проблемы возникали. Для части сценариев эта ситуация - прямо типичный MVP.
Конкретно в этом случае это касалось всех клиентов в приложении. Об этом говорил и мой пользовательский опыт, и отзывы со сторов, и внутренняя информация.
Безусловно, могли быть и проблемы в ходе разработки. Например интеграционные или блок от ИБ. Но прикрывать их завесой MVP, на мой взгляд, не очень правильно.
Судить как пользователь в этой ситуации - бессмысленно.
Окей, предположим номер действительно был недоступен. Как разработчик, я вижу этому приличный набор причин и все они допустимы в MVP:
Отдел безопасности запретил показывать полный набор данных, достаточных для оплаты. Согласование затянулось. В релиз пошли как есть, номер карты открыли после согласования.
MVP тут может служить показателем для бизнеса - вот, клиенты пользуются, они заметили новую фичу с отображением данных, но им недостаточно того, что разрешили безопасники. И бизнес договаривается с безопасниками как раз по результатам MVP.
Было разделение по продуктам. На части продуктов номер был виден (например на виртуальных карточках), на части - нет. Те кто жаловались - пользовались продуктами с недоступным отображением.
MVP показал, что клиентам нужны полные данные, жалобы вызвали необходимый результат - доработку с отображением номера на всех продуктах.
Это могло быть результатом неудачной раскатки на пользователей, не помню терминологии нормальной. Фичу сделали, открывали медленно, на часть пользователей. Смотрели, как реагируют, как пользуются, не появляются ли новые сценарии мошенничества. Звучит сомнительно с одной стороны, с другой - почему нет?
MVP же про быструю обратную связь. Быстро сделать что-то, что даст вам не просто идею, а даст и данные от клиентов\заказчиков и отзывы и что ещё важнее - реальное использование. Заказчик в разных форматах может озвучивать "мне надо А", а делать на самом деле он может совсем даже вариант "Б". И это тоже очень ярко видно, когда вы запускаете MVP и начинаете смотреть на то, как вашим продуктом\фичей пользуются.
Тут не соглашусь, МВП должен решать ПРОБЛЕМУ для пользователя, тут на лицо просто не проработали и не поняли конечную "работу" у пользователя, то есть наврятли пользователь просто хочет посмотреть 16 рандомных цифр, скорее всего он их "смотрит" во время выполнения работы "заполнить данные карты" в e-commerce, то есть МВП бы тут заключался именно в том, чтобы помочь пользователю скопировать номер/дату/cvv карты, а не просто посмотреть.
Я честно не до конца понимаю, какой сценарий закрывали. У банка явно были свои сценарии, раз без номера карты было сделано и открыто на пользователей.
Как пользователь, я ввожу данные с пластика, мне копировать неактуально. Как "идеальный сценарий" я в целом не хочу думать про ввод каких то данных, я хочу кнопку "купить" и всё.
И в этом плане - хз что и зачем делали. А когда хз что и зачем делали - сложно сказать, сделали что хотели или нет. Я допускаю, что сделано было ровно то, что хотели. Но, вполне вероятно, что пользовательские сценарии оказались намного шире, чем то что себе там напридумывал бизнес =)
UPD: два сценария придумал, где номер карты не важен, но данные карты всё ещё полезны. Первый - посмотреть, до какого там числа карта действует. Пластика под рукой нет, а в мобильном приложении быстро глянуть можно. Актуально, когда например в отпуск собираешься и карта где-то там в период отпуска может закончиться. Или когда думаешь поменять карту, из разряда "ну у этой срок истечёт, попробую другую". Не лучшие сценарии, но вполне живые, мелкие и удобные. Второй - CVC код только в приложении по подтверждению смс-кой, а на карте код стёрт или затёрт, как "защита" от кражи данных. Хороший сценарий для параноиков, я местами такое одобряю как человек который не особо следит за данными своих карт.
Разрабатываем ЦРМ, она решает основные задачи наших клиентов, но нет мобильных приложений, что не позволяет назвать нашу ЦРМ полноценным продуктом. Но она не MVP и такой не будет.
Продукт должен решать задачи.
MVP же про быструю обратную связь. Быстро сделать что-то, что даст вам не просто идею, а даст и данные от клиентов\заказчиков и отзывы и что ещё важнее - реальное использование.
Не даст. Так не работает.
Любое внедрение зависит от влиятеля, который контролирует внедрение. Если продукт неоконченный, влиятель выдает резюме: доделаете вот тогда и посмотрим.
Это видимо мне, цитата моя.
Дает и работает, если вы работаете в b2c. Потому что каждый конкретный потребитель не знает, что ему надо, и более того, хотелки отдельных потребителей - неважны. А как себя оно поведёт на массе потребителей - это и есть вопрос к MVP. Выкатываете, смотрите на реакцию (да, важно продумать как собирать реакции\статистики\любые нужные цифры) и решаете что делать дальше - дорабатывать, переделывать, выкидывать, оставить как есть.
Вот с b2b я сталкиваюсь реже. И даже там этим можно пользоваться, но больше на вторичных вещах - выкатить с пометкой "экспериментальное", выдать тем кому оно может пригодиться, собрать отзывы. И как и выше - решать, выкидывать, дорабатывать или оставить как есть.
Возможно, я неправильно понимаю, что вы подразумеваете под "внедрением". Если это какой то большой бюрократический процесс, то да, MVP только усложнит вам жизнь и сожрёт ресурсы, вместо принесения быстрых ответов на вопросы.
Ты говоришь «мы сначала сделаем для вас MVP с двумя-тремя основными сценариями, а потом будем наращивать функционал». С какой вероятностью встреча на этом закончится не в вашу пользу? Невозможно сразу зайти на рынок с продуктом драматично уступающим по функционалу условному 1С или SAP
Так а зачем идти на голиафов в лоб? Если предполагается, что продукт в стадии зрелости будет +-, как инсталляция 1С для конкретной индустрии, то и начинать не стоит, ибо, даже, если все звезды сложатся, то 1С еще пройдет вперед к тому времени, и так до бесконечности. Да и win-win c внутренним заказчиком не существует тоже. Ибо, либо одеяло перетягивает заказчик, и тогда код наполняется горой хардкода, завязанного на интерфейсы, бизнес-процессы, вендоров заказчика, и, в какой-то момент оказывается, что В2В потенциал выветрился, как идея (хотя, для внутреннего заказчика может выйти решение и неплохим, ведь, оно идеально кастомизированно, хотя, фактически, по затратам оно может выйти дороже любой коробки). Либо перетягивает одеяло продакт, и таки удерживает курс на В2В, и тогда операционка страдает, и, сцепив зубы от ненависти, решает свои задачи эксель макросами, ручной работой, и так далее (ведь, их потребности сбриваются в угоду платформизации и дополнительных слоев абстракции). К слову, вариант может выстрелить при околонулевой вероятности, что продакт гениальный визионер, и сможет таки дотолкать продукт до пригодного для сейлзов состояния.
Но можно же идти и не в лоб, и тогда пазл складывается. Каноническим примером является складской софт Амазона, который бросил вызов ряду фундаментальных принципов работы всего складского В2В софта на тот момент, которые в принципе не позволяли эффективно построить робастные процессы доставки ранородного товара большому количеству мелких покупателей. То есть, в их случае, глючный и неудобный MVP сразу же превосходил проверенный временем складской софт потому, что позволял решить несколько принципиальных проблем, которые считались нерешаемыми до этого.
Или, сфера, близкая мне лично, - антифрод решения. На рынке есть множество вендоров антифрод софта для онлайн бизнеса, и все они представляют практически тоже самое, - конструктор правил с аггрегациями, как правило, выросший из решения по противодействию чарджбекам, и расширивший домен до прозивольных транзакций, а не только фактов оплаты. Но, если взять конкретный онлайн бизнес, посмотреть в суть транзакций, понять логику фродеров, то, как правило, выходит, что за неделю-месяц можно написать MVP, который отловит конкретный паттерн фрода, неуязвимый для любого В2В антифрод решения на рынке. Да, скорее всего, это решение будет неподходящее для перепродажи кому-то еще, и да, оно будет бить по одной категории фродеров, но это будет то, что реально нужно здесь и сейчас, и, возможно, когда-то выйдет продавать, как нишевое решение, которое, в отличии от универсальных конструкторов правил, будет эффективно закрывать потребности своей ниши бизнеса
По-моему, MVP это бизнесовый термин. Это условная точка в роадмапе продукта, когда он начинает приносить вам какую-то минимальную пользу. Понятие пользы зависит от контекста. У кого-то цель впечатлить инвестора, у кого-то - угодить пользователю, кому-то важно закрыть очередной этап по гранту и т.п.
PoC (рабочий прототип) это технический термин. По сути, этап разработки, когда вы начинаете понимать, что в принципе способны решить задачу. Любая фича явно или неявно проходит через эту стадию. Все может начаться и закончиться на машинке разработчика с первым позеленевшим юнит тестом, а может выходить наружу, чтобы проверить гипотезы на реальных пользователях.
Первое отвечает на вопрос какова цель, второе - что за задачу мы решаем. Проблемы качества, удовлетворенности пользователей, сбора обратной связи тоже важны. Но из-за этой разницы формулировки будут отличаться.
В некоторых случаях MVP может быть сделан чисто на бумаге, а PoC ни когда не увидеть реальных пользователей. В других если требуется как минимум SAP, 1С или Google, ваш MVP будет размером со звездолет, создав и угробив на своем пути сотни PoC.
В комменте про самый попсовый термин оставлю такой же попсовый коммент - надо быть гибче)
Действительно, ситуации бывают разные. На первый взгляд идти на давно устоявшийся рынок энтерпрайз приложений с MVP бессмысленно. Но обязательно ли сразу стучаться в двери приёмных топ-компаний? Нельзя ли обкатать MVP на игроках попроще? Ну, здорово, когда это возможно.
Соглашусь, что важной пользой от MVP является реальная обратная связь, возможность проведения полевых исследований. Если не на стадии MVP, то когда? Уже слышу шум водопада.
Последнее, что отмечу, это место MVP в роадмапе продукта. MVP не должен быть последней осязаемой точкой, не должно быть "сейчас запилим MVP, а дальше посмотрим". Если вы так делаете, то тогда это у вас действительно "перый сырой релиз".
В тему встречала поясняющую картинку
Есть же еще не такой распиаренный термин MMP (minimal marketable product). Это вот как раз стадия продукта, когда он конкурентно способный.
Судя по статье автор хочет чтобы все понимали термин так как он сам его понимает :) выглядит наивно. Такая же ерунда творится и со всеми другими терминами которые имеют некоторую вольность в интерпретации. Для меня mvp это нечто, что позволит проверить гипотезу. В одном случае это может быть мокап в другом интерактивный прототип в третьем продукт который уже выполняет практически все функции за исключением того, что его слепили дендрофекальным методом с расчетом на то, что это будет переделано нормально, в случае успешного подтверждения гипотезы.
Про самый попсовый термин в продуктовом глоссарии и почему MVP мёртв