Hogyan határolja körül egy MVP terjedelmét: szűkítse az első verziót arra, ami valóban számít

Szinte mindenki, aki egy alkalmazásötlettel jön hozzánk, a fejében már megépítette annak teljes változatát. Le tudja írni az irányítópultot, a beállítások oldalt, az ajánlói programot, a sötét módot. Amit általában nem tud megmondani, az az, hogy annak a képnek melyik egyetlen része tenné — ha működne — az egész vállalkozást érdemessé. Egy MVP körülhatárolása az a látványtalan, kissé fájdalmas munka, amelynek során megtalálja azt az egyetlen részt — és van mersze a többit későbbre hagyni.

Sok első termék születését láttam, és amelyik küszködik, az szinte sosem azért bukik el, mert a csapat lusta volt. Azért bukik el, mert a terjedelem már az első héten rossz volt. Túl sok minden került az első verzióba, a költségvetés elfogyott, mielőtt bárki bármit tanult volna, és az indulásig a csapat mindent elköltött csak arra, hogy eljusson a rajtvonalig — pénz nélkül, hogy reagáljon arra, amit a valódi felhasználók ténylegesen tettek.

Ez tehát az az útmutató, amelyet azelőtt adok az embereknek, hogy egyetlen sornyi kód is megíródna. Nem az agilis rituálékról vagy a flancos keretrendszerekről szól. Egyetlen őszinte kérdésről szól — mi a legkisebb dolog, amit megépíthetünk, és amely megmondja nekünk, hogy ez az ötlet valós-e? — és arról a fegyelemről, hogy folyamatosan megválaszoljuk, miközben a „még csak egy funkciót” kísértése visszaszivárog. Mert mindig visszaszivárog.

Mi valójában egy MVP (és mi nem)

A kifejezést a túlzott használat elkoptatta, legyünk hát pontosak. A minimális életképes termék az ötlete legkisebb változata, amely valódi értéket nyújt egy valódi felhasználónak, és megtanít valamire, amit egy diavetítésből nem tudhatott volna meg. A kulcsszó, amelyről megfeledkeznek, az életképes. Valakinek ténylegesen működnie kell, elejétől a végéig, még ha csak egyetlen dolgot is csinál.

Íme, mi nem egy MVP. Nem a teljes termék félkész változata, mindenütt törött sarkokkal. Nem egy prototípus, amelyet eldob. És határozottan nem „az olcsó változat” — az olcsóság a jó körülhatárolás mellékhatása, nem a cél. A cél a tanulás. A lehető legkevesebb pénzt költi a legdrágább kérdés megválaszolására, amelyet feltehet: használja-e ezt egyáltalán valaki, és úgy használja-e, ahogy gondolom?

Ez a megkülönböztetés fontosabb, mint amilyennek hangzik. Az „első 20 százalék” szemlélet olyasmihez vezet, ami minden irányban törött, és egy irányban sem hasznos. Az „egyetlen dolog, rendesen megcsinálva” olyasmihez vezet, amit az ember kézbe vehet, ténylegesen használhat, és véleményt alkothat róla. A vélemények jelentik a teljes lényeget. A csenden nem lehet iterálni.

A túlépítés csapdája, és miért olyan könnyű beleesni

Senki sem szándékosan lépi túl a terjedelmet. Egyszerre egy ésszerű döntéssel történik. Hozzáadja a bejelentkezést, mert természetesen fiókokra van szükség. A fiókok jelszó-visszaállítási folyamatot, e-mail-megerősítést és egy beállítások oldalt jelentenek. A beállítások profilt jelentenek, ami képfeltöltést jelent, ami tárhelyet jelent ezeknek. Minden lépés önmagában ésszerű. Egymásra rakva azonban két hónapot és a költségvetés egy darabját költötte el, mielőtt az a rész, amely különlegessé teszi az ötletét, egyáltalán elkezdődött volna.

