Archive for the 'Põhialused' 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 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

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

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

Jan 10 2010

IT – mitte tehnoloogia, vaid kommunikatsioon

Kuna head inimesed Eesti Päevalehes on oma reklaamirahad ilmselt kätte saanud, panen ka siia oma läinudsügisese intervjuu materjalid. Parandasin ära ka mõned toimetamise/valestimõistmise apsud (irooniline, kas pole).

Tiiu Laks oli kena inimene, kes mind intervjueeris.

Communication

— Kuidas sulle tundub, kas Eestis on nii kõrge infotehnoloogia tase, kui siin tavatsetakse arvata?

— Oleneb, millisel tasandil me vaatame – kas riiki tervikuna, inimesi eraldi või IT-spetsialiste. Vastus on iga grupi puhul natuke erinev.

— Näiteks e-riik, mille üle eestlased uhked on?

— Rahvusvaheliselt on Eesti võib-olla kõige olulisem omadus see, et Eesti on hästi väike. Kui Eestis elada, siis ei anna sellest endale ehk nii väga aru, aga kui käia maailmas ringi ja sõita ühest linnast teise, siis märkad, et selles või tolles linnas elab sama palju inimesi kui terves Eestis, mõnes teises jälle kolm korda rohkem inimesi kui Eestis. See on tegelikult üsna haruldane, et nii väike riik on olemas.

Nii on meil ka infotehnoloogilises mõttes võimalik väledamalt reageerida ja igasuguseid asju teha. Teinekord me kirume Eesti bürokraatiat, aga kujuta ette suurriiki, kus riigiaparaat on sada korda suurem kui Eestis. Sada korda suurema ametnikkonnaga riiki e-riigiks muuta on üsna lootusetu projekt.

Sest mida rohkem on süsteemi kasutajaid, mida rohkem eri huvisid, mida keerulisem on protsess, seda raskem on seda IT-projekti läbi viia. Ühel hetkel kasvab keerukus nii suureks, et projekti ei ole võimalik mõistliku ajaga täide viia.

Ameerikas on olnud selliseid kolossaalseid ebaõnnestumisi IT-vallas. Tihti tuuakse näiteks FBI. FBI tahtis endale infosüsteemi, kus oleksid kõik nende menetlused ja kriminaalasjad ning igal agendil sellele ligipääs. Projekti peale kulutati müstilisel hulgal raha, sadades miljonites dollarites, mis on rohkem kui terve Eesti avaliku ja erasektori IT-kulutused ma ei tea mitme aasta peale kokku. Ja sellegipoolest asi lihtsalt ei läinud käima.

Eestis on neid asju lihtsam läbi viia, on lihtsam e-riigi taolist süsteemi käivitada. Selle pärast vaatavadki välismaalased, et ohoo. See võtab neil suu lahti, et kodanikul on võimalik riigiga kõik asjad kodunt lahkumata korda ajada. E-valimised on paljudele muidugi täielik ulmeteema, aga kas või sellised lihtsad toimingud, nagu ID-kaardiga allkirja andmine. See on väga lahe.

— See tähendab siis ju, et Eestil pole mõtetki üritada kas või e-pileti süsteemi näiteks Poola eksportida, sest süsteem ei hakka suuremas kohas tööle?

— Oleneb. See on natuke erinev, kas luua süsteem nullist või käivitada väljatöötatud lahendus uues kohas.

Paljud IT-lahendused jäävad tihti selle taha, et hakatakse nullist tegema ja tahetakse, et süsteem rahuldaks kõigi huve, et kõik inimesed saaksid kohe kõike teha. Just siin mängib rolli, kas meil on 50 või 500 või 5000 ametnikku ehk erinevat soovi. Väga tihti jääb kõik selle taha, et hammustatakse liiga suur tükk, alahinnatakse ülesande keerukust ja ülehinnatakse enda võimeid. Ühel hetkel saab jõud lihtsalt otsa.

Aga kui süsteem on juba olemas ja on selge, mis töötab ja mis mitte, siis sealt samm-sammult edasi minna on oluliselt lihtsam. Kuigi ka sel puhul võib mingil hetkel keerukuse piir vastu tulla.

— Eesti on siis IT-lahenduste inkubaator?

— Eestis on suhteliselt vähe programmeerijaid. Hästi raske on öelda, kes neist on millisel tasemel. Hulk tudengeid lõpetab igal aastal informaatika eriala Tartu ülikoolis ja tehnikaülikoolis. Kuid mitte kõik lõpetajad ei jää tingimata selle eriala peale. Aga lisaks on hulk rahvast, kes ei ole programmeerimist koolis õppinud, kuid töötavad sel alal.

Kokkuvõttes – suurusjärk jääb umbes samaks.

Aga maailma mõõtkavas on neid ikka vähe. 10–15 aasta peale kokku on seda kaadrit tekkinud ikka suhteliselt vähe. Mõnes rahvusvahelises suurfirmas (Microsoftiga ma ei hakka võrdlemagi) töötab mitukümmend korda rohkem programmeerijaid kui terves Eestis.

See tähendab, et meil ei ole võib-olla võimalik teha nii suuri, vägevaid ja seinast seina IT-lahendusi. On oluliselt vähem spetsialiseerumist ja oluliselt rohkem seda, et üks inimene peab ära tegema seitse eri ülesannet, milleks suurkorporatsioonis oleks seitse inimest. Loomulikult ei ole tal siis võimalik tööd nii põhjalikult teha. Eestlastel on tekkinud harjumus väiksemate jõududega teha valmis töötav lahendus, mis ajab asja ära.

Võib-olla Saksamaal kirtsutatakse nina, et teete seal kümne inimesega projekti, mis projekt see sihuke ka on. Aga enamiku e-riigi lahendusi on loonud maailma mõistes väga väikesed meeskonnad. Struktuurne probleem on lihtsalt Eesti üks eripära – Eesti on väike, siin on vähe inimesi ja kõik probleemid tuleb lahendada nende inimestega, kes siin on.

