MVP fejlesztés: hogyan indíts kicsi, de működő első változattal?

Az MVP (minimum viable product) magyarul nagyjából a legkisebb életképes változatot jelenti. Startupoknál azt szokták vele kipróbálni, van-e piaca egy ötletnek. Egy cég belső szoftverénél a kérdés más: mi az a legkisebb rendszer, amellyel a csapat a fő feladatot már a régi táblázatok helyett az új eszközben végzi el?

Mi az MVP, és mi nem az?

Az MVP nem prototípus. A prototípus megmutatja, hogyan nézne ki valami, az MVP-vel viszont valódi munka folyik, valódi adattal. Ezért ami benne van, annak megbízhatóan kell működnie: bejelentkezés, jogosultság, mentés és hibakezelés nem maradhat ki csak azért, mert első változatról van szó. Ami kimarad, az a funkciók száma, nem a minőség.

Mi kerüljön az első változatba?

• Egy fő folyamat elejétől a végéig: például az ajánlattól a számláig, vagy a bejelentéstől a lezárt munkáig.
• A nélkülözhetetlen szerepkörök: akik nélkül a folyamat nem megy végig, általában kettő-három.
• A valós adatok: a meglévő ügyfelek, termékek, árak, mert próbaadattal nem derülnek ki a kivételek.
• Egyetlen fontos kapcsolat: ha a számlázó nélkül nincs értelme a rendszernek, akkor az; a többi várhat.
• Mérés: egy-két szám, amiből az indulás után látszik, javult-e valami, például a feldolgozási idő.

Mi maradjon ki az első körből?

• Ritka kivételek, amelyeket havonta egyszer-kétszer kézzel is meg lehet oldani.
• Egyedi riportok és kimutatások: előbb gyűljön adat, aztán derül ki, mit érdemes látni.
• Kényelmi funkciók: tömeges műveletek, testreszabható nézetek, értesítések minden eseményről.
• Második és harmadik integráció, ha az első nélkülük is használható.
• Natív mobilalkalmazás, ha a feladat böngészőből vagy telepíthető webes alkalmazásként is elvégezhető.

Példa: egy munkalapkezelő első változata

Az egyedi szoftver költségbecslőnk óramodelljével számolva egy ilyen első változat nagyjából 150–200 munkaóra, a teljes elképzelés ennek két-háromszorosa is lehet. A különbség az, hogy az első változat hetek alatt használatba kerül, és a második kör már a valós tapasztalatokra épül. Hogyan néz ki egy ilyen rendszer a gyakorlatban, azt az elektronikus munkalap program oldalán és a munkalapkezelő bemutatóban mutatjuk meg.

Hogyan tervezd meg?

1. Írd le a fő folyamatot lépésenként: ki mit csinál, milyen adattal, és mi a kivétel. Ehhez a szoftver-követelményspecifikáció mintánk ad keretet.
2. Minden igény mellé írd oda, mi történik, ha nincs meg. Ami nélkül a folyamat megáll, az első körbe kerül.
3. Határozz meg egy-két mérőszámot, és mérd meg a mostani állapotot.
4. Jelölj ki kulcsfelhasználókat, akik az első hetekben visszajeleznek.
5. Tervezz a második körre is keretet: az MVP nem a vége, hanem az eleje.

Tipikus buktatók

• Az MVP mint olcsóbb, félkész rendszer: ha a kevesebb funkció helyett gyengébb minőség a cél, a csapat nem fogja használni.
• Túl sok szerepkör az elején: minden új szerepkör jogosultságot, felületet és tesztet jelent.
• Nincs mérés: ha nem tudod, mit vársz, a második kör tartalma vitán dől el, nem adaton.
• Nincs második kör: ha az első változat után elfogy a keret, a rendszer félúton marad.

A keretet az egyedi szoftver költségbecslővel számolhatod ki, az ütemezéshez a fejlesztési időről szóló cikkünk ad támpontot. Böngészőből használt rendszert webalkalmazás-fejlesztésként építünk; ha a telefon képességei kellenek, mobilalkalmazást. A teljes folyamatot a szoftverfejlesztési szolgáltatásunk írja le.