Čo je MVP a ako určiť rozsah bez zbytočných nákladov

01MVP potrebuje otázku, nie skrátený zoznam funkcií

MVP je minimálny životaschopný produkt. Podľa pôvodného vysvetlenia Erica Riesa má umožniť učenie o zákazníkoch s čo najmenším potrebným úsilím. Počet obrazoviek ani množstvo hotového kódu teda nestačia na jeho definíciu. Podstatné je, aké rozhodnutie má prvá verzia umožniť.

Začnite hypotézou v jednej vete: konkrétny človek v konkrétnej situácii použije naše riešenie na konkrétny výsledok. Pridajte dôkaz, podľa ktorého poznáte, že sa to deje. Pri rezervačnej službe môže byť dôkazom dokončená rezervácia použiteľného termínu. Registrácia účtu ešte nehovorí, či služba pomohla.

Oddeľte záujem o problém, schopnosť dokončiť úlohu a ochotu platiť. Rozhovor môže pomôcť pochopiť problém, ale nenahrádza skúsenosť s fungujúcou službou. Bezplatné používanie zas nepotvrdzuje navrhnutú cenu. Vyberte otázku, ktorej neistota dnes najviac bráni investícii. Širší postup overovania nápadu rozoberáme pri ceste od nápadu k MVP.

• Cieľová skupina: kto presne a pri akej potrebe príde.
• Výsledok: čo má používateľ úspešne dosiahnuť.
• Neistota: čo si tím zatiaľ iba myslí.
• Dôkaz: aké pozorovanie zmení ďalšie rozhodnutie.

02Vyberte najrizikovejší predpoklad a lacnejší spôsob overenia

Marty Cagan zo SVPG rozlišuje riziko hodnoty, použiteľnosti, technickej uskutočniteľnosti a fungovania riešenia pre firmu. Tento rámec pomáha zistiť, prečo nestačí iba potvrdiť, že vývojár dokáže aplikáciu postaviť. Používateľ ju musí chcieť, vedieť použiť a firma musí zvládnuť jej prevádzku.

Ak je otázkou zrozumiteľnosť objednávky, skúste najprv klikateľný prototyp. Ak je otázkou prístup k dátam partnera, pripravte technický dôkaz na konkrétnej integrácii. Ak je otázkou reálne používanie služby, potrebujete funkčný tok a schopnosť obslúžiť jeho výsledok. Každý z týchto krokov odpovedá na inú otázku.

Aj metodika alpha fázy GOV.UK odporúča skúšať rizikové predpoklady pomocou prototypov. Ide o postup britských verejných služieb, nie o záväzný harmonogram slovenského startupu. Prenositeľná je myšlienka overiť neistotu pred tým, ako tím zaplatí za celé riešenie.

03Zúžte publikum a zachovajte úplný používateľský tok

Prvá verzia môže obslúžiť jednu skupinu zákazníkov, jeden typ služby alebo jednu prevádzku. Takéto zúženie zjednoduší pravidlá aj podporu. Používateľ však musí dokončiť sľúbenú úlohu. Formulár bez spracovania žiadosti nie je úplná rezervačná služba, hoci funguje bez chyby.

Modelový príklad: servis chce overiť online objednávanie pravidelnej údržby. MVP môže ponúknuť konkrétnu službu, dostupný termín, kontaktné údaje, potvrdenie a spôsob zrušenia. Nemusí hneď zahŕňať všetky opravy, vernostný program ani dynamické oceňovanie. Potrebuje však zabezpečiť, aby rezerváciu dostal človek, ktorý ju vie vybaviť.

Rozsah si nakreslite od príchodu používateľa po výsledok v prevádzke. Označte, čo urobí aplikácia, čo pracovník a kde môže vzniknúť výnimka. Ak pracovník ručne potvrdí termín, zákazník musí vedieť, že zatiaľ odoslal žiadosť. Rozhranie nesmie sľúbiť okamžite platnú rezerváciu, ktorú prevádzka ešte neschválila.

Ručnú prácu merajte: čas na obsluhu, chyby, kapacitu a opakujúce sa otázky. Pomôže rozhodnúť, ktorú časť má zmysel automatizovať. Fungovanie pilotu s osobnou pomocou nesmie viesť k záveru, že rovnaká ekonomika platí aj pri samostatnej masovej prevádzke.

04Funkcie rozdeľte podľa ich vzťahu k dôkazu

Pri každej požiadavke položte otázku: bez tejto funkcie nedokážeme overiť hypotézu, alebo iba odkladáme pohodlie? Export pre účtovníctvo môže byť nutný pri reálnych platených objednávkach. Pokročilé filtre v administrácii môžu počkať, ak malý pilot zvládne jednoduchý prehľad. Rozhoduje konkrétny tok, nie všeobecný zoznam obľúbených funkcií.

• Nutné na výsledok: používateľ bez nich nedokončí základnú úlohu.
• Nutné na dôveryhodnú prevádzku: prístupové práva, ochrana údajov, podpora a spracovanie chýb.
• Vhodné na neskôr: pohodlie alebo rozšírenie pre segment, ktorý zatiaľ netestujete.
• Vylúčené z pilotu: požiadavky bez väzby na otázku a vybrané publikum.

Vylúčené funkcie zapíšte rovnako jasne ako tie zahrnuté. Pri novom nápade potom tím vidí, čo by sa muselo presunúť alebo prečo treba upraviť rozpočet. Bez tohto zoznamu vzniká prvá verzia, ktorá má byť súčasne pilotom, univerzálnym produktom aj ukážkou budúcich možností.