Kuna inimesed peavad tegelema rohkem igasuguste üldiste küsimustega, siis on spetsialiseeritus väiksem. Ma ise olen ka täielik universaal – ma teen kõike, müügitööst kuni tehniliste ülesanneteni. Kui kõrvutame Eesti ja mõne muu maa spetsialisti, on sügavust Eesti omal arvatavasti vähem. Samas on rohkem oskust, kuidas pisikese ajavaru, ressursi ja meeskonnaga midagi valmis saada. Kas see on hea või halb? Sõltub olukorrast.

— Nii et see on omamoodi väärarusaam, et IT-valdkond on üks meie suurema potentsiaaliga ekspordiartikleid?

— Ma ei tea, kuivõrd realistlik ekspordiartikkel see on, aga sellist promo eksporditakse küll kõvasti. Ma arvan, et see hakkab ennast kindlasti ära tasuma. Kui on teada, et Eestis on kõvad programmeerijad, kes teevad lahedaid asju, on see kõva plusspunkt juhul, kui näiteks Inglismaal peab keegi otsustama, kas palgata inimene Eestist või Malaisiast. Lihtsalt selle seose tekkimine ja otsustajateni jõudmine võtab natuke aega. Aga kindlasti on selline maine pingutust väärt.

— Sa lugesid Tartus informaatikatudengitele tarkvara projektijuhtimise kursust. Mida tudengitega töötamine sulle uue IT-põlvkonna kohta ütles või näitas?

— Ma arvan, et inimesed on üle maailma põhiolemuselt samad – ühesugune võimekus ja IQ. Lihtsalt digitaalses elus muutuvad olud väga kiiresti.

1960. aastatel oli IBM infotehnoloogia A ja O, nad olid võitmatud ja miski ei saanud neid kõigutada. 1990. aastate alguses oli firma aga katastroofi äärel, 1992 oli IBM-i kahjum 8,1 miljardit dollarit, mis oli tollal USA ajaloo rekord. Asi polnud selles, et IBM-i inimesed oleksid olnud rumalad (IBM-is töötas nobeliste ja Turingi auhinna võitjaid), ega ka selles, et IBM-il oleks olnud halb tehnoloogia.

Juhtus lihtsalt see, et tehnoloogia, millele IBM oli ise aluse pannud, hakkas muutma ühiskondlikke struktuure. Infotehnoloogia demokratiseerus ja peale kasvas uus põlvkond, kellel oli arvutitega hoopis teine suhe, tehnoloogia oli nende elu igapäeva osa, mitte enam miski, mida valge kitliga onud hooldama ja paigaldama pidid. Tehnoloogiauuenduse tulemusel toimus ka inimeste uuenemine. IBM ei osanud uut demograafilist gruppi enam kuidagi käsitleda ja kaotas liidrikoha.

Sama protsess kestab tõusulainena edasi. E-postist on saanud elu lahutamatu osa. Kogu see Rate.ee, Facebooki ja Orkuti asi pole mingi lastehaigus, millest inimesed välja kasvavad. See põlvkond jääbki selliseid vahendeid kasutama, vahetades ehk vaid keskkonna millegi „professionaalsema” vastu, aga see jääbki osaks nende igapäevasest elust ja tööst.

Kümne aasta pärast jõuavad paljud Rate.ee põlvkonna liikmed ühiskonnas ja IT-alal otsustajate sekka. Mina kuulun pigem e-posti põlvkonda, aga praeguste 16–20-aastaste jaoks on suhtlusvõrgustikud elu.

Inimesed on üldiselt samasugused, aga kommunikatsiooni-viisid ja kuidas igapäevaseid asju tehakse – see muutub arvatavasti pidevalt ja jääbki muutuma.

Kui ma üliõpilastega rääkisin, siis mõni leidis, et kirjandus, mida ma soovitan, on anakronistlik – nendel on uued iidolid peale kasvanud. Ma mõtlesin, et mis mõttes:  ma rääkisin ju ainult kümme aastat vanadest asjadest.

— Kas on ka mingid põhitõed, mis jäävad?

— Kindlasti. Siin tuleks rääkida, millega infotehnoloogia tegeleb… Väga paljudel inimestel on arusaam, et asi on tehnoloogias – mida vingem tehnoloogia, seda parem. Kõik probleemid on lahendatavad veel enama ja parema tehnoloogiaga, siis saab kõik korda.

Tegelikult on infotehnoloogia kõige suurem probleem hoopis infos, täpsemalt kommunikatsioonis. Ühes servas on ärimehed, kes tahavad raha teenida, teises masin, millele tuleb ülesandeid anda. Need on kaks absoluutselt erinevat maailma. Äriidee peab minema kõigepealt meeskonnale, kes peab selle konkreetsetesse sammudesse ümber panema. Peab olema IT-inimene, kes saab aru ärireeglitest ja peab olema võimeline äriidee mingisse vormi valama ja selle olemust detailselt analüüsima. Spetsifikatsioonist saavad omakorda aru programmeerijad, kes teevad selle arusaadavaks arvutile. Nii et selles ülesandes on väga mitu tõlkimise kihti.

IT-projektid võivad tihtipeale ebaõnnestuda seetõttu, et sellessamas „telefonimängus” läheb infot vahelt kaduma või see moondub. Niisiis – süsteem, mis valmis tehakse, võib hästi töötada, aga teeb täiesti erinevat asja kui see, mida inimene alguses tahtis.

Seetõttu ei ole tõhus IT-ettevõte tingimata see, kellel on kõige võimsam tehnoloogia, vaid see, kes suudab võimalikult hästi hallata tõlkimist. Kõige hinnatumad ja vajalikumad inimesed ei ole need, kes valdavad hullult tehnoloogiaid (mis on informaatikatudengite sage eksiarvamus), vaid need, kes suudavad haarata võimalikult laia osa ärimehe ja masina vahelt.

Ideaalne IT-mees on see, kes suudab rääkida firma direktoriga ja selle põhjal programmi kirjutada, aga selliseid inimesi peaaegu pole.

— Aga kui vaadata kas või popkultuuris levivaid IT-inimeste stereotüüpe, siis nad ei ole just väga suhtlusaltid…

