Archive for the 'Lugejate lemmikud' Category

Sep 17 2008

10 aastat Vana Programmeerijat

programmer.jpg 

Umbes kümme aastat tagasi oli mul kord kõrge palavik, mis takistas kooli või tööle minekut. Arvuti taha suutsin end siiki vedada ja kirjutasin teatava Kivirähu teksti põhjal üles Vana Programmeerija loo.

Kümne aasta juubeli puhul panin ta siia taas kirja. Nendele, kel huvi asja võõramaalastega jagada, tõlkisin selle millalgi ka inglise keelde.

Vana Programmeerija

Öösel toodi firmasse uus mees.
“Said su siis nõusse,” ütles üks programmeerija kaastundlikult. “Küllap jootsid su täis, nii nagu meid kõiki. Kes siis kaine peaga sellisesse firmasse tuleb!”
“Kas tead, kuhu kadus too mees, kelle asemele sind värvati?” küsis teine kaastöötaja. “Projektijuht lõi ta maha. Lihtsalt lõi maha ja kõik. Palju mehi on tema rusika läbi oma otsa leidnud.”
“Nii ongi õige!” ütles uus mees rahulikult. “Kus seda enne nähtud, et firmas ei tapeta! Mina olen vana häkker, olen kõik operatsioonisüsteemid ise läbi testinud ning iga kord on taplemist olnud. Vat vanasti, siis olid ikka mehed! Igaüks käis majas ringi, juhtmeots käes, ja kui sai, siis laskis voolu! Mina ainsana jäin hinge, lõpetasin edukalt projekti ja kauplesin end uude kohta. Jah, mina tunnen tarkvara tegemise kombeid!”
Ja ta ronis magamiskotti ning jäi norinal magama.
Hommikul tundis projektijuht uue mehe vastu huvi.
“Kus ta on?” küsis ta analüütikult. “Tutvustan talle meie firma tavasid.”
Analüütik läks näost punaseks ja lõi silmad maha.
“Kuidas nüüd öelda… Istub jututoas… Ma küll ütlesin, aga…”
“Mis!” röögatas projektijuht. “Laiskleb! Kas ta peab meie firmat laatsaretiks või! Tuhat nullpointerit! Näita, kus ta on!”
Programmeerija vedeles tõesti jututoas ning haigutas aeg-ajalt magusalt.
Projektijuhti nähes ta naeratas unelevalt.
“Mõtlesin just sellest ajast, mil ma veel noor olin,” ütles ta. “Siis olid mehed selgest rauast. Mina isegi olen ju teab kui mitu korda haljast assemblerist bugisid rookinud. Ükskord juhtus sihuke ette, et hoia ja keela! Kolm korda tuli ringi kompileerida. Aga ma talle andsin!”
“Mida!” käratas projektijuht. “Sa veel seletad, lurjus!”
“Nonoh!”, ütles mees pahaselt. “Hoia oma pudrumulk vaos, kui sa häkkeriga kõneled. Ega ma oma juttu lõpetanud pole. Teinekord tuli andmebaasimootorit parandada – t erve kollektiiv läks selle pärast peast segi, aga siis leidis terav kirves kivi! “Noh, roju!” ütlesin ma talle. “Nüüd ma su jahvatan!” See oli ka üks kodeerimine, mida tänaseni meenutatakse.”
Projektijuht kuulas ja läks raevust kollaseks.
“Kas sa tead, kellega sa praegu räägid!” kisendas ta. “Sa räägid projektijuhi endaga!”
“Mis projektijuht sina oled!” lõi vana programmeerija käega. “Selliseid projektijuhte on ennegi nähtud. Vaata vanasti, siis olid projektijuhid. Silmad olid teistel punnis, käisid trampides mööda koridori ja vandusid nii , et kõik masinad käigu pealt GPF-i andsid. Sinusuguseid keskkoolihäkkereid ei lastud uksest sissegi, nad tõid õnnetust kaasa. Mine parem oma tuppa ja küll mina siin asjad korda sean. Mina tunnen C++’i nagu oma pük se.”
“Nii!” pöördus ta seejärel analüütiku poole. “Mitut CASE-vahendit te kasutate?”
“Ühte,” vastas see hämmeldunult.
Vana programmeerija vangutas pead.
“Kus seda enne nähtud!” ütles ta. “CASE-vahendeid peab olema vähemalt seitse ja diagramme tuleb üle joonistada kaksteist korda päevas. Nii oli vanasti alati. Saada mehed joonistama!”
“Mulle tundub, et…” alustas jahmunud projektijuht, aga vana programmeerija käskis tal pudrumulgu kinni pidada.
Serveri kettaruumi kulutas vana programmeerija rohkem kui kõik ülejäänud kokku ja käskis finantsdirektoril seejärel uut riistvara muretsema minna.
“Nii ei jätku meie rahadest kuigi kauaks,” söandas finantsdirektor poetada.
“Firmas peabki vähe raha olema,” vastas vana programmeerija kindlalt. “Omal ajal, kui ma FreeBSD-ga tegelesin, ei saanud keegi seitse kuud sentigi palka. Mis teie siin ka üldse tarkvarategemisest teate.”
“Mis firma tarkvara kasutatakse?” uuris ta seejärel analüütikult.
“Microsofti,” vastas too.
“See tuleb kohe maha kustutada,” ütles vana häkker. “Kus seda enne nähtud, et Microsofti tarkvara kasutatakse! See toob ju sulaselget õnnetust! Kõik vanad programmeerijad teavad, et Microsoftis pesitsevad kurjad vaimud. Ru ttu tarkvara ketastelt maha! Mul on meeles üks juhtum, kus kah keegi rumal projektijuht Microsofti tarkvara arvutitesse lasi installeerida. Sealt firmast ei pääsenud peale minu keegi eluga, operatsioonisüsteemidest ronisid aga deemonid välja ja käisid öösiti magamiskottidest meeste verd imemas.”
Jubedusega kuulanud töötajad formateerisid kiiresti kõik kõvakettad üle.
“Jeesus Maria!” hüüdis vapustatud projektijuht. “Nüüd meie tähtajad hävivad! Ma lähen hulluks!”
“Tarkvaratootmisel peabki hulluks minema, siin teisiti ei saa,” nõustus vana häkker. “Meil läks omal ajal kogu kollektiiv hulluks.”
“Projektijuht ägas ja pages oma tuppa varju.
Vana programmeerija jalutas mööda ruume ning sattus viimaks süsopi manu.
“Süsteem töötab valesti,” ütles ta pärast hetkelist mõtlemist.
“Mul on siin graafiline abivahend, mis süsteemi jälgimisega tegeleb,” vastas süsop.
Vana häkker vilistas.
“See’p see on!” ütles ta. “Graafiline kasutajaliides! Kus seda enne nähtud on! Kellel oli vanasti graafiline kasutajaliides? Mitte kellelgi! Käsurida on kõik, mis häkkeril vaja läheb. Graafiline kasutajaliides on ainult eksitamiseks mõeldud.”
Ta lükkas süsopi kõrvale, kustutas X-Windowsi ning läks tööst väsinuna uuesti puhkama.
Siis anti teada peatsest voolukatkestusest. Projektijuht, kelle nägu reetis, et tema paar viimast tundi pole olnud kergete killast, väljus oma toast ja käskis tööd salvestada.
“Rumalus!” leidis vana programmeerija. “Las aga olla! Pidage kõik oma pudrumulgud kinni, küll mina juba andmetega hakkama saan!”
Siis tuligi voolukatkestus ja pooleliolevad tööd hävisid.
õhtul pidid Microsofti esindajad, kellega firma koostööd tegi, tulema projekti seisu üle vaatama.
Kuna süsop oma tööd teha ei saanud, ei saadud ka andmeid taastada ning Microsofti esindajad said kurjaks.
“Nüüd me oleme pankrotis,” oigas juhtkond.
“Firma peabki pankrotti minema,” õpetas vana programeerija, kes hetkekski rahu ei kaotanud. “Mis firma see on, mis pankrotti ei lähe?! Nii palju, kui mina olen töötanud, pole ükski firma pankrotistumata jäänud! Omal ajal…”
Aga ta ei jõudnud lõpetada, sest enne seda jõudsid kohale Microsofti juristid, kes ta seal koos teiste töötajatega kinni võtsid ja Bill Gatesi enda ette toimetasid.
Bill istus väärikalt troonil ja kohendas oma kandilisi prille.
“Midagi halba teiega siin ei juhtu,” ütles ta. “Hakkate vaid minu produktide kallal kodeerijateks nagu kõik need, kes enne teid minu valdustesse sattusid. Nüüdsest olete mu sulased!”
Tekkis hetkeline vaikus ja kohe seejärel oli kuulda vana programmeerija häält, kes Wordi patchis.
“Kus seda enne nähtud, et Word PC peal jookseb!” pahandas ta. “Wordi koht on HP peal.”
“Kas see pole mitte see vana programmeerija!” hüüatas Bill selge hirmuga. “Jälle siin!”
“Mina ikka,” vastas häkker. “No miks su prillid küll kandilised on? Need on ju alati olnud ümmargused.”
“Viige ta ruttu tagasi!” karjatas Bill. “Ruttu!”
Ning juristid viisid vana programmeerija minema.
Järgmisel päeval istus ta terminali taga ja mängis muda, kui sisse astusid kaks meest.
“Vajame kogenud programmeerijat!” hõikas üks neist.
“Siin ma olen,” vastas vana programmeerija ja läks meestega kaasa.

