Изградете един-единствен сценарий, който решава основния проблем на потребителите от начало до край, и почти нищо друго. MVP (минимален жизнеспособен продукт) служи да провери дали хората искат това, което предлагате. Затова първата версия трябва да съдържа най-краткия път от „имам този проблем“ до „проблемът е решен“, плюс минимума около него, който го прави безопасен и удобен. Всичко останало може да се върши ръчно, да се симулира честно или да се отложи, докато истинските потребители не го поискат.
#Започнете с един ясно формулиран проблем
Повечето MVP стават прекалено големи, защото проблемът зад тях никога не е бил записан в едно изречение. Преди да изброявате функции, напишете изречение по този модел: „[Кой] има нужда да [прави какво], а днес [го прави зле по този начин].“ Например: „Малките фитнес зали имат нужда да приемат записвания за групови тренировки онлайн, а днес ги приемат по телефона и губят представа кой ще дойде.“
Това изречение става филтър за всяко предложение за нова функция. Ако функцията не помага на този човек да свърши това нещо, тя няма място в първата версия. Ясният проблем ви казва и с кого да тествате, а това е половината от ползата от MVP.
Бърза проверка: ако не можете да назовете десет реални души или фирми, които имат този проблем днес, говорете с потенциални потребители, преди да започнете разработка. Най-евтиният MVP е разговор, който показва, че идеята не работи.
#Опишете основния сценарий
Основният сценарий е поредицата от стъпки, през които минава потребителят, за да получи главния резултат. За примера с фитнеса той може да изглежда така:
- Членът отваря графика и вижда свободните тренировки.
- Избира тренировка и запазва място.
- Получава потвърждение.
- Залата вижда кой е записан за всяка тренировка.
- Членът може да се откаже и мястото се освобождава.
Запишете сценария стъпка по стъпка и за всяка стъпка потърсете най-простата работеща версия. Може би потвърждението е обикновен имейл, изгледът за залата е един списък на тренировка, а отказът е линк в същия имейл. Всяка стъпка трябва наистина да работи, защото една счупена стъпка проваля целия тест.
След това добавете само онова, без което сценарият не може: потребителски профили, ако хората трябва да се връщат, плащания, ако тестът зависи от това дали ще платят, и основната защита около тях.
#Какво да оставите извън първата версия
Това са обичайните кандидати за по-късно. Всяко от тях отнема реално време и нито едно не ви казва дали основната идея работи.
- Пълен административен панел. В началото често стигат прост списък, експорт в таблица или директен достъп на разработчика до базата данни.
- Много потребителски роли. Започнете с двете или трите роли, които основният сценарий изисква. Детайлните права може да дойдат, когато реални екипи използват продукта.
- Вход през социални мрежи, известия по всички канали, профилни страници. Полезни са, но рядко са причината някой да започне да ползва продукта.
- Всички интеграции. Изберете тази, от която зависи сценарият. Експортът към счетоводството и синхронизацията с CRM могат да почакат.
- Мобилни приложения и за двете платформи. Адаптивното уеб приложение често проверява идеята по-бързо. Мобилно приложение има смисъл, когато сценарият се нуждае от самия телефон: камера, местоположение, push известия или работа без интернет.
- Редки изключения. Обработвайте ги ръчно и ги записвайте.
Водете писмен списък с отложеното и причината за всяко решение. Така едни и същи спорове не се връщат всяка седмица, а списъкът става ваш план за работа, щом имате данни.
#„Фалшиви врати“ и ръчна обработка зад кулисите
Два подхода ви позволяват да проверите повече от идеята, без да я изграждате.
„Фалшиви врати“
Това е бутон или елемент от менюто за функция, която още не съществува. Когато някой го натисне, вижда честно съобщение, например „Тази възможност предстои. Разкажете ни как бихте я използвали“, с кратка форма или поле за имейл. Броят на кликванията показва колко голям е интересът, преди да сте похарчили нещо за функцията. Използвайте подхода пестеливо и никога за нещо, за което хората плащат, защото страница, пълна с празни врати, руши доверието.
Ръчна обработка зад кулисите
Много стъпки, които изглеждат като софтуер, в началото може да върши човек. Свързването на клиенти с изпълнители, одобряването на профили, изготвянето на справки или възстановяването на плащания може да поеме някой от екипа ви чрез административния списък и имейла. Потребителите получават резултата, вие научавате как точно протича процесът и го автоматизирате едва когато знаете правилата и обема. На английски този подход често се нарича concierge MVP или „Wizard of Oz“.
Едно правило е задължително: бъдете честни с потребителите за сроковете. Ако дадена стъпка се върши ръчно, кажете им кога да очакват резултата.
#Решете как ще измервате, преди да пуснете продукта
MVP без измерване е просто малък продукт. Преди старта запишете двата или трите показателя, които ще ви кажат дали идеята работи, и какъв резултат би ви накарал да продължите, да смените посоката или да спрете.
- Завършване на основния сценарий. Колко от хората, започнали записване, го завършват? Следете всяка стъпка като отделно събитие, за да видите къде се отказват.
- Повторно използване. Връщат ли се хората за второ записване или втора поръчка? Едно използване може да е любопитство. Повторното подсказва реална полза.
- Готовност да се плати. Ако бизнесът зависи от плащания, проверете това рано, дори с ниска цена или предварителна поръчка.
- Мнения на потребителите. Говорете с тях. Пет кратки разговора често обясняват онова, за което числата само намекват.
Настройте анализа с мисъл за личните данни: събирайте само необходимото и спазвайте правилата за съгласие там, където са вашите потребители. Целевите стойности зависят от пазара ви, затова ги определете според собствените си разходи и цели, вместо да заимствате чужди сравнителни данни.
#Изградете MVP, който може да расте, без да го преусложнявате
Минималният продукт пак трябва да е изграден добре на местата, които по-късно струват скъпо за промяна. Да съкратите функции е нормално. Да съкратите основите означава да пренапишете всичко след година.
| Направете правилно от самото начало | Може да остане просто |
|---|---|
| Ясен модел на данните за основните обекти | Административни екрани и справки |
| Вход и сесии чрез добре изпитана рамка или библиотека | Визуален блясък отвъд чисто и удобно |
| Миграции на базата данни, пазени в кода | Мащабиране върху няколко сървъра |
| Автоматични тестове за плащанията, входа и промените в данните | Тестове за всеки екран |
| Код, хостинг и акаунти на ваше име | Отделни услуги или микросървисна архитектура |
| Резервни копия и основно записване на грешките | Сложни табла за наблюдение |
Изберете утвърдена технология с добра документация, която познават много разработчици, за да можете по-късно да разширите или смените екипа. Не проектирайте за милиони потребители, преди да имате стотици. Едно добре изградено приложение на обикновен хостинг може да носи MVP дълго време и се променя много по-лесно от разпределена система.
Когато сте готови да говорите с разработчици, кратко задание за софтуерния проект, изградено около формулировката на проблема и основния сценарий, ще ви донесе по-точни оценки. Ако основният въпрос е бюджетът, статията колко струва изработката на уеб приложение обяснява кои решения влияят най-силно на цената.
#Как може да помогне PN Scripts
PN Scripts изработва уеб приложения и MVP с утвърдени технологии, като започваме с писмен обхват и оценка, които одобрявате, преди да започне работата. На всеки две или три седмици виждате работеща версия, така че можете да променяте обхвата, докато научавате нови неща. Ако вече имате формулиран проблем и основен сценарий, вижте как подхождаме към уеб разработката по поръчка.
Коментари
Коментари
Напишете първия коментар.
Оставете коментар