— Selles probleem ongi. Selleks et selle masinaga töötada… see tuleb paremini välja teatud isiksusetüübil. Sellepärast ongi tüüpilises projektis kliendi nimel äriinimene ja äriprojektijuht, IT-inimesed ja IT-projektijuht ning täitja nimel projektijuht, süsteemianalüütik, süsteemiarhitekt ja programmeerija.

Kui rääkida karjäärist IT-alal, siis võtmeküsimus enamiku IT-inimeste jaoks on, kas nad suudavad end sellest patsiga asotsiaalse poisi stereotüübist välja murda ja rohkem suhelda või mitte.

— Millisena sa IT tulevikku näed?

— Ma ei usu, et näiteks Bill Gates ja Steve Jobs mõtlevad, kuhu võiks IT minna, või otsustavad, kuhu seda liigutada. Need muutused algavad enamasti kasutajatest, alt üles. Peamine on see, et IT demokratiseerumine jätkub.

Kui mõelda kas või Wikipedia fenomenile, siis seal on sündinud sünergia tehnoloogia ja inimeste vahel. Tehnoloogia loob uusi võimalusi ning hakkab inimeste elus suuremat rolli mängima. Muidugi oleneb inimesest, kes harjub sellega kiiremini, kes aeglasemalt. Iga järgmise põlvkonnaga – isegi mitte põlvkonna, vaid kümnendiga – moodustab tehnoloogia inimelust suurema osa, inimeste ja tehnoloogia põimumist on rohkem, mis tekitab uue sotsiaalse tellimuse uute tehnoloogiate järele, mis võimaldaksid suhtlust veelgi kasvatada.

Interneti algusaegadel poleks tänased sotsiaalsed võrgustikud Rate.ee, Facebook, Orkut olnud mõeldavad, sest interneti kasutajaid oli lihtsalt nii vähe. Aga nüüd, kui neid on kõvasti rohkem, on ka rohkem inimesi, kes kulutavad teatud tunnid nädalas internetis olemise peale. Nii on tekkinud sotsiaalne tellimus – näiteks kohvikus lobisemas käimise asemel saab nüüd suhelda sotsiaalses võrgustikus. See protsess läheb kindlasti edasi. Mis kuju see täpselt võtab, ei julge ma ennustada. Aga ma arvan, et pääsu sellest ei ole.

— Kaugele see minna võib? Skeptikud väidavad ju, et paradoksaalselt tekitavad sotsiaalsed võrgustikud antisotsiaalsust, inimesed ei suhtle enam…

— Kindlasti killustab see ühiskonda. 30 aastat tagasi ei saanud ükski radikaal (ükskõik, kas poliitikas, usu- või muus valdkonnas) kohvikus oma hulludest mõtetest rääkida, ta rahustati enne maha. Tänapäeval aga on väga lihtne leida interneti abil üle maailma endasuguseid radikaale, kes jagavad sinu mõtteid. Ja siis nad võimendavad vastastikku üksteist. Seega – selle asemel et radikaalid rahuneksid, annab internet neile ohtralt võimalusi end veel rohkem üles kütta.

Kui luusida ringi vandenõuteoreetikute, usuhullude või äärmuspoliitikute foorumites, paneb imestama, kust sellised inimesed tulevad. Sotsiaalne grupeerumine hakkab toimima hoopis teisi dimensioone mööda – samas majas elamine muutub oluliselt vähem tähtsaks kui see, et me käime samas foorumis.

Mul pole õrna aimugi, kas see on hea või halb ja mis mõõdupuuga seda peaks mõõtma, aga see on vältimatu ja sellele ei saa kuidagi kätt ette panna. Ühed struktuurid asenduvad teistega ja uued struktuurid on mitmes mõttes teistsugused, seal on oluliselt kitsam spetsialiseerumine, on oluliselt vähem sotsiaalset kontrolli, kas või radikaalide korralekutsumiseks. On muidugi ka positiivseid näiteid, kas või see, et inimesed „tulevad kokku” ja kirjutavad Wikipediat vms, mis on võimalik ainult tänu internetile.

— Euroopa Komisjoni tellitud uuringu järgi ei ole eurooplased nõus interneti sisu eest maksma, osa neist ka siis mitte, kui tasuta kvaliteetinternetti polekski.

— Kui palju neid ikka on, kes toodavad internetisisu raha teenimiseks? On tuhandeid inimesi, kes kirjutavad blogisid, mis on väga huvitavad ja sisukad ja sugugi mitte halvemad kui New York Timesis või Economistis ilmuvad artiklid. Sellepärast, et neil on sisemine tung seda teha.

Samamoodi võime rääkida muusikast. Suured muusikafirmad võitlevad hambad ristis internetipiraatlusega. Aga on selles midagi hullu, kui need suured firmad peaksid ära kaduma ja selle asemel oleks meil miljon korda rohkem võimalusi sõltumatute muusikategijate loominguga tutvuda?

Kultuuriski toimub tohutu killustumine. Selle asemel et meil oleks viis suurt valikut, on meil 5000 mikroskoopilist valikut.

— Aga kes võidab piraatide ja intellektuaalse omandi kaitsjate sõja?

— Ma arvan, et tehnoloogiliselt ei ole piraatlus põhimõtteliselt kontrollitav. Needsamad suured muusikafirmad ei ole peaaegu mingit edu saavutanud. Tõenäoliselt ei ole võimalik midagi teha. Meie moraalne seisukoht ei puutu seejuures asjasse.

Maailmas ei ole sellist jõudu, mis suudaks peatada info leviku. Täpselt samuti nagu tehnoloogilise arengu ja uute sotsiaalsete väärtuste tekkimise.

3 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

Jul 23 2008

Puugid puuri!

bug.jpg

Paljud lugejad mäletavad ehk 1990. aastate esimest poolt, kus iga endast lugupidav eestlane oma isikliku panga asutas. Mingil hetkel avastasid pankurid aga, et lihtsalt kilekottidega sularaha ühest kohast teise tarimisest ei piisa, ja algas buum Eesti IT-maastikul. Tarkvarafirma Joostes Marss oli tol vanal heal ajal loomisjärgus ning tegi suuremaid ja väiksemaid projekte Ahja Kommertspangale.