5 responses so far

May 22 2008

Assumption is the mother of all f*ck ups

iceberg.jpg

Tarkvarafirma Joostes Marss ostis hiljuti AS HüperKonsultantidelt uue HüperGeneraatori(tm) versiooni. HüperGeneraator on kirjade järgi vahend, mis kirjutab programmeerija eest 97,4% koodist ise valmis, joonistad ainult diagrammi ette, vajutad nuppu ja voilà, rakendus ongi olemas.

Järgmises projektis otsustatigi HüperGeneraator täie hooga tegevusse rakendada. Nagu ikka, tehti pärast esialgset analüüsi valmis projekti graafik. Programmeerijad Priit ja Peeter vaatasid eeldatava mahu üle, lugesid vormid-päringud-moodulid kokku ja leidsid, et kuus kuud tööd tuleb kindlasti ära. Projektijuht Joosep polnud nõus: aga HüperKonsultantide demost oli ju näha, et need vormid, mis varem võtsid päeva, võtavad nüüd ainult pool tundi! Üle kahe kuu ei tohiks kindlasti minna! Priit ja Peeter ei osanud ka suurt midagi vastu kosta, Joosepil on uhkem ametinimetus, eks tema teab paremini.

Tippjuht Tõnis vaatas graafiku üle, imestas küll, et kas tõesti saab nii ruttu, aga eeldas, et küllap projektiga lähemalt seotud inimesed teavad paremini. Samamoodi imestas klient Kustav, aga lõpuks löödi siiski käed.

generator.jpg

Tegelikkuses selgus muidugi näiteks, et

  • HüperGeneraator genereerib koodi ainult positiivse stsenaariumi jaoks, igasuguste vigade käsitlemine tuleb hiljem juurde pookida.
  • Vormide asetusest on HüperGeneraatoril küllaltki fikseeritud arusaam ja kui Kustav leidis, et tema töötajad kõiki vajalikke andmeid korraga ei näe, tuli need ringi teha.
  • Sama päringute kohta.
  • Kui midagi oli juba valmis genereeritud ja sinna seejärel muudatusi tehtud, aga äkitselt oli vaja andmemudelit kohendada, siis uuesti genereerimine hävitas muidugi olemasolevad muutused.
  • jne. jne.

Asi lõppes muidugi sellega, et Priit ja Peeter tegid kõvasti ületunde, Joosep kutsuti mitu korda Tõnise juurde vaibale, Kustav sai omakorda ministeeriumi ülemuste käest pähe jne.

Küsimus, kas koodi genereerimine on üldse mõistlik idee, on eraldi teema (sellest millalgi tulevikus), aga praegu on huvitav tähele panna, millistele eeldustele kõik osalised oma tegevuse rajasid. Igas olukorras jaguneb otsuste alusmaterjal kaheks: info, mis tegelikult teada on, ja asjad, mida me eeldame. Olukorras, kus on tegemist millegi tundmatuga (olgu see siis tehnoloogia, teostaja, partner või klient), on teadaolev info suures vähemuses, jäämäe veealuse osa moodustavad eeldused.

Antud juhul:

  • Kõik osalised eeldasid, et HüperGeneraator on antud projekt jaoks sobiv vahend.
  • Priit ja Peeter eeldasid, et Joosepil on eelnev kogemus taoliste vahenditega.
  • Joosep eeldas, et kui programmeerijad juba uue ajagraafikuga nõus on, siis saavad nad sellega ka kindlasti hakkama.
  • Tõnis eeldas, et projektirühm on kava korralikult läbi mõelnud.
  • Kustav eeldas, et Joostes Marsil on tekkinud uued võimalused projekte senisest kiiremini täide viia.

Üks eeldus viis teiseni ja kui projekt lõpuks kümne kuu pärast (sest liiga agressiivselt planeeritud projektid võtavad vahepealse ümbertegemise tõttu veel rohkem aega) valmis sai, ei jõudnud keegi ära imestada, kuidas asjad küll nii hulluks said minna.

Joostes Marss pole teab mis hiigelfirma, aga isegi seal oli halbadel eeldustel katastroofiline tagajärg. Suurtes, paljude inimestega organisatsioonides on eeldustel kriitiline roll. Töötan praegu Microsofti Office’i divisjonis, mis koosneb kümnetest väiksematest produktidest, igaühel omakorda kümned arendajad. Kõik need produktid on omavahel tihedalt integreeritud, kui näiteks SharePoint lisab uue andmetüübi, peavad inimesed Outlooki, InfoPathi, Accessi, ECMi, Searchi ja mitmetes teistes gruppides, mis SharePointist andmeid oskavad lugeda, mõtlema, kuidas seda kõige paremini toetada. Muidugi katsutakse sama ülesande mitmekordset lahendamist vältida, aga see põhjustab enamasti situatsiooni, kus mitmed tiimid ootavad kellegi järel, et need selle ühise lahenduse valmis teeksid, teised tiimid ootavad jällegi esimeste järel jne. Sellises ahelas on rohkesti võimalusi halbadel eeldustel põhinevate otsuste tegemiseks, olgu siis tegemist tehnoloogia, ajagraafiku, inimeste võimekuse või millegi muu valesti hindamisega. Sellepärast tuleb ka panna suurt rõhku uurimisele, mis meie edu jaoks kriitilistes lõikudes tegelikult toimub ja kuidas asjad töötavad. Olulisel kohal on siinkohal näiteks täpsusküsimise ja täpsusvastamise rakendamine.

Eeldused võib jagada mitmesse kategooriasse, millest igaühe kohta saab enamasti küsida häid, täpseid küsimusi. Vaatleme näiteks HüperKonsultantide reklaamlauset:

HüperGeneraator 5.0 on parim projektide läbiviimiseks! HüperGeneraator suurendab teie koodikirjutamiskiirust sada korda!!!

Juba ainuüksi seda lauset lugedes, ilma tehnilistesse detailidesse süüvimata, peaksime mõtlema järgmistele eeldustele, mis selles reklaamis peituvad:

1. Väärtuse eeldus: koodi kiiresti valmimine on hea. Küsimus: kas koodi kiire valmimine on meie projekti juures tegelikult kõige olulisem?

2. Mõõtmise eeldus: koodi hulka ja valmimiskiirust on võimalik mingi ühe mõõdupuu järgi mõõta. Küsimus: kas me saame koodi kirjutamise kiirust mõõta? Kuidas?

3. Võimalikkuse eeldus: koodi genereerimine on alati võimalik. Küsimus: kas koodi genereerimine on alati võimalik?

4. Sihtgrupi eeldus: HüperGeneraator suurendab konkreetselt meie koodikirjutamiskiirust. Küsimus: kas meie oleme toote õigeks sihtgrupiks? Või on tegemist raamatupidajatele, kes tegelikult programmeerida ei oska, mõeldud abivahendiga?

