Infoaja kultuurist ja olustikust 

Detsembri keskel toimus gümnaasiumi informaatika ainekava ümarlaud. Kohal oli igasugust huvitavat rahvast: ministeeriumist, ettevõtetest, kesk- ja ülikoolidest, teemaspetsiifilistest asutustest, nagu HITSA ja Innove. Ka mind oli kutsutud, ilmselt seetõttu, et mul on üldiselt kombeks igale poole nina toppida ja erinevatel teemadel jaurata.

Olen viimastel aastatel töötanud peamiselt idufirmades, kus kõigile probleemidele lähenetakse ülipragmaatiliselt ja peamine eesmärk on kõike muud kõrvale jättes „teeme asja ära“. Haridusvalla seltskonda sattudes pidin esmalt kohanema hoopis teistsuguse emotsionaalse õhkkonnaga.

Näide: ettekandele, mis minu arvates oli huvitav, informatiivne ja täiesti neutraalne, järgnes teise asutuse esindaja reaktsioon „Miks te meie tööd maha teete?“. Sarnaseid suuremaid ja väiksemaid solvumisi ja neile järgnevaid silumisi oli päris mitu. Sain ka ise oma esimese sõnavõtu järel kergelt vastu näppe ja olin hiljem ettevaatlikum.

Seetõttu jäi mind kummitama õppekavaväline küsimus: tegu oli ju põhimõtteliselt üsna otsese ja mõneti isegi kuiva teemaga – miks osalised nii pinges on ja miks siin nii suurt umbusaldust ja kriitikahirmu tuntakse?

Lihtsaim selgitus oleks muidugi, et õpetajatel on liiga vähe raha ja see muudab inimesi närviliseks. Samas näen ma võrreldavaid agressiivses kaitseasendis reaktsioone igal tasemel, professorite, akadeemikute ja ministriteni välja. Mul on seetõttu hüpotees, et meie haridus põhineb fundamentaalselt rohkem laitusel kui kiitusel, seda juba lasteaiast alates (võiks kasvõi statistikat teha, kui palju öeldakse koolipäevas kiitvaid sõnu võrreldes laitvatega). Seetõttu on ka õpilased ning lapsevanemad võitlusvalmis, pelgavad seda, mis koolist tuleb, ning hammustavad teinekord juba ennetavalt vastu. Tagajärjena koguvad haridustöötajad endasse kõvasti allergiat ja kasvatavad okkaid.

Kui ma pärast üritust mainisin, et väga huvitavad teemad, refereeriksin neid kusagil, kuulsin ka reaktsiooni:  „Ära tee, inimesed võivad solvuda.“ Keeruline olukord tõesti, kuid leian, et antud teema on siiski väärt laiemalt kui mõnekümnele inimesele valgustamist. Praegu jäävad mitmed teemad selliste pingete pärast üldse arutamata ja lahendamata.

Eelnevat arvestades ütlen seega juba ette ära, et kui ma kellelegi varbale astun, siis see pole minu kavatsus. Eesmärgiks on ikka see, kuidas asju paremaks teha.

The Good 