phone_rage.jpg

Tihti lõppesid Ahja Kommertspanga IT-juhi Ilmari ja Joostes Marsi projektijuhi Joosepi vahelised vestlused aga mõlemapoolse ärritusega. Tüüpiline telefonikõne oli näiteks järgmine:
Ilmar: Kas bugid on ära parandatud?
Joosep: Mis bugid?
Ilmar: Need, millest ma kuu aega tagasi telefonis rääkisin!!
Joosep programmeerija Priidule: On ära parandatud või?
Priit: Midagi ma vist parandasin jah…
Joosep Ilmarile: Jah, on küll parandatud.
Ilmar: Millal kätte saab?
Joosep: Homme saadame.

Mõned päevad hiljem:
Ilmar: No aga ikka ei ole ju kõik ära parandatud!?!
Joosep: Mis siis veel?
Ilmar kirjeldab.
Joosep Priidule: Mis värk sellega on?
Priit: Aa, selle ma unustasin.
Joosep Ilmarile: Teisipäevaks saadame uue!

Kolmapäeval: 
Ilmar: Aga IKKA ei ole ju kõiki asju!!
Joosep: Aga see polegi bug, see on feature.
Ilmar hakkab karjuma, et tema on klient ja tema otsustab, mis on feature ja mis mitte.

Lõppkokkuvõttes võttis projekt kahe kuu asemel kaheksa, Priit logeles enamiku päevi niisama ja tegi vahele meeleheitlikke spurte, et probleeme kontrolli alla saada, kui Ilmarilt järjekordne kõne tuli. Ebaregulaarse rütmi tõttu läks ta tüdruksõbraga tülli ja kirjutas koodi sisse Ilmari aadressil ebatsensuurseid kommentaare.

 bugjail.jpg

Milles asi? Nagu ühes eelnevas, projektijuhtimisele pühendet jutus mainitud, on projekti õnnestumise tagamisel peamine osa korralikul kommunikatsioonil. Arvatavasti kõige olulisem asi, mida projekti käigus tuleb kirja panna ja millest kõik osalised peavad ülevaadet omama, on see, kui palju ja milliseid vigu (ehk buge või puuke) meil parajasti koodist on leitud.

Vigade andmebaasi pidamine on tegelikult väga lihtne asi, selleks on loodud suurel hulgal nii vabu kui kommertsprodukte, enamasti on puuduliku veahalduse põhjused suhtumises.

informationoverload.jpg

Vahel tuuakse vastuväiteks näiteks, et oh, me suudame niisama ka oma vigu meeles pidada. Absurdne. Ma pole veel näinud ühtki inimest, kes suudaks korraga meeles pidada rohkem kui kolme vea üksikasju. Võib ju ka öelda, et me parandame vead kohe nende ilmnemisel ära, aga seegi ei tööta, sest parandamine võtab vahel paratamatult kauem aega, kui meil hetkel käepärast on.

Tegelikult olen ma leidnud, et isegi väikeste projektide puhul, millega ma vahel ise oma lõbuks tegelen (ehk siis 1 inimene, 1000-25 000 rida koodi), on väga kasulik vead kohe avastamisel kirja panna (kui tegemist pole just asjaga, mis sama päeva jooksul valmis saab), sest hiljem on suur osa vajalikust kontekstuaalsest teadmisest  kadunud.

Igas veakirjelduses peavad kindlasti olemas olema järgmised komponendid:

  • Täielik info, kuidas viga reprodutseerida
  • Soovitud tulemus programmi käivitamisel
  • Tegelik tulemus
  • Kellele viga on omistatud (mitte ei eelda kõik inimesed, et keegi teine asja korda teeb)
  • Vea staatus (aktiivne, parandatud, kontrollitud/suletud)

Peale selle kasutavad erinevad organisatsioonid veel mitmeid väljasid, nagu

  • Tõsidus (oluline vahe, kas programm crashib või on mõni ikoon pikseli võrra paigast ära)
  • Prioriteet (erineb tõsidusest, vahel on avalehel oleva ikooni pikselid olulisemad kui kord 10 aasta jooksul juhtuv crash)
  • Vea parandamiseks kuluv hinnanguline aeg
  • Parandamise tähtaeg (kui meil on tegemist vahepealsete verstapostidega)
  • jne.

Kui vigade andmebaasi 100% kasutatakse, siis nende andmete põhjal saab projektijuht teha juba väga võimsaid päringuid, kui palju tööd on veel jäänud, kas programmeerijad jaksavad testijatega sammu pidada, milline on produkti üldine kvaliteet (s.t kas leitakse tõsisemaid või vähemtõsisemaid probleeme) jne. Samas ei tohi lisaväljadega üle pingutada, sest siis ei viitsi keegi neid enam täita. Ülaltoodud 5 välja on aga esmase tähtsusega. Kui vigade registreerimine muutub nii vaevanõudvaks, et inimesed seda enam ei tee, tuleb meil oma protsess alati optimiseerida sellele, et 100% vigadest saaks kirja pandud.

 insult.gif

Esineb ka psühholoogilist laadi vastuväiteid, näiteks võtavad mõned programmeerijad nende koodist vigade leidmist isiklikult ja peavad selle kirjapanemist veel eriti solvavaks. Ütle mulle lihtsalt, mis värk on, ja ma parandan asja ära, pole vaja midagi kirja panna, urisevad nad testijale. Siin saame teha kaks olulist tähelepanekut:

  • Kas on parem, et vea leiab meie testija või klient? Testija peaks olema programmeerija parim sõber ja programmeerija peaks teda igal viisil julgustama, et ta rohkem vigu saaks leida, sest sel viisil päästab testija programmeerija piinlikkusest, mis leiab aset, kui hoopis klient või mõni muu tähtis tegelane vea avastab ja programmeerijal tulekahju kustutamiseks ületunde tuleb teha.
  • Programmeerija produktiivsust ei tohi hinnata lihtsalt vigade arvu põhjal, sest see loob initsiatiivi mitmesuguseks sohitegemiseks ja lõpuks oleme lõhkise küna ees: vigade andmebaas valetab ja ka produktiivsust hindame ilmselt valesti.

