Archive for the 'Raha' Category

Nov 30 2015

Minu viis kuud Bondoras

Published by Targo under Hea kood, Isiklik, Raha, Töökuulutused

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

3 responses so far

Oct 27 2015

Milleks õppida midagi peale IT?

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.

3 responses so far

Aug 06 2015

Tarkvara riknemine

Published by Targo under Hea kood, Raha

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.

5 responses so far

Jan 22 2013

Kuidas tellida tarkvaraprojekti

Published by Targo under Projektijuhtimine, Raha

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.

  1. Mis on Päikese pinna temperatuur?
  2. Mis on Šanghai laiuskraad?
  3. Mis on Aasia pindala?
  4. Mis aastal sündis Aleksander Suur?
  5. Kui palju on ringluses eurosid (sularaha)?
  6. Mis on Peipsi järve ruumala?
  7. Kui palju teenis film Titanic kinodes?
  8. Mis on Vaikse Ookeani rannajoone pikkus?
  9. Kui palju raamatuid on USA ajaloo jooksul välja antud?
  10. Kui palju kaalub raskeim sinivaal?

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.

  • Lepinguks on Tellija tüüpleping, mis ei kuulu arutluse alla!
  • Tellijal on õigused, Täitjal kohustused.
  • Tähtajad on kivisse raiutud ning nende ületamisega kaasnevad märkimisväärsed sanktsioonid Täitja suunas.

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

Esialgse ettekande väline kommentaar: enne seda seminari olin vahel imestanud, kust sellised hanked ometi tulevad? Üritusel hakkasin asjale pihta saama – paljudes asutustes on tööl spetsiaalne hankespetsialist, kes hangibki ühel nädalal ekskavaatoreid, teisel tarkvara, kolmandal põrandakütet jne. Selline spetsialist tunneb hästi riigihangete seadust ja oskab nt õiges vormis maksuvõlgnevuste puudumise tõendeid küsida, kuid asjade reaalsest sisust ta enamasti ei tea ja projekti elluviimisega kokku ei puutu. Siit tuleb ka hangete hinnapõhisus – hindu on palju lihtsam võrrelda kui pakkujate sisulist võimekust.
Minu jaoks kõige nutusem asjaolu oli aga mõnede kohalviibinute suhtumine – et mis sellest siis on, kui hange on ähmaselt sõnastatud? Las pakkujad lähevad riigihangete vaidlustuskomisjoni ja räägivad seal, kui mingi probleem on! Avaliku sektori töötaja käest sellist repliiki kuulda oli kahekordselt valus – esiteks on kahju oma maksuraha pärast, millega kõigi osalevate ametnike vaidlemiseks kuluv aeg kinni makstakse, teiseks aga on kummastav see mõistmatus. Erafirmale läheb riigihanke vaidlustamine juba õigusabikuludena maksma tuhandeid eurosid, rääkimata spetsialistide ajast, kes selle asemel millegi kasulikuga võiksid tegeleda. Nii tõstab see teenuse turuhinda ja lõppkokkuvõttes jällegi maksumaksja kulusid.
Mõistagi püüab ka täitja oma juriidilist tagumikku kaitsta. Tavaliselt koostatakse selleks mitmesuguseid lepingulisasid, kus on kirjas ka tellija kohustused, näiteks kohustus ise täpseteks tähtaegadeks teatud sisendid anda jne. Ehk toimub võidurelvastumine, mille käigus kumbki pool katsub endale võimalikult palju laskemoona varuda.

Aga egas midagi, hakkame tööga pihta!

Projekti käigus selgub, et:
  • 10 lk-ses dokumendis kirja pandu oli enam-vähem korrektne.
  • Küll aga on palju detaile, millele keegi hanget ega pakkumust kokku pannes ei tulnud.
  • Pole hullu! Hind on ju lukus ja õnneks mahub lause „Maja hind peab sisaldama kõike eluks vajalikku, s.h. siseviimistlust ning kogu vajalikku mööblit, kommunikatsioone jmt.“ taha palju, isegi väga palju!

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:

