Archive for the 'Programmeerijad' Category

Oct 31 2012

Tarkvarafirmade olemus 3: arendaja – kas kuningas või pärisori?

Kui eelmises osas oli juttu juhtidest, siis seekord arendajatest. Arendajatest sellepärast, et ilma nendeta ei saa tarkvaraprojekti teha. On tarkvara, mida tehakse ilma analüüsita, on projekte, mida ei testita, aga kuidagi saab seal midagi siiski tehtud. Samas ilma programmeerimiseta pole tarkvara valmimine mingil viisil võimalik, sellepärast on arendajate roll ka eriline.

Arendajate spekter

Kui ma juhid jagasin meelevaldselt viide kategooriasse (millest mõistagi on ka segavariante), siis arendajad panen teljele, kus ühes otsas on arendaja-kuningas (edaspidi lühidalt kunn :) ) ja teises otsas arendaja-pärisori.

Ka siin on muidugi palju vahepealseid võimalusi, kuid ülevaatlikkuse huvides on lihtsam keskenduda äärmustele. Samuti pole rollid staatilised – kui palju ma ka ise ei püüaks kunn olla, saab vahel vaimujõud otsa ja siis on lihtsam olla ori.

Inimese asukohta sellel teljel ei määra mitte niivõrd võimekus ja oskused kui isiklik ambitsioon, suhtumine ümbritsevasse ning teiste inimeste suhted temaga.

Kunnil on oma nägemus või ambitsioon, mida ta soovib ellu viia, ning ta annab sellest enamasti ka häälekalt märku ja astub samme nende teostamiseks. See nägemus võib olla arendusmetoodika, arhitektuuri, ärisuuna, kliendisuhtluse, juhtimise või ka millegi muu teemaline, kuid ulatub enamasti kaugemale kui „kirjuta-selline-ja-selline-kood“ tüüpi ülesannete täitmine. Kui ümbritsevad töötajad aktsepteerivad kunni selles rollis, küsitakse neis asjades ka tema arvamust või tõuseb ta organisatsioonis lihtsalt tähtsamale kohale.

Arendaja-pärisori soovib oma asjad tehtud saada, õigel ajal koju minna ja korrapäraselt palka vastu võtta. Muu teda eriti ei huvita, ta ei soovi mingil juhul sekkuda rahalugemisse, klientide ohjamisse või teiste kolleegide juhtimisse. Kui teised töötajad suhtuvad arendajasse kui pärisorja, on ka nende interaktsioon temaga lihtne: ülesanded sisse ja kood välja. Nagu kodumasin.

Kasutan „pärisorja“ mõistet sihilikult. Paljud tarkvara loovate üksuste juhid on seisukohal, et arendajad on lihtsa vaevaga asendatavad. Kui üks läheb ära, pole probleem, võtame teise ja anname talle samad ülesanded. Kui kusagile on jõudu juurde vaja, võime võtta teisest tiimist teised arendajad ning lihtsa liitmistehte tulemusena saame suurema tulemuse. Ehk siis ilmne analoogia keskaegsete pärisorjadega, keda võis meelevaldselt ümber paigutada, osta, müüa ning vahetada.

Oluline: ma ei anna kellelegi mingit moraalset hinnangut! Tegemist on lihtsalt tähelepanekutega.

Rollitäitja areng

Kehtib printsiip, et igaüks valib oma rolli ise. Kui inimene ise käitub kuningana ja tal on selle taga vähegi mingit sisu, siis enamasti hakkavad ka teised teda nii võtma. Kui ta käitub nagu tagasihoidlik pärisori, siis suhtuvad ka teised temasse nõnda.

Järgmiseks tuleb mängu faktor, et kuna kunn räägib kaasa „tähtsamate“ asjade juures, hakkab see kajastuma ka tema motivatsiooniskeemis ning tema tasu tõuseb enamasti teistest arendajatest kõrgemaks. See omakorda tähendab, et tal on vähem muret igapäevase toimetuleku osas, mis annab juurde julgust veel kõvemat häält teha jne – positiivse tagasisidega tsükkel (pärisorja puhul võib kehtida vastupidine tsükkel).

Ja kuigi „ori“ ei kõla väga hästi, on pärisorjaks hakkamine paljudele teadlik otsus. Olen näiteks vestelnud mitmete inimestega, kes kurdavad, et nende juht ei anna neile küllaldaselt ülesandeid, neil pole siis tööl piisavalt tegevust ja kolleegid ei respekteeri neid seetõttu piisavalt. Mina küsin seepeale, miks nad ise endale täiendavat rakendust ei otsi, tarkvaraprojektis on igasuguseid tegevusi ju lõputult, millega tulemust parandada. Tulemuseks on olnud täielik teineteisemõistmatus: „Mismõttes mina peaksin ise midagi tegema hakkama? Ülemuse asi on ju mulle öelda, mida teha! Võimalikult täpselt, detailselt ja igat asja eraldi!“

Juhtimisviisi erinevus

Suurim probleem ilmneb eri tüüpi arendajate juhtimisel. Kui pärisorjast arendaja puhul saab juht tegeleda peamiselt ülesannete kättejagamise ning nende täitmise kontrollimisega, siis kunni puhul niiviisi ei saa. Kunn teab enamasti ise ka, mida on vaja teha, ning juhi roll seisneb pigem tema eesmärkide toetamises ja nõustamises. Juhi-alluva suhe on seega täiesti erinev, samuti on erinev see, kuidas alluvad oma juhisse suhtuvad. Sümptomaatiline märk on muuseas, kas kasutatakse pigem sõna „juht“ või „ülemus“.

Mul on olnud isiklik kogemus tiimi juhtimisega, mis koosnes täielikult kunnidest. Peamine mure polnud seal mitte selles, kuidas inimesi tööle panna, vaid kuidas modereerida alatasa puhkevaid kirglikke vaidlusi. Igaühel olid oma grandioossed ideed, mida ta kibeles ellu viima. Loominguliselt lähenedes õnnestus aga igaühele leida väljund, millega ta tegeleda sai.

Vestlesin igal nädalal igaühega spetsiaalselt eraldatud pooltunni jooksul, aga rõhu asetasin eelkõige inimestele nõu andmisele ning soovituste edastamisele nende kaastöötajatelt. Konkreetsete tööülesannetega said nad ka ise hästi hakkama. Kunne huvitavad nende karjääriküsimused küllaltki palju ning seetõttu on nad ka entusiastlikud igasuguste „tee seda ja seda, et suuremat mõju saavutada“ soovituste osas. Kokkuvõttes olime väga edukad ning sain tagasisidevormide kaudu ka tiimilt väga kõrge hinnangu osaliseks.

Mõni aeg hiljem sattusin organisatsiooni, kus inimeste sisemine motivatsioon polnud samal tasemel ning kohe tekkisid ka tõrked. Kasvõi idee, et juht võiks iga alluvaga kord nädalas pikemalt vestelda, tekitas umbusku. Mismõttes? Kas ta tahab mind spetsiaalselt kontrollida või?? Appi!!! Samuti leidsin, et kupja roll pole minu jaoks – järelvalve, kas igaüks märgib ikka korrektselt oma töötunde jms kraami, jätaksin hea meelega kellelegi teisele.