5. Eksistentsi eeldus: meie probleemiks on, et kood ei saa piisavalt kiiresti valmis. Küsimus: kas koodi kirjutamise kiirus on probleemiks? Või võtab mõni muu tegevus hoopis rohkem aega?

6. Kategooria eeldus: Kõik projektid on sarnased ja HüperGeneraatoriga lahendatavad. Küsimus: kas erinevad projektid on võrreldavad? 

7. Samalaadsuse eeldus: meie projektid on samasugused kui teised. Küsimus: kas meie projekt on samasugune kui teised HüperGeneraatoriga lahendatud projektid?

8. Unikaalsuse eeldus: HüperGeneraator on parim vahend koodivalmimiskiiruse suurendamiseks. Küsimus: kas HüperGeneraator on ainus vahend, mida me kasutada saaksime?

9. Ajalise kestvuse eeldus: ka meie tulevased projektid on HüperGeneraatori abil lahendatavad. Küsimus (juhul kui praegune projekt on tõesti HüperGeneraatori jaoks sobilik):  aga meie järgmine ja ülejärgmine projekt?

Sarnaseid eeldusi võib leida igasugustest situatsioonidest. Tulevad näiteks misjonärid ukse taha ja küsivad: “Kas te usute, et Jumal soovib teile head ja armastab teid kogu südamest?”. Selle kohta võiks kohe mitukümmend eeldust leida, aga jäägu see heale lugejale mõtlemiseks :)

No responses yet

May 14 2008

Programmeerijad ja rähnid

woodpecker.jpg building_collapse.jpg

Kui ehitajad ehitaksid maju samamoodi nagu programeerijad kirjutavad programme, siis esimene rähn hävitaks tsivilisatsiooni. – Murphy seaduste kogust

Leidsin riiulist mingi ehitusinseneridele mõeldud tehnilise taskuraamatu (pole aimugi, kuidas see sinna sai). Muuhulgas on seal palju tabeleid mitmesuguste materjalide omaduste kohta: tellised, teras, vineer, tihedus, kõvadus, tugevus. Arusaadav, et iga korralik insener peab omama ülevaadet, milliste materjalidega ta töötab, mis on nende tugevuspiirid ja muud tehnilised omadused. Seda enam on hämmastav, kui vähesed programmeerijad teavad, millest nad tegelikult oma programme kokku panevad. Rakendusprogrammeerija ei tea, mis toimub klassiteekide sees, mida ta kasutab. Teekide kirjutaja ei tea, mis toimub operatsioonisüsteemis. Süsteemprogrammeerija ei tea, mis toimub riistvaras. Kõige selle juures on imekspandav, et tarkvara üldse vahel töötab ja midagi mõistlikku teeb.

Kiire test: Kui sa oled C# programmeerija, siis kas sa tead, kui suur on mscorlib.dll? Kasutad XMLi? Kui suur on System.Xml.dll? (Java, C++ jne spetsialistid võivad mõelda oma põhiliste klassiteekide ja runtime’ide peale). Ei tea? Tegemist on umbes samasuguse probleemiga, kui ehitaja ei tea, kui palju kaalub tellis, sest iga kord kui keegi vastava rakenduse käima paneb, mõjutab laetud teekide hulk rakenduse mälutarvet ja sellega otseselt programmi jõudlust. Analoogiliselt, kui sa kasutad näiteks mingit stringitöötlusteeki, on hea teada, mis on nende operatsioonide tegelik ajaline keerukus, kui pilditöötlemisteeki, siis millised on selle sisemised andmestruktuurid, et saaks hinnata mäluvajadust jne.

Objekt-orienteeritud programmeerimine on väga hea asi, aga ebasoovitava kõrvalefektina on see veelgi süvendanud olukorda, kus inimesed:

  1. ei tea, mis klassiteegi sees toimub, sest kõik on ilusasti ära peidetud, pakendatud ja kapseldatud
  2. ei oska ilma spetsiaalse teegita ise üldse ühtki probleemi lahendada

Kord saadeti mind asja uurima suure, tähtsa ja rikka kliendi juurde, kes kurtis, et tema veebiserver ei skaleeru. Lasin nende avalehe profileerijast läbi ja leidsin tuhandeid String.Concat väljakutseid. Selgus, et nad panevad suure hulga oma HTMList lihtsalt stringiliitmise teel kokku, mis on C# kasutades muidugi rumal. Tegemist on tüüpilise näitega, kus programmeerija ei tea, kuidas tema vahendid tegelikult töötavad.

Osaks minu tööülesannetest on aeg-ajalt potentsiaalsete töösoovijatega vestlemine (veel enne tegelikku intervjuud/katseid). Küsin sealhulgas nende käest lihtsaid tehnilisi küsimusi, et leida, kas on üldse mõtet edasi vestelda või on tegu mõlemapoolse ajaraiskamisega. Tuleb siis selline tegelane, küsin tema käest, et kui tal on programmis näiteks massiiv punaseid palle ja rohelisi palle, kuidas oleks kõige parem neid sorteerida, nii et punased pallid satuvad algusesse ja rohelised lõppu. Tema selle peale, et teeks ArrayListi ja kasutaks siis selle Sort meetodit. Kas ta teab, kuidas Sort meetod töötab? Ei. Aga kui ta peaks ise sellise meetodi kirjutama? Vaikus. Bzzzzzt, järgmine, palun. Esiteks pole klassiteekides leiduvad üldotstarbelised sorteerimisalgoritmid antud ülesande puhul sugugi optimaalsed, teiseks pole mul midagi peale hakata inimesega, kes arvutiteaduse põhikontseptsioonidega hätta jääb (nagu ehitusinsener, kes füüsikaeksamil põrub). Aja- ning mäluvajaduse keerukusest ei jõudnud muidugi rääkima hakatagi.

 matrix.jpg

Uuri allikteksti, sula ühte koodiga – Linus Torvalds

Inimesed küsivad mult vahel nõu programmeerimisõpikute kohta. Häid õpikuid on palju, aga minu meelest on hea programmeerija parimaks lektüüriks hea kood :) Mitmesuguste andekate inimestega koos töötamise järel olen oma Microsofti-kogemuse juures rõõmus võimaluse üle igasugust huvitavat koodi lugeda, Windows, Office, .Net Framework, kõigis neis on geniaalseid lahendusi, rääkimata asjade mõistmisest tulenevast rahuldusest ja teadmistest, mis võimaldavad mul oma tööd efektiivsemalt teha (ma ei räägi siin mingitest sala-APIdest, vaid lihtsalt algoritmide tasemel mõistmisest). Väljaspool Microsofti on loomulikult samuti tuhandeid võimalusi uurida, kuidas asjad töötavad, olgu siis Open/Shared Source’i maailmas või mujal, ja suureks vaheks hea programmeerija ning tipp-programmeerija vahel on tihti see, kui palju ta igasuguste vidinate uurimisele on aega kulutanud. Kui alliktekstid pole saadaval, uuri jõudluskarakteristikuid, profileeri klassiteeke jne, et aru saada, kuidas asjad töötavad.

Ja hoidu rähnide eest :)

9 responses so far

May 02 2008

Tunne oma kasutajat

Published by Targo under Analüüs, Kliendid, Lugejate lemmikud

customer_service.jpg

Eelmises kirjutises tuli juttu oma kasutajate mõistmise tähtsusest. Leidsin vahepeal veel rea lugusid sellest, kuidas erinevad firmad on kasutaja tundmaõppimist tõsiselt võtnud ning seeläbi huvitavaid ja innovatiivseid lahendusi tootnud.

dyson_cleaner.jpg

  • Ameerikas on praegu väga populaarsed James Dysoni leiutatud tsükloneraldusega tolmuimejad. Jättes kõrvale asjaolu, et tegemist on tehnilise uuendusega, mis tolmuimemist efektiivsemaks muudab, võime küsida, miks selle tolmuimeja kate just läbipaistev peab olema? Kas selleks, et näha, kui palju seal tolmu sees on? Tegelikult meeldib paljudele inimestele alateadlikult näha, kuidas praht tolmuimejas ringi käib ja seeläbi “tappa saab”. Katsugu ta veel tulla silmailu rikkuma! :) Inimesed ei saa sellest enamasti ise arugi, aga neile meeldib Dysoni tolmuimejaga koristamine millegipärast rohkem kui teistega.