K: “Mitut sürrealisti on vaja, et lambipirni vahetada?”
V: “Kaelkirjak.”

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:

  1. Tellija saab selle, mida ta tegelikult tahab – pool tööst ei lähe enam raisku!
  2. Arendus on efektiivsem – pidevatele plaanimuutustele läheb vähem auru -> suurem kasu nii tellijale kui täitjale
  3. Ebaõnnestumisel pole vaja kogu projektist loobuda – suur eelis klassikalise waterfalli ees!
  4. Dramaatiliselt kõrgem kvaliteet – enam pole vaja nui neljaks konkreetseks tähtajaks midagi tarnida.
  5. Ning last but not least, vähem inimestevahelisi konflikte – projektijuhid ei pea enam pärast projekti lõppu otsejoones Anonüümsetesse Alkohoolikutesse suunduma.

12 responses so far

Oct 11 2012

Tarkvarafirmade olemus 2: juhtide tüübid

Published by Targo under Juhtimine, Põhialused, Raha

Eelmises osas postuleerisin, et firmas sõltub palju juhi konkreetsetest omadustest. Need tarkvaraorganisatsioonide juhid, kellega ma ise olen kokku puutunud, saab laias laastus jagada järgmistesse kategooriatesse:

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.

6 responses so far

Oct 07 2012

Tarkvarafirmade olemus 1: üksikisiku roll

Published by Targo under Juhtimine, Põhialused, Raha

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

One response so far

Feb 13 2012

Jagatud maailm

Published by Targo under Raha, Tehnoloogia

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.

22 responses so far

Feb 11 2012

ACTA – kas eesmärk pühendab abinõu?

Published by Targo under Raha

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:

Kui aru ei saa, siis tuleks teemasse süüvida ja katsuda erinevate ekspertide poolt esitatud vastuargumentidest sisuliselt aru saada. Kui meie Riigikogu võtab seadusi vastu nii pealiskaudselt ja probleemi sisu mõistmata, tekitab see minus suurt muret. Soovitan lugeda eelkõige DMCA-d puudutavaid materjale näiteks Electronic Frontier Foundationi kodulehel.

Aga teeme selle konkreetse näite siis puust ja punaseks.

Meil on veebisait, kuhu kolmandad isikud saavad sisu lisada. Tänapäeval kasutavad kõik populaarsemad saidid seda mudelit, alates vikipeediast kuni rate.ee-ni (ka http://www.toniskoiv.ee või http://www.targotennisberg.com). Saiti haldab isik A, ostes majutusteenust firmalt B.

Isik C lisab sinna mingit sisu.

Nüüd tuleb organisatsioon D, kes saadab firmale B kirja, kus väidab, et mingi sisu rikub nende autoriõigust ja nõuab selle kohest mahavõtmist ähvardusega, et muidu tuleb maksta neile miljon eurot. Kuna firmal B pole ressursse ei juriidiliseks võitluseks ega sisuliseks kontrolliks, siis ta kas eemaldab koheselt isiku C postitatud info või sulgeb kogu saidi. DMCA-d kasutades on aset leidnud mõlemat laadi juhtumeid, olenemata sellest, kas organisatsioonil D oli tegelikult õigus või ei. A-l ja C-l on siinkohal aga täiesti minimaalsed võimalused oma õiguste kaitsmiseks.

Analoogse situatsiooni võib konstrueerida nt avalike wifi-punktidega – kui ACTAt täies mahus täita, poleks meil varsti enam ainsatki vaba leviala.

Firmadele nagu B on siin kaks varianti:
1) oma teenuste valikut oluliselt piirata
2) hakata nuhkima oma kasutajate järel, mida nood täpselt teevad
Mõlemad variandid tekitavad firmale B lisakulu, mis on majandusele summaarselt sadu kordi suuremaks koormaks kui täiendav autorikaitsetulu, rääkimata tehnoloogilise progressi tugevast pidurdamisest.

Ja TK vastus (vt täielikku):