Või siis vastupidine näide, kus pidin vahendama ühe projektijuhi ja kunnist arendaja suhtlemist. Tellija oli kirja pannud soovid, mille PJ arendajale edastas. Viimane aga leidis, et teine lahendus on parem, ning tegi mõned asjad veidi teisiti. Tekkis PJ ja arendaja vaheline vaidlus, mis päädis e-mailiga „LIHTSALT TEE NII, NAGU MA ÜTLEN!!“, mis loomulikult ei andnud tulemusi. Kuulasin ise asjaosalised ära, taipasin, miks arendaja teistmoodi tahtis teha, ning leidsin kompromissi. Kuna see projektijuht oli aga harjunud, et arendajad peavad lihtsalt sõna kuulama ja mitte vastu rääkima, polnud tal nendega arvestamise kogemust ja tekkis konflikt.

Seega võib sama juht ühes olukorras väga edukalt hakkama saada ja teises kohas läbi kukkuda.

Ühelt teisele ümberlülitumine pole lihtne, seetõttu võtavad juhid oma alluvate suhtes enamasti mingi ühtse hoiaku, suhtudes vaikimisi nendesse kõikidesse kui kunnidesse või kui pärisorjadesse. Enamasti on see suhtumine ka lihtsalt eristatav. Kas juht nimetab näiteks oma alluvaid „ressurssideks“? See on märk, et nood on tema jaoks pärisorjad.

Juhte, kes mõlema variandiga suurepäraselt hakkama saaks, on vähe ja seetõttu koonduvad arendajad ka organisatsioonidesse, kus nendesse vastavalt suhtutakse. Kunnid lähevad parema meelega sinna, kus ka teised arendajad on kunnid, ja orjad sinna, kus ka teised on orjad. Tulemusena ei jagune kahte lehte mitte ainult üksikud arendajad, vaid ka tiimid, üksused ja firmad.

Milleks meile kunnid?

Eelnev näide illustreerib, et kunnidega on üldiselt keerulisem: nad vaidlevad asjadele vastu, püüavad alatasa mingeid oma värke teha jne. Milleks nendega siis üldse jamada?

Peamine põhjus seisneb selles, et erinevate arendajate produktiivsus võib kolossaalselt erineda. Kui algatusvõimelisele (kunn on definitsiooni kohaselt asjade algataja), taiplikule ja tugevalt motiveeritud arendajale vaim peale tuleb, võib ta kõrge loomingulisuse perioodil luua kümneid kordi rohkem väärtust kui keskpärane arendaja. See tulem on tihti selline, mida poleks olnud võimalik tavalisse ülesandekirjeldusse panna, tegu on kristalliseerunud inspiratsiooniga. Iga ülieduka firma või tooteliini tagant leiame mõne kunni, kes oma kõrghetkel on loonud parimad osad vastavast tarkvarast. Ja kuna bitid on kergesti paljundatavad, saavutab parem tarkvara tihti ebaproportsionaalselt suure turuosa, mis tähendab, et kunni panus tuleb ettevõttele tagasi mitmesajakordselt.

Markantseim näide on siin Charles Simonyi, mees, kes oli Microsoft Office’i loomise taga. Ilmselgelt polnud Microsoftil kahju talle loodu eest sadu miljoneid maksta.

Või teine näide: paljud on kuulnud lugu, kuidas arendaja Mark Lucovsky teatas Steve Ballmerile, et lahkub Microsoftist. SteveB olla võtnud selle peale tooli ja toa teise serva virutanud. Kui arendajad oleksid tõepoolest teineteisega asendatavad nagu mutrid, milleks siis ärrituda? Tegelikult oli aga tegu ühe märgiga Microsofti domineerimise lõpust.

Arendajad ja ettevõtte areng

Huvitavaks läheb asi siis, kui vaadelda eri tüüpi arendajate kombinatsioone eelmises osas uuritud juhitüüpidega.

Arendajast juht on definitsiooni kohaselt ka ise kunn ning mõistab seetõttu ka teisi kunne intuitiivselt. See, kas ta neid aktsepteerib ja nendega läbi saab, on muidugi ise küsimus.

Juhtide puhul, kellel endal sügavat IT-tausta pole, saab määravaks, kas nad mõistavad tarkvara loomise eripärast dünaamikat, eelkõige seda, et kui pärisorje saab tõesti osta-müüa-vahetada ja sundida neid kõike tegema, siis kunnidega hakkama saamine on keerulisem.

On näiteid, kus juhid seda mõistavad ning jätavad kunnidele tegutsemisruumi. Paljud kõige edukamatest ettevõtetest on sellised, mille eesotsas on näiteks Müügimees, aga tema selja taga kõvad arendajad, kes saavad asjade sisulise külje üle vabalt otsustada.

Teiselt poolt võime tuua olukorrad, kus näiteks Raamatupidaja tüüpi juht keerab kruvid väga kinni ning kehtestab hulgaliselt reegleid, kuidas elu peab käima. Mõnda aega annab see isegi tulemusi ning numbrid paranevad, aga kui kunnidele piirangud enam ei istu ja nad laevalt lahkuvad, algab sisuline allakäik, mida on raske ringi pöörata.

On ka palju organisatsioone, kus kõik arendajad on pärisorjad. Põhimõtteliselt pole neil midagi viga ja nad võivad teenida väga head raha. Samas pole nende toodetu kuigi põnev ja selle kvaliteet on pigem keskpärane.

Kokkuvõtteks on oluline kunnide ja pärisorjade dünaamika mõistmine ning selle rakendamine ettevõtte strateegia huvides. Kas me tahame, et meie ettevõte oleks võimalikult äge ja kuulus? Või on meile kõige tähtsam tasa ja targu raha teenida? Või mingi kombinatsioon nendest? Siit tulenevad ka eesmärgid, milliseks kujundada arendajaskonna koosseis.

5 responses so far

Oct 25 2011

Kuhu küll kõik poisid jäid…

Published by Targo under Programmeerijad

… mis on neist küll saanud?

Eelmises artiklis oli muuhulgas natuke juttu olümpiaadidest ja olümpiaadidel käimisest. Võtsin huvi pärast ette nimekirja Eesti võistkonnas rahvusvahelistelt informaatika olümpiaadidelt medaleid võitnud poistest (jah, tüdrukuid seal kahjuks pole, kuigi oleks väga tore, kui oleks). Vähemalt mingi kriteeriumi järgi on nad kõik millalgi olnud ühed Eesti potentsiaalikaimad progejad, uurisin siis moodsaid otsinguvahendeid kasutades, mis kellestki saanud on.

