Как да определите обхвата на MVP: сведете първата версия до това, което наистина има значение

Почти всеки, който идва при нас с идея за приложение, вече е изградил пълната ѝ версия в главата си. Може да опише таблото за управление, страницата с настройки, реферал програмата, тъмния режим. Това, което обикновено не може да каже, е коя единствена част от тази картина, ако проработи, би направила цялото начинание оправдано. Да определиш обхвата на MVP е безславната, леко болезнена работа да откриеш точно тази част — и да имаш смелостта да оставиш останалото за по-късно.

Наблюдавал съм как се изграждат много първи продукти и тези, които се мъчат, почти никога не се провалят, защото екипът е бил мързелив. Провалят се, защото обхватът е бил грешен още от първата седмица. В първата версия е натъпкано прекалено много, бюджетът е свършил, преди някой да научи каквото и да било, и към момента на пускане екипът е похарчил всичко само за да стигне до стартовата линия — без пари, с които да реагира на това, което реалните потребители всъщност са направили.

Затова това е ръководството, което давам на хората, преди да бъде написан и един ред код. Не става дума за Agile ритуали или модни рамки. Става дума за един честен въпрос — кое е най-малкото нещо, което можем да изградим и което да ни покаже дали тази идея е истинска? — и дисциплината да продължаваш да отговаряш на него, докато изкушението да добавиш „само още една функция“ се промъква обратно. Защото то винаги се промъква обратно.

Какво всъщност е MVP (и какво не е)

Изразът е изтъркан от прекомерна употреба, затова нека бъдем точни. Минималният жизнеспособен продукт е най-малката версия на вашата идея, която носи реална стойност на реален потребител и ви учи на нещо, което не бихте могли да научите от презентация. Думата, която хората забравят, е жизнеспособен. Той трябва наистина да работи за някого, от край до край, дори да прави само едно нещо.

Ето какво MVP не е. Не е полузавършена версия на пълния продукт със счупени ъгли навсякъде. Не е прототип, който изхвърляте. И определено не е „евтината версия“ — евтиното е страничен ефект от добрия обхват, а не целта. Целта е учене. Харчите възможно най-малко пари, за да отговорите на най-скъпия въпрос, който имате: ще го използва ли някой и ще го използва ли по начина, по който си мисля?

Това разграничение има по-голямо значение, отколкото звучи. Манталитетът „първите 20%“ води до нещо, което е счупено във всяка посока и полезно в нито една. „Едно нещо, направено както трябва“ води до нещо, което човек може да вземе, да използва наистина и да си състави мнение за него. Мненията са целият смисъл. Не можете да правите итерации върху мълчание.

Капанът на прекаленото строене и защо е толкова лесно да попаднеш в него

Никой не тръгва с намерението да преоразмери обхвата. Това се случва с по едно разумно решение наведнъж. Добавяте вход, защото, разбира се, имате нужда от акаунти. Акаунтите означават поток за нулиране на парола, потвърждение по имейл и страница с настройки. Настройките означават профил, който означава качване на снимки, което означава място за съхранението им. Всяка стъпка сама по себе си е логична. Натрупани заедно, сте похарчили два месеца и част от бюджета, преди частта, която прави идеята ви специална, изобщо да е започната.

Другата половина от капана е емоционална. Орязването на функции усеща се като признание, че идеята ви е малка. Не е — то е признание, че още не знаете кои функции имат значение, което е просто истината. Всяка функция, която изграждате, преди да имате потребители, е залог, направен на сляпо. Някои от тези залози ще са грешни, а тези, които сте отрязали от MVP, са възможно най-евтините залози, в които да сгрешите, защото никога не сте ги направили.

Открийте единствената задача, която вашето MVP трябва да изпълни

Всеки продукт, колкото и голям да става в крайна сметка, има основен цикъл — единствената последователност, която потребителят повтаря и която създава стойността. За приложение за резервации това е намери час, резервирай го, получи напомняне. За пазар това е пусни обява, някой я намира, парите сменят собственика си. За вътрешен инструмент това е въведи данните веднъж, използвай ги навсякъде. Всичко останало в продукта съществува, за да поддържа, украсява или разширява този цикъл. Вашето MVP е цикълът. Само цикълът.