Alati on olemas variant, et konkreetse pretensiooni peale võetakse maha konkreetne materjal. Olen lugenud lausa kolmest teatest, millele tuleb enne reageerimata jätta. Mina pean oma blogi juba aastaid ning vastutan igati kõige eest, mis siin leida on. Kommentaaride modereerimine võtab aega, aga see on minu valik. Vabatahtlik valik.
Minu meelest minu eelnevad näited demonstreerisid just, et siin soovitatud käitumine ei ole realistlik. Tundub, et rohkem progressi selle aruteluga pole võimalik saavutada.

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.

18 responses so far

May 01 2011

Kuidas teenida programmeerijana rohkem raha

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.

5 responses so far

Feb 26 2011

Ideede väärtuse(tuse)st

Published by Targo under Innovatsioon, Isiklik, Raha

Ajendatuna ilmselt hiljuti populaarsust kogunud filmist Sotsiaalvõrgustik, küsis üks sõber mult, miks mina Facebooki ei leiutanud. Olin muidugi kõrvust tõstetud sellise kaudse hinnangu üle oma võimekusele, aga pidasin siiski vajalikuks õiglus jalule seada ja talle põhjendada, miks minust kunagi Mark Zuckerbergi vmt internetimiljardäri ei saa.

On väga levinud eksiarvamus, et millegi leiutamine ja rikkaks saamine seisab eelkõige briljantse idee taga. Tuleks vaid õige mõte ja kõik läheb nagu lepase reega. Tegelikult kehtib muidugi Edisoni ütlus, et geenius on 1% inspiratsiooni ja 99% perspiratsiooni. Facebook kasvas välja tavapärasest üliõpilaste isikuandmete andmebaasist, milletaolisi oli maailmas kümneid tuhandeid. Zuckerbergil oli muidugi kõvasti õnne, aga eelkõige oli tal maniakaalset eesmärgipärasust, töövõimet ning soovi olla esimene. Ilma nende omadusteta poleks temast keegi kunagi kuulnud ja need omadused on olemas eranditult kõigil edukatel ideerealiseerijatel Thomas Edisonist Bill Gatesini (või minu poolest Taavi Kotkani). Ärimaailma ideedel põhinev osa on halastamatult võistluslik, aga seda mitte sellepärast, et headest ideedest puudus oleks, vaid sellepärast, et müriaad leidureid püüab oma ideid teiste omadest kõrgemale upitada.

Lõppkokkuvõttes on suhteliselt vähetähtis, kes mingi idee peale algselt tuli. iPhone, mida vahel pea innovatsiooni etaloniks peetakse, sisaldas tehnoloogiliselt vaid inkrementaalseid uuendusi, kõik põhikomponendid olid juba ammu enne seda olemas. Oluline oli aga teistest parem teostus disaini  ja käepärasuse vallas. Samamoodi osutub Winklevosside ja Patersonide hädakisa selle üle, et nende ideid on ebaõiglaselt ära kasutatud, küllaltki narriks – idee kui sellise väärtus on müüt, tähtis on teostus.

Ja kui keegi kurdab (ning neid kurtjaid olen ma kohanud palju-palju), et oh, oleks vaid hea idee, teeniks sellega palju raha, siis pole nende tegelikuks sooviks mitte ägeda idee realiseerimine, vaid igatsus taevast sülle langeva lotovõidu järele. Muidugi eksisteerib ka akrobaaditrikke nagu Million Dollar Homepage või Punane kirjaklamber, aga neid esineb suhteliselt harva ja tõeliselt rikkaks keegi nendega ei saa.

Esialgse küsimuse juurde tagasi tulles: selles, et mul Facebook “leiutamata” jäi, polnud süüdi mitte ideedepuudus. Ideid on mul nagu putru, võin soovijatele jagada kui vaja. Tegelik põhjus on mõistagi selles, et ma olen selle ala suurmeistritega võrreldes kaugelt liiga laisk ja mugav, et end vastaval määral millegi realiseerimisele pühendada. Ja sama probleem on ka neil kurtjatel :)

4 responses so far

Next »