Tulemuseks oli:

  • 3 inimest Skype’is
  • 2 (varsti loodetavasti 3 :) ) Webmedias, peale selle mitmed, kes WMist erinevatel aegadel läbi käinud.
  • 1 Playtechis
  • 1 Logicas
  • 1 Filosoftis
  • 5 teevad ise mitmesuguseid väikefirmasid
  • 1 on riigiametis
  • 6 teevad Tartu Ülikoolis teadust (doktorandid või kõrgemad)
  • 3 käivad lihtsalt Tartu Ülikoolis
  • 1 käib keskkoolis (HTG-s)
  • TTÜ-ga ei osanud kedagi seostada…
  • 4 on vähemalt hetkel Eestist väljas, neist 2 akadeemiliselt. Kattub natuke ka teiste kategooriatega.
  • 2 tegelevad täiesti IT-väliste asjadega
  • 4 kohta pole viimastel aastatel mingit infot, radarilt kadunud…

Järeldusi võib igasuguseid teha :)

15 responses so far

Oct 18 2011

Itimees kui kunstnik

Published by Targo under Haridus, Programmeerijad

Käesoleva loo väikeste kärbetega variant ilmus mõni aeg tagasi Postimehes, siia panen esialgse pikema ja värvilisemate piltidega versiooni.

Eesti majanduse areng viimasel 20 aastal

Viimastel nädalatel on ajakirjanduses olnud palju juttu Eesti asukohtadest mitmesugustes edetabelites, sealhulgas konkurentsivõime, inimarengu ning majanduskasvu osas.

Kui üldiselt võib viimase 20 aasta arenguga väga rahul olla, siis viimastel aastatel oleme maailma üldises pingereas pigem paigal tammunud.

Allikas: Maailma Majandusfoorum

Allikas: ÜRO

Allikas: Rahvusvaheline Valuutafond. Tuleviku info on Valuutafondi prognoos.

Nagu selgub, siis läbi üheksakümnendate aastate ronisime ülespoole, kõrgemasse liigasse murdmiseks pole aga jaksu olnud. Nagu prognoosidest näha, kummitab meid oht jäädagi keskmikuks, kellel tõeliselt edukate ja rikaste sekka kunagi asja ei ole.

IT kui majanduse vedaja

Pärast taasiseseisvumist polnud edasiliikumiseks vaja teha midagi väga erilist: mitte ennast lõhki laenata, mitte lasta korruptsioonil üle pea kasvada ja muidu ka asjad lihtsalt enamvähem korras hoida. Naaberriigid, kellel asjad nii korras ei olnud, on meist nüüd mõnevõrra tagapool.

Meist eespool asuvad aga riigid, kelle asjad ongi juba korras ja nendega võistlemiseks on vaja palju suuremat osavust.

Tööstusrevolutsioonist 20.sajandi viimase kümnendini vedas majanduskasvu eelkõige tööstuse areng. Võitjad olid need, kes kaevandasid (või importisid) kõige rohkem maavarasid, ehitasid teistest enam tehaseid, autosid ja lennukeid. Kui aga saavutati teatav arengutase, enamikel inimestel kõht täis, katus pea kohal ja võimalik autoga sõita, hakkasid suuremat lisaväärtust andma hoopis võimalused kõiki neid asju nutikamaks muuta. 20. sajandi alguses oli maailma rikkaim inimene naftamees Rockefeller, aga 20. sajandi lõpus IT-mees Bill Gates.

Praegu on maailma viiest rikkaimast inimesest 3 ning kuuest suurima börsiväärtusega ettevõttest 4 seotud IT või telekomiga.

IT pole keskne mitte ainult „klassikalises“ arvutivärgis, vaid ilma selleta ei saa läbi ka üheski teises tänapäeva innovatiivses valdkonnas. Kasvõi geenitehnoloogias on paljude probleemide lahendamine ja selle kaudu hulgale haiguste ravi leidmine seotud hoopis suurte andmehulkade töötlusega. Ilma teadmiseta, kuidas vastavad algoritmid töötavad ning kuidas infot ühest vormist teise kantakse, ei saa olla efektiivne ei molekulaarbioloog, füüsikakatsete tegija ega autode disainija. Kõige kasulikum kombinatsioon on, kui inimene õpib alguses IT-d ja seejärel spetsialiseerub näiteks geneetikale või robotite ehitamisele.

Mis teeb IT majanduslikus mõttes eriliseks?

Esiteks tehakse IT-s mitte millestki midagi. Me ei kuluta mingeid loodusvarasid, mis võiks otsa lõppeda, või komponente, mille hinnakõikumine maailmaturul meid rööpast välja viiks. Ainsaks ressursiks on inimeste taiplikkus ja töövõime.

Teiseks annab IT kõige puhtamal kujul inimestele aega juurde, tehes ära paljud rutiinsed, aeganõudvad tegevused. Kui kunagi nõudis kasvõi ettevõtte finantsarvestus saalide kaupa tütarlapsi, kes tulpades arve liitsid, tehakse sama tegevus praegu ära Exceliga, ilma et keegi seda üldse tähelegi paneks. Vabanenud inimesed saavad ennast pühendada aga loomingulisematele, meeldivamatele ja kasulikumatele tegevustele – las masin töötab, tema on rauast.

Siit leiame ka IT-sektori kasvu võtme: Kui mõnele inimesele praegu tundub, et arvuteid on niigi kõik kohad täis, siis tegelikult on igasuguseid rutiinseid asju, mille tegemiseks arvuti paremini sobiks, veel kümme korda rohkem, rääkimata sellest, et praegused IT-lahendused saaks olla palju võimsamad ja mugavamad.

Seega kasvab IT roll järgmiste dekaadide jooksul veel tohutult ning kõigis ülaltoodud edetabelites annavad tooni need riigid, kus IT on kõige kõrgemalt arenenud.

Suurim probleem on tööjõupuudus

Hoolimata sellest, et IT-sektori palgad nii Eestis kui mujal maailmas ületavad vastavaid keskmisi palkasid tüüpiliselt 2-3 kordselt, valitseb seal sellegipoolest tohutu tööjõunälg. Kuigi me peame ennast e-riigiks, moodustab IT Eesti erasektori tööhõivest vaid 4%, OECD keskmine on natuke alla 6%,  Soomes üle 8% ja Rootsis üle 9%! Eesti IT-firmad ütlevad praegu, et neil on puudu 1000-2000 töötajat ja selle peale tehakse suuri silmi. Et aga kõrgliigasse murda, on meil kokkuvõttes vaja kümneid tuhandeid töötajaid!

Allikad: ITL, OECD

Praegugi on mõni Eesti firma ennast ja Eestit piisavalt üles kiitnud, et välismaine suurettevõte tulebki ja küsib, et noh, me tooks mõnede asjade arenduse Eestisse, vaja läheks umbes 200 programmeerijat. Kui arvestada juurde, et kõik need 200 inimest tarbiksid hoolega jällegi teiste inimeste loodud kaupu ja teenuseid, tõstaks selline ettevõtmine Eesti SKP-d hoobilt 50 miljoni euro ehk 0,3% võrra. Ainult et… Eestis tehakse valdavat enamikku asju ühekohalise arvu inimestega, 20 programmeerijaga projekt on juba hiiglaslik ja üle selle ulme.

Programmeerijate järelkasv