jogger.jpg

  • Kõik teavad, et tervisejooks on kasulik, aga sellegipoolest ei tule jätku enamikul inimestest püsivust sellega tegelemiseks. Kuidas asja parandada? Jooksmisest tulenev kasu on pikaajaline protsess, raja lõpus pole enamasti mingit kohest rahuldust. Kuidas aga kohe jooksjale mingi preemia anda? Nike ja Apple tulid kahe peale välja tootega, mis ühelt poolt ergutab sind jooksmise ajal ning teiselt poolt laseb enda tulemusi teiste omadega võrrelda. Ja kas saab olla suuremat rahuldust, kui näha, kuidas sa teiste inimestega võrreldes arened? Pole siis imestada, et Nike Plus on hea äri.

 elderly_driver.jpg

  • Et paremini mõista vanema põlvkonna autojuhte, leiutas Nissan spetsiaalse ülikonna, mis takistab teatud liigutusi, et mõista, milline on auto ergonoomika vanemate inimeste seisukohalt. Sarnased ülikonnad on olemas ka selleks, et simuleerida näiteks rasedat naist või muid iseärasusi.  

Tarkvara seisukohalt võime siin mõelda: enamikus IT-firmades on olemas infrastruktuur ja tööriistad (alates kiirest internetiühendusest arendusvahenditeni), mis meie jaoks IT lihtsaks ja mugavaks teevad. Enamikul meie kasutajatest seda aga pole ja me peaksime iga valminud tarkvaratoodet vaatama eelkõige nende inimeste seisukohalt, kellel on väiksemad võimalused. Näiteks kas meie vormid mahuvad ka väiksema kui 21″ ekraani peale ära? Kas meie andmehulgad on edastatavad ka vähema kui 1Gbit kohtvõrgu kaudu? Kas meie rakendused jooksevad ka alla 2GB mäluga?

autobahn.jpg

  • Autoteema teisest äärmusest leiame näite, kuidas Honda saatis Honda Legendi disainerid ja insenerid 6 kuuks Saksamaale, et nad uuriksid, mis tunne on reaalselt autobahnil kihutada ja mida ühel autol selle jaoks vaja läheks, Jaapanis sellist võimalust polnud.
  • Paljud lahendused tulevad pähe lihtsalt inimeste igapäevaelu vaadeldes. Nii on leiutatud näiteks kohvikruusihoidjaga pesumasin, väike külmkapp ühikatubade jaoks, mille pealne on lahtivolditav väikeseks lauaks jne. Minu lemmikuks on siin Whirlpool Gladiator GarageWorks ja spetsiaalne garaažikülmkapp, juba ammu ei hoita garaažis ainult autosid, vaid sellest on saanud paljude meeste elu- ja hobikeskus, mille jaoks on kohandatud terve hulk kodutehnikat.

 big_bazaar.jpg

  • Kes on Aasias reisinud, teab, et suur osa sealsest jaekaubandusest toimub kaootilistel avaturgudel. Kui Kishore Biyani Indias Pantalooni supermarketite keti asutas, olid tema poed alguses samasugused nagu nende lääne ekvivalendid, korrapäraselt seatud riiulite ja sirgete vahekäikudega. Hoolimata sellest, et poed olid ilusad, puhtad ja odavad, ei tulnud inimesed sinna, sest selline kauplemisviis polnud neile omane. Ei aidanud muu, kui imiteerida traditsioonilisi turge, praegu on Pantalooni poed ebakorrapärased, kaubad vedelevad näiliselt juhuslikult, asjade üle on võimalik tingida, aga rahvast käib seal nagu murdu.

iridium.jpg

  • Oluline on aga, et me annaks endale aru, kas tegemist on vaid ühe kasutaja iseärasusega või laiema suunaga. Tihti saavad suured projektid alguse kellegi kinnisideest, mis tegelikult aga kedagi ei huvita, üheks suurimaks ja kallimaks näiteks siinkohal on Iridiumi satelliidid. Algse idee kohaselt pidi olema tegemist tootega “mobiilsele ettevõttejuhile”, kes kogu aeg maailmas ringi rändab. Ärimehed ei tahtnud aga suurt, kallist ja kobakat satelliittelefoni, pärast 5 miljardi dollari kulutamist saadi poole aastaga vaid 10000 kasutajat ning Iridium läks vähem kui aasta pärast pankrotti. Praeguseks on Iridiumi võrk siiski kasutuse leidnud, aga hoopis avamerepurjetajate ja muude rändurite seas.

  medical.jpg

  • Teise näite sellest, kuidas me ei saa aru, kes meie klient tegelikult on, leiame meditsiinist. Meditsiiniskännerid on tõeline tehnikaime, näidates 3D pilti kõigest, mis inimese kehas toimub. Aparatuuri tootjad rääkisid arstidega, milliseid võimalusi viimastel vaja läheks ja said pika nimekirja. Kui aga masinad valmis tehti, selgus, et nende kasutusaeg hoopis langes. Milles asi? Selgus, et päriselt ei kasuta masinaid mitte arstid, vaid laborandid, kellele arst lihtsalt ütleb, et teha seda või toda. Ja kuna uuel masinal oli liiga palju nuppe ja vidinaid, millest laborandid aru ei saanud, jäid ka uued võimalused unarusse.

See on tegelikult tarkvaramaailmas igapäevaselt toimiv efekt. Inimene, kes meilt toote tellib, ei ole tihti teps mitte seesama, kes seda lõpuks kasutama hakkab!

mac_portable.jpg

  • Kui Apple oma esimese sülearvuti lõi, oli firmal juba tugev kogemus lauaarvutitega, ja juba tollal pandi Apple’is suurt rõhku disaini perfektsusele. Mac Portable oligi perfektne… lauaarvuti seisukohalt. Tüüpiliseks näiteks on, et Portable’i aku pidas vastu üle 10 tunni (!), mis tegi arvuti palju suuremaks ja raskemaks kui konkureerivad tooted, aga näitab hästi, et tegijatel polnud täpset aimu, mis elu sülearvutikasutaja elab.

hud1.jpg

  • Veel näide meditsiinitehnikast: Laparoskoopia on kirurgia haru, kus inimese sisse torgatakse fiiberoptiline kaabel ning ning kirurg vaatab ekraanilt, mis sul sees toimub. Katsetusel süsteemi testides toimis kõik hästi. Kui aga millalgi tegelikku operatsioonisaali mindi, leiti, et ruum on abistajaid täis ja kirurg peab kogu aeg üle nende küünitama, et ekraani näha. Lahenduseks oli heads-up display, spetsiaalsed prillid, millelt pilti saab vaadata, aga ilma kasutajat tema loomulikus keskkonnas jälgimata poleks tehnoloogid iial selle mõtte peale tulnud.

8 responses so far

Apr 25 2008

Kliendiempaatia

Published by Targo under Analüüs, Kliendid, Lugejate lemmikud

psychic.jpg 

Enamik maailma tarkvaraarendajaid arvab, et nad on kliendikesksed ja teevad kõik, et kliendi soovidega arvestada. Kuidas on siis võimalik, et maailmas on nii palju inimesi, kes oma tarkvaraga raasugi rahul pole?

Selgub, et tegelikult jääb enamikul ettevõtetest tõelisest kliendikesksusest kõvasti puudu.

Mida tähendab olla kliendikeskne? Eelkõige tugevat empaatiat. Kui me ei saa aru, miks klient midagi teeb, arvab või mõtleb, pole tegelik kliendikesksus võimalik.

Näiteid sellest, kuidas erinevad ettevõtted on minu isiklikus kogemuses empaatiat üles näidanud:

harmony.jpg

  • Enne, kui Google internetiotsimootorite turule sisenes, peeti loomulikuks, et kasutaja peab otsimootori poolt tagastatud tulemusi veel käsitsi läbi sõeluma, et leida, mida tal tegelikult vaja on. AltaVistaga oli tavaline, et tegelikult vajalik link oli kusagil viiendal-kuuendal leheküljel. Miks pean mina sellist käsitööd tegema? Google’i innovatsioon eemaldas olulise ärritaja minu internetikasutuselamusest.
  • Üldiselt ma vihkan lennukiga lendamist, alates turvakontrolli absurdsusest kuni selleni, et mul surevad lennukis alati jalad ära. Lastega koos reisides on aga üks minu seisukohalt kena erand, see on SAS. Kui teistel lennufirmadel lastakse lennukisse kõigepealt äriklass ja siis muu rahvas istmeridade järjekorras, siis SAS laseb kõigepealt peale väikeste lastega reisijad. Samuti jagavad nad lennu ajal lastele vanusekohaseid mänguasju, mis ei maksa ilmselt suurt midagi, aga uus mänguasi teeb lastel alati tuju heaks. Asjaolu, et nad suudavad mõista lastega reisija spetsiifilist olukorda, näitab head empaatiat ja ma valin Ameerika ja Euroopa vahel lennates peaaegu alati SASi kui võimalik.
  • Nagu paljudel teistelgi inimestel, on mul koju kogunenud hulk pultidega elektroonikavärke, neid pulte on paras hunnik, mõnede operatsioonide jaoks (et näiteks telekas+võimendi XBoxilt kaabel-TV peale ümber lülitada) on vaja kolme erinevat pulti, millest on alati mõni kadunud. Mitmed tootjad pakuvad nn universaalpulte, millel aga alati 10% funktsionaalsusest puudu jääb ja ikka originaalset pulti vaja läheb. Sealt järgmine tase on lihtsad programmeeritavad puldid, mis on kenad, aga paistab, et insenerid, kes need välja on mõelnud, pole neid kunagi kasutada proovinud, sest kui minul professionaalse programmeerijana kulub alati pool tundi manuaali sirvimist, et nuppe ja makrosid õigeks timmida, pole lihtkasutajal vähimatki lootust. Vidin, mis lõpuks hädast välja aitas, on Logitech Harmony pult, kus iga liigutus on tõesti korralikult läbi mõeldud ja intuitiivne, jällegi märk, et loojad on võtnud vaevaks kasutaja harjumusi korralikult ja põhjalikult tundma õppida.

Tarkvara alal on olukord tegelikult iseäranis hull, programmeerija elab kliendiga võrreldes tihti omaette maailmas ja lükkab oma loodu lihtsalt avalikkuse ette, kusjuures mõlemad osalised jäävad teineteise jaoks anonüümseks. Tegelik kasutajakesksus tuleb kõne alla aga vaid siis, kui me mõistame klienti palju sügavamal tasemel, kui üksnes tellimusse kirjapandut üks-üheselt koodisse ümber vorpides. Kui lasta kliendil vabalt igasugustest asjadest rääkida, saame tihti teada, mida ta tegelikult hindab ja mis tema elu palju lihtsamaks võiks muuta.

Enamik Eestis toodetavast tarkvarast tehakse konkreetsetele klientidele ja seega on seal küllaltki palju võimalust isiklikuks, individuaalseks lähenemiseks, iseasi on, kui palju seda ära kasutatakse.

Võtmetähendusega viga, mis enamasti tehakse, on see, et palju lihtsam on leida vigu teiste inimeste kaupades ja teenustes. Mina võin leida sada häda näiteks lennukiga lendamise juures, aga kui lennufirma inimesed kaebavad, et tarkvara on jama, õiendame me vastu, et mida kuradit teie ka tarkvarast teate.

child.jpg

  • Esimene lugu: Juba viieaastane laps teab, et isaga tuleb käituda natuke teistmoodi kui emaga, et oma tahtmist saada. Polegi oluline, milline see erinevus just on, aga lapsed tabavad selle kohe ära, sest neil on loomupärane avatus, uudishimu ja empaatia ja nad kasutavad seda ära, et kummalegi poolele meele järele olla. Kuna enamik lapsevanemaid oma lapsi väga kõrgelt hindavad, leiame me siit ideaalse kliendisuhte mudeli :) Kui me oma kliendi tundeid sama hästi ära tabaksime, kui väike laps seda teeb, ei läheks nad iialgi konkureeriva firma poole üle.

Erinevate äride edulugudest leiame mitmeid näiteid, kuidas inimeste tunnetest arusaamist edukalt on ära kasutatud.

Näide: üldiselt teevad inimesed arenenud maades järjest vähem ise süüa ja käivad pigem väljas ning ostavad valmistoitu. Sellele fenomenile on leitud palju põhjendusi nagu:

  • Inimesed on laisad ega viitsi kokandusele aega kulutada!
  • Nad on kiirtoiduga ära hellitatud ega hinda enam tavalisi toite!
  • Neil puuduvad traditsioonilised kultuuriväärtused, mis väärtustavad perekonda, kodust elu ja toidutegemist!

Süvitsi asja uurides leiti aga, et tegelikult on asi selles, et inimesed ei tea päris hästi, kuidas süüa teha ja kardavad ebaõnnestumist. Kodumasinate tootjad keskenduvad tänapäeval eelkõige sellele, kuidas teha toidutegemine võimalikult lollikindlaks. Näiteks teab kogenud kokk täpselt, millal on rasv pannil just täpselt õige kuumusega, sest ta säriseb sel hetkel kindlal iseloomulikul viisil. Selline kokk võib õpetada mind palju tahes, ilma suure harjutamise ja paljude ebaõnnestumisteta ei suuda ma seda ikka järele teha. Kuni Tefal leiutas panni, mille keskel on punane täpp, mis vastava kuumuse juures helendama hakkab.

Või siis teine kokk, kes teab kohe peale vaadates, kas riis on piidavalt kaua keenud. Zojirushi leiutas riisikeetja, mis väidetavalt parima kokaga samatäpselt õigesti keedab. Muuseas, ei olegi nii väga oluline, kas sellised tooted tegelikult toidu paremaks teevad, aga nad on märkimisväärsed selle poolest, et aitavad inimesel oma hirmust üle saada,  ning on seetõttu väga populaarsed.

cement.jpg

  • Teine lugu: Cemex on suur tsemenditootja Mehhikos. Palju inimesed, kellel vaja oli ehitada, kurtsid aga, et tsement on liiga kallis. Lihtne lahendus oleks muidugi olnud hinda langetada, siis oleks aga langusega kaasa läinud ka kõik teised tootjad ning hinnasõda oleks lihtsalt firma kasumi ära söönud. Selle asemel uuris Cemex, millist elu need inimesed elavad? Selgus, et paljud neist töötavad tegelikult USAs ja saadavad raha koju, mille eest siis kodused ehitavad. Suur hulk raha läheb aga kaduma erinevate vahendajate tõttu. Lahendus? Cemex asutas Construmexi, rahavahendusteenuse, millega inimesed said saata raha otse Cemexi poolt sertifitseeritud ja garanteeritud ehitajaile, ilma et vahendajad või kahtlasema väärtusega ehitusmehed suuremat osa sellest pihta oleks pannud. Inimesed olid väga rahul, sest said oma asjad odavamalt ehitatud, kuigi tsemendi hind jäi endiseks.

Eesmärgiks on, et me saaksime aru kliendi probleemidest, millest tal endal ehk üldse aimugi pole ja käituksime nagu selgeltnägijad :) Pilt artikli alguses illustreerib seda ideaali: lahendada probleem enne, kui klient sellest arugi saab!

baggage.jpg

  • Kolmas lugu: Üks põhjus, miks lendamine on nii ebameeldiv, on sekeldamine pagasiga. Perega reisides on kohvreid üksjagu ning nende tarimine ühest punktist teise võtab tihti ära kogu rõõmu, mille me muidu uute paikade uudistamise esmamuljest saaksime. Enamikul lennufirmadel on ükskõik, mis reisijast saab, kui ta lennuki pealt maha on läinud. Disney aga lahendas olukorra elegantselt, pakkudes tasuta teenust, mis inimeste pagasi kohe lennuki pealt hotelli viib, et nad ei peaks sabades seisma ja muidu kannatama. Virgin Atlantic läheb veel kaugemale: nad tulevad sulle sinu lähtekohta autoga järele ja viivad pärast sihtkohta ära, ilma et ise peaks üldse millegagi vaeva nägema. Peale selle saab inimene Atlanticu lennul süüa, millal ise tahab, ja mitmesuguseid muid mõnususi. Kuna nad inimese kõigi murede eest sel viisil hoolt kannavad, võib Virgin Atlantic endale lubada ka priske marginaaliga hinnasilti: lend võib maksta kuni 12 tuhat dollarit.