За да откриете вашия, довършете това изречение на глас: „Потребителят идва в моя продукт, за да ______, и е доволен, ако ______.“ Първото празно място е задачата. Второто е как ще разберете, че е проработило. Ако не можете да попълните и двете на един дъх, още не сте открили ядрото — и не сте готови да определяте обхват, камо ли да строите.

Бъдете безпощадни към разликата между основния цикъл и нещата, които изглеждат съществени, но не са. Входът изглежда съществен. Обикновено не е, в първата версия — много MVP стартират с един споделен линк, ръчна покана или изобщо без акаунти и научават всичко необходимо, преди да изградят машинарията за удостоверяване. Аналитичните табла изглеждат съществени. Не са; можете да четете базата данни ръчно, когато имате единайсет потребители. Сведете до цикъла и ще се изумите колко много отпада.

Сортирайте всяка функция в „трябва“, „би било добре“ и „няма“

Щом веднъж сте назовали основния цикъл, вземете големия си списък с функции и сортирайте всяка от тях в три кошници. Кошниците са нарочно груби, защото грубото е това, което спира безкрайните разговори от рода на „ама може би“.

• Трябва: основният цикъл буквално не функционира без нея. Ако я премахнете, няма продукт. Дръжте този списък шокиращо къс — обикновено три до шест позиции.
• Би било добре: прави продукта по-добър, но цикълът работи и без нея. Всичко тук чака втора версия. Без изключения в първата версия.
• Няма (засега): функциите, които съзнателно избирате да не изграждате сега. Записването им има значение — така уверявате себе си и екипа си, че идеята не се изоставя, а само се подрежда по ред.

Хитростта, която кара това да работи, е третата кошница. Повечето хора спорят само за „трябва“ срещу „би било добре“, което е изтощително и никога не свършва. Списъкът „няма засега“ е там, където живее облекчението — той е обещание към бъдещото ви „аз“, че готината идея е в безопасност и насрочена, просто не сега. Щом хората повярват, че нищо не се изхвърля, спират да се борят да задържат всичко в първата версия.

Определяйте обхвата по време и пари, не по списък с функции

Ето една тиха промяна, която променя всичко: спрете да определяте обхвата по „какво искаме“ и започнете да го определяте по „какво се събира в бюджета и срока“. Решете първо колко пари и колко седмици сте готови да похарчите, за да отговорите на основния си въпрос. После съберете списъка с функции в тази кутия. Звучи наобратно, но това е най-полезното ограничение, което можете да си наложите, защото то налага приоритизирането, което иначе бихте избягвали.

Фиксираната кутия върши и нещо психологическо. Когато бюджетът е без край, всяка функция е спорна и списъкът само расте. Когато кутията е фиксирана — да речем, осем седмици и определена сума — разговорът се обръща. Спира да бъде „да добавим ли това?“ и става „какво излиза, ако това влезе?“ Точно вторият въпрос изгражда добри MVP. Компромисите са видими, вместо скрити, и екипът ги прави целенасочено.

Реален пример: свеждане на обхвата на идея за управление на поръчки

Нека го направя конкретно с случай, по който работихме — анонимизиран, но верен на това как протичат тези неща. Малка фирма за отопление и водопровод дойде при нас с желание за приложение за изнесения си екип. Заданието на хартия беше огромно: планиране на поръчки в реално време, GPS проследяване на ванове, клиентски портал, автоматично фактуриране, инвентар на частите във всяко превозно средство, конструктор на оферти, фотодокументация и пакет за отчети за собственика. Наистина полезен продукт, в крайна сметка. Като първа версия — гарантиран начин да похарчиш годишен бюджет, преди да научиш каквото и да било.

Затова направихме упражнението. Зададохме на собственика изречението: „Потребителят идва тук, за да ______, и е доволен, ако ______.“ След известно лутане се появи истинският отговор. Най-голямата ежедневна болка на техниците не беше планирането или фактурирането — а обиколката на документацията. Завършваха поръчка, надрасквали часове и части на лист, връщали се обратно и някой в офиса препечатвал всичко наново в счетоводната система, често дни по-късно, често с грешки. Основният цикъл беше просто: заснемете какво се е случило на поръчката веднъж, на място, така че никой да не препечатва.

Какво влезе в обхвата — и какво не

Всичко беше сортирано. Кошницата трябва се сведе до четири неща: списък с днешните поръчки за всеки техник, проста форма за записване на часове и използвани части по поръчка, прикачване на снимка и начин офисът да вижда тези данни в мига на подаването им. Това беше цялото MVP. Без GPS, без клиентски портал, без конструктор на оферти, без сложни отчети — всичко това паркирано, изрично, в списъка „няма засега“ с бележка, че предстои.