Mõnel ettevõtjal ja ka poliitikul on mõte, et oh, kui häda suureks läheb, toome välismaalt abijõudu sisse. Sellega oleme ammu hiljaks jäänud. Juba palju aastaid imeb USA nagu tööstusliku võimsusega tolmuimeja endale Hiina, India, Venemaa ja teiste maade ülikoolide koorekihti. Olles ise sellistel alustel pikalt USA-s töötanud, võin kinnitada, et süsteem töötab erakordselt efektiivselt. Meie oma kehva kliima, ksenofoobilise elanikkonna ja suurte riiklike bürokraatlike takistustega ei pääse eduka spetsialisti mõttemaailmas pildilegi.

Seega on ainus variant oma jõududega hakkama saada. Siin tekitab olukord aga pessimismi.

Kõigepealt tuleb tähele panna, et programmeerimine ei ole nagu raamatupidamine või müüriladumine, mille puhul piisab kutsekoolis käimisest ning seejärel kellast kellani töötamisest. Programmeerimine sarnaneb rohkem kunsti või muusikaga: mida varem inimene seda õpib ja mida rohkem sellega ka hobi korras tegeleb, seda edukam ta on. Keegi ei kujutaks endale ette näiteks kontsertpianisti, kes alles konservatooriumis esimest korda klaveri taha istub. Markantsete näidetena on ka paljud rahvusvaheliselt tuntud nimed juba varakult arvutiga tõsiselt tutvust teinud. Microsofti looja Bill Gates hakkas programmeerima põhikoolis , Google’i asutajad Sergei Brin ja Larry Page on mõlemad rääkinud, kuidas nende kodud olid varajases teismeeas arvutikraami täis ning neid julgustati masinatega mängima. Facebooki  rajaja Mark Zuckerberg kirjutas oma esimesed programmid 11-aastaselt, viimase ajal ühe populaarseima arvutimängu Minecraft autor Markus Persson kaheksaselt, ka Skype’i põhimeeste loometöö algas hiljemalt keskkoolis. Ja täpselt nagu ühe muusiku kontserdile tuleb sada korda rohkem inimesi kui teise omale, võib üks programmeerija olla kümme või sada korda produktiivsem kui teine, ning enamasti tuleb vahe sellest, kui vara asjaga alustati ning kui kirglikult sellega tegeletakse.

Eestis tegeleb tõsisemate ülikoolieelsete arvutiteadmiste andmisega kitsas seltskond fanaatikuid, ühelt poolt hakkajamad arvutiõpetajad, teiselt poolt Tartu Ülikooli juures tegutsev Teaduskool ning informaatikaolümpiaadide toimkond, kes korraldab mitmesuguseid programmeerimise ja IT-alaseid võistlusi. Keegi neist ei saa oma tegevuse eest suurt midagi, tegutsetakse pigem hobi korras. Peamiselt on kõik laste enda teha.

Samas, kui 2000 aasta paiku võttis kasvõi programmeerimisolümpiaadi eelvoorudest osa stabiilselt üle 100 õpilase, on see arv praeguseks langenud keskmiselt 60 kanti. Need on inimesed, kelle seast moodustub kunagi IT-inseneride ja teadlaste tuumik. Et eelmistes punktides toodud kava kohaselt edasi areneda, peaks osalejaid olema mitusada, praegune arv ei võimalda isegi taastootmist. Võrdluseks on Leedus programmeerimine olemas koolides õppeainena ning seal tuleb analoogsetele üritustele 800 õpilast! See tähendab, et 10 aasta pärast on nende potentsiaal IT vallas oluliselt kõrgem Eesti omast ja meil tõsine oht edetabelites veel langeda.

Milles asi? Kui tiiger esimest korda hüppas, olid arvutite võimalused palju väiksemad ning koolide esimesed arvutiõpetajad jagasid ka lastele eelkõige programmeerimisalaseid teadmisi – et selle arvutiga oleks võimalik rohkem peale hakata. Sajandivahetuseks oli aga juhtunud kaks asja: esiteks oli arvuti jõudnud masskasutusse, sellest oli saanud tarbeasi ning ka fookus nihkus nokitsemiselt praktilisele kasutamisele. Teiseks lahkusid paljudest koolidest need esimese laine õpetajad ning järgmine laine õpetas juba ainult MS Office’it, mitte programmeerimist.

Tagajärjeks on, et lapsed, kellel muidu oleks eeldusi ja huvi asjaga tegeleda, ei saa vastavat infot ega julgustamist, mis lubaks neil areneda tulevasteks maailmanimega firmade loojateks.

Mida peale hakata?

Olukord pole roosiline, kuid siiski on võimalik vankrile hoog jälle sisse lükata.

Üleskutse ettevõtjaile: Ühe töötaja leidmine, värbamine ja esialgne väljakoolitamine võib maksta tuhandeid eurosid. Selle raha eest saaks korraldada õpilastele võistlusi ja muid üritusi, mis 5-10 aastat hiljem tooks tagasi mitukümmend potentsiaalset töötajat. Eesti ettevõtted peaksid olema piisavalt küpsed ja stabiilsed, et sellises ajahorisondis mõelda. Ja kui tekib hirm, et me teiste firmade tulevased töötajad ka kinni maksame, siis võib ju alati rahad kokku panna.

Üleskutse õpetajatele: Ärge kartke õpilastele levitada Teaduskooli kursuste või programmeerimisvõistluste infot. Olen kuulnud ahastamapanevaid lugusid, kus õpetaja pole materjale lastele edasi saatnud, sest „kui neil probleem tekib, küsivad nad minu käest ja ma ei oska vastata“. See, et tänapäeva maailm muutub kiiresti ja kõigile küsimustele ei oska vastata, on täiesti loomulik ja seda ei ole vaja häbeneda. Ma ei oska ise ka oma laste küsimustele alati vastata, aga lapsevanemad ja õpetajad polegi enam ammu viimane instants. Internetis on rohkem teadmisi kui ükski inimene elu jooksul suudaks omandada, ja needsamad informaatikaolümpiaadi toimkonna inimesed on nõus teeotsa kätte juhatama.

Üleskutse lapsevanematele: Julgustage oma lapsi õppima reaalaineid ning nokitsema arvutite kallal – maailm muutub tulevikus keerulisemaks ja omandatud teadmised tagavad edu. Kui te panete oma lapse viiulitundi või maleringi, et tal elus hiljem ekstra oskusi oleks, siis sama kasulik on saata teda ka tehnoloogiaringi.

Üleskutse noortele: Ikka veel on levinud stereotüüp, et IT-mehed on mingid patsiga poisid, kes istuvad keldris ja urisevad möödakäijate peale. Tegelikkuses kipuvad viimastel aastatel just IT-firmad võitma kõige pere- ja töötajasõbralikuma ettevõtte auhindu, neis on mugavad ja kaasaegsed tingimused, hulgaliselt soodustusi ja parimad üritused. Palkadest oli ka juba juttu. Leidke võimalus külastada Skype’i või Webmedia kontorit ning vaadake, kas meeldib.

Üleskutse riigile: Investeeringud IT-haridusse kitsamalt ning reaalharidusse laiemalt, mis algaksid juba põhikoolist, tasuvad end ära rohkem kui miski muu. Iga Eestile lisanduv IT-spetsialist saab tulevikus olema mitu korda suurema sissetuleku ja ekspordiväärtusega kui keskmine kodanik, tuues oma maksurahaga õpetamise kulu paljukordselt tagasi. Ideaalis oleks see osa kooliprogrammist, aga kui seda ei jaksa, oleks abi ka huvitegevuse ja ringide tekke soodustamisest.

