Nov 30 2015
Minu viis kuud Bondoras
Äsja täitus mul viis kuud Bondoras töötamist.
Kuidas on läinud?
Lühike vastus: suurepäraselt!
Pikka vastust tuleb alustada kaugemalt. Alustasin oma karjääri metsikutel üheksakümnendatel, kui normiks oli kaastöötajatele hambapastasse pliinitraati panna ning vajadusel juhtmejupist voolu lasta (või oli see ainult konkreetse ettevõtte eripära?) Kommertstarkvara loomine oli Eestis lapsekingades ning seda tehti üsna katse-eksituse meetodil. See, et järgmises töökohas APT-s (praeguseks transformeerunud CGI Eesti kontoriks) üldse eksisteeris selline nähtus nagu süsteemianalüüs, oli päris kõva sõna. Edasi viis elu mu juba päris suurde ettevõttesse, rohkete protsesside ning kõrgelt spetsialiseeritud rollidega.
Igas järgmises kohas olid asjad rohkem korras ja süstematiseeritud, sellest tekkis mul ka ettekujutus, et ahaa, nüüd ma tean, kuidas tuleb edukalt tarkvara teha, millised protsessid ja meetodid selleks vajalikud on. Kui aga Eestisse tagasi tulin ja keskmise suurusega ettevõttesse tööle asusin, ei hakanud kogemused siiski nii ladusalt tööle, kui oleksin oodanud. Milles siis asi?
Reaalselt ei eksisteeri paraku mingit garanteeritult edukat meetodit, kuidas tarkvaratootmist korraldada. On mingid üldised printsiibid, kuid detailid olenevad organisatsiooni suurusest, tegevusvaldkonnast ja mitmetest muudest teguritest. Jah, elementaarne, aga inimestel on kord juba kombeks seniste kogemuste haamrit kasutades ka uusi situatsioone samasuguste naeltena käsitleda.
Asi läheb aga huvitavaks, kui meil on tegu väga dünaamilise organisatsiooniga nagu Bondora. Esiteks kasvab Bondora praegu väga kiiresti, ma pole enam kaugeltki kõige uuem töötaja. Teiseks, ma ei tea, mis narkotsi Pärtel täpselt tarbib, aga igal nädalal leiutab ta mõne uue vägeva asja, mida proovida. Sel juhul tulebki protsesse jooksvalt kohandada, vahel ka organisatsioonistruktuuri ja tehnoloogilist arhitektuuri.
Minu strateegiliseks ülesandeks on: kuidas arendada tehnoloogilist platvormi maailma vallutamise eesmärgiga ettevõttes, mis pidevalt muutub?
Selline sõnastus aitab vajadusel ka mõtteid korrastada. Kui on kahtlus, et mida teha, siis tuleb kujutleda, et me saame väga, väga edukaks – mis on sel juhul õige lahendus? Sest kui me edu ei saavuta, mis siis üldse asja point on, eks.
Mis mulle Bondoras meeldib?
Võrreldes eelmise tööga, kus tegu oli suurel määral ikkagi konkreetsete klientide soovide täitmisega, on olulisteks positiivseteks külgedeks:
- Tarkvara skaleeritavuse ärakasutamise võimalus. Võrreldes majaehitamise või muude inseneridistsipliinidega on tarkvaral suurepärane omadus, et sama tarkvara võib kasutada kuitahes palju inimesi. Tootearendust katsusin ma ka Nortalis korraldada, aga see oli raskem. Nortal on hea ettevõte, kuid kui kogu elu, raamatupidamisest arenguvestlusteni, on orienteeritud pigem arendustundide müügile, on mingit teistsugust lähenemist keeruline tööle panna. Bondoras on kasutajate arvu suurendamine nii loomulik eesmärk, et sellest pole isegi vaja eraldi rääkida, ja milline insener ei tahaks, et tema tööd võimalikult palju kasutataks?
- Pikaajaline mõtlemine, mis võiks ju olla igasuguse tarkvaraarenduse loomulik osa, kuid kahjuks loob riigihangete struktuur tugeva motivatsiooni lühiajalisele edule optimiseerimiseks. Kui arendaja teab, et tal on vaja selle koodiga tegeleda ka viie aasta pärast, on ta üldjuhul palju hoolikam kui siis, kui on teada, et vastutus kestab vaid lähimate kuude jooksul.
- No bullshit. Ma tegelen oluliselt rohkem asjadega, mis mulle meeldivad, ning vähem nendega, mis ei meeldi. Tegu mõnes mõttes taas hangete vormist tuleneva probleemiga, kus tellija ja täitja vaheliste konfliktide seemned on juba lepingutesse külvatud.
Boonusena toon ära, et päris hea on taas töötada kohas, kus ettevõtte juht vajadusel ise suudab SQLi lahti võtta ja uurida, mis süsteemis toimub. Mitte, et sellel mingit suurt praktilist väärtust oleks, aga nii ei teki tunnet, et äri- ja tehnikainimesed omaette isoleeritud maailmades eksisteerivad.
Mida Bondoras tehakse?
Kui ma väike olin, laenas naabrimees minu isalt vahel viis rubla ja tõi palgapäeval tagasi. Maailmas on palju inimesi, kellel mitmesugustel põhjustel raha parajasti puudu on, aga on ka inimesi, kellel on seda hetkel üle. Kui esimestel on naaber, kellelt laenata, siis on tore, aga kui ei ole?
Mingi suvaline inimene pole jälle nõus sulle laenama… või siiski? Mittelaenamise põhjuseks on üldiselt see, et me ei tea, kas teine on usaldusväärne ja maksab raha tagasi. Sama probleem on näiteks aktsiatega – kuigi majandus üldiselt tõuseb, siis kust ma tean, et just see ettevõte pankrotti ei lähe, mille aktsiat ma ostan? Aktsiaturul on lahenduseks diversifitseerimine, ostad kas paljusid erinevaid aktsiaid või üldse indeksfondi, siis pole üksik kaotus enam nii oluline.
Laenamise puhul saab teha sama. Kui üks konkreetne inimene võib laenu mitte tagastada, siis enamik inimesi siiski teevad seda. Olgu meil seega näiteks 200 inimest, kellest igaüks soovib laenata tuhat eurot. Teisel pool on 200 inimest, kes saavad tuhat eurot laenu anda. Jagame nüüd kõik tuhanded 5-eurosteks tükkideks, nii et igaüks laenab igaühele viis eurot ja ongi riskid maandatud, konkreetsed kaotused on piiratud 5 euroga.
Pangad on sama põhimõtet rakendanud juba sadu aastaid, kuid üldiselt ei saa inimesed kontrollida, mida nende hoiustatud rahaga tehakse. Arenenud tehnoloogia võimaldab inimestele aga palju suuremat kontrolli, raha liigutamist ja jälgimist saab toimetada kiiremini, lihtsamalt ja odavamalt kui kunagi varem.
Ehk siis suures plaanis ongi asi väga lihtne, laenusoovid jagatakse väikesteks tükkideks, mida rahastavad paljud üksikinvestorid. Reaalselt on seal muidugi palju keerukusi, neist suurim on küsimus, kuidas õigesti hinnata laenaja riski? Riski hindamine on omakorda kinni selles, kui palju on laenusoovija kohta olemas infot. Info tuleb osaliselt kliendilt endalt, aga ka taustakontrollist nagu võlaregistrid jms. Paljude parameetrite põhjal hindabki statistiline mudel, mis on konkreetse laenu risk.
Protsess on üldjoontes järgmine:
Äri kasvatamisel on kaks poolt: ekstensiivne (ehk rohkem külastajaid) ning intensiivne (suurem külastajate protsent, kes joonisel toodud sammud läbi teeb). Siit tulenevad ka tehnilised eesmärgid: ühelt poolt süsteemi skaleeruvus ning teiselt poolt võimalikult sujuv kasutajakogemus.
Kasvu osas on lagi aga nii kõrgel, et pea hakkab ringi käima. Selliste laenude turu suurust hinnatakse TRILJONILE (kaksteist nulli) dollarile.
Mida mina konkreetselt teen?
Viimased 10 aastat olen ma pooleldi tegelenud tehniliste asjade ning pooleldi inimestega, nõnda ka siin. Inimesed on mõistagi tähtsamad.
Igapäevaselt kirjutan ma koodi ja uurin igasuguseid jooksvaid probleeme. Käed on pidevalt mullased, valgeid kindaid pole endale hankinud. Õnneks on abiks ka teisi väga tugevaid tegijaid:
(kes Tarmot tunnevad, siis jah, ta ongi juurde võtnud)
Paralleelselt aitan aga paika ajada viit asja, mis iga organisatsiooni disainimisel tähtsad on:
1. Õiged inimesed
Millised inimesed on õiged, oleneb suuresti ärimudelist. Olenevalt sellest, mida me teeme, võime hinnata näiteks korralikkust, paindlikkust, vastupidavust vms. Bondora-suguses keskkonnas, kus uued väljakutsed on igapäevased, on võtmeks nutikus ja õppimisvõime. Need on ka peamised omadused, mida ma värbamisel katsun silmas pidada.
2. Õige kultuur
Meie eesmärgiks on kasvada suureks oma saavutustelt, aga mitte tingimata inimeste arvu poolest. See tähendab, et tarkvara peab olema võimalikult hooldusvaba ning arendajatel peab olema motivatsioon sellist tarkvara luua. Lihtsaim meetod selleks on läbi võimalikult konkreetse vastutuse ja omanditunde.
3. Õige struktuur
Organisatsiooni struktuuri osas on peamine tegur Conway seadus, mis ütleb, et tarkvarasüsteemi disain hakkab peegeldama organisatsiooni disaini (täpsemalt organisatsioonisisest kommunikatsiooni). Kui meil on väga hierarhiline organisatsioon, saame ka hierarhilise ülesehitusega tarkvara. Kui meil on maatriksjuhtimine, siis tekivad ka tarkvarasse ristsõltuvused. Kui meil on sõltumatud tiimid, saame ka üksteisest sõltumatud komponendid.
Struktuur võib olla ajas muutuv. Kui meil on kolm arendajat, on okei, et kõik teavad kõike ja vastutavad probleemide eest ühiselt. Kui arendajaid on aga kümme, võib tekkida “kollektiivse vastutuse sündroom” ning inimestel kaob ära omanditunne koodi vastu. Siis on mõistlik jagada organisatsioon väiksemateks üksusteks.
4. Õiged protsessid
See on miski, mis muutub aja jooksul pidevalt. Murdekoht võiks olla umbes kahekordse kasvu juures. Kümne tehniku puhul töötab teistsugune lähenemine kui viiega, kahekümne juures on jälle aeg kohandamiseks jne. Vahel olengi pidanud stabiilsemate oludega harjunud kolleege lohutama, et paar korda aastas ümber organiseerumises pole midagi hullu.
5. Õige tehnoloogia
Kuigi sageli vaieldakse arendusorganisatsioonides parima versioonihaldussüsteemi, programmeerimiskeele või one true brace style‘i üle ennast näost siniseks, tulevad tehnoloogilised valikud alles pärast seda, kui eelmised asjad paigas. Lõppkokkuvõttes peame olema suutelised kiirelt ja kergelt muutuma, kui Next Big Thing leiutatakse. Võtmesõnadeks modulaarsus ja sõltumatus.
Mis on karu kõhus?
Algselt ühe arendajaga ja hiljem kasvanud tarkvarasüsteemid teevad tavaliselt läbi järgmised arenguetapid:
1. Spagetiorienteeritud arhitektuur
Pole veel päris head aimdust, mida me teeme, proovime igasuguseid erinevaid asju ja hoiame “ehk-läheb-tarvis” koodi alles. Kiirema katsetamise huvides jääb süsteemi mitmesuguseid häkke ja otselõikeid. Samas teavad esialgsed 1-3 arendajat koodi niikuinii peast ning suudavad iga üksiku spageti alguse ja otsa kergesti üles leida.
2. Lasanjeorienteeritud arhitektuur
Inimesi tuli juurde, kes enam kõigest aru ei saanud, nii et jagame süsteemi loogilisteks kihtideks. Veebiklient-vaated-kontrollerid-sõnumid-domeenimudel-DAOd-SQL või kuidas kellelegi parajasti meeldib. Paljud süsteemid jäävadki kusagile siia pidama.
3. Raviooliorienteeritud arhitektuur
Kui aga süsteemi suurus veel kasvab ja sinna on vaja rohkem muudatusi teha, pole kihid enam piisavalt paindlikud. Ühe stsenaariumi jaoks tehtavad muudatused toovad kaasa tagajärgi ka teiste jaoks, just nagu katse valmisküpsetatud lasanjel keskmine plaat ära vahetada võib kõik muu sassi ajada. Siis tuleb süsteem jagada sõltumatuteks osadeks, mida iseseisvalt muuta saab. Infosüsteemide puhul on realisatsiooniks tavaliselt microservice‘id, seda lähenemist kasutavad paljud maailma edukaimad ettevõtted nagu Amazon või Google. Konkreetselt Bondora juhul saaks ülalpool illustreeritud laenuprotsessi etapid muuta sõltumatuteks teenusteks, millest igaüht võimalik iseseisvalt paigaldada, skaleerida ja ümber teha.
Bondora on hetkel kusagil lasanje ja raviooli vahepeal – on nii kenasti jagatud kui ka üle terve maailma ulatuvaid osi. Kui ma esimest korda koodile tiiru peale sain tehtud, tekkis ka nägemus, mismoodi asjad ideaalis võiksid olla. Kuna senine elukogemus oli näidanud, et äriinimestele tavaliselt “muudame kõik ümber” ettepanekud väga ei sobi, valmistasin mõttes rea igasuguseid argumente ette, miks on tegu hea mõttega. Reaalselt jõudsin öelda umbes kaks lauset, kui Pärtel vastas, et “tehke ära”. Kas tegu oli erakordse usalduskrediidi või hulljulgusega, näitab aeg.
PS Pakume kogenud .NET arendajatele võimalust maailma vallutamises kaasa lüüa. Vastavalt jaksule ka väärilised kullakangid ning pudrumäed. Huvi korral võib minuga ühendust võtta.