Изградихме това ядро за няколко седмици, вместо за почти цяла година. И ето частта, която оправдава целия подход: щом веднъж заработи, реалните приоритети на екипа се оказаха различни от заданието. Собственикът беше предположил, че GPS проследяването ще е следващото; техниците почти не го споменаха. Това, което искаха, на глас, беше да изпратят на клиента прозорец за пристигане чрез SMS от вътре в приложението — функция, която дори не беше в първоначалния списък. Тъй като MVP беше малко и евтино, остана бюджет да се изгради това, което всъщност искаха, вместо това, което бяха предположили месеци по-рано.

Грешките, които тихо съсипват обхвата на MVP

Дори екипи, които приемат „дръжте го малко“, обикновено се спъват в едни и същи няколко неща. Никое от тях не е драматично. Това са бавни течове, които наново раздуват обхвата, докато не гледате, докато един ден „минималният“ продукт отново има трийсет екрана и шестмесечен график.

• Позлатяване на ръбовете: прекарвате дни в усъвършенстване на административен панел, който само вие ще виждате, докато основният цикъл е още груб. Полирайте това, до което потребителите се докосват; оставете задния офис грозен и функционален.
• Строене за мащаб, който нямате: архитектура за милион потребители, когато трябва да докажете, че първите десет ще се върнат. Решете проблема с мащаба, когато имате щастливия проблем на мащаба.
• Объркване на „задължително“ с „стандарт за бранша“: само защото всеки конкурент има функция X, не значи, че вашето MVP се нуждае от нея, за да тества основната ви идея. Не пускате завършен продукт, провеждате експеримент.
• Проектиране на всеки граничен случай предварително: обработка на редките, странни входни данни, преди да знаете дали някой изобщо използва обичайния, нормален път. Оставете реалната употреба да ви каже кои гранични случаи изобщо са истински.
• Без дефиниция за готовност: без записан ред, описващ как изглежда „завършено“, строежът никога не свършва. Разрастването на обхвата обича проект без финална линия.

Ако се пазите само от едно от тези, нека е последното. Ясна, записана дефиниция за готовност — „техник може да запише часовете и частите на поръчка от телефона си, а офисът ги вижда мигновено“ — е най-мощният инструмент за честен обхват. Всяко предложено допълнение се преценява спрямо това изречение. Ако не служи на изречението, то е идея за втора версия, колкото и добра да е.

Прост процес за определяне на обхвата на вашето MVP

Като събера всичко заедно, ето последователността, която бих преминал с всеки преди започване на първа версия. Тя е нарочно нискотехнологична — повечето можете да направите с документ и честен разговор, доста преди да имате нужда от програмист в стаята.

1. 1
   Назовете основния цикъл

   Довършете изречението: „Потребителят идва, за да ___, и е доволен, ако ___.“ Ако не можете, не сте готови да определяте обхват — продължавайте да говорите, докато истинската задача изплува.
2. 2
   Изсипете всяка функция, после сортирайте

   Извадете целия списък с желания от главата си на хартия. Сортирайте всяка позиция в „трябва“, „би било добре“ или „няма засега“. Дръжте списъка „трябва“ безпощадно къс.
3. 3
   Фиксирайте кутията

   Решете бюджета и срока, преди да финализирате списъка с функции. Накарайте списъка да се събере в кутията, не обратното.
4. 4
   Напишете дефиницията за готовност

   Едно конкретно изречение, описващо работещия основен цикъл. Това е вашият щит срещу разрастването на обхвата за остатъка от проекта.
5. 5
   Изградете, пуснете, наблюдавайте, после решете

   Пуснете ядрото пред реални потребители. Наблюдавайте какво всъщност правят. Оставете тяхното поведение — не предишните ви предположения — да избере какво следва от списъка „би било добре“.

Забележете, че последната стъпка ви връща в началото. Доброто MVP не е еднократно събитие, то е първото завъртане на колело. Определяте малък обхват, пускате, учите и това, което научите, преоразмерява следващата версия. Печелят не екипите, които са планирали перфектния продукт предварително — никой не прави това. Печелят тези, които са поставили нещо реално пред потребителите достатъчно бързо, че реалността още да може да ги насочи.

Често задавани въпроси