20 responses so far

Jul 06 2011

Mehaanikud, elektrikud ja insenerid

Viimases Arvutimaailmas oli lugu Eesti IT-haridusest ja seonduvatest küsimustest. Lisaks väärikamatele osalejatele anti ka mulle võimalus sõna sekka öelda. Kuna täielikud vastused AM loo sisse ei mahtunud, panen nad siia, lisaks ka paar täiendavat kommentaari. Soovitan kõigil ka päris artikkel läbi lugeda, teised inimesed ütlesid igasuguseid huvitavaid asju (siin nt Sten Tamkivi täielikud vastused).

Küsis Martin Mets.

Mis Te arvate, kui heal tasemel on Eestis antav IT alane haridus? Kas sellest piisaks välismaal läbilöömiseks või mängivad siinkohal rolli hoopis teised asjaolud?

“Välismaa” pole mingi ühene termin, et meie Eestis teeme ühtmoodi ja välismaal tehakse teistmoodi.

Ma jagan “IT-mehed” laias laastus kolme kategooriasse:

- Esimesed on nagu automehaanikud. Kui ma lähen autoga teenindusse ja kaeban, et mingi tuli läks põlema, siis nad vaatavad manuaalist veakoodi järele, putitavad vastavalt tootja näpunäidetele midagi või vahetavad mõne jupi välja. Enamik mitmesuguseid süsadminne ja erinevates ettevõtetes patsiga poisi ameti täitjaid kuuluvad siia kategooriasse.

- Teised on nagu elektrikud. Kui mul on vaja kodus elektrikilpi paigaldada, kutsun elektriku. Tema on kutsekoolis õppinud, et roheline juhe käib siia, punane juhe sinna, tal on vastavad materjalid ning tööriistad, kulutab kokku näiteks neli tundi ning küsib mult 4 korda X eurot. Valdav enamik Eesti programmeerijaid on nagu elektrikud. Neil on spetsiifilised teadmised, kuidas üht või teist probleemi standardselt lahendatakse ning nad töötavad projektides, mida tehakse konkreetsele kliendile teatud vajaduse rahuldamiseks, mille eest küsitakse kliendilt raha kulutatud tundide alusel.

- Kolmas kategooria on insenerid. Insener on keegi, kes mõtleb välja midagi uut, kasutades ühelt poolt teoreetilisi teaduslikke teadmisi ja teiselt poolt loovat mõtlemist. IT valdkonnas eeldab näiteks mõne uue toote (mitte konkreetse kliendi rätsepatöö!) loomine üldjuhul insenerilähenemist. IT-insenere on Eestis väga vähe.

Välismaa juurde tagasi: maailmas on olemas mehaanikufirmad, elektrikufirmad ja insenerifirmad. Viimases kategoorias on kasvõi Google, Microsoft ja Apple. See on ka asi, millega miljardeid teenitakse, mehaanikud ja elektrikud on sellega võrreldes peost suhu elajad.

Enamik Eesti tarkvarafirmadest on elektrikufirmad ja kui koolilõpetaja saab hakkama Eesti elektrikufirmas, siis saab ta üldjuhul hakkama ka muu maailma sarnases ettevõttes. Tuleb ainult arvestada, et mujal on inimesi rohkem ja seetõttu ka konkurents tihedam. Mingit fundamentaalset probleemi aga pole.

Kui me seame aga eesmärgiks heas insenerifirmas läbilöömise, siis enamiku Eesti koolilõpetajate tase jääb liiga nõrgaks, seda nii teoreetilise baasi kui praktiliste harjumuste osas, kuidas uusi asju välja mõelda ja teoks teha.

Paljud arendajad ja start-upid räägivad, et neid erialasid või programeerimiskeeli, mida neil vaja oleks, Eestis ei õpetataki. Kui suur peaks olema IT-alane spetsialiseerumine väikeses Eestis, kas olekski vaja üksnes baasharidust, millele hiljem lisandub juba tööalane praktika ja spetsialiseerumine?

Kui inimesel on olemas tugev teoreetiline baas, siis uue programmeerimiskeele äraõppimine tuleb paari nädalaga, olen seda ise korduvalt kogenud.

Kui ta on aga ainult õppinud, et “uue andmebaasikirje loomiseks vajaliku veebivormi loomiseks tuleb läbi teha järgmised 5 sammu”, siis tekib natukene erinevas situatsioonis muidugi probleem. Kuna tehnoloogiad vahetuvad niikuinii üsna kiiresti, siis ma rõhuksin pigem sellele, et ühelt poolt oleksid õpilastel tugevamad baasteadmised ning teiselt poolt oleks neil kohustus teha palju praktilisi harjutusi.

Eesti IT õppekavadest läbi saamine on praegu naeruväärselt lihtne. Näiteks USA üliõpilased higistavad kasvõi koduste tööde kallal palju intensiivsemalt. Ma ei räägi siin isegi mitte tippülikoolidest, kes praegu jäävad püüdmatusse kaugusse, vaid tavalistest osariigikeskuste ülikoolidest, kellega nt Tartul ja TTÜ-l oleks end igati paslik võrrelda.

Räägitakse, et Eestis on puudu juba ligi 2000 IT-spetsialisti. Viimastel aastatel on vastuvõtt IT-erialadele natukene paranenud, kuid see võiks olla endiselt palju parem. Kuidas võiks IT-haridust Eestis populariseerida?

 Siin on tegelikult kaks eraldi küsimust: kvantiteet ja kvaliteet. IT-koole on meil päris palju ja sealt tuleb ka välja palju rahvast, aga suur osa tulemusest on praak, seega lihtsalt reklaam ja läbilaske suurendamine ei aita.

Kvaliteedi ja kvantiteedi tõstmine korraga ei ole lihtne projekt. Lahendus algab vundamendist ehk reaalainete õpetamisest põhikoolis ja keskkoolis ning võtab 15-20 aastat. Kuna aga IT roll maailmas järjest kasvab, on see võtmeks, kuidas me tulevikus suudame oma majandust konkurentsivõimelisena hoida ja Eestist rikka riigi teha.

Konkreetsed soovitused:

- Vähendada laste hirmu reaalainete, eriti matemaatika ees, seostades seda rohkem tegeliku eluga. Näidata lastele, kuidas maailm päriselt töötab, sealhulgas tehnoloogia, IT ja majandus, ning kuidas matemaatika selles kõigest läbi jookseb.

- Rohkem koole, kus reaalainete süvaõpe algaks juba põhikoolis. Luua juurde tehnika- ja IT-kallakuga keskkoole.

- Igal tasemel suurendada praktiliste, loominguliste ülesannete hulka, et edendada harjumust iseseisvalt uusi asju välja mõelda.

- Tõsta ettevõtluse mainet. Keegi peab neile tulevastele inseneridele ka soodsa loomekeskkonna tekitama.