Neodkladajte bezpečnosť alebo povinnosti voči ľuďom len preto, že produkt nesie názov MVP. Rozsah údajov, oprávnenia a prevádzkové pravidlá prispôsobte reálnemu pilotu. Úsporu hľadajte aj v tom, že citlivé údaje vôbec nepotrebujete zbierať. Technický plán môže byť jednoduchý, ale musí zodpovedať skutočnému použitiu.

05Rozpočet uvoľňujte podľa výsledku, nie podľa nadšenia

Rozdeľte investíciu na overenie rizika, dodanie funkčného pilotu a jeho vyhodnotenie. Ku každej etape priraďte limit v eurách, zodpovednú osobu a podmienku, za ktorej sa uvoľní ďalšia časť. Samotné dokončenie obrazoviek nie je dôvod na financovanie širšieho produktu.

Do rozpočtu zahrňte výskum, návrh, vývoj, testovanie, infraštruktúru, podporu a čas ľudí, ktorí obsluhujú pilot. Zapisujte aj služby tretích strán a rozdiel medzi jednorazovým výdavkom a pravidelným nákladom. Ponuky dodávateľov porovnávajte pri rovnakom rozsahu a pravidlách odovzdania, vrátane režimu DPH.

Pri nejasnej integrácii objednajte najprv obmedzené overenie. Z jeho výsledku môže vyplynúť, že potrebný prístup partner neposkytne. To je užitočný dôvod zmeniť plán pred väčšou investíciou. Podobne zistenie, že ľudia službu nechcú bez osobného vysvetľovania, môže zmeniť produkt aj predajný postup.

Pri každej etape určte aj výstup pre vlastníka rozpočtu. Môže ním byť záznam pozorovaní, funkčná ukážka a prehľad nákladov, nie iba faktúra za odpracovaný čas. Dodávateľ má vedieť, čo odovzdá a ktoré závislosti musí zabezpečiť firma. Tak sa neistota nezamieňa s neobmedzeným zadávaním ďalšej práce.

Nevyberajte architektúru podľa hypotetického milióna používateľov. Pomenujte potrebnú kapacitu pilotu, obnovu dát a podmienky rozšírenia. Väčší systém riešte, keď existuje konkrétny dôvod a rozpočet. Výpočet budúcich nákladov a prínosov rozoberáme pri návratnosti investície do softvéru.

06Dohodnite meranie a rozhodnutie pred spustením

Pred pilotom zapíšte, kto môže vstúpiť, ako sa k službe dostane a čo považujete za dokončenú úlohu. Rozlišujte ľudí z cieľovej skupiny od kolegov a známych. Zaznamenajte aj pomoc pracovníka, chyby a dôvod, prečo človek skončil. Inak neviete, či meriate produkt alebo ochotu tímu pomáhať.

Úspech neposudzujte len podľa počtu návštev. Sledujte dokončenie výsledku, námahu zákazníka, opakované použitie tam, kde dáva zmysel, a náklady obsluhy. Ak overujete ochotu platiť, musí pilot umožniť jej poctivé posúdenie. Kliknutie na tlačidlo s cenou nie je to isté ako zaplatená a vybavená objednávka.

Malý pilot dáva užitočné pozorovania, ale jeho výsledok nemusí reprezentovať celý trh. Uvádzajte počet oslovených a zapojených ľudí, okolnosti, verziu produktu aj spôsob náboru. Nenazývajte niekoľko rozhovorov dôkazom konkrétneho podielu záujemcov v populácii.

Dohodnite termín vyhodnotenia a pravidlá pokračovania. Ak sa výsledok nedá posúdiť, pomenujte chýbajúci dôkaz a cenu ďalšieho overenia. Neupravujte kritériá spätne iba preto, aby pilot vyzeral úspešne. Pri pozitívnom výsledku najprv rozšírte to, čo sa osvedčilo, a sledujte, či platí aj pri menšej osobnej pomoci.

07Jednostranové zadanie udrží tím pri rovnakej otázke

Pred odhadom vývoja pripravte krátke zadanie, ktoré spolu odsúhlasí vlastník produktu, návrhár a vývojár. Majú rozumieť rovnakému problému a vedieť, čo sa má po pilote rozhodnúť. Podrobné zadania obrazoviek vytvárajte až v rámci tejto dohody.

Do prijatia verzie zahrňte aj bežnú výnimku: používateľ zmení termín, zopakuje odoslanie alebo nedostane potvrdenie. Malý rozsah neznamená testovanie iba ideálneho priebehu. Keď firma pozná pravidlá pre tieto situácie, vie prevziať pilot a obslúžiť zákazníka bez improvizácie. Výnimky mimo rozsahu musia mať jasný postup, napríklad kontakt na podporu.

1. Zapíšte cieľovú skupinu, problém a hlavnú hypotézu.
2. Popíšte úplný používateľský tok vrátane ručnej obsluhy.
3. Rozlíšte zahrnuté funkcie, odložené možnosti a hranice kvality.
4. Určte meranie, pravidlá vyhodnotenia a zodpovednú osobu.
5. Priraďte rozpočet, etapy, prevádzkové náklady a podmienky ďalšej investície.
6. Dohodnite odovzdanie, podporu, prístupy a riešenie zmien rozsahu.

Ak počas práce pribudne nová požiadavka, vráťte sa k hypotéze. Zmena môže byť potrebná, ale musí mať vysvetlenie a dopad na cenu alebo termín. Na plán širšieho produktu môže nadviazať príprava vývoja SaaS.

08Časté otázky o rozsahu MVP