Lisaks on vigade andmebaasil mitmeid sekundaarseid väärtusi, näiteks langeb ära vaidlus teemal, kas mingi asi on bug või feature, sest kõik on ilusasti kirja pandud ja kohe vea registreerimisel saab arutada, kas asjad peavad nii olema või ei.

Kokkuvõtteks võib öelda, et võrreldes projektiga, kus projektijuhtimisvahendid täielikult puuduvad, on vigade andmebaas ilmselt esimene asi, millest alustada, sest see annab lihtsa vaevaga kõige suuremat kasu. Lisalugemist muidu Joelilt.

No responses yet

Jun 06 2008

Eduka projekti retsept

Published by Targo under Projektijuhtimine, Põhialused

ingredients.jpg

Enamikule tarkvaraga kokku puutunud inimestele pole vist üllatuseks, et suur osa tarkvaraprojektidest lõpeb kas osalise või täieliku ebaõnnestumisega.

Samas ei ole projekti edukuse tagamine mingi must maagia, on loodud mitmeid metoodikaid, mis kohusetundliku projektijuhi kätes enamiku tavalistest riskidest korralikult ära maandavad ja edu tõenäosuse kolme-neljakümnelt protsendilt üheksakümne viieni tõstavad (muuseas, kui sa töötad firmas, mis teeb projekte alltöövõtu korras teistele organisatsioonidele, siis töö enamvähem edukas üleandmine ei tähenda veel projekti õnnestumist või seda, et tellija sinu juurde uuesti tagasi tuleb!). Häda on ainult selles, et enamik projektijuhtidest ei oma tegelikult spetsiifilisi projektijuhtimise alaseid teadmisi või siis on nendest kuulnud, aga ei oska või viitsi neid korralikult rakendada.

Allpool on toodud üks võimalik nimekiri eduka projekti koostisosadest, kasutatav mitte ainult tarkvara-, vaid ka igasuguste muude projektide puhul.

vision.jpg

  • Projekt peab olema osa laiemast visioonist, strateegiast või eesmärgist.

Kui projekt ei haaku organisatsiooni mingi laiema eesmärgiga, on ta enamasti ka raskesti piiritletav, valgub esialgsetest raamidest kergesti välja ning väljub kontrolli alt. Samuti on sellistel projektidel palju raskem saavutada juhtkonna huvi ja toetust. Eriti halb on muidugi olukord, kus organisatsioonil polegi mingit visiooni, sel juhul võib garanteerida, et ka projektidest ei saa enamasti asja.

IT-projektidel on siin spetsiifiline oht: kuna infotehnoloogiaga on põnev ka asjana iseeneses tegeleda, alustavad tehnoloogid “rohujuure tasandilt” tihtilugu mingeid oma projekte, mis vahel sobivad organisatsiooni üldkavaga, vahel aga mitte. Enamasti sellised “asjana iseeneses” projektid hääbuvad, kui esialgsetel tegijatel entusiasm otsa saab, sest projekti taga pole organisatsiooni jõudu.

irontriangle.jpg

  • Ressursid, ajakava ja tarnitavad omadused (featured) peavad olema tähtsuse järjekorda seatud ja seda järjekorda tuleb kogu projekti vältel ohjata.

Ja kui siis Jänes veel küsis, mida külaline leiva peale sooviks, kas mett või kondenspiima, oli Puhhi erutus juba nii suureks kasvanud, et ta vastas: “Mõlemat!”

Kõik on ilmselt kuulnud trilemmast: kiire, odav, hea, vali üks (heal juhul kaks), sellegipoolest tahavad projektide tellijad Puhhi kombel kõike korraga saada. On äärmiselt oluline, et meil oleks selge pilt, milline nendest kolmest küljest on kõige olulisem, et me teaks, mida hädaolukorras ohverdada. Samamoodi peab olema selge, milline on näiteks erinevate featurete omavaheline prioriteedijärjekord, mitte ei ole nii, et kõik asjad on kõige tähtsamad.

sponsor.gif

  • Projektil peab algusest peale olema sponsor ja seda sponsorlust tuleb hoida kogu projekti jooksul.

Sponsoriks on enamasti keegi juhtkonnast (alltöövõtu puhul siis tellija juhtkonnast), kellel on voli projekti jaoks raha ja muid resursse eraldada ning muul viisil toetust avaldada. Tihti juhtub aga, et kui esialgne raha on käes, unustatakse sponsor ära, temaga ei konsulteerita enam ja kui ta kuus kuud hiljem leiab, et ei-ei, see polnud üldse see, mida ma alguses mõtlesin, lõppeb nii mõnigi projekt enneaegse katkestamisega.

stakeholders.jpg

  • Koguda peamiste huvituvate osapoolte nõuanded ja toetus ja seda terve projekti jooksul alal hoida.

Huvituvateks osapoolteks on juba mainitud sponsor, projekti läbiviijad, juurutajad, lõppkasutajad jne. Selleks, et projekt saaks olla edukas, peab igaüks neist asjaga rahul olema. Kui lõppsaadus näiteks kasutajatele ei meeldi, on kogu vaev asjata, keegi ei hakka seda kasutama, sellepärast on ka kriitilise tähtsusega, et iga osaline saaks igas projektifaasis sõna sekka öelda.

scope_creep.jpg

  • Projekti ulatus (skoop) on selgelt piiritletud.

Olen ise näinud suurel hulgal projekte, millele muudkui lisatakse ja lisatakse uusi omadusi, kuni kõik lõpuks kraavi läheb ja tegijad on lõhkise küna ees. Üks võimalus selle vältimiseks on projekti alguses dokumenteerida mitte ainult see, mida on plaanis teha, vaid ka seonduvad omadused, mida ei ole plaanis teha, et kellelgi ei tekiks hiljem kaksipidi mõistmist.