- Lapsevanemates arusaam, et reaalained tagavad edu. Viimasel ajal on ajakirjandus õnneks selgeks teinud, et IT-mees kipub finantsiliselt paremini elama kui keskmine eestlane, aga eelnenud 20 aastat on ühiskonnas levinud olnud mõtlemine, et vaja on õppida eelkõige keeli, kõnekunsti ja avalikkussuhteid. Need kõik on vajalikud, kuid ei muuda fakti, et IT-spetsialist, keemik või aatomiinsener teenib maailmas keskmiselt siiski rohkem kui tõlk või PRi tegija.

- Kaasata rohkem häid välisõppejõude, sarnaselt Marlon Dumas’ga Tartu Ülikoolis. See annab uue hingamise ning sunnib nii kaasõppejõude kui ka üliõpilasi end rohkem kokku võtma.

Muid lisamõtteid veel:

Üks meie koolide suuremaid probleeme pole seotud mitte õppekavade, vaid õppedistsipliiniga.

Näide 1: Räägib (eraviisiliselt) minuga üks tsikk, et tal varsti eksam. Küsin seltskondlikult, kas vaim valmis? Tema vastu, et eriti ei ole, aga kui õppejõule ilusti naeratada, siis küll ta läbi laseb. Wtf.

Näide 2: Kui ma ise ülikoolis loenguid ja kodutöid andsin natuke, puutusin üsna pidevalt kokku ka küsimustega, et kas saaks üht või teist asja hiljem või lihtsamalt või uuesti teha jne. Enamikus ‘meerika ülikoolides tähtaeg on tähtaeg ja kui valmis ei ole, on oma viga.

Näide 3: Mõnedele värskelt ülikoolist tulnutele on esimesed päris tööl veedetud nädalad parasjagu šokeerivad – kas tõesti tuleb nii palju asju tuleb teha? Eesti koolide kodutööde maht on suurusjärgu võrra väiksem kõvema kategooriaga ülikoolide omast. Selle tõstmine aitaks ühelt poolt kaasa koolist saadavale teadmiste tasemele (iseseisvalt läbi töötatud materjal jääb palju paremini külge kui  loengus kuuldu) ning teiselt poolt muutuks ka uute IT-meeste töö efektiivsus kõrgemaks, kuna on tekkinud paremad tööharjumused.

49 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

Mar 27 2011

Pinu kokkutulek 6.aprillil

Published by Targo under Isiklik, Programmeerijad, Tehnoloogia

Kes veel ei tea, siis 6.aprillil toimub Pinu.ee kokkutulek, kus loodetavasti räägitakse mitmesuguseid huvitavaid asju. Võib-olla räägin ise ka midagi, kes soovib, võib minu teema üles hääletada (ja kes ei soovi, võib alla hääletada).

Ja kui on keegi, kes veel ei tea, mis on Pinu, aga tunneb huvi kitsamalt või laiemalt huvi programmeerimise vastu, saab muidugi liikmeks hakata.

No responses yet

Jul 06 2010

Kelleks saada

Published by Targo under Haridus, Programmeerijad, Põhialused

Tööd ei karda me juhhei,
ametid on kõigil meil!

Rääkisin ühe tuttavaga teemal, mida on võimalik IT-s karjääri poolest üldse peale hakata. Enda üllatuseks leidsin, et ükski IT-d õpetav Eesti kool ei loetle just kuigi põhjalikult võimalusi ja ameteid, millega pärast nende stuudiumi lõpetamist on võimalik tegeleda, ja samuti ei kujuta ka paljud tudengid ette, mida nad täpsemalt pärast kooli tegema hakkavad. Hakkasin neid seetõttu ise kirja panema ja mõningase mõtlemise järel jõudsin järgmise tabelini (kliki, et suurendada):

Siin on ära toodud üksteisest ülesannete sisu poolest erinevad ametid, mille täiskohaga pidajaid ma ise näinud olen, ja kus tarkvaraalasest (päris tervet IT-d+arvutiteadust ei oleks jõudnud ühte tabelisse kirja panna) haridusest kasu oleks. Grupeering on mõneti meelevaldne ja mõnes situatsioonis liigitataks ameteid ehk teisiti. Siiski läheb praktiliselt igas tarkvaraprojektis peaaegu kõiki ka vaja, kuigi olenevalt projekti suurusest võib mõnele neist kuluda 0,1% ühemehefirma omaniku ajast kuni tervete meeskondadeni. Nt Microsoftis on tiim, kes päevast päeva lihtsalt jooksutab igapäevaste Office’i buildide suitsuteste. Testid käivad automaatselt, kuid sellegipoolest on vaja, et keegi kontrolliks, et kõik sujub, koordineeriks parandusi, saadaks vastavaid teavitusi jne.

Peale nende on muidugi veel musttuhat spetsiifilisemat varianti, üks huvitavamaid ametinimetusi, mida ma olen kohanud, oli Emulation Ninja Microsofti XBoxi divisjonis, aga need on üldjuhul teisendid tabelis toodud ametitest.

Kuna aga need ametid erinevad mitte ainult tehnoloogia, vaid ka sisu poolest, oleks väga hea, kui ülikoolid mõistaksid nende olemasolu ja annaksid ka spetsiifilisemaid teadmisi, kuidas ühes või teises hakkama saada. Igaüks neist vääriks eraldi loengukursust, kardetavasti utoopia, aga unistada ju võib.

Veel: siit ei järeldu, et ma pooldaksin mingit superkitsast spetsialiseerumist. Minu peamine point on, et nende tegevusalade olemasolu tuleb teadvustada ning ennast nende läbiviimiseks korralikult ette valmistada, kuid õige professionaal võiks vallata päris paljusid selle tabeli lahtritest. Inimene on ikkagi generalist, spetsialiseerumine on putukatele :)

7 responses so far

Mar 01 2010

Kuidas kirjutada CV-d

Published by Targo under Juhtimine, Programmeerijad

cv-mistakes

Mult on vahetevahel küsitud nõu, kuidas efektiivsemat CV-d kirjutada. Internetis on selle kohta küll üsna palju materjali, aga kuna minu lauale jõuavad vahel ikka päris traagilised kirjutised, ütlen sõna sekka.

Esimene küsimus on tegelikult, kas meil on üldse CV-d vaja? Minu meelest on nii värbamisel kui töölesaamisel oluliselt, oluliselt parem variant CV-d mitte kasutada. Nagu Toots ütles, parim soovitus mehele on mees ise. Ehk siis, kui tegemist on inimesega, kelle teod räägivad iseenda eest (on näiteks valmistanud või kirjutanud midagi, millest kõik teavad), milleks talle siis veel CV? Väga abiks on siin muidugi ka võimalikult laia sotsiaalse võrgustiku (vana kooli mõttes, mitte tingimata rate.ee) omamine, et saaksid õigel ajal õiges kohas olla.

Kui me esimesele küsimusele vastates siiski leiame, et meil piisavalt tuntust ei ole, tuleb järgmiseks uurida ühtteist selle ettevõtte kohta, kuhu me tahame pääseda. On muidugi ka geneerilisi CV-sid, mida spämmitakse tuhandesse eri kohta, et ehk näkkab, need on kergesti äratuntavad ning jäetakse enamasti kõrvale.

