MVP arendus Eestis: mida kolme nädalaga päriselt valmis saab

Mida kolm nädalat hõlmab

Kolm nädalat on selles näites viisteist tööpäeva, mitte üldine tähtaeg. Tegelik töö ulatus ja kuupäev lepitakse enne algust kirjalikult kokku. Esimene töötav versioon valmib tavaliselt 1–2 nädalaga; näidiskava hõlmab sellele järgnevaid täiendusi, testimist ja üleandmist.

See näidiskava aitab enne tööd kontrollida, millised tegevused ajakavasse mahuvad ja millised tuleb eraldi kokku leppida.

Kolm nädalat jääb B2B SaaS arenduse lehel kirjeldatud 2–4-nädalase piiritletud MVP vahemiku keskele. See on näidistähtaeg suurema etapi lõpetamiseks, mitte lubadus, et iga toode valmib viieteistkümne tööpäevaga. Integratsioonileping või suurem põhivoog muudab kuupäeva.

Mis kolme nädalaga valmib

Selles näidisskoobis on kolm nädalat ühe tervikliku töövoo täiendamiseks, testimiseks ja üleandmiseks. Esimese töötava versiooni saab tavaliselt proovida varem, 1–2 nädalaga. Iga lisanduv punkt võtab ära aega millegi muu arvelt.

• Üks töövoog algusest lõpuni: kasutaja siseneb, teeb oma töö ära, näeb tulemust ja saab kinnituse.
• Sisselogimine. Väikese kasutajaskonna puhul Smart-ID, Mobile-ID või e-post ja parool. Ettevõtte SSO on eraldi töö.
• Andmete salvestus, otsing ja nimekirjavaated. Kui otsing on toote mõte, siis on see põhivoos; kui mitte, piisab filtreerimisest.
• Üks integratsioon. Üks tähendab ühte: kas registriandmed, pangamakse, e-arve või e-post, mitte kõik korraga.
• Kaks rollitaset. Tavaliselt „kasutaja“ ja „administraator“. Rohkem rolle saab lisada siis, kui päris kliendid on öelnud, mida nad eraldada tahavad.
• Teavitused. Üks e-kiri või süsteemiteade, mis ütleb, et midagi juhtus. Ilma selleta ei kasuta keegi toodet iseseisvalt.
• Paigaldus sinu pilvekontole ja sinu domeenile, käivitusjuhend ja arhitektuuriotsuste kirjeldus.
• Kood sinu repositooriumis ja taristu sinu kontrolli all. See peab paigas olema esimesest päevast.

Andmete eraldus ning raha ja juurdepääsu puudutavate muudatuste logimine kuuluvad esimesse kasutatavasse versiooni; nende vajadust ei määra kasutajate arv.

Mida see näidisskoop välja jätab

Järgmised tööd ei kuulu sellesse kokkulepitud näidisskoopi automaatselt. Need võivad mahtuda teise ajakavasse; kirjuta need pakkumises eraldi välja.

Kolm lõiget, mis töö ulatust vähendavad

Kui nimekiri tundub liiga pikk, vähenda töö ulatust, mitte ära püüa sama tööd kiiremini teha. Kolm lõiget, mis tavaliselt töötavad:

• Asenda teine vaade ekspordiga. Kui keegi tahab andmeid näha teises lõikes, piisab esimeses versioonis CSV-ekspordist, mille ta avab oma tabelis. Vaade ise tuleb siis, kui on selge, milliseid veerge ta vaatab.
• Asenda integratsioon käsitsi sammuga, mille koht on teada. Kui liides on ainult mugavus, mitte töövoo tingimus, jäta see teise etappi ja kirjuta kokku, et seni teeb inimene selle ühe sammu käsitsi. Nii jääb töövoog tervikuks ja liides ei blokeeri käivitamist.
• Jäta teine kasutajagrupp välja. Kui tootel on „tellija“ ja „teenusepakkuja“ vaated, ehita esimeses versioonis see pool, kes toote eest maksab. Teine pool saab esialgu e-kirja või PDF-i, mitte oma liidese.

Kirjuta need lõiked töö ulatusse koos sellega, millal need tagasi tulevad. Nimekiri, mis ütleb „hiljem“, on soovide nimekiri. Nimekiri, mis ütleb „teine etapp pärast seda, kui X on tõestatud“, on konkreetne kokkulepe.

Töö ulatus kolmes suuruses

Sama toodet saab arendada kolmes eri mahus. Vahe ei ole pingutuses, vaid selles, mida sa pärast esimest versiooni teha saad.

Kui sa ei oska valida, vali väiksem töö ulatus. Suurem ei anna varem rohkem infot. Väiksem aitab vastata küsimusele, mille pärast MVP üldse tehakse: kas keegi teeb selle abil oma töö ära ega taha enam vana tööviisi juurde tagasi minna.

Miks esimene versioon varem odavam on

Pikkade projektide kalleim osa ei ole arendus. See on aeg, mille jooksul otsused vananevad. Kui arveldus ehitatakse enne päris kasutajaid, ehitatakse plaanid vale kasutajagrupi järgi ja need tuleb ümber teha. Kui õiguste maatriks ehitatakse enne teist klienti, kirjeldab see ettevõtet, kus on üks roll.

Lühike tsükkel teeb sama asja vastupidi: iga paari päeva tagant näed töötavat versiooni, ütled, mis on valesti, ja see parandatakse enne, kui see läheb kalliks. See on ka põhjus, miks ma ei kirjuta kuue kuu spetsifikatsiooni. Spetsifikatsioon, mida ei ole veel ükski kasutaja proovinud, on oletus, mille hind selgub hiljem.

