Мобильді қосымшадағы MVP-ді жиі қараламамен шатастырады. Қателер де осыдан туындайды. Команда көп экран жасайды, бюджет жұмсайды, бірақ басты сұраққа жауап алмайды. Сұраныс бар ма. Және өнім нақты міндетті шешеді ме.
Бұл мақалада MVP-ді гипотезадан бастап қалай есептеуді талдаймыз. Минималды функционалды қалай таңдау керек. Және бірінші нұсқаны шексіз әзірлеуге қалай айналдырмау керек.
Мобильді қосымшадағы MVP деген не және ол не емес
MVP — бұл нақты адамдар қолданатын қосымшаның бірінші нұсқасы. Ол бір негізгі міндетті шешеді. Және өлшенетін сигнал береді. Гипотеза жұмыс істей ме, жоқ па.
MVP әдемі әрі толық болуға міндетті емес. Бірақ ол пайдалы болуға міндетті. Пайдаланушы нәтижеге жетуі керек. Және чаттағы түсіндірмесіз құндылықты түсінуі керек.
Егер пайдаланушы негізгі сценарийді орындай алмаса, бұл MVP емес. Бұл демо. Егер қосымша іске қосылса, бірақ құндылық бермесе, бұл да MVP емес. Бұл — экрандар жиынтығы.
MVP-ді прототиптен, PoC пен пилоттан қалай ажыратуға болады
Прототип түсінуді тексереді. Ол мынадай сұраққа жауап береді: пайдаланушы мұнда не істеу керектігін мүлдем түсіне ме. Прототип жұмыс істейтін өнім болуға міндетті емес. Ол басылатын экрандарда өмір сүре алады.
PoC техникалық іске асырылуын тексереді. Ол мынадай сұраққа жауап береді: біз мұны жұмыс істетіп жібере аламыз ба. Мысалы, камераны, төлемді, картаны, тануды қосу. PoC көбіне UX пен бизнес-әсерге қарамайды.
Пилот енгізу процесін тексереді. Ол мынадай сұраққа жауап береді: өнім нақты компанияда немесе нақты серіктесте орнығады ма. Пилот аудитория, аймақ немесе қызметтер жиынтығы бойынша шектеулі болуы мүмкін.
MVP құндылықты пайдаланушыларда тексереді. Ол мынадай сұраққа жауап береді: адамдар қолдануға және қайта оралуға дайын ба. Немесе модельде төлем болса, төлеуге дайын ба.
Неге MVP — пайдаланушыларға арналған өнім, ал экрандар тізімі емес
Экран өзі ештеңе дәлелдемейді. Дәлелдейтін — мінез-құлық. Пайдаланушы қосымшаны ашады, әрекет жасайды және нәтиже алады.
Сондықтан MVP-ді экран санымен емес, сквозной сценарий бойынша есептейді. Пайдаланушы бірінші қадамда не істейді. Ол нені көреді. Қай жерде шешім қабылдайды. Қай жерде процесті тастайды. Және қосымша міндетті соңына дейін қалай жабады.
Екі қосымшада экран саны бірдей болуы мүмкін. Бірақ біреуі құндылық пен метрика береді. Екіншісі тек әдемі презентация береді.
MVP қажет болмайтын және идеяны басқаша тексерген жөн болатын кездер
Кейде қосымша — тексерудің басты тәсілі емес. Егер сіз әзірге міндет пен аудиторияны түсінбесеңіз, қарапайымнан бастаған дұрыс.
Мобильді қосымша түріндегі MVP мынадай жағдайларда артық болуы мүмкін:
- сізде басыңыздағы идеядан басқа айқын гипотеза жоқ
- кімді дәл тексеретініңізді білмейсіз
- құндылықты лендинг, өтінім формасы және қолмен жасалатын процесс арқылы тексеруге болады
- өнім серіктестер желісіне тәуелді, ал сіз әлі шарттар туралы келіспедіңіз
- сіз алғашқы пайдаланушыларды тартуға және тест жүргізуге дайын емессіз
Мұндай жағдайларда алдымен сұраныс пен сценарийді тексерген жөн. Ал кейін ғана әзірлеуге қаражат салу керек.
MVP есебі неден басталады — гипотеза мен құндылық арқылы
MVP есебі дизайннан да, платформаны таңдаудан да басталмайды. Ол гипотезадан басталады. Дәл нені растағыңыз келеді.
Сұраныс гипотезасы мен шешім гипотезасын тұжырымдау
Екі түрлі гипотеза бар. Оларды жиі араластырады.
Сұраныс гипотезасы былай естіледі: адамдарда мәселе бар және олар шешім іздеп жүр. Мұнда ауырсыну белгілері маңызды. Жиілік. Шұғылдық. Және әдеттерін өзгертуге дайындық.
Шешім гипотезасы былай естіледі: біздің қосымша бұл мәселені жақсырақ немесе оңайырақ шешеді. Мұнда жылдамдық, ыңғайлылық, сенім және түсінікті нәтиже маңызды.
Екі гипотеза да қысқа болуы керек. Бір сөйлеммен. Егер сіз тұжырымдай алмасаңыз, MVP-ді есептей алмайсыз.
Аудитория сегменті мен пайдалану сценарийі
MVP нарықты тұтастай тексермейді. Ол бір сегмент пен бір сценарийді тексереді.
Сегмент — бұл нақты жағдайдағы нақты адамдар. Жай ғана 25-тен жоғары әйелдер емес. Ал, мысалы, кешке смартфоннан тапсырыс беретіндер. Немесе үзіліс кезінде қызметке жазылатындар. Немесе қайта сатып алып, оны тезірек жасағысы келетіндер.
Сценарий — бұл қосымшаны ашу себебінен нәтижеге дейінгі жол. Сценарийсіз сіз бірінші нұсқада нені құру керектігін түсінбейсіз. Және нені өлшеу керектігін де.
Табыс шарттары: іске қосқаннан кейін қандай сигналдар пайда болуы керек
MVP-де әзірлеу басталғанға дейін табыс шарттары болуы керек. Әйтпесе сіз қосымша мен эмоцияға негізделген дауды аласыз.
Сигналдар модельге байланысты, бірақ логика біреу:
- адамдар мақсатты әрекетке жетеді
- адамдар қайта оралып, әрекетті қайталайды
- адамдар өтінім қалдырады немесе диалог бастайды
- адамдар төлеуге дайын немесе мақсат болса, төлем үшін деректер қалдырады
Нені дәл растау деп санайтыныңызды алдын ала шешу маңызды. Және нені сәтсіздік деп санайтыныңызды да. Сонда MVP есебі басқарылатын болады.
MVP-де жұмыс істеуі тиіс пайдаланушы сценарийін қалай сипаттау керек
MVP функциялар санымен жеңбейді. Ол ішінде бір негізгі жол жұмыс істейтінімен жеңеді. Кіруден нәтижеге дейін.
Кіруден нәтижеге дейінгі пайдаланушы міндеті
Міндетті етістікпен сипаттаңыз. Тапсырыс беру. Жазылу. Табу. Төлеу. Қол жеткізу. Мәртебені бақылау. Сабақтан өту.
Әрі қарай жолды сипаттаңыз. Қысқа қадамдармен:
- пайдаланушы қосымшаны ашады
- ұсынысты көреді және не істеу керектігін түсінеді
- ең аз дерек енгізеді
- негізгі әрекетті жасайды
- растауды және келесі қадамды алады
Егер жолды 8–12 қадаммен сипаттай алмасаңыз, сіз сценарийді шамадан тыс үлкейттіңіз. Немесе сізде бірнеше сценарий бар және сіз барлығын бірден тексеруге тырысып жатырсыз.
Қосымшаларда сценарий жиі бұзылатын нүктелер
Сценарий көбіне үш жерде бұзылады.
Бірінші орын — бірінші экран. Пайдаланушы құндылықты түсінбей кетіп қалады.
Екінші орын — тіркеу. Тым көп өріс. Адам пайданы көрмей тұрып міндетті авторизация.
Үшінші орын — нәтижені растау. Пайдаланушы әрекет жасады, бірақ әрі қарай не болатынын түсінбеді. Мәртебе жоқ. Хабарлама жоқ. Түсінікті аяқталу жоқ.
MVP-де бұл нүктелерден әсіресе қатаң өту керек. Өйткені сізде сенім кредиті жоқ. Және өнімге деген әдет жоқ.
Әзірлеуді үлкейтпеу үшін бастапқыда нені қолмен қалдыруға болады
Жиі кездесетін қате — бәрін бірінші күннен бастап автоматтандыру. Бұл әрдайым дерлік мерзім мен бюджетті ұлғайтады.
MVP-де пайдаланушы үшін құндылықты бұзбайтын нәрсені қолмен қалдыруға болады:
- өтінімді оператордың растауы
- тапсырыстарды күрделі логикасыз админкада өңдеу
- контентті күрделі CMS емес, қарапайым панель арқылы басқару
- рұқсат етілсе, хабарламалардың бір бөлігін дайын арналар арқылы жіберу
- чат пен мессенджерлер арқылы қолдау
Мұнда принцип маңызды. Пайдаланушы нәтиже алуы керек. Ал ішкі процесс қарапайым болуы мүмкін. Тіпті ол қолмен жасалатын жұмысты талап етсе де.
Функцияларды басымдыққа қою және минималды жиынтықты анықтау
Сценарийден кейін функциялар тізімі пайда болады. Енді оны қысқарту керек. Қатаң әрі шынайы түрде.
Мобильді MVP үшін MoSCoW әдісі
Функцияларды төрт топқа бөліңіз.
- Must have — мұнсыз сценарий жұмыс істемейді, пайдаланушы нәтижеге жетпейді
- Should have — тәжірибені жақсартады, бірақ онсыз да өмір сүруге болады
- Could have — жағымды, бірақ гипотезаны тексеруге әсер етпейді
- Wont have қазір — MVP-ге саналы түрде кіргізбейміз
Талғам туралы таласпау маңызды. Дауды мынадай сұраққа аудару керек: бұл гипотезаны тексеруге әсер ете ме, жоқ па.
Walking skeleton — минималды жұмыс істейтін сквозной жол
Walking skeleton — бұл қаңқа. Өнім арқылы өтетін минималды сквозной жол.
Мобильді MVP-де бұл әдетте мынаны білдіреді:
- қосымша орнатылады және іске қосылады
- пайдаланушы қысқа кіруден өтеді
- негізгі әрекетті жасайды
- жүйе әрекетті тіркейді және мәртебені көрсетеді
- команда бұл әрекетті админ-бөлікте немесе есеп контурында көреді
Бұл қаңқа сізге басты нәрсені береді. Жұмыс циклін. Және аналитикаға негізді.
Даулы функцияларды тәуекел мен құндылық арқылы қалай шешу керек
Даулы функциялар әрдайым пайда болады. Мысалы, таңдаулылар, чат, карта, бонустар, ұсыныстар, күрделі сүзгілер.
Екі сұрақ арқылы шешіңіз:
- біз бұл функциямен қандай тәуекелді жабамыз
- ол негізгі сценарийге қандай құндылық қосады
Егер функция тәуекелді жаппаса және құндылық қоспаса, оны MVP-ден алып тастаңыз. Егер функция тәуекелді жабса, бірақ қымбат тұрса, жеңілдетуді іздеңіз. Мысалы, автоматтандырудың орнына қолмен жасалатын процесс. Немесе рөлдер бойынша шектеу. Немесе бір платформада іске қосу.
Қосымша блоктары бойынша минималды функционал
Қосымшаны блоктар ретінде қарасаңыз, функциялар тізімін қысқарту оңайырақ. Әр блоктың рөлі бар. Бір блок қол жеткізу береді. Екіншісі құндылық береді. Үшіншісі командаға басқарылуды береді. MVP-де әр блок минималды болуы керек. Және әрқайсысы бір сквозной сценарийді қолдауы керек.
Онбординг, тіркеу және артық кедергісіз қол жеткізу
MVP-дегі онбординг бір міндетті шешеді — адамға сценарийді бастауға көмектесу. Миссия туралы айту емес. Барлық фичаларды көрсету емес. Болашаққа ол туралы дерек жинау емес.
Бірінші нұсқада қауіпсіздік пен бизнес моделін бұзбайтын ең қысқа кіруді қалдырыңыз. Жиі кездесетін логика мынадай:
- пайдаланушы қосымшаны ашады
- мұнда дәл қазір не істеуге болатынын көреді
- ұзын анкетасыз қол жеткізеді
- сценарийдің бірінші қадамына түседі
MVP-де әдетте нені жеңілдеткен жөн:
- SMS немесе email бойынша код жеткілікті болса, құпиясөзді сұрамау
- пайдаланушы пайданы көрмей тұрып тіркеуді талап етпеу
- нәтиже үшін қажет болмаса, туған күні мен мекенжай сияқты артық өрістерді сұрамау
- әрекеттің орнына ұзақ онбординг слайдтарын көрсетпеу
MVP-де де нені қалдыру маңызды:
- рөлдер әртүрлі болса, түсінікті рөл таңдау
- дерек жинасаңыз, ережелер мен саясатпен келісу
- қол жеткізуді қалпына келтіру мүмкіндігі
Егер күмәндансаңыз, былай істеңіз. Алдымен адамға әрекетті орындауға мүмкіндік беріңіз. Кейін жалғастыру үшін қажет деректерді сұраңыз. Бұл көбіне сценарийдің аяқталуын арттырады.
Негізгі операция: тапсырыс, броньдау, төлем немесе контент
Дәл осы блок — MVP. Мұнда сіз гипотезаны тексересіз. Сондықтан блок толық циклді жабуы керек. Жартысын емес.
Әртүрлі өнім түрлеріне ядро әртүрлі болады, бірақ логика біреу:
- таңдау
- растау
- нәтиже
Тапсырыс мысалы. Пайдаланушы тауар немесе қызметті таңдайды. Растайды. Мәртебені көреді. Келесі қадамды алады.
Броньдау мысалы. Пайдаланушы күн мен уақытты таңдайды. Растайды. Растауды және келу ережелерін алады.
Контент мысалы. Пайдаланушы материалды табады. Ашады. Пайда алады. Әрі қарай не істеу керектігін көреді.
MVP-де көбіне ядро емес, оның айналасындағы байлам бұзылады. Сондықтан үш нәрсені тексеріңіз:
- түсінікті шарттар — неге кіреді, қанша тұрады, қалай жұмыс істейді
- түсінікті растау — түймені басқаннан кейін не болды
- түсінікті мәртебе — өңделуде, расталды, тоқтатылды, аяқталды
Егер модельде төлем болса, бастапқыда барлық төлем тәсілдерін мен барлық қайтару сценарийлерін жабуға тырыспаңыз. Бір негізгі жолды таңдаңыз. Бірақ оны сенімді етіңіз. Егер төлем гипотезаны тексерудің бөлігі болмаса, оны MVP-ден шығарыңыз. Мысалы, MVP-де сіз жазылу мен сұранысты тексересіз, ал төлемді растағаннан кейін қолмен аласыз.
Админ-бөлік пен контентті басқару: нені бірден, нені кейін
Админ-бөліксіз MVP көбіне хаосқа айналады. Команда деректерді басқара алмайды. Өтінімдерді көрмейді. Контентті өзгертпейді. Нәтижесінде әр кішкене нәрсе әзірлеушінің тапсырмасына айналады. Және тест тоқтайды.
MVP-де админ-бөлік қарапайым сұраққа жауап беруі керек: сіз сценарийге қалай қызмет көрсетесіз.
Әдетте бірден қажет минимум:
- өтінімдер немесе тапсырыстарды қарау
- мәртебелерді өзгерту
- базалық нысандарды басқару, мысалы қызметтер, слоттар, тауарлар, бағалар
- қолдау үшін маңызды болса, пайдаланушыларды қарау
- әзірге есептер құрмасаңыз, кем дегенде кестеге қарапайым экспорт
Нені кейінге қалдыруға болады:
- командаңыз әзірге кішкентай болса, күрделі рөлдер мен қол жеткізу матрицалары
- автоматты ережелер, мысалы тапсырыстарды автожабу мен ақылды шектеулер
- терең есептер мен дашбордтар
- контентті сирек өзгертсеңіз, күрделі контент редакторы
Админкаға операциялық минимум ретінде қараңыз. Ол тестке көмектесуі керек, бөлек өнім болмауы керек.
Мобильді қосымшаға арналған MVP форматын таңдау
MVP форматы сіз жауап беретін сұраққа байланысты. Түсінуді тексергіңіз келе ме. Сұранысты тексергіңіз келе ме. Бірден өсуге негіз қалағыңыз келе ме. Бір функциялар тізімі әртүрлі форматта әртүрлі нәтиже мен әртүрлі тәуекел береді.
Түсіну мен UX-ті тексеруге арналған басылатын прототип
Басылатын прототип сценарий мен логикаға әлі сенімді болмаған кезде қолайлы. Сіз адамдардың қай жерде шатасатынын көргіңіз келеді. Олардың басқа түймелерді қай жерде күтетінін. Қай жерде құндылықты түсінбейтінін.
Мұндай формат көмектеседі:
- экрандар құрылымы мен қадамдар ретін тексеру
- алғашқы пайдаланушыларда сұхбат пен тест жүргізу
- командада және инвесторлармен көзқарасты келісу
- әзірлеуден кейінгі қымбат қайта өңдеу тәуекелін азайту
Бірақ прототип өнімдегі нақты мінез-құлықты тексермейді. Ол ұстап тұруды көрсетпейді. Ол төлемдегі нақты бас тартуларды көрсетпейді. Ол жүктемені мен интеграция қателерін көрсетпейді.
Прототипті сүзгі ретінде қолданыңыз. Алдымен логикалық қателерді алып тастаңыз. Кейін әзірлеуге кіріңіз.
Сұранысты жылдам тексеруге арналған No-code пен webview
Бұл формат идеалды архитектура құрудан гөрі тестті жылдам іске қосу маңыздырақ болғанда қолайлы. Сіз трафик әкеліп, өтінімдер жинап, конверсияны өлшеп, құндылықтың жұмыс істейтінін түсінгіңіз келеді.
Мұнда жиі қолданады:
- лендинг плюс форма және қолмен өңдеу
- қосымша ішінде webview ретінде ашылатын қарапайым веб-шешім
- сценарийге сыйса, жазылу, броньдау, каталогтарға арналған дайын құралдар
Басты артықшылық — жылдамдықта. Басты тәуекел — шектеулерде. Сіз интеграцияларға, рөлдерге, қауіпсіздікке және өсуге тіреліп қалуыңыз мүмкін. Сондықтан дәл нені тексеретініңізді алдын ала шешіңіз. Және бұл формат сізге қандай мерзімге қажет екенін.
Өсуге негіз қажет болғанда базалық backend-і бар толыққанды қосымша
Мұндай формат мынадай кезде қажет:
- сценарий түсінікті және сіз нақты пайдаланушыларда тестілеуге дайынсыз
- сізге мәртебелер, есеп пен деректердің сенімділігі маңызды
- сізде сценарий онсыз жұмыс істемейтін интеграциялар бар
- сіз гипотеза расталғаннан кейін өнімді толық қайта жасамай дамытқыңыз келеді
Бұл нұсқада MVP бәрібір функциялар бойынша минималды болып қалады. Бірақ сіз команда ядроны бұзбай модульдерді жылдам қоса алатындай негіз қалайсыз.
Қызмет
MVP-ді есептеуге, форматты таңдауға және минималды жұмыс істейтін нұсқаны жинауға көмектесеміз
Гипотеза мен сквозной сценарийді талдаймыз, функцияларды басымдыққа қоямыз және бірінші нұсқаның форматын ұсынамыз — басылатын прототиптен бастап iOS пен Android-қа арналған базалық backend-і бар толыққанды қосымшаға дейін.
Нақты сметасыз MVP мерзімін мен бюджетін қалай бағалау керек
ТЗ болмаса, нақты смета болмайды. Бірақ сіз шамасын бағалап, дәл нені құн жылжытатынын түсіне аласыз. Бұл соқыр таласпауға көмектеседі. Және бірінші нұсқаның шекараларын бекітуге көмектеседі.
Еңбек сыйымдылығы неге байланысты: экрандар, логика, интеграциялар, рөлдер
Мерзім мен бюджет көбіне экран санына емес, мінез-құлықтың күрделілігіне байланысты.
Үш басты фактор:
- экрандар мен күйлер, мысалы бос, қате, жүктеу, қол жеткізу жоқ, слот жоқ
- бизнес-логика, мысалы есептеу ережелері, тексерулер, мәртебелер, шектеулер
- интеграциялар, мысалы төлем, карталар, CRM, хабарламалар, сыртқы базалар
- рөлдер мен құқықтар, егер әртүрлі пайдаланушылар әртүрлі интерфейс пен әрекет көрсе
Екі қосымша бірдей көрінуі мүмкін. Бірақ біреуі ережелер мен интеграциялардан екі есе күрделі болады. Сондықтан MVP бағалауын визуалдан емес, сценарий мен деректерден бастаңыз.
Мобильді әзірлеуде MVP-ді ең қатты не қымбаттатады
MVP-де көбіне күтпеген жерден мынадай нәрселер қымбаттатады:
- күрделі тіркеу мен қауіпсіздік, әсіресе құжаттар мен тексерулер қажет болса
- бір нұсқада бірнеше пайдаланушы рөлі
- бірнеше сценарийі, қайтарулары мен күрделі мәртебелері бар төлем
- деректердің синхрондалуы мен қайшылықтары бар онлайн режим
- бірден көп интеграция
- минималды панель емес, бөлек күрделі жүйе ретіндегі админка
Егер бұл тармақтарды өз тізіміңізден көрсеңіз, гипотезаға қайта оралыңыз. Өзіңізге сұрақ қойыңыз: бұдан жауап үшін шынымен не қажет. Қалғанын келесі релизге аударыңыз.
Шексіздікке кетпеу үшін бірінші нұсқаның шекараларын қалай бекіту керек
MVP-де әрдайым тағы азғантай қосу азғырылуы бар. Дәл осы жылдамдықты өлтіреді.
Шекараларды қарапайым түрде бекітіңіз:
- бір гипотеза
- бір аудитория сегменті
- бір негізгі сценарий
- бір метрика жиынтығы
- бір Must have функциялар тізімі
- MVP-ге нақты кірмейтіннің тізімі
Кейін өзгерістер ережесін бекітіңіз. Кез келген жаңа идея ағымдағы релизге емес, бэклогқа түседі. MVP-де сіз жетілдірулерге тыйым салмайсыз. Сіз оларды келесі циклге аударасыз, алдымен нарықтан жауап алу үшін.
MVP жауап бермейтін болатын метрикалар мен аналитика
Егер сіз мінез-құлықты өлшемесеңіз, MVP пікірге айналады. Команда ұнайды ма, ұнамайды ма деп таласады. Бірақ MVP жауап үшін қажет. Гипотеза жұмыс істей ме, жоқ па.
Қандай метрикалар сіздің сұрағыңызға жауап беретінін бірден шешіңіз. Және өлшеулерді релизге дейін өнімге кіріктіріңіз. Кейін сіз бейнені толық қалпына келтіре алмайсыз. Сіз тек қорытынды мен болжамдарды көресіз.
Бірінші күннен қандай оқиғалар мен воронкаларды өлшеу керек
Негізгі сценарийдің воронкасынан бастаңыз. Ол әрдайым дерлік былай көрінеді:
- орнату және алғашқы іске қосу
- сценарийдің бірінші экранына түсу
- әрекетті бастау
- әрекетті сәтті аяқтау
- модель үшін маңызды болса, әрекетті қайталау
Әрі қарай бас тартуды түсіндіретін оқиғаларды қосыңыз:
- тіркеу қатесі
- растау қадамындағы бас тарту
- болса, төлем қатесі
- қолжетімді слоттар немесе тауарлар жоқ
- шарттар мен баға экранынан кету
MVP-де ондаған оқиға маңызды емес. Бір сұраққа жауап беретін 10 немесе 20 оқиға маңызды. Сценарий қай жерде бұзылады. Және адам дәл нені істей алмайды.
Кері байланысты қосымша ішінде және одан тыс қай жерде жинау керек
Кері байланыссыз сіз тек сандарды көресіз. Бірақ себептерін түсінбейсіз.
Кері байланысты екі жерде жинаңыз. Қосымша ішінде:
- негізгі әрекеттен кейінгі қысқа сұрақ, мысалы не кедергі болды немесе не түсініксіз болды
- сценарий күрделі болса, қате туралы хабарлама формасы
- түсінікті байланыс арнасына апаратын қолдау түймесі
Қосымшадан тыс:
- 2 немесе 3 сессиядан кейін алғашқы пайдаланушылармен сұхбат
- сценарийді аяқтамағандарға арналған сауалнама
- пайдаланушылар қалдырса, пікірлер мен түсініктемелерді талдау
Ұзын анкеталарды сұрамаңыз. MVP-де бұл тартылымды төмендетеді. Бір сұрақ пен мәтінге арналған бір өрісті сұраңыз. Және кейінірек жазу мүмкіндігін беріңіз.
Гипотезаның расталғанын, тек орнатулар бар екенін емес, қалай түсінуге болады
Орнатулар мен тіркеулер құндылыққа тең емес. Адамдар қосымшаны қызығушылықтан орнатады. Немесе ұсыныс бойынша. Немесе оларға бонус уәде еткендіктен. Бұл сценарийдің жұмыс істейтінін білдірмейді.
Үш сигналға қараңыз:
- адамдар көмексіз мақсатты әрекетке жетеді
- сценарий қайталауды көздесе, адамдар әрекетті қайталайды немесе қайта оралады
- адамдар мағыналы кері байланыс береді, сұрақ қояды және жетілдіру сұрайды
Егер сізде ақылы модель болса, төлем әрекетіне немесе төлеуге дайындықты көрсететін қадамға бағдарланыңыз. Мысалы, төлем әрекеті немесе түсінікті бағасы бар тапсырысты растау.
MVP-ді есептеу кезіндегі қателер және оларды қалай болдырмауға болады
MVP-дегі қателер кодпен сирек байланысты. Олар фокуспен байланысты. Команда мақсатын жоғалтады. Немесе бизнестің барлық міндеттерін бірден шешуге тырысады. Немесе ешкім қолдана алмайтын нұсқа жасайды.
Бір гипотезаны тексерудің орнына функциялармен шамадан тыс жүктеу
Функциялар көп болғанда сіз мерзімді созасыз. Және нәтижені бұлдырлатасыз. Дәл не сәтті болды, не болмады — сіз түсінбейсіз.
Бұл тәжірибеде қалай көрінеді:
- MVP-ге чат, карта, пікірлер, бонустар мен ұсыныстар қосады
- қатар бірнеше сценарийді іске қосады, мысалы тапсырыс пен жазылым
- бірін тексерсе де, екі-үш пайдаланушы түрін жасайды
Қалай болдырмауға болады:
- бір гипотеза мен бір сквозной сценарийді бекітіңіз
- бір негізгі аудитория сегментін қалдырыңыз
- функцияларды сценарий үшін Must have принципі бойынша қысқартыңыз
- қалғанын келесі релизге аударыңыз
Құндылық бермейтін тым кедей нұсқа
Кейде команда тым қатты қысқартады. Және нәтижеге жету мүмкін емес өнім жасайды. Пайдаланушы оған қосымша не үшін қажет екенін түсінбейді. Және тест бұзылады.
Жиі белгілер:
- әрекет пен мәртебені растау жоқ
- түсінікті шарттар, баға немесе ережелер жоқ
- контент немесе дерек жоқ, сондықтан сценарий бос
- минималды админ-бөлік жоқ, команда өтінімдерге қызмет көрсете алмайды
Қалай болдырмауға болады:
- пайдаланушы әрекетті соңына дейін аяқтай алатынын тексеріңіз
- түсінікті аяқталуды, мәртебені мен келесі қадамды қосыңыз
- операциялық басқару үшін минимумды қосыңыз, кем дегенде қарау мен мәртебені өзгерту
Тарту арнасы мен тестілеу жоспарынсыз іске қосу
MVP өздігінен жұмыс істемейді. Егер сіз пайдаланушыларды әкелмесеңіз, сигнал алмайсыз. Егер кездейсоқ адамдарды әкелсеңіз, шу аласыз.
Жиі жағдай. Қосымша дайын. Бірақ алғашқы пайдаланушылар қайдан келетіні туралы жоспар жоқ. Командада сұхбатқа уақыт жоқ. Жетілдіру циклі жоқ.
Қалай болдырмауға болады:
- алғашқы ағын қайдан келетінін, тіпті шағын болса да, алдын ала шешіңіз
- тест ұзақтығын және әр апта не істейтініңізді келісіңіз
- дерек жинау мен өнім бойынша шешімдерге жауапты адам тағайындаңыз
- релизден кейін тексеретін гипотезалар мен түзетулер тізімін жүргізіңіз
MVP әзірлеуін бастамас бұрын нені дайындау керек және әрі қарай қалай жылжу керек
Жақсы MVP қарапайым артефактілерден басталады. Жүздеген бет құжаттамадан емес. Бірақ сөзбен айтылған идеядан да емес. Сізге фокусты ұстайтын және көлемді бағалауға көмектесетін сипаттама қажет.
Кірудегі артефактілер: гипотезалар сипаттамасы, сценарийлер, функциялар тізімі
Кем дегенде бес тармақтан дайындаңыз.
- Біріншісі — сұраныс гипотезасы мен шешім гипотезасы, әрқайсысы бір сөйлеммен
- Екіншісі — аудитория сегменті: бұл адамдар кім, олар қандай жағдайда қосымшаны ашады, олар қазір сізсіз не істейді
- Үшіншісі — сквозной сценарий: кіруден нәтижеге дейінгі қадамдар, қысқа әрі нақты
- Төртіншісі — MoSCoW бойынша функциялар тізімі, әсіресе Must have тізімі мен MVP-ге нақты кірмейтіннің тізімі
- Бесіншісі — табыс метрикалары: қандай оқиғаларды өлшейсіз, қандай мәндер немесе белгілерді растау деп санайсыз
MVP форматы мен бірінші нұсқаның шекаралары туралы әңгімені бастау үшін осы жеткілікті.
MVP релиздерінің жоспары мен тексеруден кейінгі келесі қадам
MVP релизбен аяқталмайды. Ол шешіммен аяқталады.
Қарапайым жоспар қалаңыз:
- релиз 0, іске қосу және базалық деректерді жинау
- сценарийдің басты сәтсіздіктері бойынша қысқа түзету циклі
- түзетулерден кейінгі қайталама өлшеу
- әрі қарай не істейтіндігіңіз туралы шешім
Тексеруден кейін әдетте үш нұсқа болады.
Біріншісі. Гипотеза расталады. Сіз функционалды кеңейтесіз және тарту арналарын күшейтесіз.
Екіншісі. Гипотеза ішінара расталады. Адамдар құндылықты қалайды, бірақ сценарий бұзылады. Сіз қадамдарды өзгертесіз, кіруді жеңілдетесіз және ядроны күшейтесіз.
Үшіншісі. Гипотеза расталмайды. Сіз өнімді кеңейтпейсіз. Сіз сегментті, құндылықты немесе форматты қайта қарайсыз. Және идеяның басқа нұсқасын тестілейсіз.
Qazaqsoft мобильді қосымшаларды әзірлеу командасын қашан тарту керек
Жолды тезірек және шекараларды бұлдырлатпай өткіңіз келгенде команданы тартыңыз.
Әдетте бұл үш жағдайда орынды:
- сіз гипотеза мен сценарийді анықтадыңыз, бірақ қай MVP форматы жауапты тезірек беретінін түсінбейсіз
- сіз базалық backend-і бар толыққанды MVP-ді іске қосып, дамуға негіз қалдырғыңыз келеді
- сізге тест релизден кейін тоқтамауы үшін интерфейсті, рөлдерді мен минималды админ-бөлікті жобалау қажет
Егер сіз iOS пен Android-қа арналған MVP әзірлеуін жоспарласаңыз немесе бірінші нұсқаның форматын талқылағыңыз келсе, «Мобильді қосымшаларды әзірлеу» қызметінің бетінен бастаңыз. Ал бюджеттер мен құн факторлары бойынша бағдар қажет болса, бағалар бетін пайдаланыңыз.
