Nädal XI (Arendus- ning ärimudelid)

Üheteistkümnenda nädala postituse eesmärgiks oli analüüsida üht tarkvara arendus- ja üht ärimudelit mõne konkreetse projekti näitel. Projektiks sai valitud Dropbox ning agiilne (antud juhul peamiselt lean) arendus- ning freemium/SaaS ärimudel.


Arendusmudel

Lean arendusmudel taotleb peamiselt järgmist (1):

1. Raiskamise elimineerimine (eliminate waste) - arendada vaid seda, mida on koheselt vaja. Kõik, mis ei lisa otseselt väärtust, on raiskamine.
2. Õppimine (amplify learning) - mitte leppida esimese lahendusega, vaid proovida variatsioone ning leida neist parim.
3. Võimalikult hilja otsustamine (decide as late as possible) - lähitulevik on kindlam, kui kauge ning otsused on kvaliteetsemad, kui nad põhinevad faktidel, mitte spekulatsioonil. Ehitada süsteem paindlikult, et seda oleks vajadusel võimalik lihtsasti muuta.
4. Võimalikult kiire tarne (deliver as fast as possible) - disainimise, implementeerimise, mõõtmise ning parenduse tsükkel. Mida kiiremini saab toode kasutajate kätte, seda varem saab tagasisidet. Lühemalt "build-measure-learn" tsükkel.
5. Meeskonna mõjuvõim (empower the team) - tehnilisi detaile mõistavad kõige paremini inimesed, kes koodi kirjutavad - neil peaks olema õigus tehnilistes otsustes kaasa rääkida. Kogu tööd ei saa koordineerida tsentraalne jõud.
6. Terviklikkus (build integrity in) - tarkvara põhifunktsioonid peavad kenasti kokku istuma, moodustama terviku. Ajaga muutudes võiks see terviklikkus säilida.
7. Näe tervikpilti (see the whole) - optimeerida tuleks toodet tervikuna, mitte nii, et igaüks optimeerib osa, milles ta spetsialiseerub. Mõte on selles, et kui terviku pudelikaelaks on andmebaas, ei ole mõtet näiteks GUI-d optimeerida, vaid keskenduda tuleks sellele, mis on ennekõike oluline - teha seda, mis on päriselt oluline.

Seda arendusmudelit on nimetatud ka MVP (minimal viable product) ehk minimaalse töötava toote mudeliks. MVP on oma olemuselt miski, mis aitab võimalikult vähese hulga vaeva ning tööga koguda võimalikult suure hulga valideerivat või ümberlükkavat informatsiooni arendatava toote kohta (2) ning on ühtlasi esimeseks “build-measure-learn” tsükliks eesmärgiga tehtust midagi uut õppida. Eriti ilmekalt illustreerib MVP olemust Dropboxi lugu. Nende meeskond koosnes puhtalt tehnilistest inimestest, kuid sellest hoolimata oli töötava prototüübi ehitamine üsna keeruline ettevõtmine puhtalt selleks, et teada saada, kas inimesed nende tootest üldse huvituks või mis neile selle osas enim huvi võiks pakkuda (3). Selleks, et mitte ennatlikult aastaid arenduse alla matta, tegi Dropboxi tegevjuht Drew Houston kolme minuti pikkuse demovideo (4), mis näiliselt toimivat toodet demonstreeris. Tegelikult oli tegu osavate videotöötluse võtetega, kuid selle tulemusena kasvas Dropbox’i beta-ga liitunute nimekiri 5000-lt inimeselt 75000-le, mis üsna selgelt valideeris nende lähenemist tollel ajal üsna tihedalt asustatud pilveteenuste pakkujate rägastikus ning andis selge positiivse signaali ka investoritele (5).

