Tihti põevad idufirmad oma esimese toote avalikkuse ette viimisel selle pärast, et see pole veel lõpuni valmis lihvitud ja kõiki võimalusi lisatud. Tegelikult polegi seda vaja. Arendustehnoloogia Minimum Viable Product (MVP) eeldab, et avalikuks minnakse juba hetkel, kui tootel on minimaalsed vajalikud omadused olemas ning kasutajad annavad sellele hinnangu enne, kui lõplik toode valmis saab.
Sellise lähenemisega on hea ka arendusfirma poole pöörduda, kes aitab valmis saada esimese minimaalsete vajalike omadustega digitoote prototüübi ja seda testida. Thorgate pakub tarkvaraarenduse tellijatele tasuta esialgset ühetunnist konsultatsiooni, kuid soovitab kindlasti osa võtta ka pikemast Lean Requirements Workshop´ist, kus paaripäevase mõttemaratoniga tehakse selgeks, mida on üldse minimaalselt vaja, et toode avalikkuse ette viia. Aitavad Thorgate´i spetsialistid ja arendajad ning mõnikord juhtub, et klient leiab pärast konsultatsiooni, et toode polegi piisavalt elujõuline. Kuid igal juhul saab enne arenduse alustamist paika panna MVP plaani ja ära hoida palju asjatut lisatööd enne toote avalikustamist. See on kasulik nii tellijale kui ka arendusfirmale, sest esimene ei taha asjatult raha kulutada, teine aga ei pea asjatult lisatööd tegema.
Minimum Viable Product ehk MVP on paljude tootearendajate jaoks üsna uus mõiste, kuid startup-maailmas kasutatakse seda juba ligi viis aastat üsna tihti just startupi ja arendusfirma omavahelise koostöö parandamiseks. Pole ju mõtet kohe “täispangale” minna ja detailidesse uppuda, kui saaks oma toote kohta esialgse hinnangu kätte juba siis, toode on lihtne ja väheste, kuid hädavajalike funktsioonidega.
Nii on alustanud ka paljud tuntud tehnoloogiamaailma tegijad nagu Dropbox, Amazon või isegi Facebook.
Millal on MVP-d vaja?
MVP võib olla ükskõik milline uus toode – tarkvara, auto, veebiportaal, elektrijalgratas, arvuti, nutitelefon. Põhiline on, kuidas seda toodet arendatakse. MVP-d on tavaliselt vaja kui paindlikku arendustehnoloogiat keerulistes muutuvates oludes. Kui kõiki toote edukuse mõjutajaid ei tea, siis pole ju ka mõtet kõiki detaile kohe peensusteni paika panna, vaid suur osa neist sõltub ikkagi nendest samadest muutuvatest oludest. Praegu on turul muutujaid väga palju: koroonakriis, kiirelt arenevad tehnoloogiavaldkonnad ning täiesti uuenenud vajadustega kliendid-ostjad. Selleks, et neile pakkuda sobivaimat toodet, ongi vaja enne proovida minimaalsete võimalustega.
Muidugi on MVP-d vaja ka arenduskulude kokkuhoiuks. Thorgate annab kuus selget põhjust, miks peaks enne tootearendust MVP konsultatsiooni läbima, mis kestab ainult tunni.
1. Selles puudub peidetud pakkumine. Kõik on lihtne – konsultatsioon on kasulik nii tellijale kui arendajale ning aitab läbi mõelda küsimused, mida pole varem küsitud, kuid mis on olulised. Midagi ei üritata konsultatsiooni käigus varjatult maha müüa.
2. Muuda oma nõudmised paindlikumaks. Konsultatsiooni käigus selguvad 1-2 ärilist põhjust, miks peaks oma toodet arendama. Seega saad fokuseerida peaeesmärkidele. Samas selgub kindlasti ka vajadus olla oma nõudmistes ja lahenduste valikus paindlikumad, kuna keskkond võib muutuda.
3. Saab valmis kasutaja lugu. Konsultatsiooni käigus muutub täpsemaks ja konkreetsemaks selle kasutaja lugu, kes peaks toodet kasutama hakkama. Ei pea keskenduma kõikidele funktsioonidele, mida kasutaja saaks uue tarkvaratootega teha, vaid hoopis kasutaja loole, ehk milline on tema probleem ja kuidas toode peaks aitama seda probleemi lahendada.
4. Selgub täpsem kasutajaprofiil. Kes on uue toote kasutajad, millised on nende kasutajate tunnused? Kasutajaprofiili loomine on oluline juba enne tootearendust selgeks teha, sest siis saab igas etapis selgelt ette kujutada, kas sellisele kasutajale on toote uusi omadusi vaja või saab need ära jätta. Hea on kasutada 80/20 reeglit (Pareto printsiipi) ehk mis on need 20% omadustest, mis annavad 80% tulemuse?
5. Väljatuleku ajajoon. Toote avalikkuse ette toomine ei ole vaid üks kuupäev, see koosneb mitmest etapist. Tarkvaratoode vajab enne vaheetappe, kus seda testitakse ja antakse hinnang toote küpsuse kohta.
6. Kui palju kulub aega ja raha? Muidugi ei selgu tunniajase konsultatsiooni käigus, palju kõik maksma läheb ja kaua arendus kestab. Siiski saab juba mingi ettekujutuse, millega arvestada ning kuidas on arenduse aeg ja raha omavahel seotud. Tähtis on läbipaistvus mõlemalt poolet – tellija teab, mida tahab tellida ning arendaja annab teada, kui aja- ja kulumahukas see on.
Tasuta konsultatsiooniks saab end kirja panna siin.
Küsi endalt enne olulised küsimused, kui arendama hakkad!
Kui alustad MVP arendamist, pole vahet, kas võtad lahti lihtsa Exceli (või Google Sheetsi) tabeli, joonistad tahvlile ilusaid skeeme või kasutad mõnda spetsiaalset tarkvara plaanide joonistamiseks. Põhiline on, et oskad endalt alguses küsida õigeid küsimusi.
Ah et milliseid küsimusi siis küsida? Thorgate´il on rohkem kui 150 arendusega tekkinud kogemus, mida jagada. Nimelt aitavad edasi minna need küsimused, kui neile head vastused leida.
1. Kellele see toode on mõeldud? Ehk siis kes üldse on teie toote kasutajad? Kas kõik need kasutajad on esimeses etapis minimaalsete omadustega toote puhul vajalikud? Võib-olla saab siin juba keskenduda kitsamale kasutajagrupile ja koos sellega mõne omaduse esialgu tootest välja jätta.
2. Mida kasutajad kõige rohkem soovivad? Raske, aga oluline küsimus – seda paremini vastata aitab 80/20 printsiip ehk millised on 20% funktsioonidest, mis annavad 80% tulemustest? Ülejäänu võib ehk esialgu oma tootest välja jätta.
3. Kuidas saaks prototüüpi testida? Testimine on hädavajalik enne toote väljatulemist, tarkvaratoote puhul on õnneks testimisvõimalusi palju. Siiski vajab läbimõtlemist, mida ja kuidas testida – kas saaks esialgu prototüübi peal testida disaini või proovida alustuseks mobiilirakenduse asemel veebirakendusega?
4. Kas sama tulemuse saamiseks oleks võimalik kasutada mõnda olemasolevat lahendust? Kui alguses võib tunduda ainuvõimalikuna nullist kõik üles ehitada, siis enamasti see pole nii – paljudel juhtudel on midagi sarnast juba varem tehtud ning jääb üle see vaid oma lahendusse sobitada, mis on lihtsam.
Pole üldse probleemi, kui tootest asja ei saa
Thorgate on peale konsultatsioone jõudnud üsna mitmel korral kliendiga ühisele arusaamisele, et toodet polegi mõtet tegema hakata. Kuidas siis nii – klient tuleb sooviga arendada ja ei lähegi töösse?
Paraku on see mõnikord kõige mõistlikum asjade käik. Pole mõtet kõrbeda siis, kui palju vaeva on nähtud ja ohtralt tööd tehtud, kui toote elujõulisus selgub varem, juba MVP käigus.
MVP aitab testida tellija ideed ja hoida samas kulud minimaalsed. Nii võibki ideega, mis ei pruugi heaks tooteks realiseeruda, suhteliselt väikeste kuludega lõpetada ning minna edasi muude ideede ja toodetega. Võidavad kõik.
Siin on viis näidet, mille puhul leidsid Thorgate ja tellija lõpuks ühiselt, et toodet ei tule, vähemalt mitte sellisel kujul, nagu plaanitud.
HealX on Suurbritannia tehisintellektiplatvorm, mille eesmärgiks on diagnoosida haruldasi haiguseid. Üllas eesmärk osutus peale konsultatsioone liiga suureks ja mahukaks, millega pole mõtet vähemalt hetkel edasi tegelema hakata. Lähemalt saab prototüübi loomise kohta lugeda siit: https://thorgate.eu/healx.
Film It on Kanada filmiplatvorm, mis tahtis ühendada kõik sõltumatud filmitegijad ühele platvormile. Arendus oli juba enne Thorgate´i poole pöördumist alanud ning oli võtnud üsna suured mõõtmed. Pärast MVP Workshop´i jõuti selgusele, et projekt on liiga laiahaardeline ning vajaks ümbermõtestamist.
Pet Doctor Program on Slovakkia veterinaarettevõtte platvorm, mis pidi kokku tooma veterinaarid, vahendama nende materjale ja korraldama koosolekuid. Pärast esialgse prototüübi tegemist selgus, et see lahendus siiski ei vasta kliendi vajadustele ning peidab endas võimalust kiiresti ebaõnnestuda.
X-Sports Challenge Portal on kliendi nägemuse kohaselt ekstreemsportlaste väljakutsete portaal, kuid peale analüüsi selgus, et ilmselt see idee ei suuda tekitada piisavalt tulu, et oleks kliendi jaoks vastuvõetav.
Tehisintellektilahendus tööstusettevõttele. Tootmisettevõte pöördus Thorgate´i poole sooviga ehitada tehisintellekti lahendus, mis võimaldaks parandada tootmisest väljuva kauba kvaliteeti. Lean Requirements Workshop’i tulemusena selgus, et digitoodet polegi tarvis, vaid tuleks luua erilahendusega rakis toote paigalhoidmiseks tootmisprotsessis, vähendades juba eos tekkivate vigade arvu. 250 000 euro asemel kulus rakise loomiseks 2500 eurot ja tehisintellekti polnudki tarvis rakendada.
Kõigi edukate (ja ka lõpetatud) toodete kohta saab lähemalt ülevaate projektide lehelt.
Seega veel enne, kui tellid arenduse, võta kindlasti arendajaga ühendust ja küsi tasuta konsultatsiooni. Võib-olla saab oluliselt kokku hoida kulusid ja aega, enne kui tarkvaratoodet arendama hakata.