A csapda másik fele érzelmi. A funkciók kihúzása olyan, mintha beismerné, hogy az ötlete kicsi. Pedig nem — azt ismeri be, hogy még nem tudja, mely funkciók számítanak, ami egyszerűen az igazság. Minden funkció, amelyet azelőtt épít meg, hogy felhasználói lennének, egy vakon megtett fogadás. Néhány fogadás rossz lesz, és azok, amelyeket kihúz az MVP-ből, a lehető legolcsóbb fogadások, amelyekben tévedhet, mert sosem tette meg őket.

Találja meg az egyetlen feladatot, amit az MVP-jének el kell látnia

Minden terméknek, bármilyen naggyá is válik végül, van egy alaphurka — az egyetlen sorozat, amelyet a felhasználó megismétel, és amely az értéket teremti. Egy foglalási alkalmazásnál ez a találj egy időpontot, foglald le, kapj emlékeztetőt. Egy piactérnél ez a hirdess meg egy dolgot, valaki megtalálja, gazdát cserél a pénz. Egy belső eszköznél ez az egyszer rögzítsd az adatot, használd mindenhol. Minden más a termékben azért létezik, hogy ezt a hurkot támogassa, díszítse vagy bővítse. Az MVP-je maga a hurok. Csak a hurok.

Hogy megtalálja a sajátját, fejezze be hangosan ezt a mondatot: „A felhasználó azért jön a termékemhez, hogy ______, és akkor elégedett, ha ______.” Az első hiányzó rész a feladat. A második az, ahogyan megtudja, hogy működött-e. Ha nem tudja egy szuszra kitölteni mindkét hiányt, még nem találta meg a magot — és nem áll készen a körülhatárolásra, nemhogy az építésre.

Legyen könyörtelen az alaphurok és azon dolgok közötti különbséget illetően, amelyek létfontosságúnak tűnnek, de nem azok. A bejelentkezés létfontosságúnak tűnik. Az első verzióban általában nem az — rengeteg MVP egyetlen megosztott linkkel, kézi meghívással vagy egyáltalán fiókok nélkül indul, és mindent megtanul, amire szüksége van, mielőtt megépítené a hitelesítési gépezetet. Az analitikai irányítópultok létfontosságúnak tűnnek. Nem azok; az adatbázist kézzel is elolvashatja, amikor tizenegy felhasználója van. Csupaszítsa le a hurokig, és el fog ámulni, mennyi minden lemorzsolódik.

Sorolja minden funkciót háromfelé: kell, kellene és most nem

Miután megnevezte az alaphurkot, vegye elő a nagy funkciólistáját, és sorolja minden elemét három vödör egyikébe. A vödrök szándékosan nyersek, mert épp a nyerseség az, ami megállítja a véget nem érő „de talán” beszélgetéseket.

• Kell: az alaphurok szó szerint nem működik nélküle. Ha eltávolítja, nincs termék. Ezt a listát tartsa megdöbbentően rövidre — általában három-hat elem.
• Kellene: jobbá teszi a terméket, de a hurok nélküle is működik. Itt minden a második verzióra vár. Az első verzióban nincs kivétel.
• Most nem: azok a funkciók, amelyeket tudatosan úgy dönt, hogy most nem épít meg. Leírni őket fontos — így nyugtatja meg önmagát és a csapatát, hogy az ötletet nem hagyják el, csak sorba állítják.

A trükk, amitől ez működik, a harmadik vödör. A legtöbben csak a „kell” kontra „kellene” körül vitatkoznak, ami kimerítő, és sosem ér véget. A „most nem” lista az, ahol a megkönnyebbülés lakik — ígéret a jövőbeli énjének, hogy a klassz ötlet biztonságban van és ütemezve, csak épp nem most. Amint az emberek megbíznak abban, hogy semmit sem dobnak el, abbahagyják a harcot azért, hogy mindent benntartsanak az első verzióban.

Időben és pénzben határolja körül, ne funkciólistában

Íme egy csendes váltás, amely mindent megváltoztat: hagyjon fel azzal, hogy a „mit akarunk” alapján határoljon körül, és kezdje azzal, hogy a „mi fér bele a költségvetésbe és a határidőbe” alapján teszi. Először döntse el, mennyi pénzt és hány hetet hajlandó az alapkérdése megválaszolására fordítani. Aztán illessze a funkciólistát abba a dobozba. Fordítva hangzik, de ez a leghasznosabb korlát, amelyet önmagának adhat, mert kikényszeríti azt a rangsorolást, amelyet egyébként elkerülne.