Minu jaoks kõige positiivsem oli see, et kohal oli palju inimesi, kes tõesti soovivad elu edendada ja asju paremaks muuta. Eestis on mitmeid asutusi ja ettevõtmisi, mis vankrit sikutavad, kuigi nende struktuur ja võimalused on väga erinevad. Need, kelle jaoks üritusele kohaletulek polnud otsene tööülesanne, ongi muidugi definitsiooni kohaselt entusiastid, nii mõnigi neist korraldab ainealast ringi või kursust. Ma ise korraldan informaatikaolümpiaadi, mille üle olen ka päris uhke, aga kõige kõvema panuse on minu arvates andnud Eno Tõnisson, kelle juhitud internetikursused (http://programmeerimine.ut.ee) on õpetanud programmeerimist juba tuhandetele ja tuhandetele inimestele.

Eno tegi ka ühe põhiettekannetest, kus oma mass-internetikuruste (MOOCide) kogemusi jagas. Kokku on neil kursustel osaletud üle 15 000 korra, kuigi seal on ilmselt korduvusi, sest paljud on osalenud mitmel kursusel. Arv näitab, et ühiskondlik huvi programmeerimise vastu on kõrge, ületades suuresti kõigis Eesti vastavates erialakoolides õppijate koguarvu.

Eesti Informaatikaõpetuse ajaloost rääkis Urmas Heinaste. Siin saan õnne tänada, et mu enda keskkoolitee jäi selle ajaloo algusjärku, kui keskkoolides õpetatigi konkreetselt programmeerimist. See andis mulle omal ajal päris tugeva tõuke ja nii mõnedki praeguste kõvade IT-firmade juhid on samast perioodist. 1996. aastal eraldi programmeerimise õpe lõppes ning pärast seda on informaatika sildi all õpetatud mitmesuguseid erinevaid asju.

Erinevatest õppemudelitest rääkis Mart Laanpere, kelle ettekandest jäi mulle enim meelde järgmine joonis:

Skeemi mõte on selles, et on kolm peamist jõudu, mis informaatika õppekava erinevates suundades sikutavad. Ülemine neist on ”akadeemiline” suund, mis täidab eelkõige vastava eriala (antud juhul arvutiteadust õpetavate) kõrgkoolide ja ettevõtete tellimust. Parempoolne peaks ette valmistama nö laiatarbe IT-oskusi, selliseid mida nõutakse näiteks arstilt, taksojuhilt või müüjalt. Lõpuks alumine osa täidab eelkõige kooli enda eesmärke, arendades IKT-oskusi lõimitud kujul, näiteks läbi arvuti kasutamise teistes ainetundides.

Ettekandja oli teinud ära huvitava taustatöö, paigutades skeemile selle, kus mitmed riigid praegu asuvad ja kuhu nad liikuda plaanivad. Kui Inglismaa puhul oli määravaks erialaste firmade tellimus ja surve, siis näiteks Soome asus end liigutama kuulujutu tõttu, et Eestis õpivad kõikesimeste klasside lapsed programmeerimist, ega soovinud naabrist maha jääda.

Enamik ürituse diskussioonist keskenduski sellele, milline võiks olla Eesti liikumissuund (A tähistab praegust asukohta).

Headest asjadest edasi rääkides tahan tunnustada Eesti haridusasutusi, eriti Tartu Ülikooli, kus hoolimata spetsiifilise rahastuse puudumisest juba mitu aastat laia avalikkust on programmeerimise juurde toodud. Teiselt poolt lähevad minu tänusõnad paljudele ettevõtetele, kes mitmesuguseid haridusalaseid ettevõtmisi on toetanud, olgu siis tegu õppejõudude hankimise, oma töötajate ülikoolidesse õpetama saatmise või õpilasürituste sponsoreerimisega.

The Bad 

Kuigi üritus oli hästi läbi viidud ja ettekandjad valdasid selgelt teemat, jäid minu hinge kripeldama mitu asjaolu.

Esimene oli see, et vaatlusalune kolme tõmbesuunaga mudel keskendub sellele, mida mingid välised osalised täna soovivad. On selge, et arsti või taksojuhi kutsestandard on suure tõenäosusega koostatud vastava valdkonna juhtide ehk siis eelmise või üle-eelmise põlvkonna esindajate poolt. IKT ettevõtted on pisut paremad, kuid olles viibinud üritustel, kus arutatakse näiteks nende tellimust ülikoolidele, tundub ka seal olevat kahetsusväärselt palju lühiajalist mõtlemist. Kui täna on vaja Java-programmeerijaid, siis seda nõuamegi, kui teatud metoodikat tundvaid süsteemianalüütikuid, siis nõuame neid jne.

Ideaalses maailmas oleks joonisel esindatud ka konkreetselt tulevikku vaatav jõud, kes mõtleks, millistest oskustest on kasu nt 15-20 aasta pärast. Omaaegne keskkoolis programmeerimise õpetamine oli küll nõukogudeaegse kampaania vili ning sai koosviibimisel ka arvestatava sarkasmi osaliseks, kuid see oli siiski oluliselt tulevikku vaatav. Kui toona oleks lähtutud pigem vabrikudirektorite ja kolhoosijuhtide tellimusest, siis kas näiteks 90. aastate alguses keskkoolis käinud Skype’i tegijad oleks samaks ajaks sama kogemuse saanud?

Teiseks olid valikud suuresti kinni mitte sisus, vaid vormis. Kas õpetus peaks olema iseseisva ainena või teistega lõimitult? Kas rühmaprojekti või tunnipõhise kava alusel? Algama kümnendas või üheteistkümnendas klassis?

Nii palju kui sisust juttu oli, jäi mulle tunne, et see on küllaltki eklektiline: samal pulgal 3D-modelleerimine, geoinformaatika, mehhatroonika, programmeerimine, robootika. Programmeerimise kohta öeldi korduvalt, et see on spetsiifiliselt neile, kes seda erialaselt õppima ja hiljem vastavasse ettevõttesse tööle läheks.

Viimases punktis jäin ma eriarvamusele: minu seisukohalt pole programmeerimine sugugi ainult kitsalt erialainimeste pärusmaa, vaid väga praktiline üldoskus ja ka märgatavalt laiema kasutuspinnaga kui teised loetletud oskused.

Kui 90. aastate alguses olid arvutid veel vähelevinud ja programmeerimisoskust raskem rakendada, siis tänapäeval kasutatakse neid igal erialal. Arvuti eripära on aga selles, et ta on masinana universaalne – lisaks tööjuhendis vajalikele ülesannetele saab teda panna tegema ka igasuguseid muid asju. Ning kui sa suudad arvuti enda heaks tööle panna, on see sama võimas kui isiklik assistent, kes osa su tööst endale võtab – sinu efektiivsus ja ühiskonnale toodav lisaväärtus kasvavad hüppeliselt. Siin võivad näideteks olla nii lasteaiaõpetaja, kes kohalolijate märkimiseks lihtsa veebisaidi loob, ametiasutuse asjaajaja, kes skaneeritud dokumentide laialijagamiseks väikese skripti koostab, kui ka põllumees, kes optimaalse väetisekoguse leidmiseks Exceli makro teeb. Need kõik on elust võetud näited ja igaüks neist suurendab mingis pisikeses lõigus ühiskonna toimimise efektiivsust. Tulemusena saavutaksime aga samasuguse sotsiaalse hüppe nagu siis, kui kogu rahvas lugema ja kirjutama õppis.

Selliseid võimalusi panna masinaid tegema ära rutiinseid tegevusi on tuhandeid, kuid enamik neist ei jõua kunagi seda järge ära oodata, et „päris“ programmeerijad suure raha eest vastava töö ära teeks. Analoogiliselt olid kunagi olemas üksikud kirjaoskajad inimesed, kes teiste eest kirju kirjutasid ja neile raamatuid ette lugesid, ilmselgelt jäid siis enamik vajalikest kirjadest kirjutamata ning raamatud lugemata. Praegu kardaks enamik inimesi selliste ülesannete lahendamist isegi üritada, kuid need, kes on programmeerimisega natukegi kokku puutunud, saaks juba kasvõi veebist leitud instruktsioonide varal hakkama. Ka Tartu Ülikooli MOOCide populaarsus kinnitab vastavat vajadust.

Osalejaskond jagunes selles osas kahte lehte, oli nii neid, kes mind toetasid, kui ka neid, kes ütlesid, et koolis programmeerimise õpetamine on sama praktiline kui alpinismi õpetamine – ainult entusiastidele. Mis tegelikult saama hakkab, näitab aeg.

The Ugly 

Räägitud teemadest olulisem oli aga ruumis viibinud elevant, kelle vari kõigile teemadele langes, aga kelle olemasolu sellegipoolest keegi ei maininud. Tõenäoliselt sellepärast, et keegi ei osanud sellega midagi peale hakata, kuid igasugusele plaanile on ta takistuseks ikka.

Tegu on mõistagi informaatikaõpetajate palga teemaga. Kui informaatikaõpetajad saaks riigieelarvest rohkem palka kui teised õpetajad, põhjustaks see ilmselgelt kõvasti nurinat. Kui tal on aga olemas head IT-alased oskused (ja selleks, et lapsi õpetada, võiks need ju olla, lisaks ka pedagoogilised teadmised), aga palka saab vähem kui nooremspetsialist suvalises IT-firmas, on ka narr eeldada, et see eriala teab kui populaarne oleks. Ja tõepoolest, TLÜ sulges hiljuti vastava õppekava nõudluse puudumise tõttu.

Teiseks oleme langenud omaenda „kuvandi loomise“ kampaania ohvriks. Ühelt poolt, nagu eeltoodud Soome näitest näha, teevad naaberriigid ära asjad, millest Eesti puhul vaid pressiteated eksisteerivad. Teiselt poolt on ka kohalikud otsustajad uskuma jäänud, et IT-s ongi kõik juba suurepärane ja vastavasse haridusse pole tarvis rohkem panustada. Drastiline näide: Statistikaameti andmetel olid avaliku sektori kulutused teadus- ja arendustegevusele 2016. aastal väiksemad kui 2008. aastal! (https://www.stat.ee/pressiteade-2017-128).

Silmaga nähtav väljund neile probleemidele ongi, et osalised on vastastikku umbusklikud (olen olnud korduvalt tunnistajaks näiteks olukorrale, kus üldhariduskoolid ja ülikoolid takerduvad koostööd arutades sellesse, kelle kaudu mingi raha peaks liikuma), tirivad õhukesevõitu tekki enda poole ja jagelevad saadaoleva ressursi pärast, kui tegelikult peaks tegelema sellega, kuidas laiem ja paksem tekk hankida, mis kõiki korralikult kataks.

Mis on lahendus?

Õppekava ürituse üks meeldejäänud joon oli veel erinevate osaliste arv – haridusasutused, riigiasutused, sihtasutused, ettevõtted, liidud, seltsid. Igaüks neist korraldab oma üritusi ja projekte, mõnel on raha, teisel on inimesi, mõnel õnnelikul ka mõlemat. Tegevused on aga tavaliselt suhteliselt piiratud, ebastabiilse rahastusega. Ma käin isegi igal sügisel erinevatelt firmadelt olümpiaadi korraldamiseks raha küsimas.

Rääkisin teemast TÜ Arvutiteaduse Instituudi juhi Jaak Viloga, kes kinnitas samuti: „Probleem on Eestis, et kõik käigu justkui õhina-tuhina korras ja projektikestega. Õppekava võimalusi nii ei saa arendada.“

Tõepoolest, entusiastide tegutsemine on väga hea, kuid küsimuse struktuurseks lahendamiseks peaks enim panustama need, kes IT ja programmeerimise õpetamisest ka kõige rohkem kasu saavad. Peamisteks kasusaajateks on ühelt poolt IT-ettevõtted, kelle praegust potentsiaalset käivet ja kasumit kvalifitseeritud tööjõu nappus otseselt piirab, ning teiselt poolt Eesti riik, kellele vastava võimekusega spetsialistid mitmekordse keskmise jagu makse maksavad ja samal ajal riigi üldist infrastruktuuri efektiivsemaks muudavad.

Kahjuks esineb siin aga palju näpuga näitamist: ettevõtjad süüdistavad riiki ja haridusasutusi, et nood ei tee piisavalt õigeid asju, aga riik uriseb vastu, et miks ettevõtted ise ei panusta. Lahendus võiks peituda koostöös.

Esimene koostöötase saaks aset leida eraettevõtete vahel. Selle asemel, et igaüks midagi eraldi teeb, saaks luua Eesti IT-hariduse konsortsiumi, millel on võimalik tuhandete eurode asemel käsutada miljoneid ning sellega midagi tõsisemat korda saata.

Teine koostöö võimalus on ettevõtete ja riigi vahel. Olgu meil vaja palgata ülikoolidesse paar kõva õppejõudu või meelitada hulk spetsialiste koolidesse programmeerimist õpetama – vastastikune hea tahte avaldus ja riske maandav käitumine oleks see, kui näiteks ettevõtete konsortsium panustaks veerandi jagu rahast lõiku, mis neid enim aitaks ja riik kataks vastavatest kuludest ülejäänud kolmveerandi (viimase skeemi soovituse sain samuti Jaak Vilolt).

Veel üks vastus peitub taas pikemaajalises mõtlemises ja tänasest kaugemale vaatamises. Praegu räägitakse palju spetsialistide sissetoomisest. Esiteks ei suuda me sellel turul iial konkureerida selliste industriaalse võimsusega ajuimejatega nagu Silicon Valley või ka London või Berliin, mistõttu Eestisse jõuavad vaid globaalse intellekti teise ešeloni esindajad. Teiseks on see nagu kolmanda maailma riikide majanduskäitumine – selle asemel, et investeerida omaenda tööstusse, ostetakse teiste riikide valmistoodangut.

Nii nagu Saksamaa ehitas 20. sajandi keskel uuesti nullist üles kõva tööstuse ja tagas endale sellega pikaajalise juhtpositsiooni, on ka spetsialistide osas pikas plaanis efektiivsem ostmise asemel „ehitada ajutööstus“ ehk panustada vastavalt haridussüsteemi.

Selleks tuleb aga ettevõtetel mõelda kaugemale järgmise paari aasta kasumiaruandest ning riigivalitsusel kaugemale järgmistest valimistest. Vastasel korral ei jää ei tiigrist ega kuvandist lõpuks midagi järele.

Viimane lahendus on rohkem unistuste vallast, kuid siiski realistlik. Palju on räägitud sellest, kuidas Skandinaavia maade elanikud ei pane pahaks kõrgeid makse maksta, sest nad saavad selle eest vastu häid teenuseid, maksude maksmine on rohkem au- kui häbiasi. Analoogselt võiks Eesti eripäraks olla uhkus tulevikku (eriti haridusse) panustamise üle. Nii riik, omavalitsused kui ettevõtted saaks kiidelda ja võistelda, millise protsendi keegi oma eelarvest/kasumist haridusse ja tulevikuprojektidesse paneb. Maailmas, kus pahatihti elatakse pigem tuleviku arvelt, oleks “IT-riigi” kuvandist veel kõvem sõna “tulevikku panustav riik ja ühiskond”.

Ä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.

Augustis kirjutas Sandra Niinepuu Nihilistis, et IT õppimine on üle haibitud ja ei sobi igaühele.

Mõni aeg hiljem vastas sellele Margus Niitsoo, et reklaam on õigustatud, kuna inimesed (eriti keskkoolis) niikuinii ei tea, mida nad tahavad. Eks teismelise iga ongi see aeg, kui sa ei tea, mida sa tahad, aga tead väga täpselt, kuidas seda saada – katsun neid seetõttu hädast välja aidata.

Nimelt jäi esialgses diskussioonis minu meelest kummalgi poolel nägemata tõusulaine, mis kõik muud argumendid varjutab ning küsimuse hoopis teravamasse valgusse seab. Selles laines on aga nii mõnedki vastused.

Tarkvara sööb maailma

(Jaotuse pealkiri pärineb Marc “munapea” Andreesseni vastavast artiklist.)

Inimjõu asendamine tehnoloogiaga on sama vana kui tsivilisatsioon ning viimase arenguga lahutamatult seotud. Vankriga sai vedada suuremat koormat kui seljas ning veskiga jahvatada rohkem jahu kui käsitsi.

Pidevalt on muutunud ka inimeste töö sisu. 200 aastat tagasi töötas 90% eurooplastest põllumajanduses, praegu umbes 5%. 70 aastat tagasi oli enamik arenenud maade tööjõust hõivatud tööstuses, praegu 20-25%. Tehnoloogia asendas inimtööjõu kas otseselt või võimaldas tootmist liigutada odavamatesse piirkondadesse.

Muutused toimusid siiski vähehaaval. Kui külla tuli uus traktor, mis tegi ära kolme hobusemehe töö, hakkas üks neist traktoristiks, teine leidis töö kõrvalpõllul ning kolmas läks linna vabrikutööliseks. Tööpuuduse tase on ajalooliselt püsinud kümnekonna protsendi piires.

Nüüd on muudatuste tempo aga hüppeliselt kiirenenud, kuna peamine innovatsioon toimub tänapäeval tarkvaras. Erinevalt traktorist on meil tarkvarast võimalik kohe teha miljon koopiat, millest igaüks kohe kusagil inimtööaega sööma hakkab.

Võtkem näiteks Uber, mis võimaldab eraisikul pakkuda taksoteenust (eestlased võivad mõelda, et Uber=Taxify+telefoniga maksmine+tagasiside+eraautode võimalus). Tellimine ja tasumine on lihtne ja kiire, samuti saab nii arvestada nii juhi kui reisija kohta eelnevalt jäetud tagasisidega. Seetõttu eelistavad paljud inimesed Uberit tavataksodele, argumentideks odavam hind, suurem mugavus ja parem teenus. Uberi kasutuselevõtt suurlinnas paneb aga silmapilkselt löögi alla tuhanded traditsioonilised taksojuhid, kuigi materiaalselt on kõik sama, liikunud on ainult bitid ja baidid.

Praeguseks tegeleb tarkvara loomisega nii palju inimesi, et uus tehnoloogia kaotab töökohti kiiremini, kui need asenduvad – sotsiaalne koormus ületab ühiskonna seedimisvõime.

Muutuste sümboliks on minu jaoks isesõitev auto. Füüsiline sisu on kõik sama: mootor, käigukast ja rattad nagu igal teiselgi autol. Kaamerad ja radarid muidugi lisaks, aga ka need on maailmas juba ammu eksisteerinud. Kuid lisame tarkvara, mis võimaldab neid kõiki koordineerida piisavalt hästi, et inimest pole sinna enam tingimata vaja, ja mis juhtub? Miljoneid taksojuhte, bussijuhte, kaugsõiduautojuhte pole enam tarvis. Samuti pole tarvis neid miljoneid, kes on tegevad liikluskindlustuses või automüügisalongides. Doominoefekt ulatub kaugele.

Sarnaseid näiteid leiame pea igalt alalt, kuid eriti tavaliste keskklassi töökohtade seast. Kui vaadata tegevusi, mida ma praegu online teen, on nimekiri pikk: reisiplaneerimisest ja lendudele registreerimisest raamatute ostmise ja filmide vaatamiseni. Igaüks neist on kusagil ära söönud mingi tükikese varem inimeste poolt tehtud tööd, kuid see on alles algus. Näiteks enamik tegevustest, mida teevad arstid, õpetajad ja juristid, on tehnoloogiaga asendatav. Perearstile jääb pigem inimliku kontakti roll, kuid diagnoosi panna ja parimat ravimit soovitada suudab arvuti tema eest paremini. Kui üles kasvab põlvkond, kes suhtlebki ainult nutiseadmete vahendusel, võib ka sotsiaalne funktsioon kaduda.

Olles sel teemal erinevate inimestega rääkinud, on mitmetel tekkinud vihane reaktsioon, “kuidas ma julgen nende ametit maha teha!“ Ma ei anna kõnealustele muutustele moraalset hinnangut hea või halva osas. Jah, see võib olla hirmutav. Jah, paljude inimeste elu pööratakse pahupidi. Aga seda protsessi suunavad majandusseadused on sama vääramatud kui loodusseadused, mis näiteks mõne asteroidi Maaga kokku põrkama suunavad. Näppude kõrvadesse surumine ei muuda asja olematuks, kuid me võime nendeks muutusteks valmistuda.

Tulevikuühiskonna struktuur

Tuleme nüüd tagasi esialgse teema juurde – mida võiks inimene õppida, kuidas tulevaseks eluks valmistuda?

Üldised printsiibid on:

1. Tehnoloogia muudab enamiku töövaldkondadest majanduslikult efektiivsemaks.
2. Kui mingis vallas keegi tehnoloogiasse investeerib, on konkurentsis püsimiseks vaja seda teha ka teistel. Süsteem saab positiivset tagasisidet ning liikumine kiireneb.

Järeldus 1: Praegune ülisuur nõudlus tehnoloogiaspetsialistide järele kasvab veelgi.

Järeldus 2: Kui on võimalik, et masin saab sinu ametit (või mingit osa sellest) efektiivsemalt teha, siis varem või hiljem see ka juhtub.

Trendi ekstrapoleerides jõuame järgmise kihilise ühiskonnani:

• Inimesed, kes tehnoloogiat loovad ja käigus hoiavad (liigitan siia alla ka ettevõtjad, juhid ning organisaatorid, kes seda oma tegevuses rakendada suudavad).
• Traditsioonilised ametid, millest paljusid tehnoloogia ohustab.
• Sotsiaalsed töökohad, mida luuakse neile, kes uues maailmas muidu kohta ei leia, vältimaks tänavarahutusi.

Valikuid tehes tuleb seega arvestada, et mitte-tehnoloogiliste töökohtade olemus muutub oluliselt. See ei tähenda tingimata, et ametid täielikult kaoks. Näiteks med-õe töö füüsilist aspekti saaks suuresti täita masin. Inimese peaosaks jääks patsiendi käehoidmise osa, mis eeldab aga teistsugust oskuste komplekti. Töötundide koguarv siiski väheneb, mis tähendab, et personali on võimalik koondada.

Globaalne vaade

Mida see kellelegi konkreetsemalt võiks tähendada? Alustame maailmast globaalselt.

Ajalooliselt on riigid käinud läbi kolm majandusmudeli etappi: põllumajanduslik, tööstuslik ja teenustepõhine, vastavalt sellele, millega inimesed eelkõige tegelevad. Euroopa ja Põhja-Ameerika on jõudnud kolmandasse etappi. Riigid, kus valmib enamik meie tarbekaupu (eelkõige Hiina), tegelevad tööstusega. Osad piirkonnad (eelkõige Aafrika) on aga endiselt kinni situatsioonis, kus valdav osa inimestest tegelevad põllumajandusega.

Kui Hiina elatustase tõuseb, liiguvad sealsed inimesed samuti pigem teenuste sfääri ning tööstus suundub mujale. Ajalooliselt pole veel ükski majandus liikunud otse põllumajandusest teenustesse. Alati tehakse vahepeal läbi industrialiseerimise etapp, mis võimaldab kasvatada inimkapitali, tõsta elanikkonna haridustaset ning välja kujundada kaasaegse ühiskonna toimimiseks vajalikke institutsioone.

Globaalne tööstuse raskuskese on odavamat tööjõudu otsides korduvalt ühest kohast teise liikunud, luues uusi tehaseid ja infrastruktuuri. See on omakorda aidanud eri piirkondadel teha hüpet tänapäeva.

Mis juhtub aga siis, kui robotid muutuvad odavamaks kui maailma kõige odavam tööline? Kui igasuguseid plastikust vidinaid on lihtsam kohapeal 3D printida, mitte üle mere importida?

Võib juhtuda, et tööstuse maailmarännak peatub. Rohkem pole vaja midagi outsource’ida ning näiteks Aafrika riigid jäävadki lõksu, kus neil pole võimalik oma majandust moderniseerida. Neist saab sotsiaalseid töökohti vajava ühiskonnakihi globaalne ekvivalent – piirkonnad, mida toetatakse parasjagu nii palju, et mäss liiga suureks ei kasvaks, aga neil on väga raske sealt edasi liikuda.

Riiklik vaade

Tsiteerin Sandra esialgset artiklit: „Nn STEM (science, technology, engineering, math) erialade ebaproportsionaalne ülerõhutamine ei ole jätkusuutlik, sest innovatsiooniks ja dünaamiliseks majandusarenguks vajame erinevate oskuste ja teadmistega inimesi.“

Kui ma muidu olin Sandraga enamikus asjades nõus, siis ebaproportsionaalse ülerõhutamise osaga kindlasti mitte.

Arvudele otsa vaadates näeme, et:

• IKT sektor toodab kõigis maades võrreldes tööhõivega suurema protsentuaalse osa sisemajanduse kogutoodangust.
• IKT töökohtade arv on kõikjal kiiresti kasvav. Nende „erinevate oskuste ja teadmistega inimeste“ osas on kohtade täitmine reaalselt palju lihtsam kui hea tehnoloogi leidmine.
• Eestis on IKT osa tööhõivest väiksem kui OECD keskmine.

Seega oleme ülerõhutamisest väga kaugel. Vastupidi, tegelikult rõhume me liiga nõrgalt, konkurentsis püsimiseks on tarvis oma insenerkonda kasvatada nii kiiresti kui jaksame.

Organisatsiooni vaade

Aga kuidas on ettevõtetega, mille tegevus on midagi muud? Kas pole nii, et nende jaoks on IT lihtsalt tugifunktsiooni rollis? Jah ja ei.

Võime küsida, kas Amazon.com on kaubandus- või tarkvaraettevõte? Kas Netflix on videolaenutus või tarkvarafirma? Kas Pixar on filmi- või tarkvaraettevõte? Kas Transferwise on finants- või tarkvaraettevõte? Kas Skype on telko- või tarkvaraettevõte?

Kõigi nende näidete puhul sööb tarkvara vastavat valdkonda seestpoolt ja on saanud määravaks osaks ettevõtte põhiväärtuse loomise protsessist. (Kõik nad on ka maailmast kaotanud suurel hulgal “vanu” töökohti.)

Ka teistes traditsioonilistes tööstusharudes on tohutult ruumi revolutsiooni läbiviimiseks. Arvatavasti määrab järgmise generatsiooni edukaimate ettevõtete nimekirja ära see, kui efektiivselt suudab keegi tavapärast tootmist tarkvara abil nutikamaks muuta. Isegi poliitikas on andmeanalüüsi võimekus saanud võtmetähtsusega probleemiks.

Isiklik vaade

Tulles veelkord tagasi Sandra artikli juurde, paistis seal silma milleniaanlik optimism, et kui sa vaid tegeled millegagi, mis sulle meeldib, küll siis kõik hästi läheb. Jah, kui sul on tugev kirg millegi vastu, on ilmselt parem seda järgida. Aga kui erilist vahet ei ole, on parem lasta mikroökonoomikal enda kasuks töötada.

Nagu igal teiselgi turul, määrab ka tööturul hinna nõudmise ja pakkumise suhe. Kuna IT alal ületab nõudlus pakkumist, lähevad ka palgad üles, seda isegi tavapäraselt jäigas avalikus sektoris.

Näiteks on Tartu Ülikooli professorite keskmine palk 3000 euro kandis (miinimum samas 1780 eurot). Samas arvutiteaduse professorile pakutakse 5000 eurot.

Või vaatame suurepärast tabelit, kus on kirjas kõik Eesti riigiametnike palgad ja mida vastava veeru järgi sorteerides võib iga riigitöötaja näha, mitmendal kohal ta asub. Kui teiste asekantslerite keskmine põhipalk on 3473 eurot, siis Taavi Kotka, IT asekantsler, saab 4999 eurot.

Erasektorist ei hakka rääkimagi, nii Eesti kui ka maailma rikkaimate inimeste edetabelites domineerivad praeguseks IT-ga seotud nimed. Ka seni ainus inimene, kes on miljard dollarit teeninud mitte ettevõtluses, vaid kellegi teise firmas töötades, oli tarkvaraarendaja. Just tänu suurele nõudlusele kvalifitseeritud inimeste järele sai IT-st ka alguse komme tasustada kõiki töötajaid aktsiaoptsioonidega, mis on tekitanud miljonäre rohkem kui kunagi varem.

Isegi kui raha pole sulle tähtis, tuleb meeles pidada eelpool mainitud tõusulainet. Kui praegu on silmapiiril tehnoloogia, mis võimaldab mingi töö paremini ära teha, siis 5 aasta pärast on see prototüüp, 10 aasta pärast edukaimates kohtades kasutusel, 15 aasta pärast mainstream ning 20 aasta pärast pole inimestel enam mõtet tööavaldusi saata.

Juba praegu toodavad mitmed ülikoolis õpetatavad erialad surnult sündinud spetsialiste, kellel pole erialast väljundit. Milleks siis sinna lõksu astuda?

IT haridus

Eelnevast võib jääda mulje, et IT-s on ainult pudrumäed, liigutad aga näppe ja klotsi kukub nagu tetrises. Päriselt puudutavad kirjeldatud muutused muidugi ka IT-sektorit ennast. Nagu teisteski majandusharudes, on ka IT-s palju tegevusi, mida on võimalik automatiseerida. Hea näide on igasugune „administreerimine“. 20 aastat tagasi oli kasvõi ülikooli arvutiklassi administraator oma asendamatuse tõttu nii kõva mees, et õppejõudki teda kartma pidid, aga nüüd toimib halastamatu vähempakkumine – igasugune IT infraga tegelemine liigub hoogsalt kas odavamatele teenuspakkujatele või siis automatiseeritakse täielikult.

Septembris vaatasin konverentsil ettekannet, kus rääkis Amazon.com’i CTO Werner Vogels. Hoolimata sellest, et Amazonil on miljoneid servereid, pole seal süsadminne, sest kõik on automatiseeritud. Ning aastas liigutavad sajad tuhanded ettevõtted oma andmed Amazoni serveritele. Selgelt väheneb siis ka vajadus igasuguse kohaliku riistvara järele, olgu tegu kas serverite müügi või kaablite vedamisega.

Seega ei söö tarkvara mitte ainult teisi valdkondi, vaid ka omaenda lapsi, vähemalt neid, kes ei suuda loomingulisuselt ja nutikuselt masinast üle olla.

Siin on mängus veel üks oluline asjaolu. Peaaegu igale konkreetsele tehnoloogiale on sisse programmeeritud tema eluiga. Olenevalt oma keerukusest ja paindlikkusest on ta kas kiiremini või aeglasemalt asendatav millegi uuema, abstraktsema ja võimsamaga. Kuna tehnoloogia nõuab uuendamist, siis on vaja ka tehnolooge, kes suudavad seda pidevat asendamist läbi viia.

Vahel küsitakse mult: „mida ma peaksin õppima?“ Andmebaase või veebidisaini? Javat või PHP-d? Millisesse kooli minna? Tartu? TTÜ? IT Kolledž? MIT?

Sisu osas tegelikult suurt vahet pole. Kõike, mis koolis õpetatakse, saab omandada ka ise. Samuti tuleb karjääri jooksul niikuinii palju kordi rada vahetada ning täiesti uusi asju õppida. Seega pole oluline mitte konkreetse asja tundmine, vaid õppimisvõime.

Sellepärast küsin ma ka tööintervjuudel otse ülikoolist tulevatelt kandidaatidelt, mis koolis nad käisid, kuidas neil seal läks, milliseid aineid võtsid ning milliseid õppejõude kuulasid. Konkreetsed ained ei oma tegelikult tähtsust, aga kui inimene on käinud pigem raskemas koolis, võtnud raskemaid aineid ning saanud selle eest paremaid hindeid, demonstreerib see tema suuremat õppimisvõimet ja ennustab seeläbi edasist edukust. Analoogiliselt on tähtis, kas kandidaat tegi näiteks oma lõputöö ära või on veel pooleli – mitte sisu pärast, vaid seetõttu, et see näitab asjade lõpule viimise oskust.

Kokkuvõtteks: maailm keeratakse pea peale, meeldib see meile siis või mitte. Mingil määral on kontrollitav, kas maandud siirupitünni või virtsavaati, aga igaüks saab oma saatuse suunamises ainult iseendale toetuda. Suuremad struktuurid nagu riik ja ühiskond jäävad kaugelt liiga aeglaseks, et nendele loota.

Igaüks, kes on puutunud kokku mingi tarkvaraarendusega, on kuulnud või kogenud ka järgmist:

“See on mingi vana kood, mida keegi ei tunne, ära seda parem puutu.”

“See vana süsteem, millest keegi midagi ei mäleta. Mõnikord see ei tööta, siis me lihtsalt restardime seda.”

“Me vajutame siin neid nuppe kindas järjekorras, et asjad töötaks. Me ei tea, mis juhtub, kui teises järjekorras vajutada.”

Tegu on riknenud ehk legacy süsteemiga, pea igas organisatsioonis on mõni selline, vahel ka päris mitu. Kunagi on nende loomiseks kulunud palju raha, aega ja vaeva, aga nüüd tundub, et neist on rohkem tüli kui tulu. Kui uurida, mida teha, on arendajate lemmikvastuseks: “See vana asi on täielik jama ja kõik tuleks nullist ümber kirjutada!” Rahakoti käsutajatele see muidugi ei meeldi ja nii lükatakse “nullist ümber kirjutamist” edasi nii kaua kui võimalik. Eestis on suuremad süsteemid pea eksklusiivselt avalikus sektoris ning sagedaseks lahenduseks legacy probleemile on uue rahalaeva saabumine Euroopast.

Viimasel ajal on ümberkirjutamise idee aga jõudu kogunud ning Eesti avalik sektor soovib sisse viia lausa reegli, mis kohustaks süsteeme teatud aja tagant uuendama (otsi artiklist “no-legacy”).

Kas see ümberkirjutamine on aga parim tee? Kuidas süsteem üldse legacyks muutub? Ja mis elukas see legacy üldse on?

Minu kogemuses on tarkvara sisulise moraalse vananemise peamiseks sümptomiks hirm. Kas programmeerijad kardavad mingeid asju muuta? Kui neid muudatusi siiski tehakse, siis kas tellijad kardavad “kaardimaja efekti”? Hirmu mõõtmiseks on keeruline head joonlauda välja tuua, peamiselt on see hinnatav arendajate küsitlemise kaudu.

Aga miks arendajad kardavad? Sellepärast, et neil pole võimalik kergesti kontrollida, kas nende muudatused teevad midagi katki.

Regressioonide vältimiseks kasutatakse erinevates organisatsioonides mitmesuguseid meetodeid. Kõige tavalisem neist on, et tarkvara vastuvõtja (sageli mingi peakasutaja isikus) käib enda tavalised stsenaariumid läbi ja vaatab, et tema lemmiknupud paigast poleks nihkunud. Kui kontrollimiseks on mingid kirjapandud stsenaariumid ja fikseeritud protseduur, on tegu juba päris kõva sõnaga.

Sageli juhtub aga, et organisatsioonis polegi kedagi, kes suudaks kontrollida, kuidas asi peaks tegelikult töötama, sest “eit teadis, aga eit suri ära” ehk siis lahkus töölt, kaotas vastavad dokumendid ära või lihtsalt unustas. Siis ongi meil klassikaline riknenud tarkvara, kus me ei tea, mis töötab, mis mitte.

Rohkemat on väga raske teha, sest tarkvara regulaarne käsitsi kontrollimine on ausalt öeldes üsna nüri tegevus. Uncle Bob ütleb, et see on lausa amoraalne. Teoreetiline lahendus on mõistagi ilmne – las masin teeb igavat tööd, tema on rauast. Head automatiseeritud unit testid vähendavad süsteemiga seotud hirmu drastiliselt.

See on niivõrd oluline asjaolu, et ma kasutaks sellist definitsiooni: legacy on tarkvara, millel puuduvad efektiivsed unit testid.

Unit testide puudumine viib muudatusteni, mis pole verifitseeritud ja kasvatavad statistilist tõenäosust, et süsteemis on igasuguseid varjatud vigu, kuni lõpuks on olukord täielikult kontrolli alt väljunud.

Kui palju unit teste tegelikult kasutatakse? Minu kogemuses on siin tugev korrelatsioon sellega, kui palju tarkvarast hoolitakse. Oma isiklikud projektid on mul üsna hästi kaetud, mõni neist on 10+ aastat vana ja kannatab ikka üsna hästi arendamist ja täiendamist. Erasektoris on olukord laiguline – kui organisatsiooni eduks vajalikku tarkvara tehakse majas sees, saadakse üldiselt ka aru selle jätkusuutlikkuse hoidmise vajadusest.

Avalik sektor, kus mittehoolimise seemned on külvatud juba sügavale seadusandlusse, lepingutesse ja organisatsioonikultuuri, on vaeslapse osas. Unit testing nõuab ehk 20% ekstra aega (ja see aeg võidetakse tagasi juba esimese suurema muutuse realiseerimisel), kuid tarneahel, kus prioriteetideks on kiirus ja odavus, lõikab selle ekstra viiendiku armutult maha.

Ja nii olemegi olukorras, kus tarkvara on reaalselt riknenud juba esimesest päevast peale ning meil ei jää muud üle, kui peatselt uus süsteem tellida.

Poliitika, mis kohustab asutusi oma süsteeme regulaarselt uuendama, parandab mõnevõrra olukorda, kuid minu meelest ravime me sellega haiguse sümptomeid, mitte põhjust. Samuti on siin oht, et kui me kehtestame reegli, mille kohaselt tuleb iga 10 aasta tagant niikuinii uus tarkvara teha, siis kaob ka motivatsioon disainida tarkvara, mis peaks vastu nt 15 aastat. Viimane on hetkel küll puhtteoreetiline konstruktsioon, praegu oleks tore näha ka tarkvara, millega kasvõi pärast ametliku garantiiperioodi lõppu midagi teha on.

Minu endine tubli kolleeg ja praegune MKMi osakonnajuhataja Aet Rahe uurib, kuidas Eestis legacyga lood on ning milliste probleemidega asutused peamiselt kokku puutuvad. Tegu on tänuväärse tegevusega, sest minu teada pole sellist kaardistust Eestis varem tehtud.

Uurimuses on välja toodud mõned ideed, miks võiks organisatsioon soovida oma tarkvara vahetada. Kui häda käes, on need muidugi pädevad põhjused muudatuste tegemiseks, aga märksa parem oleks neid põhjusi ennetada. Siin väljavõte:

• Liiga suured haldus- ja hoolduskulud

“Hoolduskulud” tähendab enamasti, et asjad lähevad katki, neid proovitakse parandada, aga edutult, parandatakse uuesti, mispeale lähevad hoopis teised asjad katki jne. Tegu on asjaga, mida unit testid definitsiooni kohaselt peaks parandama.

• Ärilised või seadusandlikud muudatused

Ma eeldaksin, et kui organisatsioon ei hakka tegelema just mingi täiesti teistsuguse põhitegevusega, puudutab see muudatus siiski vaid väiksemat osa süsteemi loogikast. Ja kui tarkvara on disainitud korrektselt, s.t selle osad ei ole omavahel liiga tihedalt seotud, on võimalik neid osi ka üksteisest sõltumatult muuta.

• Arhitektuuri keerukuse tõttu ei ole mõistlik enam süsteemi täiendada

Probleemi sõnastus ütleb ette ka vastuse – hea arhitektuur ei ole ülemääraselt keeruline.

• Vendor lock-in

Vendor lock-in tähendab enamasti, et keegi peale vendori ei tea, kuidas tarkvara päriselt töötab (vendor teab vähemalt natuke) ja seetõttu ei julge keegi seal muudatusi teha. Kui meil on võimalik süsteemi tööd kergesti verifitseerida, kaob ka see oht.

• Tehniliselt aegunud platvorm

Kui kasutatav tehnoloogia pidurdab süsteemi täiendamist, pole süsteemi osad suure tõenäosusega üksteisest piisavalt eraldatud. Kui kasutajaliideses pole eeldusi äriloogika reeglite kohta, ei takista keegi meil nt uut töövoomootorit kasutusele võtta. Kui äriloogikas pole eeldusi andmebaasistruktuuri kohta, ei takista keegi meil andmebaasi vahetamast. Kui andmebaasi pole sisse kirjutatud veebilehekülgede aadresse, pole ka mõne uue fancy UI toolkiti kasutuselevõtt probleemiks.

• Puudub korrektne dokumentatsioon

Dokumentatsiooniga on see häda, et me tahaks mõõta tema eluiga kuudes ja aastates, aga reaalselt vananevad dokumendid päevade ja vahel isegi tundidega. Samas, kui meil on olemas korrektne töötavate automaattestide kogum, kajastab see definitsiooni kohaselt meie tarkvara tööd. Maha dokumentatsioon, elagu testid!

Kokkuvõttes:

1. Tehes asju korralikult, saame enamikku probleemidest vältida ning tarkvara eluiga dramaatiliselt pikendada.
2. Tarkvara korralikult tegemine ei ole eriti palju kallim (kui üldse).

Korralikkus jääb aga kahe asjaolu taha: lühiajaline mõtlemine ning teadmiste puudumine.

Lühiajaline mõtlemine on suuresti tingitud lepingute struktuurist. Kui ikka täitjale on loodud tugev motivatsioon teha asju võimalikult kiiresti ning pärast meid tulgu või veeuputus, on ka ennast hävitav kuidagi teisiti talitada.

Üks lahendus oleks siin pikemaajaliste raamkokkulepete kasutamine. Eestis on raamlepingud tavaliselt 3 aastat pikad, Soomes sageli nt 10-15 aastat. Teiseks saab paremini lahti kirjutada, millised on hooldusperioodi kohustused.

Teadmiste puudumine on probleemiks nii tellija kui täitja poolel. Kui võtame näiteks test-driven developmenti (TDD), siis ülikoolis seda ei õpetata ja ka enamik tööandjaid ei suuna oma töötajaid selles osas. Nii õpib enamik TDD praktiseerijaid kas kolleegidelt või internetist, enamasti pärast mitmeid põrumisi ja suurt frustratsiooni. Ma ise sain ka asjale alles siis pihta, kui olin kogenud asjatundjaga samasse tiimi sattunud.

Kusagilt tuleb aga siiski alustada. Minu meelest annaks kohustusliku best before tähtaja sisse seadmise asemel hoopis suurema efekti avaliku sektori tarkvaratellijate koolitamine selle osas, kuidas tarkvara rikneb ja kuidas seda välditakse. Hea oleks ka hangete tarvis näidisnõuete ette kirjutamine, kuidas tagada tarkvara paremat verifitseeritavust.

Eelmise aasta lõpupoole korraldas Äripäev seminari Kuidas korraldada edukaid tarkvarahankeid, kuulajaskonnaks mitmesugused avaliku ja erasektori esindajad, kellel aeg-ajalt vaja tarkvara tellida. Tegin ise ettekande agiilse arenduse teemal, refereerin nüüd ka siin. Osaliselt on kasutatud kaastöötajate Tiit Anmanni ja Aet Rahe koostatud materjale.

Aga kõigepealt väike viktoriin. Andke igale järgnevatest küsimustest vastusena 2 arvu: alampiir ja ülempiir. Püüdke teha nii, et olete 90% kindel, et õige vastus on nende 2 arvu vahel.

Väliseid abivahendeid ei tohi mõistagi kasutada. Kui vastused kirjas, võib neid kontrollida siit.

Kui vastata nii, et iga küsimuse puhul on 90% tõenäosus, et õige vastus jääb antud alam- ning ülempiiri vahele, peaks saama keskeltläbi 9 õiget vastust. Samas olen seda viktoriini aga päris mitu korda tegelikus elus korraldanud. Olukorras, kus inimesed häbenevad teiste kuuldes väga ebamääraselt vastata, on tavapärane õigete vastuste arv pigem 2.

Milles on point? Mõistagi mitte inimeste vaaladealaste teadmiste kontrollis. Pigem on asi selles, et enamvähem sellise metoodikaga antakse mahuhinnangud ka enamikule maailma tarkvaraprojektidest. Kuidas nii? Väga lihtne – iga projekt on tegijate jaoks uus. Kui järgmine projekt oleks täpselt samasugune nagu eelmine, poleks seal vaja midagi teha, vaid võiksime lihtsalt võtta olemasoleva koodi ja selle kopeerida. Väga tihti sisaldab uus projekt ka mingeid uusi tehnoloogiaid ja ärivaldkonda, mille kohta teostajatel pole vähimatki aimu.

Siiski leiab iga päev kusagil aset stseen, kus projektijuht näitab vanemarendajale mingit umbmäärast kirjeldust ja küsib, kui kaua sellega läheb. Vanemarendaja ei taha muidugi välja näidata, et tal on sellest sama vähe aimu kui Peipsi ruumalast, ning käibki mingi arvu välja. Sealjuures enamasti ühe arvu, mitte alam- ja ülempiiri.

Hinnang läheb pakkumisse, sealt lepingusse ja aasta-paari pärast kakeldakse, miks asjad õigeks ajaks valmis pole saanud. Samuti võivad tellija ja täitja esialgsed hinnangud olla radikaalselt erinevad.

Mis on tarkvaraprojekti tüüpilised mured?

• Asjad ei saa planeeritud eelarves ja ajakavas valmis.
• See, mida telliti, ei ole see, mida vaja oli.
• Projekti käigus muutuvad ja täienevad nõuded pidevalt.

Halvemal juhul võib juhtuda, et:

• “Teine pool” on laisk, loll jne.
• Projekt ei saagi valmis!
• Ja isegi raha juurde makstes ei saa valmis!!

Mispärast? See pole ju ometi esimene projekt, mida “te” teete? Te olete ju oma ala asjatundjad?! Professionaalid!?

Vaatleme järgnevat illustratiivset näidet (NB! Tegemist on üldistusega. Igasugune kokkulangevus reaalse elu sündmuste või tegelastega on juhuslik).

Oletame, et oled ehitusfirma omanik. Kui palju maksab see maja?

Pakkumise esitamise tingimused:

• Esitada fikseeritud hinnaga pakkumine 05.02.2013.
• Valmimise tähtaeg 15.06.2013.
• Täpsustavaid küsimusi saab esitada kirjalikult, vastame 3 tööpäeva jooksul.
• Maja hind peab sisaldama kõike eluks vajalikku, s.h. siseviimistlust ning kogu vajalikku mööblit, kommunikatsioone jmt.
• Tööde käigus hinda suurendada ei ole võimalik, küll aga on Tellijal õigus vajadusel hinda vähendada.
• kaasas 10 lk-line maja „detailne“ kirjeldus.
• Kirjeldus sisaldab enamasti maja välimuse kirjeldust väljastpoolt vaadates. Erilist tähelepanu on pööratud detailse maja eestvaate kirjeldamisele (kuna see on tellija arvates eriti oluline osa!).
• Kirjelduses ka üldandmed. Näiteks: elamispind 200 m², maja taga terrass, 3 korrust jne.
• Kirjelduse on koostanud ehitusalase hariduseta ja kogemuseta isik.

Ainsaks valikukriteeriumiks on hind.
Hankega käib kaasas lepingu projekt.

Kui keegi nüüd arvab, et ma liialdan, siis valdav enamik tarkvarahankedokumente, mida ma olen elus lugenud, vastavad sellele kirjeldusele.

Aga egas midagi, hakkame tööga pihta!

Ainsateks muredeks on mõistagi vaid asjaolud, et kõik kaasatud osapooled on õnnetud ning ka lõpptulemini jõudmine ei tee kedagi õnnelikumaks.

Kirjeldatu oli praegu standardsituatsioon. Kui selline projekt juba alanud on, juhtub enamasti üks kahest variandist:

Esimene võimalus on see, et täitja projektijuht hoiab raudhammastega skoobist kinni. Aset leiavad järgmised tüüpilised dialoogid:

“Aga me tahaks seda ka.”
“Ei saa.”
“Aga kuidas sellega oleks?”
“Ei saa.”
“Aga…”
“Ei saa.”

Ja loomulikult kurdab tellija, et täitja on mõistmatu.

Siiski tuleb tähele panna, et see on pigem hea variant!

Alternatiiv on tavaliselt selline:

Kõigepealt tekivad haldamatud muudatused. Pärast mitmeid tähtaegadest üleminekuid on kaks võimalust: projekt ei valmigi mitte kunagi või siis tuleb seda saneerida, suurest osast ideedest (ja poolvalmis tööst) loobuda ning see, mis toodangusse antakse, võib olla isegi väiksem kui esialgne skoop ette oleks näinud.

Kõik tarkvaraprojektidega kokku puutuvad inimesed on ilmselt seda kolmnurka näinud. Samas keegi ei kasuta seda. Alati, kui kellegagi rääkida, et mida neist valida, saab sama vastuse nagu Karupoeg Puhhilt, kui küsiti, kas too soovib mett või kondenspiima: “Mõlemat!”

Tulemus on mõistagi selge: kui kolmnurga igat tippu väljapoole tirida, käriseb see seest ning ohverdatakse see, mida on kõige raskem mõõta – kvaliteet. On ka täiesti loomulik, et kui lepingusse ikka tähtaegade ületamise eest on trahv sisse kirjutatud, lükatakse kliendile ette mida iganes, et sellest pääseda – eks pärast jõuab klaarida.

Kuna senikirjeldatud probleemid on äärmiselt tavalised, on neile mõistagi ka mitmesuguseid vastumeetmeid leida püütud.

Üks levinumaid “lahendusi” on võimalikult põhjaliku nõuete loetelu koostamine enne projekti algust. Tavaliselt käib see nii, et tellija poolelt on keegi saatnud laiali ringkirja ja palunud kõigil huvilistel oma mõtted kirja panna. Tulemus copy-paste’itakse hankedokumenti ning öeldakse, et vaat, täpselt neid asju ongi vaja.

Selle lähenemise probleemid on muidugi ilmsed:

• Kirjapandu on prioritiseerimata – kuna igaühel on hirm, et tema soovid võivad välja jääda, fantaseeritakse kokku pigem rohkem kui vähem. Tulemuseks on süsteem, mille võimalustest rohkem kui 50% ei hakka keegi kunagi kasutama – enam kui pool tellija rahast läheb lihtsalt raisku! Halvemal juhul võib hankedokumendist leida ka omavahel risti vastu käivaid soove…
• Me välistame kõik head ideed, mis meil projekti käigus võivad tulla.
• Lõplikul süsteemil on kõik “design by committee” omadused.

Teine võimalus on, et lepingus fikseeritakse keerukas muudatuste haldamise protseduur. Iga muudatus tuleb kõigiga kooskõlastada, projektiplaani täiendada jne. See on natuke parem variant, aga toob kaasa äärmiselt koormava bürokraatia. Kui iga ettepanek nõuab projektiplaani mõjuhinnangut ja spetsifikatsioonide ümberkirjutamist enne muudatuse heakskiitu, võtab plaanide ümberjoonistamine ja kooskõlastamine lõpuks inimeste kogu aja ära ja keegi ei taha seda teha. Lõpuks jõuame olukorrani, kus muudatuste haldamise protseduurist on saanud muudatuste vältimise protseduur.

Täitja poolt pakutakse muidugi omi võimalusi. Raudhammastega projektijuhist oli juba juttu, aga kõige tüüpilisem on kõigi ajahinnangute korrutamine mingi konstandiga (näiteks π). Siin on muidugi tulemuseks, et tegelik ajakulu tuleb tõenäoliselt hoopis midagi muud, kui esialgu planeeritud, ning üks või teine pool tunneb paratamatult, et on pügada saanud.

Arendajate lemmikalternatiiv on mõistagi Time&Material – tellija maksab kogu aja eest, mis arendajal kulus. See on tellijaile tihti hirmutav ning õigusega – kulude kontrolli alt väljumine on arvestatav oht.

Kokkuvõttes jõuame arusaamisele, et:

• Mittetriviaalsed tarkvaraprojektid on põhimõtteliselt ennustamatud.
• Muudatused on vältimatud.
• Tarkvaraprojekti ei ole võimalik ega praktiline detailselt ette planeerida.
• Kombinatsioon “fikseeritud hind, skoop ja tähtaeg” lõpeb enamasti ebaõnnestumisega.

Järeldus: muudatustesse tuleb suhtuda nagu paratamatusse ning protsess tuleb üles ehitada nendega arvestamiseks, mitte nendega võitlemiseks.

Aga mida konkreetselt teha?

Peamine rohi, mida kirjeldatud probleemide vastu välja pakutakse, on agiilne arendus. Peaaegu kõigile tarkvaraorganisatsioonidele meeldib kirjeldada ennast kui agiilseid. Mis värk sellega aga tegelikult on?

Agiilse arenduse alustalad on:

• Suhtlemine on tähtsam kui protsess.
• Töötav tarkvara on tähtsam kui dokumentatsiooni täielikkus.
• Kliendi ja täitja koostöö on tähtsam kui lepinguläbirääkimised.
• Muudatustele reageerimine on tähtsam kui plaani järgimine.

Vaatlen siin lähemalt Scrumi, aga nimetatud printsiibid kehtivad ka kõigi teiste metoodikate (nt Kanban) puhul.

Scrumi peamine omadus on Product Backlog – tööde hulk, mille võiks ära teha. Kõik uued ideed lisatakse lihtsalt backlog’i. Iga alametapi ehk sprindi alguses valitakse tööde nimekirjast (tellijaga koostöös!) kõige olulisemad asjad, mida ära teha, ja tarnitakse selle tulemus mõned nädalad hiljem.

Siit on ka selgelt näha, et projekti lõplik skoop ja tähtaeg ei saa olla korraga fikseeritud! See tähendab ka loobumist konkreetseks tähtajaks valmivast detailsest projektiplaanist (ning selle pidevast ümberjoonistamisest).

Teine peamine omadus on sagedased (mõõdetavad nädalates, mitte kuudes) tarned ning see, et iga tarne tulemus peab olema kliendile kohe kasutatav.

Ja kolmas peamine omadus on kiire klienditagasiside. Siit tuleneb ka nimetus “agiilne” ehk väle. Asi pole mitte selles, et programmeerijad liigutaksid kiiremini näppusid, vaid selles, et klient vaatab tööde tulemusi kiiremini ja sagedamini üle!

Scrumi õnnestumise või ebaõnnestumise määrab üldjuhul see, kas tellija läheb metoodikaga kaasa või mitte. Tean paljusid projekte, kus tiimiliikmed ütlevad, et oh, meil on Scrum, sest nad teevad igapäevaseid koosolekuid, aga tegelikult on projektil ikka fikseeritud skoop ja tähtaeg. Kui projekti üks pool on agiilne ja teine mitte, on tulemus nagu absurdianekdoot:

See, et skoop pole fikseeritud, peab olema ka arenduslepingus kajastatud, vastasel korral ei tule asjast midagi välja.

Lisaks tagasisidele on vajalik ka tellija aktiivne osalus backlogi prioritiseerimises, mis nõuab detailset süvenemist ning inimesi, kellel on tegelikult ka võimalik panustada aega ja pingutust ning samas võtta vastu otsuseid prioriteetide osas. Kui iga otsust mingi komitee või juhtrühm kinnitama peab, ei tule jälle midagi välja.

Kuidas Scrumi hinnastada?

Heaks mudeliks on fikseeritud skoobi ja T&M vahepealne variant. Iga sprindi alguses lepitakse kokku mingi tulem ning vastava sprindi lõpus tasutakse selle eest. Enam pole vaja maagilisi konstante, millega hinnanguid korrutada ja mis emmale-kummale poolele kaotuse kaasa toovad!

Süsteem on õiglane, sest tellija maksab parasjagu selle eest, mis on kätte saadud (iga sprindi tulemus peab olema kasutatav!), ning täitja saab parasjagu nii palju raha, kui palju on tööd tehtud.

Siiski võib jääda kahtlus, et milleks see kõik? Tundub kangesti hirmutav, et kuidas me siis ei kirjelda kõiki nõudeid, kuupäevi ja eurosid algusest peale ära…

Agiilse arenduse konkreetsed kasutegurid, mida igaüks oma tuttavatele tarkvaratellijatele võib presenteerida, on:

Arendaja

Tegeles kunagi tõsiselt programmeerimisega, aga siis otsustas, et kellegi teise heaks töötamise raamid on liiga kitsad, ning asutas oma firma. Ettevõtte suuremaks kasvamise ajaks on enamikest uutest progejatest vanem ning armastab neile rääkida, kuidas vanasti olid mehed rauast ja väänasid haljast assemblerit.

Arendaja hindab töötajates ennekõike pragmaatilisust, probleemide lahendamise ja asjadega valmis saamise oskust.

Ettevõtte eesmärkideks seab ta tehnilise arengu, väljakutsuvad ülesanded ning elegantse teostuse.

Teadlane

Teadlane on Arendaja sarnane, aga akadeemilise taustaga. Viimasega võrreldes eelistab ta ülesande täielikku, täpset ja teoreetiliselt korrektset lahendamist. (Arendajale piisab, kui tal on otsene ja lihtne lahendus, mis  töötab 90% juhtudest.)

Visionäär

Tihti mõnes IT-ettevõttes analüütikuna või sarnases rollis alustanud inimene, kellel ei tarvitse olla IT-haridust. Töötas end läbi ettevõttehierarhia üles või siis asutas ettevõtte ise, mingi konkreetse idee elluviimiseks.

Visionäär hindab töötajates loomingulisust ning kasutajate probleemide mõistmist.

Tema ettevõtte eesmärgiks on võimalikult suur kasutajate arv.

Müügimees

Müügimees asutas oma IT-ettevõtte ise, „sest sellega saab head raha teenida“ või siis võeti ta Arendaja/Teadlase poolt kampa, kui nood ei suutnud oma ideid piisavalt hästi turustada.

Töötajates hindab Müügimees entusiasmi. Eeldab, et kõik tehnilised probleemid on lahendatavad.

Ettevõtte eesmärgiks on käive.

Raamatupidaja

Raamatupidaja on tüüpiliselt mõne ärikooli kasvandik ja tegeles ettevõttes rahaasjadega. Omapäi üldjuhul ettevõtet ei asuta (kui mitte just eelnevate tüüpidega koos), aga saab juhtpositsioonile, kui omanikele (kes võivad aja jooksul vahetuda nagu juhidki) tundub, et organisatsioon toimib liiga kaootiliselt.

Raamatupidaja hindab töötajates täpsust, usaldusväärsust ja etteennustatavust.

Eesmärgiks on puhaskasum.

Juhtide dünaamika

Ülaltoodu on mõistagi lihtsustus, eksisteerib ka igasuguseid hübriidvariante, aga stereotüübid aitavad olukorrast ülevaadet saada.

Muuseas, kui nt Arendaja eesmärk on võimalikult hea süsteem, ei tähenda see, et ta ei tahaks palju raha teenida. Lihtsalt tema visioon selleni jõudmiseks on läbi vägeva tehnilise lahenduse. Juhtub ka, et näiteks Visionääri ideede elluviimine kestab aastaid, mille jooksul ettevõte vaevalt hingitseb, kuid kui see lõpuks valmib, möödub firma raketina nt Raamatupidajate juhitud konkurentidest, kes vahepeal püsivat, kuid mõõdukat kasumit teenisid. (Loomulikult juhtub ka seda, et visioonist ei tule midagi välja ja rakett ei lahkugi stardiplatvormilt).

Alati kehtivad aga järgmised seaduspärasused:

• Printsiip 1: Omanik määrab, kes on juhid.

Uued idufirmad asutatakse kõige sagedamini Arendajate poolt. Kuni asutaja=omanik=juht, on asi lihtne. Kui aga omanike ring laieneb, tõstatub kohe ka küsimus, milline juhtimisstiil oleks parem. Kõige dramaatilisemad muutused toimuvad siis, kui:

• • a. Ettevõttesse kaasatakse väliseid investoreid.
  • b. Ettevõte saab nii edukaks, et läheb börsile.

Investoritele ja börsianalüütikutele meeldivad regulaarsed rahanumbrid enamasti rohkem kui tehnilised visioonid ja see tekitab tugeva surve Müügimeestest või Raamatupidajatest juhtide kaasamiseks. Kui esialgne juht on erakordne isiksus, ei hakata paati kõigutama, kuid enamik inimesi pole siiski erakordsed.

• Printsiip 2: Juht määrab, kes on ettevõttes kunnid.

Kui firmat juhib Arendaja, on ka tema värbamispõhimõtetes esikohal kõige kõvemate programmeerijate kaasamine ning neile kuulub visioonide ning plaanide tegemisel võtmeroll. Näide: Bill Gatesi Microsoftis olid arendajad alati kõige olulisemad. Paljud neist olid ettevõttes väga tähtsatel positsioonidel ning teenisid suurel hulgal raha.

Kui ettevõtet juhib Visionäär, on samadel põhjustel võtmeisikuteks analüütikud ja disainerid ning arendajad tantsivad nende pilli järgi.

Müügimehe ettevõttes on tehnikud enamasti ilma erilise struktuurita ühises katlas, sest selles organisatsioonis ei eristata neid tehnilise võimekuse järgi kuigi oluliselt.

Kui ettevõtet juhib Raamatupidaja, on tal suur Exceli tabel, kus iga töötaja taha on kirjutatud talle vastav puhaskasuminumber. Kellel on suurem number, see on ka olulisem.

Isegi kui me ise ei kuulu ei omanike ega juhtide sekka, on vastav dünaamika meile oluline. Omanike ringi muutus toob kaasa muutused juhtkonnas, see aga omakorda tõstab esile ühtesid gruppe ning paiskab teisi tagaplaanile. Nagu esimeses osas kirjeldatud, on juhi roll tarkvara alal määravam kui enamikus teistes tööstusharudes. Sellest tulenevalt võib vahetus tuua üksikisikule kaasa drastilisi karjääri ning töökeskkonna muudatusi. Hinnatud spetsialistist võib üleöö saada tähelepandamatu pärisori ja Tuhkatriinust printsess.

(See artikkel on esimene osa pikemast teemakäsitlusest, stay tuned)

Mõned nädalad tagasi astus Apple ühte oma viimase aja suuremasse ämbrisse, lastes välja mitmesuguste probleemidega kaardirakenduse. Apple’i kaartidest on juba küllalt jahutud ja küllap need probleemid leiavad lahenduse. Huvitavam küsimus on aga, kas selline asi oleks saanud juhtuda, kui Steve Jobs veel elus oleks? Jobsi surmast möödus just aasta, paras aeg selleks, et suurettevõtte süsteemne inerts veidi raugeda jõuaks ning esimesed jamad uksest välja ulatuks. Kui oluline on tegelikult üksikisik? Kas on olemas asendamatuid inimesi?

Asendamatuse sündroom tekitab paljudele muresid. Juht muretseb, et kellegi lahkumise või ajutise eemaloleku ajal elu seisma ei jääks. Kliendid muretsevad, et nende tarnesüsteem mõne olulise isiku puudumise pärast ei katkeks. See on ka peamisi põhjuseid, miks osade tellimuste puhul eelistatakse suurettevõtteid, kuigi väiksem teeks ehk kiiremini ja odavamalt. Eeldatakse, et suure tarnija puhul on inimesed lihtsamalt asendatavad. Ka sellel asendamatul inimesel endal viskab lõpuks üle, kui talle rohkem kui korra on puhkuse ajal helistatud.

Asendamatuse vältimiseks tehakse mitmesuguseid asju: soodustatakse kommunikatsiooni, luuakse mitmesugust dokumentatsiooni, standardiseeritakse töökorraldust, roteeritakse  inimesi töötama erinevate lõikude kallal jne. Sel viisil saab spetsialistide puhul tihti ka võimekust dubleerida ning asendamatust vältida, kui tegu pole just superstaariga (nendest tuleb juttu kolmandas osas).

Samas võib see viia ekstreemsuseni. Paljude jaoks on ideaalne vabrikutaoline töökorraldus: iga töötaja on asendatav osa suurest masinast, kõigile peab saama kiiresti leida samaväärse isiku kas sisemiste ressursside või välise värbamise abil. Paljud juhid armastavad rääkida (klientide rahustamiseks?), et “meil pole mitte keegi asendamatu”. Ma ise leian, et vabrikumudelit taga ajades viskame me lapse koos pesuveega välja, kuid mõte on sellest hoolimata populaarne.

Juhtide puhul tuleb mängu teine sündroom. Nimelt ei mõjuta nad ettevõtet mitte niivõrd sellega, mida nad teevad, kui sellega, millised nad on. Tippjuhi järgi joondub kas teadlikult või ebateadlikult ülejäänud juhtkond, nende järgi keskastme ülemused jne. Kui näiteks ettevõtte juht armastab naisalluvatele külge lüüa, hakkavad seda tegema ka teised. Kui ta hiilib seadustest kõrvale, ei pea ka alluvad reeglite järgimist väga oluliseks. Kui ta on aga vastupidiselt üdini printsipiaalne ning ajab igas küsimuses ausust taga, muutub ka ülejäänud ettevõte sirgjoonelisemaks.

Peale otsese jäljendamise koguvad juhid enda ümber enamasti ka sarnase mõttemaailmaga inimesi. Perfektsionistid armastavad teisi perfektsioniste, uljaspead teisi uljaspäid ning tehnoloogiafriigid teisi friike.

Asendame nüüd sellise juhi mõne teisega (eriti sellisega, kes ei pärine esialgse juhi otsesest meeskonnast). Ta võib käia täpselt samadel kohtumistel, juhatada samu koosolekuid ja teha üleüldse täpselt sama tööd, kuid sellegipoolest ei pruugi me mõne aasta möödudes enam organisatsiooni äragi tunda. Paljud, kellele teine stiil ei sobi, on lahkunud, ning ülejäänud on joondunud uue inimese järgi.

Teine oluline faktor on juhi unikaalsed oskused. Mida suurem, silmapaistvam ja edukam on firma, seda tõenäolisemalt on selle juhil mingi eriline talent. Bill Gates oli väga tugev teiste inimeste andekuse ja taiplikkuse äratundmises ning nende oma tiimi värbamises. Kõik on kuulnud Steve Jobsi võimest panna inimesi reaalsust teisel viisil nägema. Warren Buffett suudab firmade kasvupotentsiaali hinnata paremini kui keegi teine. Need eripärad ei ole asendatavad. Kui selline inimene organisatsioonist eemaldada, kaotab ettevõte ka vastava erilise võimekuse, isegi kui asendaja püüaks muidu igas asjas eelkäijat emuleerida.

Tarkvaratööstus on muudega võrreldes palju kiiremas muutumises. Kui tellisetehast juhtida samal viisil nagu vanaisadki, ei juhtu suurt midagi. Aga tarkvaraettevõttes tuleb palju sagedamini võtta vastu kriitilise tähtsusega otsuseid, vastavalt muutuvale situatsioonile. See tähendab, et juhtide ja nende eriliste isikuomaduste roll on ka vastavalt suurem.

Sama kehtib ka Eestis – kõik tarkvarafirmad, mida ma tean, on tugevalt mõjutatud oma juhtide isikuomadustest. Mida edukam ja säravam firma, seda tõenäolisemalt saab selle eesotsast leida ka vastavate omadustega juhi ning vastupidi.

Edit: Mõte on eelkõige selles, et kuigi tehniliselt nagu asendamatuid inimesi ei oleks ja üldjuhul keegi rolli täiteks leitakse, pole ettevõte pärast enam seesama. See võib olla parem, halvem või lihtsalt teistsugune, aga pole mõtet loota, et midagi ei muutu. Vahel võtavad muutused kaua aega. Bill Gatesi aeglane eemaldumine Microsofti tegevjuhtimisest toimus kokku päris mitme aasta vältel ja läks veel aastaid, kuni efekt täielikult alla välja jõudis, aga see juhtus siiski.

Mida selle teadmisega peale hakata ning milliseid juhte olemas on, sellest järgmises osas.

Pirate Bay teatas hiljuti, et laiendab oma “tootevalikut” ka 3D printerite mudelifailidele.

Kas just sellega seoses, aga mõni päev tagasi küsis Digitunnist (kõnealune saade arhiivis siin) tuntud Henrik Roonemaa minult, kas ma avaldaks saates oma arvamust, mis juhtuks siis, kui meil oleks võimalik paljundada/jagada näiteks kingi, telefone või autosid sama lihtsalt kui praegu muusikat ja filme. Kas maailm saaks otsa? Kas keegi tahaks veel midagi luua või välja mõelda? Kas kõik inimesed jääksid tööta?

Raadios saab vahel sõna vaid kümneks sekundiks, aga siin kirjutan nii palju, kui tahan (NB! See siin on praegu kõik ainult hüpoteetiline konstruktsioon/mõtteharjutus, kes teab, millal see võimalikuks saab. Aga küll ta kunagi saab).

Esiteks peame astuma sammu tagasi ja mõtlema, miks inimesed üldse midagi teevad? Organisatsioonipsühholoogia ja töönõustamise õpetamisel räägitakse muuhulgas, et töötaja motivatsioon kuulub üldjuhul ühte neljast kategooriast:

1. Soov teenida raha. Selle puhul läheb inimesele eelkõige korda see, et õigel kuupäeval oma papp kätte saada, mida rohkem, seda parem.
2. Soov meisterlikkuse järele, teha oma tööd võimalikult hästi, näidata, kes on parim.
3. Soov muuta maailma, et sinu tööst oleks ühiskondlikult “kasu”.
4. Soov liikuda mööda hierarhiat, saada “suureks ülemuseks”, nii et ümbritsevad sulle alt üle vaataksid.

Igal inimesel on mingi kombinatsioon nendest motivaatoritest ja see muutub kindlasti elu jooksul. Ma arvan, et ma ise olen praegu umbes 10-30-50-10. Natuke rohkem raha ei muudaks mu elus suurt midagi, ülemus olemist on ka piisavalt proovitud, tööoskuste osas tuleb millalgi isikliku suutlikkuse lagi vastu, aga maailmaparandamise tung pole veel ära kadunud. Seega, kui kusagil on vaja midagi ära teha, olen ma 5x suurema tõenäosusega kambas, kui sellel on ühiskondlik mõju, võrreldes näiteks rahalise preemiaga.

Olulisem on aga see, et enamik kõvemaid tarkvarategijad, keda ma tean, on motiveeritud 2.liigist, paljud ka 3.liigist (huvitaval kombel makstakse neile enamasti siiski rohkem raha kui neile, kes valivad eriala raha pärast). Sama teema on näiteks muusikute või kunstnikega, ma pole veel kordagi näinud kedagi, kes ütleks, et hakkas pillimängu õppima, sest tahtis palju raha teenida. Üldiselt on loovate inimeste puhul tegu ikka sellega, et neile meeldib midagi teha ja nad püüavad sellega võimalikult hästi hakkama saada. Teiseks on enamik neist muidugi edevad, pole vist palju muusikuid, kes tahaks esineda kümnele inimesele, kui saaks ka kümnele tuhandele.

Kuigi ma ise teenisin oma elu parimat raha Redmondis töötades, on mul praegu hoopis suurem heameel sellest, et mul õnnestus osaleda tarkvara loomisel, mida on kasutanud miljonid inimesed.

Tohutu hulk väga andekaid programmeerijaid töötab vaba tarkvara kallal, tehes seda suurema pühendumuse ja hoolikusega kui oma palgatööd, lihtsalt sellepärast, et neile meeldib tarkvara teha, teistelt selle eest respekti saada ja maailmale ehk tugevam jälg jätta, kui neil selleks igapäevatöös võimalust oleks.

Kui ma katsun ausalt vastata küsimusele, kas mulle läheb korda, kas keegi kasutab kusagil minu osalusel tehtud tarkvara ilma loata või ei, siis väga ei lähe, kuna valdava enamiku tuludest võtab endale  niikuinii keegi teine. Aeg on sisse tuua vahendajad ja müüjad. Ma olen kindel, et enamik neist on väga toredad inimesed, kellega koos kõrtsis käia jne. Samas kahtlen, kas keegi saab tunda litsentsitingimuste koostamisest või tarkvarakarpide müügist sama suurt rõõmu kui arendaja hästi koostatud algoritmist.  Seega on nende motivatsioon tõenäoliselt pigem 1 või 4 liigist. Loogilise järeldusena on nemad ka inimesed, kes kõige rohkem ebaseadusliku paljundamise üle kurdavad (kuigi on kindlaks tehtud, et need kahjud pole üldse märkimisväärsed).

Kui nüüd näiteks Nike’i jalatseid saaks lihtsalt paljundada, mis siis juhtuks? Paneme tähele, et nende “loojad” töötavad viletsates tingimustes paari dollari eest päevas, endal vaevalt hinge sees hoides. Kas ehk nende jalatsimoodide väljamõtlemine maksab palju? Selgub, et ei! Jalatsite jaehinnast näevad kõik, kes selle loomisel tegelikult osalevad, ainult mõnda protsenti, ülejäänud läheb mitmesugustele vahendajatele, kellele selline korraldus ilmselt ei meeldiks.

Seega, kui vahendajad jäävad miinuspoolele, siis jalatsite (ja igasuguste muude kaupade) hind langeks samas muinasjutuliselt. Ka needsamad Indoneesia õmblejad, kes praegu ei saa endale elus lubada ainsatki paari omaenda toodangut, saaksid korralikud jalatsid ja riided. Iga India küla saaks endale paljundada vajalikud osad veepuhastusagregaatide kokkupanekuks. Iga lühinägelik Aafrika laps, kes ei saa seetõttu praegu koolis käia, saaks endale prillid. Kõige tähtsam on aga, et arengumaad saaks oma põllumajandust paremate seadmete abil efektiivsemaks muuta, nad suudaks oma rahvast paremini toita, tekiks rohkem ülejääke, ning endised jalatsitegijad saaks edaspidi töötada teenindussektoris, töötades edaspidi 100 tunni asemel nädalas näiteks 40 tundi, kuni Läänele järele jõuab.

Ja praegune Lääne inimene, kes igasuguse kola kokkuajamise nimel praegu rügab nagu orav rattas, saaks aru, et see kraam polegi nii oluline, kuna seda jätkub niikuinii kõigile, töötaks 10 või 20 tundi nädalas (tõenäoliselt samuti teeninduses, programmeerija, massööri või ujumistreeneri töö niipea veel ära ei kao), kulutades ülejäänud aja millegi mõnusama peale.

Oluline on see, et mingit massilist tööpuudust ei teki, täpselt nagu seda ei tekkinud põllumajandusliku revolutsiooni järel (ühe hektari põllu harimiseks kulub praegu palju vähem inimaega kui vanasti), rasketööstuse revolutsiooni järel (ka tonni terase valmistamiseks kulub palju vähem inimaega) või infotehnoloogilise revolutsiooni järel (ka firma raamatupidamine võtab vähem aega kui enne Excelit).

Ja mis saaks väljamõtlejatest? Nagu nägime, maailma majandus välja ei sure, kuna vähemalt teenindussektor jääb mingil kujul alati alles. Seega jääb alati ka midagi, mida reklaamida. Ja nagu praegu on hulgaliselt tarkvaraarendajaid või kasvõi veebikoomiksikirjutajaid, kes elavad reklaamimüügist, saavad seda tulevikus teha ka tootedisainerid. Mõtlevad välja näiteks uue riidemoe, aga sinna sisse kujundavad kellegi reklaami, kes selle eest on maksnud. Kes tahab tasuta riideid, peab leppima reklaamiga, samas väikese tasu eest autorile võib selle eemaldada.

Samuti on alati turgu igasugusele eksklusiivselt eritellimusel loodavale kaubale. Kui kõik asjad on odavad, leidub alati neid, kes maksavad natuke raha lihtsalt selle eest, et oma erinevust demonstreerida, nii et fundamentaalselt pole katki midagi.

Kokkuvõttes: jään unistama jagatud maailmast.

Pildil on ACTA vastased protestijad Stockholmis, Rootsis, riigis, mille kohta Ansip ütles, et kui juba rootslaste meelest asi korras on, pole meil ka vaja muretseda. (Pilt ise on pärit Rootsi Piraadipartei juhilt Rick Falkvinge‘lt, kes mõistetavatel põhjustel ei pahanda, et ma seda siin kasutan).

ACTA üle on paljud inimesed sel nädalal end muidugi juba siniseks vaielnud, aga sellegipoolest sattusin täna seltskonda, kus pidin selgitama, miks selle pärast mures ollakse, koondan seega oma vastavad mõtted ka siia. Vabandan ette suure hulga teksti pärast, aga küsimus on paraku oluline.

Lihtsaim lähenemine on muidugi selline, et “varastamine on halb”, meil on nüüd leping, mis võimaldab seda piirata, kõik on suurepärane, hurraa. Vaatame nüüd aga järgmist hüpoteetilist näidet: Mis oleks, kui selsamal ettekäändel, et “varastamine on halb” sunniksime kõiki tööandjaid oma töötajaid tööle tulles ja sealt lahkudes kohustuslikus korras läbi otsima, et leida, ega neil mingit varastatud kraami kaasas ei ole? Paar varastatud asja leitaks kindla peale üles, aga keegi ilmselt ei kahtle, et majanduslik raiskamine ning inimeste isikuvabaduste rikkumine selle kasu tuhandekordselt üles kaaluvad.

Ma ei ütle, et ACTA tingimata samasugused tagajärjed kaasa tooks, seda (ega ka vastupidist) pole keegi veel suutnud minu jaoks piisavalt veenvalt põhjendada. Samas piisab sellest näitest illustreerimaks, miks lihtsa “varastamine on halb” lahmimisega ei saa ehku peale suvalisi otsuseid vastu võtta. Kahjuks näitavad isegi tavapäraselt mõistlikud ajalehed üles väga primitiivset suhtumist, ei viitsi küsimuste olemusse süüvida ning korrutavad puhta kullana esimest ettejuhtuvat infot.

Minu isiklik ACTA lugu algas veebis mitmesuguste materjalidega tutvumisega, mis tundusid mulle veenvamate ja sisukamatena kui ACTA-t pooldavad materjalid (huvitaval kombel pole ma eriti näinud, et keegi muudele materjalidele peale selle memo viitaks). Isikuvabaduste teema on mulle tähtis, minu vanemad olid taasiseseisvumisliikumise ajal aktivistid ja mäletan ise lapsena Balti ketis seismist. Nad ei riskinud repressioonidega mitte selleks, et me oma kättevõidetud õigustel nüüd lihtsalt hooletusest, selgrootusest või pahatahtlikkusest kaduma laseks minna.

Sellepärast kirjutasin kolmapäeval järgmise kirja, saajaks Rait Maruste, koopia Riigikogu Reformierakonna fraktsiooni liikmetele.

Lp. hr. Maruste!

Kirjutan Teile kui oma rahvaesindajale, kelle poolt viimastel Riigikogu valimistel hääletasin. Hääletasin eelkõige seetõttu, et olen kõrgelt hinnanud Teie panust Eesti kui õigusriigi kujunemisse ning arengusse, nii et Eestist on saanud kodaniku- ja isikuvabadusi austav riik.

Samuti on Reformierakonna poliitika olnud läbi aegade minu vaadetega enim kooskõlas, austades inimeste majanduslikku ning isiklikku vabadust, see viimane on kesksel kohal minu väärtushinnangutes.

Nüüd aga ähvardab kõik selle üles kaaluda Eesti toetus ACTA lepingule, mida toetab ennekõike just Reformierakond. Kuna ACTA piirab minu hinnangul oluliselt ettevõtete ja inimeste põhilisi vabadusi, tekitab sündmuste areng minus suurt muret.

Palun seetõttu Teil kui ausal ja väärikal inimesel väljendada avalikult oma selget seisukohta ACTA osas. Kui Reformierakond oma toetust siiski jätkab, ei pea ma edaspidi enam võimalikuks Teid toetada.

Juhin tähelepanu, et Reformierakond saavutas suure edu just viimatistel e-valimistel, s.t selle osa seas rahvast, kes on noorem, haritum ja aktiivsem internetikasutaja. Praegu on tuhanded inimesed just nimelt sellest grupist tulemas tänavatele, et protestida Reformierakonna vedamisel sõlmitava lepingu vastu. ACTA toetamine saeb seega eelkõige just seda oksa, millel Te ise kõik istute.

Parimate soovidega,

Targo Tennisberg

Sellele kirjale sain mitu huvitavat vastust, alates mõnest, kes ütles, et jagab seisukohti ja ACTAt ei toeta, kuni mõneni, kes arvas, et ACTA on täiesti normaalne värk.

Samas tooniandvaim oli seisukoht, et ei tea, pole veel päriselt jõudnud tutvuda, misasi see selline on. Ühesõnaga, tunda andis mõningane peataolek ja imestus, et mis nüüd ometi lahti on. Palju viidati Justiitsministeeriumi memole, milles omakorda on tõlgitud Euroopa Komisjoni seisukoht, et kõik on korras. Tekib muidugi küsimus, et kui kõigil piisab mingile välisele arvamusele viitamisest ja ise pole vaja sugugi mõelda, milleks meile neid ametnikke siis üldse vaja on?

Põnevaim vastus oli aga Tõnis Kõivu oma, kes viitas oma blogikandele teemal “varastada ei tohi“. Refereerin puhkenud diskussiooni põhjalikumalt, sest minu meelest on siin tegu ACTA debati musternäidisega, mis iseloomustab väga hästi ka mitmeid teisi praegu käimasolevaid sarnaseid väitlusi.

Esialgset sissekannet ei hakka siin sõna-sõnalt tsiteerima, mine tea, mis seadused meil aasta pärast on, aga muuhulgas kirjutab Tõnis Kõiv, et:

• inimesed on ära hirmutatud ja paanikas,
• ACTA kohta levitatakse valelikke müüte,
• kedagi kunagi kohtuväliselt taga kiusama ei hakata,
• ACTA on mõeldud ainult laiaulatuslike kommertseesmärgil rikkumiste tõkestamiseks.

Kirjutis leidis laialdast vastukaja, saades ilmselt rohkem kommentaare, kui kõik Tõnis Kõivu senised postitused kokku Ühes neist kommentaaridest tõi hr Kõiv ise näitena Eesti Ekspressi artikli, kus räägitakse Lotte filmi allalaadimisest, ning lubas kõhklemata selliste nähtuste vastu seista. Kuna neil, kes oma lastele Lotte filmi tõmbavad, pole kindlasti laiaulatuslikke kommertseesmärke, tekkis mul küsimus:

Vaat siin Lotte filmi näites peidab ennast üks kurikaval vastuolu.
Esialgses blogikandes mainite, et “VVL-i reguleerimisalaks on laiaulatuslikud ja organiseeritud intellektuaalomandi rikkumised, kus kaupu võltsitakse müügi -ehk kommertseesmärgil”.
Aga siin tuleb järsku sisse Lotte filmi näide? Ehk siis tegelikult on ikkagi kavas hoopis “pisikestel piraatidel”, kes oma lapsele Lotte filmi tõmbavad, sest poest ostetud plaat on ära kribitud, käsi väänama hakata?

Praegusel hetkel on küsimus veel lahtine.

Mingil hetkel kirjutas Elmar Osa:

ACTA ise on küll avalik, aga oluline osa tema mustanditest ja läbirääkimiste dokumendidest on salastatud…. Viini Konventsioon näeb ette, et kui mõni rahvusvahelise lepingu punkt on ebaselge, siis tuleb seda tõlgendada varasemate mustandite ning läbirääkimis dokumentide põhjal.. kas ei ole see vastuolus põhiseaduse mõttega, kui seaadus ise on avalik aga selle loomise ja arutelude dokumendid salastatud.

Sellele vastas Tõnis Kõiv (vt täielikku vastust):

Kahjuks on tõesti suur osa Euroopast tunduvalt suurema salastatusega harjunud kui meie siin Eestis.
Seetõttu leiab vajalikud dokumendid meie Välisministeeriumi kodulehelt:http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2011:0380:FIN:ET:PDF

Siin jääb mulle segaseks, kas hr Kõiv vastas Elmari küsimusele meelega mööda või kogemata, palusin seetõttu ise täpsustust:

Viidatud link ei sisalda läbirääkimisprotokolle, mille salastatusele Elmar Osa tähelepanu juhtis. Ma olen veendunud, et valdav enamik Riigikogu ja valitsuse liikmetest pole neid samuti näinud.
Samas on rahvusvahelises õiguses riikidevahelised lepingud üldjuhul ülimuslikud kohalike seaduste ees, sõltumata sellest, kas leping on salajane või mitte. Seega on nende salajaste materjalide täitmine ikka kohustuslik, isegi kui me neid kunagi näinud pole.

Sellele küsimusele pole ma samuti veel sisulist vastust saanud.

Minu põhikommentaar oli aga järgmine:

Esiteks, diskussiooni pööramine rajale, kas “varastada tohib või ei tohi”, on demagoogiline ja näitab üleolevat suhtumist vastaspoolesse. Sama hästi võiksime teemale panna pealkirjaks “kas inimesi tohib või ei tohi kohtuta karistada”, mis rõhub vastsapoole emotsioonidele.
Minu jaoks on probleemi keskmes hoopis küsimused:
1. Isikuvabaduste potentsiaalne piiramine
2. Äriliste takistuste tegemine paljudele ettevõtetele
3. Võimu andmine riigi ja rahva käest suurkorporatsioonidele
Vähemalt esimese kahe punkti osas olen seni pidanud Reformierakonda pigem õiguste ja vabaduste kaitsjaks kui vastaseks, seisukoht, mis ühtib minu enda põhiväärtustega. Praegu kardan aga, et pean pettuma ja oma senise toetuse ümber vaatama.

Teiseks, Teie kommentaarid rõhuvad suuresti teesile, et “niikuinii midagi ei juhtu ja keegi kedagi kiusama ei hakka”. Samasuguseid väiteid esitati ka mitmete teiste sarnaste seaduste ja lepingute puhul, näiteks USAs DMCA seaduse osas. Ka seal väideti, et “midagi hullu ei juhtu”, aga reaalselt kujunes välja situatsioon, kus paljusid inimesi ja ettevõtteid ahistatakse ebaõiglaste autorikaitseteadetega. Näiteks võib saata veebimajutuse pakkujale kirja, kus väidetakse, et nende majutatav veebisait sisaldab autoriõigusi rikkuvaid materjale. Seepeale veebimajutaja tihti sulgebki kiiremas korras lihtsalt terve vastava saidi, tegelikesse asjaoludesse süüvimata, sest juriidiilne võitlus oleks liialt ressursikulukas ning potentsiaalsed karistused absurdselt kõrged. Tegelikult võib aga tegu olla hoopis kaebaja pihta tehtud kriitika vaigistamisega.
Vt näiteid:
http://arstechnica.com/tech-policy/news/2007/03/victims-fight-back-against-dmca-abuse.ars
https://www.eff.org/deeplinks/2007/07/mom-sues-universal-music-dmca-abuse
http://www.techdirt.com/articles/20091103/1839446788.shtml
Siit on näha, kuidas inimeste süüdi mõistmine on läinud riigi ja kohtute käest erafirmadele, ning üksikisik lihtsalt ei saa neile vastu.

Kolmandaks, väites, et VVL/ACTA reguleerib ainult “müügi- ja kommertseemärkidel” sooritatavaid rikkumisi, ei saa kindel olla. Heaks näiteks on siin jälle USA kohtupraktika, kus algselt suures mastaabis piraatkaupade tootjate vastu mõeldud seadusi on hakatud kasutama hoopis tavaliste inimeste vastu, vt:
http://www.wired.com/threatlevel/2007/10/riaa-jury-finds/
Samuti on autoriõigusi hoidvad ettevõtted (mitte autorid!) kaevanud inimeste peale, kellel pole isegi mitte arvutit, surnud inimeste peale jne.
Samuti poleks midagi uut selles, et mingi tagamõttega vastuvõetud seadusi haktakse (kuri)tarvitama hoopis teistel eesmärkidel, vt nthttp://en.wikipedia.org/wiki/Controversial_invocations_of_the_USA_PATRIOT_Act

Neljandaks, ACTA võimalikud hüved ja ohud ei ole kuidagi tasakaalus. Internetis failivahetamise vastu võitlemine on küllaltki lootusetu projekt, sest vastumeetmed on tehnoloogiliselt alati sammu võrra maas. seetõttu on ka parimal juhul saavutatav kasu väga väike, suurendades autorõiguste omanike (mitte tingimata autorite!) tulusid ehk paari protsendi võrra. Kui nüüd peaks juhtuma, et kasvõi mõnesid inimesi seetõttu ebaõiglaselt ruineeritakse, teisi ahistatakse või nende järel nuhitakse, siis oleme maksnud tulemuse eest mitu suurusjärku kõrgemat hinda kui vaja.

Minu keskne tees on paralleel DMCA-ga. Kolisin üsna varsti pärast selle vastuvõtmist USA-sse ja mäletan sealsete poliitikute sõnavõtte, kes küll seemneid ei soovitanud süüa, aga väitsid ikkagi, et kõik on korras ja midagi hullu ei juhtu. Nagu ülaltoodud linkidelt näha, juhtus ikka küll.

Tõnis Kõiv andis aga sellise vastuse (vt täielikku kommentaari):

Vaatasin läbi teie postitatud lingid, mis puudutasid USA-s aastatel 2007-2009 toimunut. Ma arvan, et te mõistate ise ka, et Ameerikas plaanitavad SOPA ja PIPA (mis ei ole veel vastu võetud) ei saa mitte kuidagi olla aastaid tagasi toimunud kohtulahendite aluseks. USA õigussüsteemist hoiatavaid näiteid võtta ei ole eriti viljakas tegevus, sest Eestis on hoopis teine õigussüsteem. Kui USA-s on common law süsteem siis Eestis kontinentaal-euroopa õigussüsteem.

Kuna minu meelest oli taas tegemist mööda vastamisega, täpsustasin:

1. Ma pole SOPA/PIPA kohta sõnagi öelnud. Ma rääkisin peamiselt DMCA-st, mis võeti vastu sarnaseid eesmärke silmas pidades. DMCA sündis enne, kui internetiaktivism oma praeguse ulatuse saavutas, seetõttu ei protestitud selle vastu ka nii, nagu praegu SOPA või ACTA vastu, ning tagajärjeks on kirjeldatud kuritarvitused.
2. Õigussüsteemide erinevus pole siinkohal absoluutselt oluline. Common law tähendab seda, et juhtumite üle otsustatakse eelnevate kohtupretsendtide alusel. Aga kirjeldatud juhtumid ei ole sellised mitte eelnevate pretsedentide pärast, vaid sellepärast, et seaduses on niiviisi kirjas. Kui kontinentaaleuroopas võetakse vastu sarnane seadus, on ka tulemused täpselt samad.
Ja see, et korporatsioonid saavad inimesi ahistada ja neilt välja pressida, läheb kohtu- ning õigussüteemist üldse mööda.

Ja sain vastuse:

MInu arvates on õigussüsteemide erinevus oluline ja automaatselt olukordi ja lahendusi USA-st üle kanda ei saa. Siin jääme selgelt eriarvamusele.

Selle peale ei oskagi midagi kosta.

Sama threadi teises harus, Tõnis Kõiv:

Kahjuks ei saa ma ilma näiteid toomata teie hirmudest aru. Mida te siis oma veebilehel hoida tahate, millele teistel inimestel õigused on?! Miks te siis õiguste omanikuga kokku ei lepi? Miks te ei saa kolmest hoiatusest aru?!

Selle peale mina:

Kellel selles diskussioonis õigus on, kas mõni osalejatest on üles näidanud naiivsust, pahatahtlikkust, pealiskaudsust, demagoogitsemist, võhiklikkust, hoolimatust või välist mõjutatust, jäägu lugeja otsustada.

Aeg näitab, mis sellest kõigest saab, täna aga soovitan kõigil osaleda protestiaktsioonides, sinna ka tegelikult kohale minnes, mitte ainult Facebookis nuppe vajutades! Muuseas, sealsamas Stockholmis, millele esialgne pilt viitab, on end protestile kirja pannud peaaegu 12 000 inimest.

Poliitikutelt, kes ACTA-t pooldavad (eriti kui olete mõne sellise poolt hääletanud), soovitan aga küsida:

• Mis on konkreetsed negatiivsed mõjud, kui Eesti ACTA-t heaks ei kiida?
• Kas olete nõus vastutama, kui mõnda eestlast ikkagi hakatakse ACTA tõttu ebaõiglaselt taga kiusama?
• Kas olete nõus vastutama, kui Eesti ettevõtted siiski hakkavad ACTA pärast majanduslikku kahju kandma?
• Kas olete nõus vastutama, kui Eesti tehnoloogiline positsioon maailmas ACTA pärast kannatada peaks saama?

Kui kõik on hästi, pole neil ju kaotada midagi.

Lisaks peaksid nad sisuliselt vastama järgmistel linkidel mainitud murekohtadele:

http://kogukond.org/2012/02/mis-on-actaga-katki-vaike-hunnik-viiteid/
http://action.ffii.org/acta/Analysis
http://en.wikipedia.org/wiki/Anti-Counterfeiting_Trade_Agreement#Criticism
http://www.sirp.ee/index.php?option=com_content&view=article&id=13977%3Akas-interneti-lopp-ja-acta-algus&catid=9%3Asotsiaalia&Itemid=13&issue=3379
http://falkvinge.net/2012/01/31/why-acta-is-so-mercilessly-pursued/
http://falkvinge.net/2012/02/03/european-commission-slip-reveals-censorship-in-acta/

Mingisugustele välistele materjalidele viitamine ei ole vastuvõetav, inimene peaks vastama oma sõnadega, demonstreerides küsija probleemist tegelikku arusaamist. Meie rahvaesindajad peaksid olema piisavalt pädevad, et endale asjad korralikult selgeks teha, selle põhjal otsus vastu võtta ning suuta seda sirge seljaga kaitsta.

Tehke talle ka konkreetselt selgeks, et mõistliku vastuse andmata jätmise korral jäetakse tema nimi hoolega meelde ning edaspidi tema poolt ei hääletata.

Olen aastate jooksul osalenud paljudes vestlustes, mille peateemaks on “ma tahaksin rohkem raha saada”, vahel küsija, vahel lubaja/keelduja rollis. Seeläbi on nüüdseks tekkinud teatav mõistmise tase ja rääkisin eelmisel kuul ka Pinu kokkutulekul sel teemal. Soovitused on kõik iseenesest triviaalsed, aga vajavad siiski vahel üle kordamist. Nüüd panen materjalid ka siia.

Jutu läbiv mõte põhineb kahel eeldusel.

Esiteks, et meie eesmärgiks on raha teenimine. Kui meile on elus olulised muud asjad (käia iga päev matkamas, saada palju lapsi, jõuda nirvaanasse vms), siis selle jaoks on teised vahendid, aga praegune jutt on rahast.

Teiseks, et me oleme tehnikud. Parim võimalus rikkaks saamiseks on muidugi ise äri teha, aga see nõuab üldjuhul progemisest loobumist, mida paljud ei raatsi.

Raha ja majandus

Alguses peame mõistma, mis on üldse raha ja miks ta eksisteerib. Raha definitsioon on:

• Vahetusvahend
• Akumulatsioonivahend
• Arveldusühik ehk väärtuse mõõt

See viimane on meile praegu kõige olulisem: raha ei maksta meile mitte selle eest, et me oleme ilusad ja toredad, vaid selle eest, et me loome midagi, mis on väärtuslik. Triviaalne, aga millegipärast tekitab selle mõistmine paljudele inimestele probleeme. Rääkisin kord ühe kunstiinimesega, kes oli väga solvunud, kui ma tema töö väärtuslikkuses kahelda julgesin. Aga samas, kui sinu piltide eest ikka ei maksta, siis järelikult ei hinda inimesed neid piisavalt ja nende väärtus on lihtsalt madal. See on majandusteaduslik definitsioon ja narr on selle üle vaielda.

Järgmiseks tuleb meil mõista peamisi majanduse seaduspärasusi, eelkõige nõudmise ja pakkumise tasakaalu.

Tihti diskuteeritakse, mis peaks olema mingi töö “õiglane hind”. See on tegelikult nonsenss, iga töö on väärt parajasti nii palju, kui palju selle eest ollakse nõus maksma ja kui palju eest seda ollakse nõus tegema. Kui neid, kes konkreetse asjaga hakkama saaks, on vähem kui tellijaid, läheb hind üles ja vastupidi. Reeglid kehtivad nii ettevõtete ja klientide vahel kui ka tööandjate ja töötajate vahel. Vastavalt sellele on meil ka võimalik positsioneerida ennast selliselt, et meie tehtava töö eest makstav tasu oleks maksimaalne.

Siit ka soovitus nr 1:

• Kui vähegi võimalik, siis tee läbi mingi mikroökonoomika kursus, paljud asjad elus saavad seeläbi oluliselt selgemaks.

Teenusearendus vs tootearendus

Enamik Eesti tarkvaraettevõtteid (ja seetõttu ka enamik Eesti programmeerijaid) tegelevad teenusearendusega. See tähendab, et konkreetses projektis on konkreetne klient, kes ostab ettevõttelt teatud hulga tagumiktunde ja maksab nende eest. Teine variant oleks tootearendus, kus klient ei maksa mitte tundide, vaid mingi juba varem valmistehtud asja eest litsentsitasu.

Tüüpilise Eesti IT konsultatsiooniäri teoreetiline finantsmudel on lihtsustatult järgmine:

Teoorias tundub, et tegemist peaks olema küllaltki tulusa tegevusega.

Päriselus on efektiivsus aga tüüpiliselt madalam, mõned projektid lähevad üldse aia taha ja nende kulu tuleb muude projektide tuludest katta jne. Seetõttu ongi enamiku eesti IT-ettevõtete kasumimarginaal ühekohaline, kui seda üldse on. Samuti on meil inimesi kord liiga palju, kord liiga vähe, mis jällegi suurendab kulutusi. Ehk siis tegemist on igavese peost suhu elamisega. Tegelik suur IT-raha on ikkagi tiražeerimises.

Olles näinud, kuidas ettevõtted raha teenivad, mainin järgmiseks mõnesid “antisoovitusi” ehk asju, mis ei aita, aga mida inimesed ikkagi kogu aeg teevad.

• Mul on vaja rohkem raha, et [lapsi saada, koolis käia, uude majja kolida]
  • Tööandja vastus: me oleme äriettevõte, mitte heategevusasutus

Inimesed, kellel on kombeks raadiosse helistada ja kiruda, kuidas valitsus ja ettevõtjad on nõmedad, teevad mu selle peale ilmselt maatasa, aga majandusseadused on täpselt samasugused nagu teisedki loodusseadused ja nende üle tigetsemine on sama efektiivne kui halva ilma kirumine.

• Ma käisin koolitusel ja tahan nüüd palka juurde
  • Tööandja vastus: kas see koolitus aitab meil klientidelt rohkem raha saada?

Kõik, mida me teeme, tuleb tõlkida konkreetseks väärtuseks, mida meie töö aitab luua.

• Mul on hiilgav idee
  • Tööandja vastus: ideid on mul endalgi küll, vaja on teostust

Vahel tuleb inimene ja ütleb, et vaat, mul on sihuke idee! Ja jääb siis ootama, et kus on miljonid, mida talle idee teostamiseks antakse. Tegelikult pole teostamata idee midagi väärt.

Programmeerija kasutegurid

Tüüpilises IT projektis võime näha kliendi äripoole esindajat, kliendi projektijuhti, ärianalüütikut, süsteemianalüütikut, arhitekti, programmeerijat ja lõpuks arvutit, mis tegelikku ülesannet hakkab täitma.

Selle ahela alguses eksisteerib vaid küllaltki udune idee sellest, mis toimub ja kuidas “asjas võiksid olla”, ahela lõpus aga peavad meil olema väga täpsed, mustvalged instruktsioonid, et nüüd tee seda ja siis toda. Kõik need vahepealsed inimesed tegelevad lihtsalt uduste ideede tõlkimisega järkjärgult formaalsemasse vormi.

Samas on siin vahel suured infokaod ja ebaefektiivsus, igal sammul läheb midagi kaduma, tekib juurde või moondub. Ideaalses maailmas oleks siin vahel seega vaid üks inimene, kes mõistaks nii äri kui ka arvutit, aga seda juhtub harva.

Selge on siiski, et:

• eksisteerib spekter erineva formaalsustasemega info esitamise viisidest,
• me loome väärtust uduse info formalismideks tõlkimise kaudu,
• spektri erinevaid osi katavad tüüpiliselt erinevad inimesed.

Seega, mida laiema osa spektrist me suudame haarata, seda suurem on ka meie väärtus ja võimalus raha teenida.

Nimetan seda Tõlkimise Atomaarseks Ulatuseks ja tähistan kreeka tähega τ (tau).

Mul endal on küllaltki kõrge τ ja eelkõige tänu sellele olen suutnud ka erinevates situatsioonides oma tegevuse eest piisavalt head tasu küsida.

Teine soovitus on seega:

• Väärtus kasvab koos võimega mõista kliendi mõtlemisviisi. Suhtumine, et “mina olen progeja, andke mulle konkreetsed ülesanded kätte, mida ma teen, ja muu mind ei huvita”, on kindlaim viis oma palgale lae seadmiseks.

Järgmiseks tuleme tagasi küsimuse juurde teenusearendusest ja tootearendusest. IT omapära on teatavasti, et kord juba valmis tehtud asja kopeerimine on üliodav. Seepärast on rahateenimise võti taaskasutus.

Efektiivne taaskasutus nõuab spetsialistidelt aga oluliselt kõrgemat kvalifikatsiooni, seda nii analüüsi, programmeerimise, aga eelkõige testimise osas. Kui me lihtsalt võtame ühe kliendi projektist mingi koodi, kohandame seda teisele kliendile ja kolmandale, on tulemuseks tüüpiliselt jalgade ja tiibadega madu, kes saab endale peagi südamerikke. Korralik taaskasutus nõuab vastavat planeerimist algusest peale ning oluliselt suuremat panustamist süsteemi arhitektuuri ning töökindlusse, sest meil pole võimalik käia iga üksiku kliendi juures asju mcgyveri teibiga putitamas nagu tavaliste ühekliendiprojektide puhul ikka juhtub.

Üldine idee on aga selles, et kasutajad toovad ettevõttele raha sisse, programmeerijad viivad välja.

Seetõttu tuleb kasvatada suhet Kasutajate Arv jagatud Programmeerijate Arvuga, mida ma tähistan kreeka tähega ϰ (kapa).

Ajal, mil ma Microsoftis progejana töötasin, oli mul muidugi väga kõrge ϰ, mis võimaldas MSil mulle ka rohkem palka maksta, kui konsultatsioonifirmadel.

Aga kolmas soovitus on:

• Tõsta oma kvalifikatsioon tootearenduseks vajalikule tasemele ning mine tööle tootearendusprojekti/firmasse või püüa leida võimalus oma praeguse töö tulemite tiražeerimiseks.

Nüüd veel ideedest. Nagu eelnevalt mainitud, tähtis pole mitte idee, vaid teostus, edu jaoks on vaja 1% annet ja 99% tööd. Seetõttu on edukad eelkõige inimesed, keda iseloomustab Maniakaalne Üleolekuvajadus ja Ühele asjale keskendumine. Tähistan seda kreeka tähega μ (müü). Ma ei tea ühtki tehnoloogiavallas rikkaks saanud inimest, kes poleks mingil perioodil teinud 80-100 tunniseid töönädalaid, tegelenud tehnoloogiaga ka tööväliselt ning tundnud kinnisideed enda loodud lahenduste võimalikult laialdasest levitamisest.

Minu isiklik μ on arvestatavalt üle keskmise, aga mitte võrreldav vastavate tippudega. Neljas soovitus on aga:

• Suhtuda oma töösse kirega ning võtta omaette eesmärgiks, et sinu lahendus oleks alati parem kui teiste oma.

Kõik pole küll enda teha. Või siiski?

Tüüpiline viis, kuidas programmeerija rikkaks saab, on vanemarendajana raketiks muutuvas firmas, kus töötajatele on aktsiaoptsioone jagatud (ja mida suurem τ ja μ, seda rohkem optsioone). Muidugi on vaja valida selline ettevõte, millel on  (vähemalt potentsiaalselt) suur ϰ ning juhiks keegi, kellel on tohutu μ. Kanooniliseks näiteks on siin Charles Simonyi, kes oli kunagi MS Office’i peaarendaja, aga kes nüüd saab lubada endale eraisikuna kosmoses käimist.

Seega on vaja olla Õigel ajal Õiges kohas. Tähistan seda eesti tähega õ (õõ).

Näiteks töötasin Microsoftis samas toas ühe selliga, kellel juhtus olema erakordselt halb ülemus. Nii halb, et ta läks lõpuks MSist ära. Google’isse. Aastal 2001. Mina olin konservatiivne ja mõtlesin, et ei tea, kas sellest internetiotsingu ärist ikka õiget asja saab. Kuna alates sellest ajast läksid ettevõtete aktsiahinna kõverad radikaalselt lahku, on temal praeguseks muidugi palju rohkem raha kui mul. See, et tema viletsa ülemusega tiimi sattus, aga mitte mina, oli ilmselt puhas juhus, nii et tundub et siin pole suurt midagi võimalik ette võtta.

Siiski, kui me ühe korra täringuid viskame, siis Yahtzee saamise tõenäosus on küllaltki väike. Mida rohkem aga viskame, seda suuremaks kasvavad šansid.

Sellest ka viies soovitus:

• Kui oled paar aastat mingis ettevõttes olnud ja see pole raketina lendu tõusnud, otsi järgmine töökoht.

Sest kui seda siiani pole juhtunud, pole ka tulevikus plahvatusliku kasvu tõenäosus kuigi suur.

Lõppkokkuvõttes saame aga järgmise lihtsa valemi:

€ = τ * ϰ * μ * õ

Valem on lihtne, täitmine aga oluliselt raskem.

PS Kommertsteadaanne

Töötame praegu dokumendihaldustoote kallal, millel on potentsiaalselt hea ϰ. Võtame kampa analüütikuid, programmeerijaid (.NET baasil) ja testijaid, kellel oleks silmapaistev mõistus ja taiplikkus, kõrge τ ja piisav μ. Asukohana on eelistatud Tartu. Kel on huvi, võib vastava sooviavalduse ja CV saata kas otse mulle või kairi.pauskar /at/ webmedia /punkt/ ee.