resources.jpg

  • Ajakava ning ressurssid on selgelt paika pandud ja osaliste poolte heaks kiidetud.

Usalda, aga kontrolli (ja pane kirja) :) . Väga vajalik selleks, et kellelgi ei tekiks hiljem “valikulist amneesiat” ja hilisemaid vaidlusi “aga mina eeldasin, et A, B ja C on augustiks valmis”.

plan.jpg

  • Projektil peab olema plaan.

Plaani täpne olemus sõltub projektist, aga sealt peaksid kindlasti näha olema projekti etapid, vahetähtajad, osalised, kes mingi etapi või komponendi eest vastutab jne. Tihti jäetakse sellised asjad kirja panemata ja siis selgub jällegi mõne kriitilise osa kohta, et kõik eeldasid, et keegi teine teeb selle ära.

wine.jpg

  • Nõutav kvaliteet peab olema defineeritud ja projekti vältel ohjatud.

Veel üks teema, kus tarkvara on keerulisem kui enamik muid valdkondi. Põhimõtteliselt on tarkvaras võimalik leida peaaegu lõputult vigu ja võimalusi selle parandamiseks, alates sellest, et kasutajaliideses võiks mõnda jubinat pikseli võrra vasakule nihutada, et see esteetiliselt meeldivam oleks, kuni koodikirjutamisstiili ühtlustamiseni. Projekte, kus enam millegi kallal norida ei oleks, pole olemas, ning suur osa sellistest “vigadest” jääb parandamata (andes muuhulgas alust legendidele Windows 2000 65000st veast jne). Igasuguste vigade tõsidus on suuresti vaataja silmades ja sellepärast ongi tähtis, et näiteks tellija ja teostaja asjast samamoodi aru saaksid.

Asja teine pool on seotud tarkvara põhiteoreemiga. Meil peab kindlasti olema selge ülevaade, kui palju ja kui tõsiseid vigu projektis hetkel on, projektigraafikus peab olema eraldatud spetsiaalne aeg nende vigade parandamiseks ning meil peavad olema defineeritud vahetähtajad, mil kontrollitakse kvaliteedi vastavust projektis nõutavale.

responsibility.jpg

  • Rollid ja vastutusalad peavad olema selged ja dokumenteeritud.

Üks hea võimalus seda teha on koostada maatriks, kus ühel teljel on osad projekti plaanist, teisel aga osalised (arendajad, projektijuht, kasutajad jne). Igasse lahtrisse teeme märke, mis on vastava osalise roll antud aspekti puhul. Võimalikud rollid on näiteks “vastutaja”, “teostaja” (tihti erinev vastutajast), “konsulteeritav” (ehk me peame vastavalt isikult nõu küsima enne kui midagi teha) ja “informeeritav” (et keegi ei unustaks mõnd tähtsat osalist teavitamast). Kui tabel läheb liiga suureks, paneme teatud valdkonna lahtrid kokku, kirjutame sinna ainult vastutaja nime ning delegeerime alamtabeli koostamise juba tollele vastutajale.

change.jpg

  • Eksisteerib muudatuste tegemise protsess, millega kõik nõus on ja mida nad ka kasutavad.

Tihedalt seotud skoobiprobleemiga. See on jällegi asi, mis tarkvaraprojekte iseäranis kollitab. Kui majale ekstra korruse lisamine on kõigile nähtav ja inimesed saavad kohe vastu vaielda, siis tarkvarale millegi lisamist võetakse tihti palju kergema südamega. Samas tingib tarkvara olemus selle, et muudatus ühes komponendis võib vahel põhjustada ettearvamatuid tagajärgi ja suuri probleeme hoopis teises komponendis.

Oluline! Ülaltoodu ei tähenda, et me keelame igasuguste muudatuste tegemise ära ja kliendile iga asja peale lihtsalt “ei” ütleme, sest siis võime projekti küll valmis saada, aga see jääb meile viimaseks selle kliendiga tehtud projektiks. Samuti on muidugi muudatusi, mida programmeerija lihtsalt omapäi võib teha, aga mõlemal juhul peab olema kokku lepitud, millised asjad vajavad kelle heakskiitu.

risk.jpg

  • Nii projekti alguses kui ka selle kestel uuritakse, millised on projekti ohustavad riskid ning valmistutakse nendeks.

Riske on mitmesuguseid ja nad on tihti seotud erinevate eeldustega. Kuna tarkvara alal toimub kogu aeg kiire tehnoloogiline areng, on siin palju rohkem tundmatus kohas vettehüppamist ja seega ka rohkem riske projektile.

Tarkvaraspetsiifilised riskid on näiteks uue tehnoloogia kasutamise risk, milleks saab valmistuda varase prototüüpimisega või võimalusega kasutada varuvariandina alternatiivset tehnoloogiat, või asendamatute inimeste sündroom (programmeerijad on enamasti unikaalsemate teadmistega kui näiteks ehitajad), mida saab vältida regulaarsete koodiülevaatuste abil. Nendest mõlemast teen kunagi ehk pikemalt juttu.

communication.gif

  • On olemas kommunikatsiooniplaan, mida ka täidetakse.

Kommunikatsiooniplaani tegemine on nii lihtne, et on üsna kurb, kui vähe seda kasutatakse. Projektijuht teeb lihtsalt tabeli, kuhu ühte veergu kirjutab kõik olulised asjaosalised ja teise kommunikatsiooniaja ning -viisi. Näiteks: sponsor, saata emailiga ülevaade iga 2 nädala tagant. Arendajate juht, koosolek igal teisipäeval. Tellija esindaja, helistada esmaspäeviti ja neljapäeviti. Jne.

Sellisel viisil ei unune keegi ära ja ei teki situatsiooni, kus mitme kuu järel järsku teatatakse, et asjad ei kõlba kusagile ja tuleb ringi teha.

mistake.jpg

  • Õpitakse vigadest.

Üks lihtne viis vigadest õppimiseks on iga vahetähtaja järel korraldada koosolek kõigi peamiste osalistega, kus arutatakse, mis läks hästi, mis halvasti. Selle “lahkamise” tulemuste põhjal tuleb muidugi teha ka vastavad muudatused, olgu siis järgmise etapi ajakavas, kommunikatsiooniplaanis või mõnes muus aspektis.