Oluline tähelepanek nende lugude juures on, et inimene ei osta mitte tsementi, vaid ilusa maja ehitamise ja selles elamise kogemust. Ta ei osta mitte lennupiletit, vaid lihtsalt ja mõnusalt ühest kohast teise saamise teenust. Sama kehtib ka tarkvara puhul! Kui me saame tarkvara eest raha kätte, aga klient seda reaalselt kasutama ei hakka, ei ole meie äri tegelikult õnnestunud. Kui me suudame kliendile pakkuda tervikliku kogemuse, on ta meiega palju rohkem rahul ja meil tekivad võimalused talle müüa ka mitmesuguseid muid huvitavaid ning mõlemapoolselt kasulikke teenuseid.

One response so far

Apr 18 2008

Meie ja nemad

Published by Targo under Kliendid, Lugejate lemmikud

 frustration11.jpg

  • Eelmise aasta aprillis ütles Motorola toonane CEO (nüüd ta seda mõistetavatel põhjusetel enam pole), et ta vihkab oma kliente.
  • Mõni aeg varem väitis Quark Inc’i boss, et kõik kliendid on valetajad ja vargad.
  • Läbi 90. aastate oli Fordil probleeme, et Brasiilia turul midagi müüa. Fordi selgitus? Brasiillased on lollid ega oska korralikke autosid hinnata.

Millest sellised arusaamad tekivad? Kas klient ei peaks mitte olema kuningas, kelle tahtmise järgi ettevõtted oma poliitikat ja plaane seavad, ja kelle poolt firmasse toodud raha maksab nii direktori Ferrari kui ka liinitöötaja laste leiva eest?

Sellegipoolest olen ma ka ise, sõltumata töökohast, kohanud inimeste seas kurtmisi nagu:

Äkki on asi hoopis selles, et me ise ei saa kliendist ja tema vajadustest aru? Äkki me ei tahagi temast korralikult aru saada?

old_man.jpg

  • Esimene lugu: Minu tuttava tuttava tuttavatel oli vana isa, kes elas üksi, lastest lahus. Vana mees käis iga päev arsti juures, sest ta väitis, et tal on meelest läinud, kas tal oli tegelikult selleks päevaks aeg kinni pandud või ei. Lapsed küsisid, miks ta arstile ei helista ja järele ei küsi, isa vastas, et telefon ei tööta. Osteti isale uus telefon, ikka sama. Mis nüüd? Need nupud on nii väikesed, ma ei näe neid lugeda. Osteti spetsiaalne suurte numbritega telefon, nüüd ütleb isa, et tal on arsti number meelest läinud. Kleebitakse arsti number suurelt telefoni kõrvale ja pannakse kiirvalimisse, ikka ei midagi…

Neutraalne lugeja saab muidugi aru, et isa probleem polnud mitte telefonis, vaid selles, et ta oli üksi ja tahtis kellegagi rääkimas käia. Sellegipoolest on elus iga päev juhtumeid, kus me “parandame kliendi telefoni”, selle asemel, et sügavuti huvi tunda, mis teda tegelikult vaevab.

Enamasti on asi selles, et me oleme kinni omaenese ideedes maailma kohta ja selles, milline üks hea lahendus kõigile probleemidele peab olema. 

yam.jpg

  •  Teine lugu: Haier on Hiina suurim kodumasinate tootja. Maapiirkondadest saadeti neile pidevalt kaebusi pesumasinate äravoolutorude ummistumise kohta. Asja uurides selgus, et maainimesed pesid pesumasinates pesu asemel juurvilju. Kas Haieri reaktsioon oli kaevelda selle üle, kui rumalad kliendid on? Inimesi harida pesumasina õige kasutamise osas? Ei, selle asemel disainisid nad masina, millel olid suuremad torud ja mis sobis ka juurviljade pesemiseks. Inimesed olid ülirahul ja Haier teenis palju raha. Loe lähemalt siit.

Enamasti on reaktsioon “me peame klienti harima” näide valest mõtlemisest ja me jätame selle asemel kasutamata mingi kavala võimaluse kliendi rahulolu tõstmiseks.

Oluline on, et isegi kui inimesed käituvad meie meelest absurdselt, on nad iseenda silmis alati mõistlikud!

frustration2.jpg

  • Kolmas lugu: Kui ma oma programmeerijakarjääri alguses olin, portisime me üht programmi DOSist Windowsi. Üks klient kaebas, et uus versioon on igavene jama, sest tekst on kribu ja ta ei näe sealt midagi selgelt. Võrreldes DOSi 80×25 tekstimoodis ekraaniga olid uue variandi kirjad muidugi väiksemad, kuid pean häbiga tunnistama, et toona me lihtsalt naersime kliendi selja taga tema rumaluse üle – kuidas ta siis aru ei saa, et graafiline kasutajaliides on palju parem? Tegelikult oleksime pidanud mõtlema sellele, kuidas oma programm selgemaks ja sõbralikumaks teha, mida me noorte ja uljastena muidugi ei teinud.

Sellepärast, kui klient teeb midagi, mis meid tavaliselt juukseid katkuma paneks, on mõistlikuks reaktsiooniks mitte ärritus, vaid uudishimu, astuda emotsionaalselt samm eemale. Mis see on, mis pani teda niiviisi talitama? On meil siin võimalus kasu tuua?

shimano.jpg

  • Neljas lugu: Maailmas on mitusada miljonit inimest, kellele meeldis lapsena jalgrattaga sõita, aga kes täiskasvanuna seda enam ei tee. Tihti on põhjuseks, et rattapoodide töötajad on nende jaoks hirmuäratavad, rattad ise on aga lapsepõlvega võrreldes muutunud komplitseeritumaks. Jalgrattadisainereid see muidugi ei sega, nemad saavad hakkama ka kõige keerulisema rattaga ja tootjate vahel toimub omamoodi “võidurelvastumine”, et kes teeb valmis uhkema ja keerulisema järgmise mudeli. Nende mudelite ostjateks on aga suhteliselt kitsas seltskond entusiaste, samal ajal kui tohutu hulk elanikkonnast tähelepanuta jääb. Hiljuti tuli Shimano aga välja ideega selle probleemi lahendamiseks, automaatkäiguvahetusega jalgratas! Snoobid disainerid kirtsutasid selle idee peale esialgu muidugi nina ja küsisid vastu: “aga kui paljude inimeste käest te uurisite?” Vastuseks lasti neil proovida sõita üherattaliste jalgratastega, ideega, et tavainimesele on tavaline jalgratas sama keeruline kui profile üherattaline.

Siin on meil mitu moraali:

  1. Proff, olgu siis jalgratta- või tarkvaraproff elab täiesti omaette maailmas ega saa aru, kui keeruline see teiste jaoks on.
  2. Küsimus “kui paljude inimeste käest te uurisite” on enamasti märk juurdunud mõtlemisest, hea viis uus idee kahtluse alla panna ilma sisulistesse argumentidesse laskumata.
  3. Väga oluline on, et meil säiliks alati võime luua toodet, mis meile endale ehk ei meeldi, aga mis meeldib tavainimesele.