Kõige olulisem asi ettevõtte kohta on see, kas seal värbavad inimesi teised tehnikud või on tegemist 100% HR funktsiooniga (mingi osalus on HRil muidugi alati, oluline on see, kes otsuseid teeb). Esimene variant on üldiselt palju parem, teist liiki firmad soovitan ma madalamaks prioriteediks võtta.

dilbert_hiring

Kui HRile silmajäämiseks tuleb enamasti õigeid buzzworde teada, siis tehnikute osas on kuldreegliks: kui sa ise kedagi tööle võtaksid, siis mis laadi inimest sa tahaksid? See mõtlemine aitab enamasti sobivust kontrollida. Vaata, mis on selle ettevõtte või organisatsiooni ning tema juhtkonna põhiväärtused, mõtle, kas sa jagad neid, ning too nad seejärel enda juures esile.

Näiteks mulle isiklikult jäävad silma need, kes demonstreerivad:

  • Taiplikkust
  • Pealehakkamist
  • Passionit
  • Võimet asju ära teha
  • Koostööoskust

Kui mainid oma CVs mitmesuguseid üritusi või projekte, mida oled algatanud ja korraldanud, siis see on hea, kuna näitab pealehakkamist.

Kui kirjutad projektidest, milles oled osalenud, too kindlasti välja, mis oli sinu isiklik panus sellesse. Millega sa hakkama said? See näitab asjade ära tegemise võimet.

Kas tegeled tööväliselt mingite lahedate tehnoloogiliste asjadega? Proged ehk midagi või ehitad roboteid? See näitab taiplikkust ja passionit.

Kui sul on kogemusi suuremas tiimis koos töötamise alal, siis seda peaks ka mainima, sealhulgas oma rolli tiimis. Et siin projektis oli 3 progejat ja mina tegin neile tehnilist disaini, see ütleb ühtteist koostöövõime kohta. Paljud programmeerijad on üksikud hundid, omaette teevad asjad ära, aga suures projektis ei saa teistega koos töötatud.

See oli nüüd minu isiklik vaatenurk, aga metaõppetund on alati järele uurida, kes antud ettevõttes värbamisega tegeleb, mis on nende metoodika ja väärtused, mille alusel nad inimesi hindavad, ning seejärel natuke kodutööd teha.

Ja last but not least - korrektsus on alati abiks, enamik komavigu ei tekita päris sellist piinlikkust nagu ülaloleval pildil, aga lohaka mulje jätavad ikka.

6 responses so far

Jan 05 2009

Peresõbralike ajagraafikute koostamine

Hulkuvate Kasside Riiklik Inspektsioon tellis tarkvarafirmalt Joostes Marss täiendusi oma andmeregistrile. Ülesandepüstitus oli küllaltki selge ja põhjalik ning projektijuht Joosep küsis programmeerija Priidult, kui kaua asjaga läheb. Neli nädalat, vastas Priit, Joosep pani igaks juhuks puhvri mõttes veel nädala otsa ning teatas klient Kustavile, et viie nädala pärast saab asja kätte.

Priit hakkas asjaga hoolega pihta, Joosep käis regulaarselt pärimas, kuidas läheb, ja üldiselt asi sujus. Nagu programmeerimise puhul ikka ette tuleb, tekkis ka siin ootamatuid viivitusi, kuid viienda nädala lõpuks teatas Priit siiski, et kood on valmis.

Joosep helistas Kustavile, et asjad on korras, aga arvas seejärel, et vaatab ise ka siiski funktsionaalsust. Tulemused tõstsid tal ihukarvad püsti – enamvähem iga viie kliki järel rakendus crashis ja praktiliselt ühtki kasutusjuhtu polnud võimalik algusest lõpuni läbi käia.

Joosep tormas kõva kisaga Priidu juurde, et mis toimub. Aset leidis järgmine kahekõne.

Joosep: Mis bl*#¤% selle koodiga toimub??
Priit: Kood sai just valmis ja kogu funktsionaalsus on teostatud.
Joosep: No aga miks see crashib siis, jo*#¤ma*#¤% ?!?
Priit: No aga keegi pole ju seda testinud, loomulik ju, et koodis pole kõik asjad kohe päris õiged.
Joosep: Kas sa ise ei testinud siis oma asja?
Priit: Testimiseks polnud aega ette nähtud, ise küsisid, et kui kaua teostamisega läheb, mitte testimisega. Ja üldse oled ise üks hu*”%¤% !!

Oops.

Asi lõppes sellega, et Joosep istus ise järgmise paari nädala hilisõhtud töö juures ja testis erinevaid stsenaariume ning käis ka Priidul piitsaga kannul. Mõlemad olid stressis ja magamata, Kustav õiendas iga päev, et mis ikkagi toimub, pidi ju valmis olema, ning kui projekt lõpuks üle anti, tekkis seal ikkagi probleeme, sest testimine polnud nii põhjalik, kui vaja oleks olnud.

Lisaks süüdistasid Joosep ja Priit pidevalt ka teineteist asja nässukeeramise eest, Joosep leidis, et Priidu tulemus ei oleks tohtinud selline olla, Priit omakorda, et kõik on Joosepi süü selle pärast, et projektigraafikusse ei arvestatud testimise ja vigade parandamise aega.

Milles siis tegelikult asi? Minu isiklikus kogemuses ei hävi projektigraafikud mitte niivõrd sellepärast, et hinnangud oleksid ebatäpsed, kui sellepärast, et mingid tegevused unustatakse lihtsalt graafikusse lisamata.

Iidseks vaidluste allikaks on siin, et kes peaks tegelikult hoolt kandma, et kõik tegevused oleks arvesse võetud? Programmeerijad sõimavad enamasti projektijuhte, samas õppis Joosep Audentese koolis rahvusvahelist ärijuhtimist ja kuigi ta saab hästi hakkama kliendisuhtluse ja raha lugemisega, on temalt mõneti utoopiline loota, et ta täpselt teaks, mida kõike üks tarkvaraarendaja peab tegema, et asi valmis saaks. Seda enam, et “valmis” võib tegelikult erinevate inimeste jaoks tähendada väga erinevaid asju, näiteks:

  • Funktsionaalsus on koodiridadena olemas
  • Keegi on rakenduse peamised kasutajajuhud läbi käinud
  • Programmeerija on rakendusele kirjutanud unit testid ja need töötavad
  • Testija on mingi testimisplaani alusel kontrollinud, et funktsionaalsus töötab
  • Tellija on formaalse kava alusel kontrollinud mitmesuguste nõuete täidetust

Jutu peamine moraal kõigile tarkvaraprojektides osalejaile on:

  • Täpsustada, mida nimetatakse valmis olekuks, kuna see on olenevalt inimese taustast ja ametist väga suuresti vaataja silmades
  • Teha vahet lubaduste (commitmentide), ligikaudsete esmärkide ja tõenäosuslike ajahinnangute vahel ning iga mainitava kuupäeva puhul täpsustada, millega on tegemist.

