Feb 25 2008
Programmeerija produktiivsus
- 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.
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
“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
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
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
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
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
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.