Kokkuvõtteks: üheski ülaltoodud punktidest pole midagi keerulist ja nende kohta võib lähemat teavet leida pea igast projektijuhtimise õpikust. Iga projektijuht saab küllaltki lihtsa vaevaga oma projekti ebaõnnestumitõenäosust mitmekordselt vähendada.

Huvitav on veel tähele panna, et projektijuhtimise seisukohalt pole erilist vahet, millist tarkvarametodoloogiat me kasutame. Ükskõik, kas me kasutame ekstreemprogrammeerimist või formaalseid meetodeid, aabitsatõed jäävad ikka samaks.

No responses yet

Feb 25 2008

Programmeerija produktiivsus

Published by Targo under Programmeerijad, Põhialused

productivity.jpg 

- Mis on programmeerija produktiivsus?

Paljud tarkvaraprojektide eest vastutavad inimesed vaatlevad programmeerijat kui masinat, kuhu ühest otsast lähevad sisse raha ja kofeiin ja välja tuleb programmikood, umbes nagu joogiautomaat: paned raha sisse ja vajutad nuppu ning tulemus ongi käes.

vending.jpg

Puutudes kokku olukorraga, kus üks programmeerija või programmeerijate meeskond saavutab paremaid tulemusi kui teine, piirdubki enamik otsustajatest nende parameetrite timmimisega. Programmeerijat proovitakse ära osta, pakutakse talle nii palju tasuta kohvijooke, kui süda kannab, ning nõutakse selle eest iga päev tuhandet uut koodirida.
Selline lähenemine on muidugi vigane nii sisendi kui ka väljundi osas. Koodiridade hulk on küllaltki halb mõõdik, samamoodi nagu seda on tehtud vigade arv jms statistilised näitajad. Millised on paremad mõõdikud, sellest teine kord, praegu keskendume eelkõige sisendi poolele.

- Miks produktiivsuse üle muretseda? 

Teine tüüpviga on enamasti programmeerija produktiivsuse tähtsuse tohutu alahindamine. Õmbleja või müürsepa poolt tehtud töö hulk kõigub ehk paar korda ja tihti vaadeldakse programmeerijat samamoodi. Ahah, lõpetasid sama kooli? OK, paneme su sama palgataseme peale samu asju tegema. 
Tegelikult võib üks programmeerija ideaalolukorras produtseerida 100 või rohkem korda toodangut kui teine ning ilmselgelt peaks iga projekti eest vastutaja tähtsamate murede seas (tarkvaratootmise põhiteoreemi kõrval) olema produktiivsuse tõstmine. Millised komponendid produktiivsust mõjutavad, katsume allpool lahti kirjutada.

1. Motivatsioon

 maslow.gif

“Don’t work for a living, work for a reason” ütles Microsofti värbamissait, kui ma nendega liitumist plaanisin. Ja tõepoolest, Microsofti kultuur on täielikult läbi imbunud ideest, et me teeme midagi vägevat, mida miljonid inimesed kasutavad, ja oleme turuliidrid. Erinevatel firmadel on muidugi erinevad motivaatorid, mida selle koha peal välja pakkuda, kuid sellised ideed on tihti asjaolu, mis inimesi pärast kella viite tööl hoiab või laupäeval kontorist läbi astuma kutsub. Kui mul on valida, kas vaadata telekat või tegeleda projektiga, saab kaalukeeleks asjaolu, kas see projekt on miski, mis rahuldab minu kõrgemaid vajadusi Maslow hierarhias (eeldusel, et kõik programmeerijad saavad tänapäeval piisavalt raha, et esmased vajadused on rahuldatud). Näideteks neist hüvedest võivad olla teiste inimeste respekt, võimalus rakendada loovust, saavutuse tunne, huvitavate probleemide lahendamine, tähtsustunne vms.
Ma arvan, et kõigi muude asjaolude võrduse korral on hästi motiveeritud, innuka töötaja ja sunnitud, jalgu järel vedava töötaja produktiivsuse vahe kuni 3x.

2. Vahendid

handsaw.jpg chainsaw.jpg 

Vahendite all pean ma silmas nii riistvara kui ka tarkvara, kusjuures mõlema kategooria alla kuulub ehk rohkem asju, kui inimesed tavaliselt mõtlevad. Näiteks on monitori suurus produktiivsuse seisukohalt enamasti olulisem kui protessori kiirus, tarkvara alla ei kuulu mitte ainult kompilaator/debugger, vaid ka hulk muid vidinaid profileerijatest source controlini jne.
Valede/kehvade vahendite valik on vahel põhjustatud kliendi veidratest soovidest, vahel teadmatusest, vahel ihnsusest. Olen ise kogenud variante kõigist, igal korral katastroofiliste tagajärgedega, halvimal juhul neist kulus teatud ülesannete sooritamiseks julgelt terve kuu, kui korralike vahenditega oleks läinud loetud päevad.

3. Keskkond

sweatshop.jpg

Kas programmeerijatel on olemas koht, kus nad saavad ukse kinni tõmmata ja segamatult oma tööle keskenduda, eemal mürast, tuuletõmbest ja kõrvalruume rentiva pontsikubaari aroomist? Või on fooniks telefonide pidev helin, inimeste sisse-välja traavimine, bossi õiendamine sekretäri kallal ja kõrvallauas anekdoote rääkiv kolleeg? Kõrge produktiivsuse tsooni jõudmine võtab vaimset pingutust nõudva töö puhul vähemalt 15 minutit ning iga segaja puhul tuleb nullist alustada. Suur segajate arv päeva jooksul kahandab kõrge produktiivsusega aega mitu korda.

4. Teadmised

knowledge.jpg