A rögzített doboz pszichológiailag is tesz valamit. Amikor a költségvetés nyitott, minden funkció vitatható, és a lista csak nő. Amikor a doboz rögzített — mondjuk nyolc hét és egy adott összeg — a beszélgetés megfordul. Abbamarad a „hozzáadjuk ezt?”, és „mi esik ki, ha ez bekerül?” lesz belőle. Ez a második kérdés az, amely jó MVP-ket épít. A kompromisszumok láthatóvá válnak ahelyett, hogy rejtve maradnának, és a csapat szándékosan hozza meg őket.

Egy valós példa: egy terepi munkakezelő ötlet terjedelmének szűkítése

Tegyem ezt kézzelfoghatóvá egy esettel, amelyen dolgoztunk — anonimizálva, de hűen ahhoz, ahogy ezek zajlanak. Egy kis fűtés- és vízszerelő cég jött hozzánk, alkalmazást szeretett volna a terepi csapatának. A papíron lévő feladatleírás hatalmas volt: élő munkaütemezés, a furgonok GPS-követése, ügyfélportál, automatikus számlázás, alkatrészkészlet minden járműben, ajánlatkészítő, fotódokumentáció és egy jelentéscsomag a tulajdonosnak. Végeredményben valóban hasznos termék. Első verzióként viszont biztos módja annak, hogy egy év költségvetését elköltsék, mielőtt bármit tanulnának.

Így hát elvégeztük a gyakorlatot. Feltettük a tulajdonosnak a mondatot: „A felhasználó azért jön ehhez, hogy ______, és akkor elégedett, ha ______.” Némi ide-oda után felszínre került a valódi válasz. A technikusok legnagyobb napi fájdalma nem az ütemezés vagy a számlázás volt — hanem a papír oda-vissza útja. Befejeztek egy munkát, egy lapra firkálták az órákat és az alkatrészeket, visszahajtottak, majd valaki az irodában mindezt újragépelte a könyvelési rendszerbe, gyakran napokkal később, gyakran hibákkal. Az alaphurok egyszerűen ez volt: rögzítsd, mi történt a munkán, egyszer, a helyszínen, hogy senki ne gépelje újra.

Mi fért bele — és mi nem

Mindent besoroltunk. A kell vödör négy dologra szűkült: az aznapi munkák listája minden technikusnak, egy egyszerű űrlap az órák és a felhasznált alkatrészek munkánkénti rögzítésére, egy fotómelléklet, és egy mód, amellyel az iroda abban a pillanatban látja az adatokat, amint elküldik. Ez volt az egész MVP. Nincs GPS, nincs ügyfélportál, nincs ajánlatkészítő, nincs flancos jelentéskészítés — mind kifejezetten a „most nem” listára került, azzal a megjegyzéssel, hogy jönni fog.

Azt a magot néhány hét alatt megépítettük, csaknem egy év helyett. És íme a rész, amely az egész megközelítést igazolja: amint élesben működött, kiderült, hogy a csapat valódi prioritásai eltérnek a feladatleírástól. A tulajdonos azt feltételezte, hogy a GPS-követés lesz a következő; a technikusok alig említették. Amit hangosan akartak, az az volt, hogy az alkalmazáson belülről SMS-ben elküldhessék az ügyfélnek az érkezési időablakot — egy funkciót, amely az eredeti listán nem is szerepelt. Mivel az MVP kicsi és olcsó volt, maradt költségvetés arra, hogy megépítsék, amit valóban akartak, ahelyett, amit hónapokkal korábban kitaláltak.

A hibák, amelyek csendben tönkreteszik egy MVP terjedelmét

Még azok a csapatok is, amelyek elfogadják a „tartsuk kicsinek” elvet, ugyanazon a néhány dolgon szoktak megbotlani. Egyik sem drámai. Lassú szivárgások, amelyek visszafújják a terjedelmet, miközben nem figyel, mígnem egy nap a „minimális” termék megint harminc képernyő és hat hónapos ütemterv lesz.