Sama loogika kehtib integratsioonide kohta. Kui ühendan raamatupidamise või e-arve alles siis, kui põhivoog töötab, tean juba, millised andmed välja lähevad. Vastupidi tehes ehitan liidese andmetele, mis muutuvad kolmandal nädalal.

Hind ja kirjalik töö ulatus

Enne tööd teen kaardistuse, mis on 0 €. Selle tulemus on kirjalik töö ulatus: kes kasutab toodet, millise töö teeb, millised funktsioonid kuuluvad esimesse etappi, millised jäävad välja ning mis on esimese etapi fikseeritud hind ja kuupäev.

Hinda mõjutavad neli asja ja nende töömahtu saab kokkuleppes piirata:

• Integratsioonide arv. Iga liides toob kaasa veakäsitluse, korduskatsed, logimise ja küsimuse, mida teha siis, kui teine süsteem ei vasta.
• Andmete seis. Olemasolev tabel, kus veerud on eri aegadest, tähendab tavaliselt rohkem tööd kui tühi leht.
• Rollide arv. Iga lisaroll on õiguste maatriksi rida ja igas vaates kontroll.
• AI hindamise maht. Kui tootes on AI, on vaja testnäidete kogumit ja viisi, kuidas hinnata, kas muudatus rikkus tulemuse.

Fikseeritud hind töötab ainult siis, kui töö ulatus ja muudatuste kord on kirjas. Kui töö ulatus muutub, lepin sinuga enne jätkamist kirjalikult kokku muudatuse sisu ning selle mõju hinnale ja ajakavale.

Kaks praktilist asja, mis hinda ja töö ulatust mõjutavad. Esiteks ei tasu ehitada oma arvemootorit: kui toode peab ise arveid väljastama, saab selle teha raamatupidamistarkvara liidese kaudu, sest näiteks Merit Aktiva API on REST- ja JSON-põhine ning nõuab Pro või Premium litsentsi. See on üks integratsioon, mitte uus moodul. Teiseks ära planeeri eelarvet toetuse peale: RTE äriprotsesside automatiseerimise toetuse taotlusvoor on suletud, sest eelarve täitus 1. septembril 2026. Kui toetus avaneb uuesti, on see lisavõimalus, mitte eeldus.

Kuidas hinnata, kas töö ulatus on realistlik

Enne kui kinnitad kolmenädalase näidiskava, küsi need viis küsimust. Kui mõnele ei ole vastust, tuleb töö ulatus või kuupäev ümber rääkida.

1. Mitu eri kasutajagruppi toodet kasutab?

   Üks kuni kaks on selle näidisskoobi eeldus. Kolm tähendab tavaliselt kolme erinevat avavaadet ja kolme erinevat õiguste loogikat.

2. Mitu välist süsteemi on põhivoos kohustuslik?

   Null kuni üks on selle näite eeldus. Iga kohustuslik liides, mis peab esimesel päeval töötama, surub põhivoo testimise ajakavasse hiljem.

3. Kas andmed on olemas ja kelle käes?

   Kui andmed on Excelis, kes need välja annab ja mis kujul? Kui keegi ei tea, on andmete teisendamine eraldi töö.

4. Kas makse on esimeses versioonis?

   Makse toob kaasa testkeskkonna, veebikonksud ja küsimuse topeltmaksetest. Selle töö ulatus lepitakse eraldi kokku.

5. Kes vastab pärast üleandmist?

   Kui tootel ei ole omanikku, kes kasutajate küsimustele vastab, ei saa esimest versiooni õigel ajal proovida.

Kuidas teada, kas esimene versioon töötas

Kolm kontrollküsimust aitavad hinnata, kas versioonist oli kasu:

• Kas töö tehti tootes või kõrval? Kui inimene kasutab toodet ja hoiab sama asja jaoks kõrval Excelit, ei ole toode veel töövoog, vaid lisavaade.
• Mitu käsitsi sammu kadus? Enne viis sammu, pärast kaks. Kui sammude arv ei muutunud, ei muutunud ka töö.
• Kas keegi kasutas seda ilma sinu juuresolekuta? Esimene päris märk on see, kui keegi teeb töö ära ja sa ei tea sellest enne, kui vaatad logi.

Kui need kolm vastust on olemas, põhineb järgmise etapi skoop andmetel, mitte soovide nimekirjal. Kui neid ei ole, on aus järeldus see, et esimene versioon valis vale töövoo. Ka see on kolme nädala eest kasulik tulemus, sest vale töövoo avastamine kolmandal nädalal on odavam kui kuuendal kuul.

Mida enne vestlust ette valmistada

Kaardistus on kiirem, kui sul on olemas kolm asja: näidis dokumentidest või tabelitest, millega töö käib; kirjeldus, kuidas töö praegu toimub, samm-sammult; ja esimese igapäevase kasutaja nimi.

• Üks lause: millise töö tegemiseks toode olemas on.
• Praegune protsess, isegi kui see on „Excel ja telefonikõned“.
• Kaks kuni kolm näidet andmetest, millega toode peab hakkama saama.
• Otsus, kes on esimene kasutaja ja kes vastutab, kui tulemus on vale.

Need sisendid aitavad fikseerida töö ulatuse ja esimese etapi hinna kirjalikult. B2B SaaS arenduse lehel on kirjeldatud kaardistuse ja hinnakokkuleppe käik.

Järgmised otsused, mis sellest etapist välja jäävad, on kirjas artiklis B2B SaaS: kuus otsust, mis hiljem kalliks lähevad. Integratsioonide osa, mis esimeses versioonis tavaliselt kõige rohkem aega võtab, on lahti kirjutatud artiklis API integratsioonid, mida Eesti ettevõttes päriselt vaja läheb.