MVP arendus: mida esimesse versiooni panna ja mida mitte

MVP arendus tähendab esimese versiooni ehitamist. MVP ehk minimaalne toode lahendab ühe päris probleemi ühele kasutajarühmale nii hästi, et nad seda tõesti kasutavad. Kui toode on mõeldud müügiks, peab leiduma keegi, kes on nõus selle eest maksma. Esimeseks versiooniks sobib sageli veebirakendus: see töötab nii arvutis kui telefonis.

Oletame, et väike paigaldusfirma võtab tellimusi vastu telefonil ja kirjutab need Exceli tabelisse. Tabelit muudavad kolm inimest. Keegi kirjutab kellegi teise rea üle ja keegi ei tea, kes homme kuhu sõidab. Seda näidet kasutame kogu postituse jooksul.

Üks protsess, üks kasutaja

"Minimaalne" tähendab väikest ulatust, mitte kehva kvaliteeti. Funktsioone on vähe, aga need töötavad. Firmal on kolm suurt teemat: tellimuste vastuvõtt, ajaplaneerimine ja arved. Esimeseks versiooniks võtame ühe, tellimuste vastuvõtu, ja ühe kasutaja, telefoni taga istuva koordinaatori. Ulatust saab kontrollida ühe lausega kujul "X teeb Y, et saada Z":

Koordinaator lisab tellimuse, et paigaldaja näeks homset tööd ilma helistamata.

Koordinaator on õige esimene kasutaja, sest tabeli all kannatab tema kõige rohkem. Ta ei hakka uut süsteemi viisakusest kasutama, vaid siis, kui see tema päeva päriselt lihtsamaks teeb. Seepärast saad temalt ka kõige ausama tagasiside.

Kui lausesse kipub teine kasutaja või teine tegevus, on ulatus liiga lai. Sama põhimõte kehtib ka valmis tootes. Tageris on üles ehitatud ühe töövoo ümber: üks kirje liigub QR-koodi skaneerimisest arveni ja andmeid ei pea vahepeal uuesti sisestama.

app.tageris.ee

Mis läheb sisse ja mis ootab

Sisse läheb kõik, ilma milleta see lause tõeks ei saa:

• Kontod ja õigused. Koordinaator muudab tellimusi, paigaldaja näeb ainult enda töid.
• Põhivoog algusest lõpuni. Tellimus tehakse, määratakse paigaldajale ja märgitakse tehtuks. Kui tellimus jõuab süsteemi, aga paigaldajani mitte, on see sama hea kui tabel.
• Kasutajate haldus. Uue paigaldaja võib alguses käsitsi lisada.
• Maksed ainult siis, kui just müüki tahadki proovile panna. Siin on tegu sisemise tööriistaga, seega makseid pole vaja.

Ootama jääb see, mille puudumine ei takista tellimust läbi käimast:

• Aruanded. Alguses piisab tellimuste ekspordist tabelisse.
• Integratsioonid. Tehtud tööd kantakse arveprogrammi käsitsi, kuni selgub, kas see üldse vaeva väärt on.
• Eraldi mobiiliäpp. Veebirakendus töötab ka paigaldaja telefonis. Kui ta töötab sageli levita keldris, tuleb võrguta töö kohe alguses arvesse võtta.
• Seadistuste vaated. Vajalikud valikud pannakse paika käsitsi.
• Harvad erandid. Tellimus kahele paigaldajale lahendatakse telefoniga, kuni näed, kas see kordub. Kui kordub, ehitad selle sisse.

Mille pealt kokku ei hoia

"Ajutine" kood jääb kasutusse. Kiire lahendus, mille kohta öeldi "parandame hiljem", on varsti see, millele kõik muu toetub. Kolm kohta tasub seepärast teha korralikult juba algusest.

• Andmemudel. Klient, tellimus ja paigaldaja on eraldi seotud kirjed, mitte üks lahter tabelis. Muidu tuleb iga uus funktsioon selle ümber ehitada.
• Õigused ja turvalisus. Klientide aadressid ja telefoninumbrid ei tohi olla kõigile nähtavad, isegi kui kasutajaid on ainult kolm.
• Varukoopiad. Kui andmed kaovad, kaovad kõik tellimused ja see, kes kuhu sõidab. Varukoopia puudumist ei märka keegi enne, kui seda vaja läheb.

Kuidas aru saada, et see töötab

• Koordinaator kasutab süsteemi ka siis, kui keegi seda meelde ei tuleta.
• Ta küsib ise juba järgmist: "Kas siia saaks ka ajad panna?"
• Ta oleks tõsiselt pahane, kui süsteem ära kaoks.
• Müügitoote puhul maksab keegi ilma pika veenmiseta.

Kui neid märke pole, lahendas esimene versioon valet probleemi või valele inimesele. Ka see on kasulik teada, enne kui ülejäänud funktsioonid on ehitatud.

Kuidas edasi

Vali protsess, mis praegu kõige rohkem kinni jookseb, ja kirjuta see üles ühe lausena, nagu ülal. Siis saame koos otsustada, mis läheb esimesse versiooni. Mida me ehitame, näed veebirakenduste lehelt, ja päris toote näite leiad portfooliost.