Mis rattapoodide hirmuäratavusse puutub, siis olen seda kogenud ka omal nahal. Viimase ratta ostmise ja hooldamisega käis kaasas müügimehe pidev vingumine, kuidas inimesed ei oska oma rataste eest hoolitseda, ning silmade pööritamine, kui rumal ma ikka võin olla. Ja sellest ajast peale sõidan ma rohkem autoga :( Paraku on suur hulk programmeerijaid samasuguse halva suhtumisega ja see on üks peamisi põhjusi, mis takistab neil kliendiga paremat kontakti saamast.

butiik.jpg

Tegelikult peaks kõigil olema kohustus aeg-ajalt mõnes “hirmuäratavas” poes käia, et paremini hinnata, kui oluline on kliendi tasemele laskuda. Nohikud programmeerijad võiksid proovida näiteks mõnest peenest butiigist huulepulka osta ja oleksid teinekord tagasihoidlikumad, kui butiigitibidel midagi nende tarkvarafirmasse asja on.

Kokkuvõtteks: pole olemas sellist asja nagu terve mõistus (common sense), igaühel on oma arusaam maailmast. Meil pole võimalik oma mätta otsast vaadates eeldada, et ka klient samamoodi arvab, vaid me peame alati vaatluste teel selgitama, kuidas ta tegelikult oma elu elab.

No responses yet

Apr 08 2008

Juhtimisviisid ja motivatsioon

motivation.jpg

Motivatsiooni saame jagada positiivseks (me teeme midagi, et meiega midagi head juhtuks) ja negatiivseks (teeme midagi, et halb juhtumata jääks), samuti väliseks (keegi teine tahab, et me midagi teeks) ja sisemiseks (ise tahame seda teha).

Selle põhjal saame laias laastus neli liiki motivatsioonifaktoreid: kolm neist ei tööta ja üks töötab. Sellegipoolest kasutab 95% maailma ettevõtetest enamasti mingit kombinatsiooni kolmest mittetöötavast meetodist.

Kõige olulisem tähelepanek on, et väline motiveerimine üldjuhul ei tööta, ei hea ega halvaga, vaatleme seda mõnede näidete varal:

military.jpg

Sõjaväes õpivad inimesed küllaltki kiiresti, et käsk on vanem kui meie ja käsule vastuhakkamisel on enamasti kurvad tagajärjed, olgu tegemist siis kuitahes rumala käsuga. Ka tsiviilelus juhib nii mõnigi organisatsioonijuht oma inimesi nagu sõdureid: “Teed sellepärast nõnda, et mina ütlen nii, muidu oled vallandatud! Ja jutul lõpp!!”

Programmeerijad, sindrinahad, arvavad aga enamasti, et nad teavad ise kõige paremini, kuidas asju teha (ja tihti teavadki), ja reageerivad seetõttu kamandamismeetodile lastes oma produktiivsuse allapoole igasugust arvestust. Teiseks eeldab kamandamismeetod arvestatavat mikromanageerimist, niipea kui piitsaplaksutataja silmapiirilt kaob, lastakse end jällegi lõdvaks ja ei tehta üldse midagi. Asi lõpeb sellega, et juht kurnab ennast ära, tehtud ei saa aga ikka midagi.

Hoiatava näite sellest, kuidas väline halvaga ähvardamine ei aita, leiame tegelikult meditsiinist. Südameoperatsioonil käinud inimesi hoiatatakse üldjuhul, et kui nad oma eluviise (olgu siis liigse söömise, joomise, suitsetamise vms osas) ei muuda, siis nad surevad varsti ära. Kui paljud inimesed aga tegelikult ennast parandavad? Selgub, et 2 aastat pärast operatsiooni on 90% patsientidest tagasi endiste harjumuste juures!

Ühesõnaga, kui isegi surmaga ähvardamine ei aita, kui inimesel puudub tegelik sisemine soov midagi muuta, kui palju lootust on siis otsesel ülemusel?

money2.jpg

Teine viis, kuidas inimesi püütakse panna midagi tegema, on neid ühel või teisel viisil ära ostes, olgu tegemist siis raha, nänni, “kuu parima töötaja” tiitli või muude vahenditega.

Esimene probleem sellise lähenemise juures on, et tarkvaraprojekti juures on äärmiselt raske leida mingit lineaarset väärtust, mida mõõta ja seejärel rahasse ümber kantida. Kui premeerida näiteks koodiridade arvu, kirjutab programmeerija kas suure hulga kommentaare või formaadib koodi niiviisi, et see võimalikult pikk välja tuleks, või teeb otseselt sohki, lisades projektile hulga “võltskoodi”, mis tegelikult midagi ei tee.

Kui premeerida ennetähtaegset ülesannetega valmis saamist, “täidetakse” ülesanne ilma testimata ja muul viisil üle nurga lastes.

Kui premeerida vähest vigade arvu, teeb programmeerija testijaga diili, et vigu ei panda kirja ja statistikas näeb kõik ilus välja (kui me maksame testijale lisatasu selle järgi, kui palju vigu ta leiab, lähevad programmeerija ja testija tülli ning tiimitöö lendab vastu taevast).

Sõltumata sellest, millise meetodi me leiutame, on programmeerija üldjuhul piisavalt taiplik, et optimiseerida oma tulemust vastavalt sellele, mida me parajasti mõõdame, ning tulemus saab enamasti palju hullem, kui enne mõõtmisviisi sisseviimist.

birdflight.jpg

Peamine viga, mis mõlemal juhul tehakse, on see, et inimese sisemine motivatsioon asendatakse välisega. Kui ma tahan kirjutada head koodi sellepärast, et mulle meeldib hea tulemus, siis ma pingutan selle nimel, et kood tuleks võimalikult hea. Kui mulle selle eest aga raha pakutakse, siis hakkan ma mõtlema, et “ma pean kirjutama head koodi, et raha saada”. Väline motivaator on aga alati nõrgem kui sisemine ning paradoksaalsel kombel on mul äkitselt hoopiski vähem soovi oma tööd võimalikult hästi teha.

Kuidas sisemist motivatsiooni kasvatada? Kui ma teaksin sellele küsimusele täpset vastust, siis juhiksin praegu mõnd Fortune 100 ettevõtet, aga arvamusi siiski:

On väga oluline, et töötaja jagaks ettevõtte identiteeti ja peaks ettevõtte eesmärke enda omadeks. Siinkohal on suureks abiks, kui ettevõttel on mingil viisil üllas või võimas visioon, millega inimestele meeldib ennast samastada. Miljonid väga andekad inimesed töötavad küllaltki väikese raha eest heategevates organisatsioonides, sest neile meeldib töötada õilsa eesmärgi nimel, isegi kui nad ise on lihtsalt raamatupidajad või itimehed, mitte ei jaga isiklikult nälgivatele lastele leiba.

Kommertsettevõttel on muidugi natuke raskem üllas olla, aga ka siin leiab hea tahtmise korral lahenduse. Microsofti missioon on aidata inimestel kogu maailmas oma tööd efektiivsemalt teha. Paljude teiste firmade missioon on Microsoft troonilt tõugata ja seeläbi “õiglus jalule seada” :)

Teine identiteedi aspekt on seotud töötaja kolleegidega. Kui inimesed tunnevad end kokkukuuluvatena nagu perekond, on nad vastastikku lojaalsed ja üksteisele pühendunud. Kui minu töökaaslased on mulle olulised, pole mulle vaja mingit välist motivaatorit, et nende nimel ekstra pingutada ja ühise eesmärgi nimel asjad võimalikult hästi valmis teha.

Kolmandaks on vaja, et ettevõtte kultuuris väärtustatakse siiralt head tulemust. Meile kõigile meeldib, kui meid hinnatakse ja respekteeritakse, seda siis nii ülemuste kui ka kolleegide poolt. Kui programmeerija ülemuseks on aga endine müügimees, kes C-l ja Javal vahet ei tee, jääb see vajadus aga rahuldamata ning mingil hetkel langeb paratamatult ka motivatsioon.

No responses yet

Mar 13 2008

Myers-Briggsi iseloomutüübid tarkvaraorganisatsioonis ehk miks programmeerijaid kliendiga kokku ei lasta

Paljud inimesed on kindlasti kuulnud Myers-Briggsi iseloomutüüpide testist, kui mitte, siis soovitan kindlasti see test läbi teha, annab väga viljakat mõtlemisainet nii iseenese mõistmise kui ka teistega suhtlemise osas. Internetis on mitmeid saite, kus saab MB testi teha. Siinkohal vaatame, millised on mõned huvitavad MB rakendused konkreetselt tarkvaratootmise situatsioonis.

MB teljed on: Introvert-Extravert, Sensing-Intuitive, Thinking-Feeling ja Judging-Perceiving. Vastavalt sellele, kuidas inimene neil telgedel paikneb, vastab tema iseloomutüübile 4-täheline lühend.
Järgneval diagrammil on toodud statistilised tulemused, kus kollasel põhjal on (protsentuaalselt) USA elanikkonna statistilised iseloomutüübid ja rohelisel põhjal 5000 kas organisatsiooniliselt või tehnoloogiliselt liidripositsioonil töötava tarkvaraspetsialisti tüübid.