Dropbox jätkas kasvufaasis sarnase metoodikaga, õppides pidevalt kasutajate tagasidest ning kogutud andmetest (6). Drew Houstoni sõnul on suurimaks riskiks ehitada midagi, mida keegi ei taha. Kui eksperimendis selgub, et toode või funktsionaalsus ei toimi, siis selle välja laskmata jätmine on küll valus, kuid eelnevalt eksperimendi vormis testimata jätmine võib olla ettevõttele sootuks saatuslik. Eesmärgiks peab ta midagigi võimalikult kiirelt kasutajate kätte saada (mis ei pea olema ilmtingimata kood, nagu ka nende MVP näide välja tõi) - ning sellelt tagasisidet koguda (7). Kõiki ülaltoodud punkte tundub Dropbox jälgivat veel ka täna, nagu seda väljendab kahe aasta eest välja antud dropbox.tech blogipost Dropbox Plusi arendustsükli kohta (8). Seal käiakse üle, kuidas uue funktsionaalsusega säilib süsteemi terviklikkus, kuidas kaasatakse otsustusprotsessis meeskonda ning kuidas kiire tarne ning tagasiside aitavad ehitada seda, mida kliendid päriselt soovivad. Laias laastus koosneb blogis kirjeldatud perepaketi funktsionaalsuse tarne neljast etapist: sisemine alfa, välimine alfa, beta ning lõpuks GA, ehk general availability. Igas etapis kogutakse järjest suurema ning mitmekesisema grupi käest tagasisidet ning andmeid, mida kasutatakse järgmise etapi täiendamiseks.


Ärimudel

Ärimudelilt kasutab Dropbox freemiumit ning SaaS’i. Nad pakuvad eraisikutele kuni 2GB salvestusmahtu tasuta (9), kuid pakuvad eraisikutele ühtlasi ka Plus ning Family pakette, ning ettevõtetele Professional, Standard ning Advanced pakette - seda igakuise tasu eest (10). Tasulise teenusega kaasnevad mitmed mugavused, nagu teenuse tugi, API kasutusvõimalus, otsing ja palju muud. Ettevõtetele on lisaks failide lukustamine, süsteemi kujundamine oma brändi järgi, garantiid vastamaks regulatsioonidele, vesimärgid, tsentraalne kontroll ning mitmed muud spetsiaalsed funktsionaalsused. Sarnast mudelit, olgugi et vähema arvu plaanidega, on Dropbox kasutanud algusest peale. Lisaks kasutavad nad suunamisprogrammi (referral), ehk kutsudes sõbra liituma, on võimalik saada lisaks tasuta salvestusruumi (11) - see on küll rohkem turundust, kui ärimudelit puudutav, aga huvitav sellegipoolest. Ka selle taktika juured peituvad päris Dropboxi algusajas. Olles proovinud traditsioonilisemaid meetodeid nagu tasulist otsingut (paid search), veebireklaame ning saavutades sellega CPA (cost per aquisition) $233-$388 toote eest, mis maksis tol ajal $99, saadi aru, et lähenemist tuleb muuta. Vaadati põhjalikkult otsa sellele, kust kliendid hetkel tulevad ning loodi tööriistad selleks, et muuta see võimalikult mugavaks ning hõõrdevabaks. Dropbox levis peamiselt “suust suhu” - läbi soovituste. Sellest lähtuvalt optimeeriti vastavalt kodulehte, kasutajaks registreerimist ning loodi suunamisprogramm, tänu millele kasvatati pikemaks ajaks registreemiste arvu 60% võrra. Esimese 30 päevaga koguti 2.8 miljonit suunamist ning sealt tulnud registreemised moodustasid tervikust igapäevaselt 35% (12).


Allikad:

1. http://www.poppendieck.com/pdfs/Introduction.pdf
2. https://www.agilealliance.org/glossary/mvp
3. https://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/
4. https://www.youtube.com/watch?v=7QmCUDHpNzE&t=9s
5. https://benchhacks.com/growthstudies/dropbox-growth-hacks.htm
6. https://www.ransfordantwi.com/posts/dropbox/
7. https://slidetodoc.com/startup-lessons-learned-drew-houston-drewhouston-background-cofounder/
8. https://dropbox.tech/frontend/the-software-engineering-lifecycle--how-we-built-the-new-dropbox
9. https://www.dropbox.com/basic
10. https://www.dropbox.com/plans
11. https://help.dropbox.com/accounts-billing/space-storage/earn-space-referring-friends
12. https://slidetodoc.com/startup-lessons-learned-drew-houston-drewhouston-background-cofounder/