• A szélek aranyozása: napokat tölteni egy adminisztrációs panel tökéletesítésével, amelyet csak ön fog látni, miközben az alaphurok még nyers. Csiszolja azt, amihez a felhasználók hozzáérnek; a háttérirodát hagyja csúnyán, de működőképesen.
• Olyan léptékre építeni, amilyenje nincs: egymillió felhasználóra tervezni az architektúrát, amikor azt kell bizonyítania, hogy az első tíz visszatér. A lépték problémáját akkor oldja meg, amikor megvan a lépték boldog problémája.
• A „nélkülözhetetlen” összekeverése az „iparági szabvánnyal”: attól, hogy minden versenytársnak megvan az X funkciója, az MVP-jének még nincs rá szüksége az alapötlet teszteléséhez. Nem kész terméket indít, hanem kísérletet végez.
• Minden határeset előzetes megtervezése: a ritka, fura bemenetek kezelése, mielőtt tudná, használja-e bárki a megszokott, normál útvonalat. Hagyja, hogy a valós használat mondja meg, mely határesetek egyáltalán valósak.
• A kész definíciójának hiánya: egy leírt mondat nélkül, amely megfogalmazza, hogy néz ki a „kész”, az építés sosem ér véget. A terjedelemkúszás imádja a célvonal nélküli projektet.

Ha csak egy ellen védekezik ezek közül, legyen az az utolsó. A kész egyértelmű, leírt definíciója — „egy technikus a telefonján rögzíteni tudja egy munka óráit és alkatrészeit, és az iroda azonnal látja” — a leghatékonyabb eszköz a terjedelem őszinteségének megőrzésére. Minden javasolt kiegészítést ehhez a mondathoz mérnek. Ha nem szolgálja a mondatot, az egy második verziós ötlet, bármilyen jó is.

Egy egyszerű folyamat az MVP-je körülhatárolásához

Mindezt összegezve, íme a sorrend, amelyet bárkivel végigjárnék egy első verzió megkezdése előtt. Szándékosan alacsony technológiai igényű — a nagy részét egy dokumentummal és egy őszinte beszélgetéssel elvégezheti, jóval azelőtt, hogy fejlesztőre lenne szüksége a szobában.

1. 1
   Nevezze meg az alaphurkot

   Fejezze be a mondatot: „A felhasználó azért jön, hogy ___, és akkor elégedett, ha ___.” Ha nem tudja, nem áll készen a körülhatárolásra — beszéljen tovább, amíg felszínre nem kerül a valódi feladat.
2. 2
   Öntse ki az összes funkciót, majd sorolja be

   Vegye ki a teljes kívánságlistát a fejéből, papírra. Sorolja minden elemét a kell, kellene vagy most nem közé. A „kell” listát tartsa brutálisan rövidre.
3. 3
   Rögzítse a dobozt

   Döntse el a költségvetést és a határidőt, mielőtt véglegesíti a funkciólistát. A listát illessze a dobozhoz, ne fordítva.
4. 4
   Írja le a kész definícióját

   Egyetlen konkrét mondat, amely leírja a működő alaphurkot. Ez a pajzsa a terjedelemkúszás ellen a projekt hátralévő részében.
5. 5
   Építsen, indítson, figyeljen, aztán döntsön

   Juttassa a magot valódi felhasználókhoz. Figyelje, mit tesznek ténylegesen. Hagyja, hogy a viselkedésük — ne a korábbi feltételezései — válassza ki, mi kerül le legközelebb a „kellené” listáról.

Vegye észre, hogy az utolsó lépés visszavezeti a kezdethez. Egy jó MVP nem egyszeri esemény, hanem egy kerék első fordulata. Kicsire határolja a terjedelmet, kiszállít, tanul, és amit tanul, az újrahatárolja a következő verzió terjedelmét. A győztes csapatok nem azok, amelyek előre megtervezték a tökéletes terméket — ezt senki sem teszi. Hanem azok, amelyek elég gyorsan tettek valami valódit a felhasználók elé ahhoz, hogy a valóság még irányíthassa őket.

Gyakori kérdések