mb.jpg

  
Väga oluline on rõhutada, et ükski iseloomutüüp pole a priori teistest parem või halvem. Ühiskonnas edukate inimeste seas on kõiki tüüpe, neid tuleb lihtsalt ära tunda ja arvestada, milline käitumine neile millist mõju avaldab.Kui kedagi huvitab, siis mina olen INTJ :)  

Esimene telg ehk kust me oma energiat ammutame: Extravert-Introvert

mb_ie.gif 
Küsimus: Mis vahe on introvertsel ja ekstrovertsel programmeerijal?
Vastus: Introvertne programmeerija vaatab sinuga rääkides enda kinganinadele, ekstrovertne sinu omadele…

Tegelikult on muidugi ka programmeerijate seas nii tõelisi  I-sid kui ka E-sid, kõigi sellest tulenevate tagajärgedega. I/E tänavadefinitsioon on, et E räägib palju ja I on kogu aeg vait. See pole tegelikult õige, ma ise võin vajaduse korral rääkida-rääkida-rääkida, rahvale kõnesid pidada ja üleüldiselt esineda, aga tegelikult olen ma pigem introvert. 

I/E tegelik definitsioon on, et E saab oma tegutsemiseks vajaliku energia inimestega suhtlemisest, I aga omaette olemisest ja mõtisklemisest. Selle asjaolu mõistmine on väga oluline näiteks inimestele sobiva töökeskkonna loomisel.

E moto on “arutame asja”, ta on sotsiaalne, aktiivne, laiutiminev, väljendusrohke. E peab kogemuse läbi tegema, et seda mõista.
I arvab, et E on lärmakas, pealetükkiv, pealiskaudne, impulsiivne, väsitav.

I moto on “mõtleme asja läbi”, ta on vaikne, sügavutiminev, privaatne, reserveeritud. I peab kogemust enne mõistma, et seda läbi teha.
E arvab, et I on vaikne, kättesaamatu, ennastimetlev, eemalviibiv, väsitav.

Tarkvaraorganisatsioonis avaldub see eelkõige tiimide kompositsioonis ja õige keskkonna loomisel. Tüüpiliseks näiteks on igavene debatt selle üle, kas inimestel peaks olema vaikne, privaatne oma tuba või peaksid nad olema koos ühes suures ruumis, kus on võimalik igal hetkel teistega suhelda, olenevalt iseloomutüübist on mõne inimese jaoks õige variant üks, mõne jaoks teine. Vale valiku puhul juhtub lihtsalt, et töötaja on päeva lõpuks väsinud ega saa eriti midagi tehtud, kuigi kõik muud tingimused võivad olemas olla.

Minu idee on siinkohal luua asutuses “vaiksed piirkonnad”, toad, kuhu I saab vajaduse korral minna ja kriitilisel hetkel vaikselt ning segamatult oma tööd teha, ilma et ta sinna kogu aeg isoleeritud oleks. Suhtlemises on tähtis märgata, et I eelistab tihti kirjalikku väljendust, ütleb vähem, kuid väljaöeldu on see-eest rohkem läbi mõeldud, ning I võib kergemini solvuda, kui need mõtted tähelepanuta jäetakse.

Olukorras aga, kus kiiresti ja agressiivselt oma sõna sekkasaamine on oluline (nagu teatud tüüpi läbirääkimistel), omab E jällegi suurt eelist, sest selleks ajaks kui I on küsimuse oma peas läbi mõelnud, on E-d juba järgmisele teemale hüpanud. 

Teine telg ehk kust me infot saame: Sensing-iNtuition

gauge.jpgthirdeye.jpg  
 ”Sensing” tuleb siinkohal mõista selles tähenduses, mida me oma viie meelega konkreetselt tajume.

S-tüüpi inimesed hindavad eelkõige fakte, praktilisust, detaile, korrastatust ning on oma mõtetega peamiselt olevikus.
N arvab, et S on kujutlusvõimetu, pedantne, detailne, igav ja piiratud.

N mõtleb pigem tulevikule, võimalustele, tähendustele, mustritele ja muutustele.
S arvab, et N on ebapraktiline, lõdva mõtlemisega, abstraktne, ennustamatu ja distsiplineerimatu.

Programmeerimine on väga abstraktne tegevus ja programmeerijad kipuvad olema rohkem N-tüüpi. Siit saab alguse ka üks tüüpilisi konflikte programmeerijate ja klientide vahel. Tarkvarainimesed on tihti peaga pilvedes ning mõtlevad sellele, kui tehnoloogiliselt uhke, võimas, universaalne ja abstraktne nende lahendus on, samal ajal kui klient nutab, et tema konkreetset erijuhtumit arvesse ei võeta.
Universaalset ja abstraktset koodi on palju põnevam kirjutada, kui erijuhtumeid nikerdada, aga reaalne elu paraku peamiselt erijuhtumitest koosnebki. Selle asjaolu teadlik arvestamine, enese kahe jalaga maa peale surumine ning püüd maailma kliendi seisukohalt näha aitab tihti kaasa palju soojematele ja viljakamatele suhetele.  

Kolmas telg ehk kuidas me otsuseid teeme: Thinking-Feeling

thinking.jpgfeeling.gif
T-d iseloomustavad sõnad on objektiivne, kindel, täpne, analüüsiv, ta mõtleb eelkõige sellele, kas miski on loogiline või ei ning püüdleb absoluutsele õiglusele.
F arvab, et T on objektiivne, kuid “ei saa asjale pihta”, range, tundetu ja hoolimatu.

F seevastu subjektiivne, empaatiline, hooliv, lähtub väärtustest ja harmooniast ning hindab eelkõige inimestevahelisi suhteid.
T arvab, et F on ebaloogiline, subjektiivne, pehme, irratsionaalne ja emotsionaalne.

Kuna arvutile tuleb kõik konkreetselt puust ette teha, on programmeerijad enamasti T tüüpi ja siit leiamegi järgmise konflikti. IT-mees võib tähtsat klienti külastades talle otse näkku öelda, et kliendi firmas on kõik valesti, korda pole ollagi ning keegi ei oska oma tööd õigesti teha. Enda seisukohalt käitus ta täiesti loogiliselt ning tegi kliendile teene, samamoodi nagu arvutile patchi installeerides, asjaolu, et suhe rikutud sai, ei pane ta tähelegi.  

Neljas telg ehk kuidas me asju lõpule viime: Judging-Perceiving
  

perceiving.gif
J teeb kindlaid plaane ja otsuseid, seab kõigele tähtaja, armastab organisatsiooni, struktuuri ning lõpetatust.
P arvab, et J on kontrolliv, struktuurne, planeeriv, piirav ja paindumatu.

P on pigem paindlik, uudishimulik, avatud, spontaanne ning eelistab kõik võimalused avatuks jätta.
J arvab, et P on kontrolli alt väljas, korratu, teeb asju viimasel hetkel, organiseerimatu ja ebausaldusväärne. 

Siinkohal on tarkvarainimeste seas esindatud mõlemad tüübid, aga me leiame terava vastuolu näiteks siis, kui on vaja projektigraafikut koostada või muud laadi tähtaegu seada.

J lubab kohe, et asjad on nädala lõpuks valmis, aga jätab vahel mõned asjaolud tihti arvestamata, mis lõpeb pikkade ületundidega.
P jällegi katsub konkreetse tärmini väljaütlemisest igati hoiduda, aga see ei tulene mitte laiskusest, vaid  arusaamast, et probleemi lahendamiseks on palju võimalusi ning ta soovib asja kallal lihtsalt vabas vormis nikerdada, et näha, mis välja tuleb.

Projektijuhtimise seisukohalt on oluline kummalegi anda ülesanded, mis neile sobivad: konkreetsed, ajakriitilised asjad J-le ning vabamas vormis (näiteks mõne uue tehnoloogia uurimise) P-le.

Kokkuvõtteks rõhutaks veelkord, et ükski neist tüüpidest pole parem kui teised, aga oma kolleegi, ülemuse, alluva või kliendi loomuse mõistmine aitab kindlasti kõigil oma tööd paremini teha.
Lisalugemiseks veel üks huvitav lehekülg antud teemal: http://www.sfu.ca/~smbarber/educ819.htm

3 responses so far