Programmeerimine on asjana iseeneses põnev tegevus, inimene loob eimillestki midagi, mis on väga rahuldustpakkuv kogemus. Sellepärast ongi ehk maailmas rohkem programmeerijaid, kes ka hobi korras oma erialaga tegelevad, võrreldes näiteks juuksuritega.
Teiselt poolt on tegemist väga laia ning kiireltareneva valdkonnaga, kus on samas võimalik peaaegu igat probleemi paljudel erinevatel viisidel lahendada.
Seega pole olemas mingit konkreetset teadmiste kogu, mille inimene koolist kaasa saaks ja oleks “valmis programmeerija”, valdav enamik inimeste teadmistest pärineb lihtsalt niisama asjade kallal nikerdamisest ja nende vastu huvi tundmisest. Programmeerijat tööle võttes küsin ma talt alati näidet sellest, mida ta on lihsalt niisama oma lõbuks valmis teinud või milliseid probleeme lahendanud. Inimestel, kellel on harjumuseks tarkvaraga ka hobi korras tegeleda, on üldjuhul tohutult laialdasemad teadmised kui teistel. Kas ja millal neid teadmisi vaja läheb, on juhuse küsimus, aga kriitilisel hetkel võib leidlik lahendus hoida kokku mitmeid päevi “jõumeetodil” lahendamisele kulunud aega.
Sama kehtib ka akadeemiliste teadmiste kohta: andmebaaside loengut kuulates võib ju küll mõelda, et millal mul seda algrebrat vaja läheb, aga olles vastamisi keerulise päringuoptimiseerimisülesandega, on mul tihti hea meel olnud, et koolikogemus aitab mul mõista, mis andmebaasimootori sees tegelikult toimub.

Üldise tähelepanekuna paistavad kõige produktiivsemad ja mõjukamad inimesed projektis alati silma laialdase teadmistepagasiga, mis on suhteliselt lõdvas sõltuvuses lõpetatud koolide arvust või akadeemilise kraadi kangusest.

5. Projekti läbipaistvus

glass.jpg

Kui programmeerija ei tea, mida klient tegelikult tahab, kui analüütik ei  tea, mida programmeerija parajasti teeb, ja bossi peal kasutatakse Jedivõtteid stiilis “these aren’t the droids you’re looking for”, pole midagi imestada, kui asjad venivad ja venivad, aga midagi valmis ei saa. Korralik projektijuhtimine garanteerib muuhulgas:
- spetsifikatsiooni, millest nii klient kui ka programmeerija samamoodi aru saavad
- source trackingu, mille põhjal igaüks saab vaadata, kui palju koodi on kirjutatud ja mida see teeb
- vigade andmebaasi, kust on võimalik igal hetkel vaadata, kas produkt on heas või halvas seisus
- muutuste kontrolli, kus koodimuutused üle vaadatakse, et vältida projekti isevoolu teed minekut
- põhifunktsionaalsuse pideva (soovitatavalt automaatse) testimise, mille pealt on alati võimalik vaadata, kas asi tegelikult töötab või ei.

Need asjad aitavad igal osalisel mõista oma rolli projekti üldises olekus ning võtta vastu optimaalseid otsuseid selles osas, mida parajasti on vaja teha (nt kas on praegu hea uut funktsionaalsust luua või hoopis vanad vead ära parandada, mida kuu aega hiljem juba palju raskem teha on).

6. Otsustusvabadus

freedom.jpg

Tänapäeva sõjavägedes ei pääse samuti tarkvarast üle ega ümber ja nii mõnigi mundrikandja väänab samas ka koodi. Samas pole tulemused enamasti just kiita. Ma arvan, et probleem on suuresti sõjaväe hierarhilises, vastuvaidlematus ülesehituses. Kui seersant Sigajenko ikka ütleb, et siia paned goto, siis hoiad suu kinni ja paned.

Enamik programmeerijaist õnneks mundrit kandma ei pea, aga tundub, et nii mõndagi firmat juhitakse sarnastel alustel. Programmeerija on siiski see, kes asja tehnilisest küljest kõige rohkem teab, ja nii mõnigi projekt on kihva keeratud sellega, et asjatundmatu juhtkond sunnib tehnilisi töötajaid ebaoptimaalsetele radadele. Leian, et inimene, kes tegelikult koodi valmis kirjutab, peab omama otsustusvabadust vahendite, tehnilise disaini ja muude sarnaste küsimuste osas. Kui projekti kallal töötab palju inimesi, on neil muidugi vaja ühte jalga käia, kuid ka siis peavad otsustajad olema programmeerijate endi esindajad. Kokkuhoitud aeg kaalub kindlasti üles mittetehnilise juhtkonna või tellija võimunäitamisvõimalused, inimeste moraali hoidmisest rääkimata.

7. Kogemused

Last but not least, eelmiste projektidega saavutatud kogemused on alati kulla hinda väärt. Infotehnoloogia on tohutult kiiresti muutuv valdkond ja projekti tegemise ajal õppimine on pigem reegel kui erand. Seda enam väärtustuvad juhused, kus eelmises projektis õpitut on võimalik uuesti kasutada, või veelgi parem, on olemas näiteks üldotstarbeline klassiteek, mida uuele projektile sujuvalt üle saab kanda.

Kogemused võivad olla mitut laadi, vahel on nad kogenud programmeerija peas, kes uutele inimestele oma nõuga palju päevi jalgratta leiutamist kokku võib hoida, vahel kristalliseerunud olemasoleva koodi näol. Oluline on selle kogemuse loomine ja säilitamine. Kui vana programmeerija uuele bossile ei meeldi ja lahti lastakse, või kui keegi leiab, et nüüd liigub kõik see mees uuele tehnoloogiale ning vana koodi viskame minema, on tagajärjeks üldjuhul paljude, paljude inimkuude kaotus.

Kokkuvõtteks, programmeerija produktiivsus sõltub paljudest faktoritest, lisaks ülaltoodutele on veel mitmeid teisigi. Edukad on üldjuhul ettevõtted, kes suudavad võimalikult paljud nupud õigesse asendisse pöörata ning hiljem imestavad nad isegi, et mis küll naabermaja inimestel viga on, et nad ka kümme korda rohkema aja ja raha kulutamise järel midagi valmis pole saanud.

No responses yet

Next »