Konkreetselt programmeerijad on mitmel korral mulle kurtnud, et nende ajagraafikud on ebarealistlikud, sest ei võta kõiki tegevusi arvesse. Peamine nõu, mida ma neile olen andnud, on:

  • Tavaliselt on ebarealistlik oodata, et projektijuht ise kõiki tehnilisi tegevusi meeles jõuab pidada ja nende kohta eraldi ajahinnanguid küsida. Seega peaks programmeerija tõusma oma positsioonilt natuke kõrgemale ja ise järele mõtlema, mis on tegelikult projekti õnnestumiseks vaja teha.
  • Selle asemel, et keskenduda oma ajahinnangute kitsale definitsioonile ja anda ainult koodikirjutamiseks kuluv aeg, eelda, et niikuinii tuleb sul teha hulk muid asju nagu unit testide kirjutamine, komponenditestimine, süsteemitestimine, vigade parandamine jne. Kui on teada, et keegi teine mingi osa nendest tegevustest enda kanda võtab, on väga hea, aga üldiselt seda ei juhtu ja vaikimisi on parem need kohe hinnangutena kirja panna. Mõte siis selles, et lõpuks tuleb need tegevused niikuinii ära teha, iseasi, kas ületundidena või mingil mõistlikul ajal.
  • Kuus kuud hiljem ei mäleta üldjuhul keegi, kui kaua see asi tegelikult aega võttis, küll aga mäletavad inimesed hästi, kas 1) tähtajad pidasid 2) kui hästi tulemus toimis. Töötasin kord koos ühe arendajaga, kelle ajahinnangud alati väga kõrged tundusid. Kui teda aga lähemalt üle kuulata, tuli välja, et tegelikult oli ta graafikusse lisanud ka väga täpsed ja detailsed ajahinnangud sellele, kui palju teste ta ise tahab kirjutada, kui palju võtab aega funktsionaalsuse testijale üleandmine ja tutvustamine, potentsiaalsete vigade parandamine jne. Ja tulemuseks oli, et kuigi ta lõpetas oma lõigu nominaalselt teistest hiljem, oli ta projekti testimis- ja stabiliseerimisfaasi lõpuks teistest ees ning tema kood töötas palju paremini kui kellelgi teisel. NB! See ei tähenda, et kõik võiks lihtsalt oma ajahinnanguid hakata kahega korrutama, vaid seda, et inimesel tuleb tõesti hoolikalt järele mõelda, kui palju nendele ekstra tegevustele kulub ja neid detailselt hinnata!
  • Vahel väidavad ülemused või kliendid, et testimine pole oluline, või et selle eest niikuinii ei maksta. Ma arvan, et selline seisukoht on tihti tingitud valdkonna puudulikust tundmisest. Kui keegi tõesti ütleb, et ärme neid lisategevusi graafikusse pane, siis ma soovitan nad enda jaoks sellegipoolest kirja panna ning lihtsalt “koodikirjutamisele” juurde liita. Elu on näidanud, et lõpuks tuleb sellised tegevused nii või teisiti ära teha ja kuna shit flows downhill, näidatakse pärast ikka näpuga progeja peale, et tema tegi halvasti.

5 responses so far

Sep 24 2008

Arendajate arengust

 evolution.jpg

On arenguvestluste aeg. Praegu on neljas aasta, mil see ülesanne minu ametijuhendis seisab, ja panen sel teemal lõpuks mõned kogutud mõtted kirja.

Tarkvara tellija seisukohalt näeb projekt välja umbes selline:

tellija_vaade1.jpg

Ehk siis nad eeldavad, et saavad mingi raha eest kaetud ära erinevate valdkondade kompetentsi mingite tarkvarakomponentide osas. Erinevaid komponente võib teostada sama või erinevad inimesed, eeldame siinkohal lihtsuse mõttes, et iga ruutu täidab erinev inimene.

Kui meil tuleb nüüd tööle ilma eelneva kogemuseta nooremarendaja, on tema kompetents tegelikult selline:

arendaja1.jpg

Selge see, et tellijale selline valgete laikude jätmine ei meeldi, sellepärast aitavad meie uut arendajat üldjuhul kolleegid kõrvalruutudest, näiteks inimesed, kes seonduvaid komponente haldavad, annavad tehnilist nõu, analüütik hoiab asjal rohkem silma peal jne.

arendaja2.jpg

Igal inimesel tekib mingi ala, mille raames ta projekti üldist käiku mõjutab. Ja kuna tellija maksab meile lõppkokkuvõttes kogu ruumi täitmise eest, on kasu, mida inimesed projektile toovad, otseselt seotud nende mõjuala suurusega. Teisisõnu, kui palju on teistel teda ümbritsevatel inimestel temast abi, võrreldes sellega, kui palju teised peavad teda järele aitama.

Tegelikus elus tuleb neid dimensioone veel juurde, näiteks saavad inimesed oma mõju avaldada projektijuhtimise ja kliendiga suhtlemise liinis, aga põhimõte jääb samaks.

Ja tavaliselt ei jää inimesed igaveseks ajaks abivajajaks, vaid arenevad nii kaugele, et täidavad oma valdkonna adekvaatselt ära ja hakkavad ise pigem teistele nõu andma:

areng.jpg

Mis on jutu moraal:

See mudel annab meile ka automaatselt meetodi inimeste tulemuste ja kasutoomise hindamiseks. Meil pole vaja lugeda koodiridu ega bugisid ega function pointe ega spetsifikatsioonilehekülgi ega laua taga istutud tunde. Kõik need mõõdikud illustreerivad vaid pisikest lõiku sellest, mida inimene tegelikult teeb, kui paljude teiste projektiosalistega ta suhtleb ja millist kasu ta neile saab tuua, rääkimata asjaolust, et need andmed on väga kergesti võltsitavad :)

Vaja on ainult vestelda kõnealuse inimese kaastöötajatega erinevatest dimensioonidest (arendaja puhul näiteks teised arendajad, tema lähim analüütik, testija, projektijuht, klient jne) ja küsida, millist kasu on inimene X teie vaatekohalt nii projektile kui ka teile endale toonud, ning me saamegi hea pildi sellest, kes on tegelikult väärtuslik, kes mitte.

Kokkuvõtlikud järeldused:

  1. Arendaja loomulik karjääriprotsess on, et ta vajab aja jooksul vähem kõrvalist abi ja hakkab järjest rohkem aitama teisi. Esimeseks sammuks on siin üldjuhul oma loomuliku ruudukese äratäitmine ning teiseks laienemine mõnda kõrvalasuvasse, vastavalt isiklikele huvidele ja projekti vajadustele.
  2. Igal inimesel tuleb ette loomulik piir, millest alates ainult omaenda kitsas töövaldkonnas opereerimine pole piisav, et igal aastal palka juurde küsida, kuna ta on iseenese ruumi lihtsalt ära täitnud. Samas on igas projektis alati küllaga valgeid laike, mille täitmisega rohkem kasu tuua.
  3. Ja kõige olulisemana minu isiklik põhireegel arenguvestluste osas: inimese väärtus projektile on võrdeline talle töökaaslastelt osaks saava respektiga.

No responses yet

Next »