Targo tarkvara

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

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

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

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

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

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

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

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

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

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

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

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

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

Rahva soovil panen ka siia kirja loengutes vahel räägitud loo seitsmest ahvist.

Korraldati kord katse, kus kõrgesse ruumi pandi kinni seitse ahvi. Keset lage oli riputatud kimp banaane ja nende alla treppredel. Teatud kõrgusest alates aktiveerisid trepiastmed aga lüliti, nii et kui mõni ahvidest püüdis üles ronida, pritsiti terve tuba üle jääkülma veega.

Ahvid said peagi aru, et parem on redel ja banaanid rahule jätta ja hakkasid muude asjadega tegelema.

Nüüd aga viidi üks ahvidest minema ja tema asemele toodi uus. Uustulnukas märkas kohe banaane ja tahtis neile järele minna. Teised ahvid tirisid ta redelist eemale ja klohmisid natuke, nii et uus ahv sai ka aru, et targem on banaane mitte puutuda.

Nüüd vahetati välja keegi teine. Järgmise ahviga läks samamoodi: tuli, nägi banaane, sai tappa. Tähelepanuväärne on aga see, et kõige rohkem klobis viimast ahvi eelmine uustulnukas, kes polnud üldse veega pritsida saanud!!

Nõnda vahetati järk-järgult välja kõik ahvid, kuni esialgsest seitsmest polnud enam kedagi järel. Keegi ei teadnud külmast veest midagi (pealegi oli see juba ammu välja lülitatud), aga kõik teadsid, et banaane ei tohi võtta ja kõigile uutele tehti see ka kohe selgeks.

Sellisel viisil kujunevadki välja organisatsioonikultuurid.

Kolmas osa Projektijuhtimise loengutest.

Slaidid on siin. Audiosalvestus: 1. osa, 2. osa, 3. osa, 4.osa (right-click -> Save As).

Seekordses loengus pärinevad mõned slaidid minu taipliku kolleegi Ivo Mägi sulest.

Räägin teile kõigepealt ühe loo.

Üks kõige ohtlikumaid olukordi inimese jaoks on lahing sõjas. Piirkond on täis suurt kuumust, ohtlikke aineid, ülehelikiirusega ringi lendavaid metallitükke jne.

Samas, kõige olulisem mõjutaja inimese elus on enesealalhoiuinstinkt. Seega, kui sõduritel on vaja näiteks üle mingi lagendiku rünnaku joosta, on see nende jaoks kõige loomuvastasem asi maailmas.

Sellegipoolest, kui antakse vastav käsk, siis sõdurid tõusevad püsti ja jooksevad üle selle lagendiku.

Miks?

Peamiselt sellepärast, et neisse on pikkade ja raskete õppuste kestel sisse drillitud absoluutne sõnakuulamine. Nad teavad, et käsk on vanem kui meie ja et nende enda elu pole suures plaanis oluline. USA merejalaväelastel pole lubatud kasutada sõna “mina”.

Põhiväljaõppe käigus õpivad sõdurid oma ülemust kartma rohkem kui surma. Sest ülemus on suur ja hirmus (nagu mina). Ülemus ütleb, et jookse ja sõdur jookseb. Ütleb, et lama ja sõdur lamab. Ütleb, et lenda ja sõdur vehib kõigest hingest kätega, et lendu tõusta.

Paljudele tsiviilelu organisatsioonijuhtidele meeldiks oma organisatsiooni samamoodi juhtida. Et aina käsuta ja kõik kohe teevadki nii, isegi kui see nende isiklikele huvidele või enesealalhoiule vastu käib.

Paljud proovivadki nii teha. Paraku küll mitte väga edukalt. Sõjaväes pole sõduril kusagile pääsu – kui ta jalga laseb, siis püütakse ta kinni, pannakse vangi või lastakse maha. Tsiviilelus saadetakse nõme ülemus aga varem või hiljem pikalt või siis lihtsalt ignoreeritakse teda.

See suhtumine on tegelikult väga levinud, mul on endal ka tihti kiusatus olnud karmi käsutamise abil probleeme lahendada. Ja kui ma kunagi oma vennale rääkisin, et minu  tiimi liikmete töö tulemused ei vasta alati päris sellele nagu ma soovisin, oli tema esimeseks reaktsiooniks: kas sa nende suhtes mingeid sanktsioone ei saa rakendada?

Vabandust, vennas, see asi pole paraku nii lihtne.

Kui ma selle habeme ära võtan, siis mina olen endiselt mina.

Tänane loeng on eelkõige inimeste juhtimisest. Suure tõenäosusega te kõik ei hakka oma karjääri jooksul inimesi juhtima, aga üsna kindel on, et keegi hakkab teid ennast juhtima ja siis on hea teada

Kui paljud siin ruumis on suitsetajad? Kas see, et ma seda pilti näitan, paneb teid suitsetamist maha jätma?

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!

Aga kõigepealt sellest, keda meil üldse ühte projekti vaja on. Järgmised slaidid olid mul juba esimeses loengus ka, aga kordamine kulub ära.

http://www.targotennisberg.com/tarkvara/2008/03/02/staarid/

Audiosalvestuse 1. osa lõpp.

http://www.targotennisberg.com/tarkvara/2008/09/24/arendajate-arengust/

Uus arendaja tuleb projekti, ta ei kata veel oma ruudukest täielikult ära.

Teised arendajad, analüütikud, testijad peavad teda abistama.

Aja möödudes saab abi vajajast abi andja, inimese kompetents kasvab.

http://www.targotennisberg.com/tarkvara/2009/01/15/tagasiside-andmisest-ja-saamisest/

Lugu seitsmest ahvist. Kuulake audiosalvestust J

http://www.targotennisberg.com/tarkvara/2008/06/06/eduka-projekti-retsept/

Audiosalvestuse 2. osa lõpp.

http://www.targotennisberg.com/tarkvara/2008/02/25/programmeerija-produktiivsus-i/

Audiosalvestuse 3. osa lõpp.

Arenguvestluste teema on jälle päevakorral ja nagu kunagi eelnevalt kirjutasin, on minu silmis väga olulisel kohal kaastöötajate poolt inimesele antav tagasiside.

Aga tagasiside teemal üks lugu, ei mäleta enam, kust see pärit on, aga loo jutustaja nimi oli Laura.

Laura elas väiksemat sorti kortermajas. Ühel päeval kuulis ta alumiselt korruselt, kuidas naaber (naabri nimi oli Susan) mängib trummi – pumm, pumm, pumm. Ja varsti oli jälle vaikus. Siis mingi aja pärast mängiti jälle trummi, siis oli jälle vaikus. Laura oli üldiselt küllaltki tolerantne inimene ja talle oli oluline naabritega hästi läbi saada, sellepärast otsustas ta, et ei tee asjast välja. Milleks ikka pinget tekitada, eks.

Järgmistel päevadel ja nädalatel kestis trummimängimine aeg-ajalt edasi ja muutus siis sagedasemaks, vahel mängiti hommikul, vahel päeval, siis ka kell kümme õhtul. Pummadi-pummadi-pumm-pumm. Nüüd läks Laural kops üle maksa. Aitab naljast. Tormas, endal pidžaama seljas, oma korterist välja ja alla korrusele ja prõmmis ukse pihta. Susan teeb ukse lahti ja vaatab Laurale ärevuses otsa.

Laura: Mida kuradit sa õige mõtled, et sa teed???

Nüüd Susan, selle asemel, et vastu karjuma või vaidlema hakata, ütleb Laurale: Hm, sa oled tõesti vihane, tule sisse.

Laura astub sisse ja räuskab edasi. Bla-bla-bla.

Susan kuulab ega ütle midagi vastu, küsib ainult: millal ma seda teen? Kui vali see on?

Laura vastab neile küsimustele ja tunneb samas, et ta rahuneb maha.

Ja äkitselt nad lihtsalt räägivad läbi küsimuse osas, mis tundus esmapilgul täiesti mustvalge!

Ja lepivad kokku, et OK, las Susan mängib päeval oma trumme, aga mitte liiga valjusti.

Jutul on mitu moraali:

Tagasiside andmise osas on inimesed tihti kahes äärmuses – nad kas ei räägi asjadest üldse või siis reageerivad üle. Oluline on siinkohal mingi mõistuslik kesktee leida ning rääkida probleemidest kohe, kui need ilmsiks tulevad.

Tagasiside saamise osas võtavad inimesed tihti kaitseasendi ning hakkavad vastu vaidlema, ilma süüvimata, milles teise inimese probleem tegelikult seisneb ja kas seal on võimalik kompromisse saavutada. Ülikergesti oleks praegu võinud juhtuda, et naised oleks lootusetult konflikti sattunud ja kumbki poleks saavutanud, mida ta tahtis, aga sellegipoolest osutus võimalikuks olukord päästa.

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:

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:

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.

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:

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.

Mitmesuguste uuringute põhjal on leitud, et ligi pooli alustatud tarkvaraprojekte võib lugeda ebaõnnestunuks. Seega, kui lugejal on olnud tegemist mõne tarkvaraprojektiga, on suure tõenäosusega olemas ka kogemus mõne puusse läinud projektiga. Huvitav on aga jälgida, milliseid abinõusid selle puhul ette võetakse. Selgub näiteks, et inimesed on õnnetud ja rahulolematud, mida teha? Juhtkond korraldab neile kõva peo, uskudes, et selle abil saab kõik korda, aga kas see oli tegelikult asi, mida vaja?

Steve McConnell laiendab oma suurepärases raamatus “Software Project Survival Guide” Maslow hierarhia ideed tarkvaraprojektidele.

Järgneval skeemil on klassikaline Maslow hierarhia inimeste kontekstis:

Laiendades sama ideed tarkvaraprojektile saame aga sellise diagrammi:

Ja nagu inimeste puhul, pole meil mõtet tegeleda hierarhia ülemiste osadega, kui alumised on rahuldamata. Oletame, et mul on paha tuju. Sõbrad kutsuvad mind kinno, et asja parandada, aga see ei muuda midagi, kui minu probleem on tekkinud hoopis sellest, et mul on kõht tühi! Samamoodi ei aita inimestele peo korraldamine, kui probleemiks on see, et tähtajad on ebarealistlikud ning inimesed peavad kogu aeg ületunde tegema.

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:

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?

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.

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.

Eelnevalt käsitletud täpsusküsitlemise teema lõpuks ka natuke juttu vastamisest. Ka kõige konkreetsem, täpsem ja asja tuumani tungivam küsimus pole suurt midagi väärt, kui sellele vastata pikalt, laialivalguvalt ja mitteasjassepuutuvalt.

Hoiatuseks muidugi, et jutt käib endiselt tööalastest vestlustest, kus tuleb mingit konkreetset probleemi lahendada. Kodus naisega rääkides pole selline kõneviis ilmselt kuigi edukas Igapäevaelus on küllaltki tavaline, et küsimusele ei vastata otse või välditakse vastamist üleüldse. Kui näiteks pärast kinoskäiku küsida, kuidas film meeldis, vastatakse sellele tihti hoopis kommentaaridega sellest, kui palju kinos rahvast oli ja kuidas paks mammi näris kõrvalistmel kogu aeg popkorni.

Kui meil on vaja ärilisi otsuseid teha, olukorrast ülevaadet saada või probleemi uurida, on abiks aga kolm reeglit:

1. Vasta küsimusele

Näide.
Küsimus: kas me oleme graafikus?
Vastus: me seadsime projekti alguses pingelised tähtajad ega oodanud partnerite poolset viivitust. Samuti unustasime me pühadeperioodi graafikusse lisada.

Selle asemel, et küsimusele vastata, hakkas vastaja pajatama lugulaulu graafiku saamisloost, mis pole üldjuhul antud punktis üldse oluline. Parem variant oleks:

Küsimus: kas me oleme graafikus?
Vastus: Ei, me oleme kaks nädalat maas.

Me saame vestlusega edasi liikuda ega pea olulisi infokillukesi õngitsema ja filtreerima.

2. Alusta vastuse tuumast

Enne pikema selgituse andmist on hea vastuse põhiolemus edasi anda, et vastaspool ei peaks pinevalt mõtlema selle üle, kuidas sinu jutust olulist tabada ja saaks keskenduda lihtsalt info vastuvõtmisele.

Näiteid headest tuumvastustest:

• Jah
• Ei
• <Mingi arv>
• <Mingi tähtaeg>
• Ühelauseline vastus
• Bullet pointid (lühidalt)
• Ei tea (selle asemel, et pika ja ähmase jutuga seda peita)

3. Anna vajalik lisainfo, aga lühidalt

Siin on abiks tähele panna, et kui küsija on see, kes peab otsuse langetama, aitavad teda kõige rohkem konkreetset ja täpsed vastused. Kui tal on vaja rohkem teada, küsib ta juba ise edasi (eeldusel muidugi, et tegemist on inimesega, kes oskab küsida).

Lisaks eelpooltoodule saab vastaja kasutada muidugi ka teisi võtteid:

- Selgitamine.
Küsimus: Mis on praegu kõige tähtsam asi, millega sa tegeled?
Vastus: Kas kõige tähtsam kliendi või ajagraafiku seisukohalt? (selle asemel, et mõlemat varianti lahti seletada)

- Ümbersuunamine.
Küsimus: Kuivõrd see projekt meie kasumit suurendab?
Vastus: Ei suurendagi. Eesmärk on kvaliteedi tõstmine.

- Riskikontroll.
Kui paistab, et eelnevate küsimustega on midagi olulist vahele jäänud, võib kumbki pool küsida midagi üldist stiilis:
Küsija: Kas on veel midagi, mida ma graafikust mahajäämise kohta peaksin teadma?
või
Vastaja: Riskianalüüs on muutnud, kas ma saaks selgitada, enne kui me teemat vahetame?

Eelmises postituses sai mainitud, et iga sisuka lause kohta on võimalik küsida 70 erinevat küsimust, mis kõik annavad lisainformatsioonikillukesi, mille põhjal on palju prem mitmesuguseid otsuseid vastu võtta.

Selline lähenemine on osa täpsusküsitlemise (Precision Questioning) metoodikast, kus vestlust suunatakse lühikeste konkreetsete küsimuste ja vastustega. Erinevalt tavalisest diskussioonist, kus vastaja kontrollib, kui palju ja millist infot edastada, kontrollib vestlust küsitleja. Lühikesed küsimused/vastused:

• Võimaldavad vastajal probleemi paremini läbi mõelda
• Lasevad küsijal probleemi samm-sammult uurida
• Ei ujuta küsijat liigse infoga üle
• Lasevad küsijal esitada lisaküsimusi

Vaatleme nüüd järgmist näidet: projektijuht Joosep tormab sisse ja edastab klient Kustavilt järgmise hädasõnumi: “Süsteem ei skaleeru ja kukub kogu aeg kokku!!!”
Milliseid küsimusi oleks meil täpse tegevuskava koostamiseks võimalik küsida? Hea lugeja võib paberile kirja panna, mitu küsimust ta kokku saab  

NB: Oluline on vahet teha täpsetel ja ebatäpsetel küsimustel. Täpsed küsimused hoiavad vestlust laiali valgumast, allpool on näiteid nii täpsetest kui ka ebatäpsetest küsimustest.

PQ metoodikas jagatakse küsimused seitsmesse kategooriasse, hea küsitleja leiab vähemalt 10 küsimust igast kategooriast.

1. Metaküsimused (kas probleem on uurimist väärt?)

Näiteid ebatäpsetest küsimustest:
1. Kes me peame sellest praegu rääkima? (Joosepi arvates kindlasti peame)
2. Kellele see korda läheb? (Joosepile ilmselgelt läheb)

Näiteid täpsetest küsimustest:
1. Mida me tahame kohe praegu selle vestlusega saavutada?
2. Kui kiire selle probleemiga on?
3. Kui tähtis see muude probleemide kõrval on?
4. Kui palju aega me saame selle arutamisele kulutada?
5. Kas mina olen õige inimene sellega tegelemiseks?
6. Kelle me veel peaksime siia kutsuma, et asja arutada?
7. Kelle probleemi me katsume lahendada? (Kustavi? Joosepi? Minu?)
(Teiste kategooriate küsimuste vahepeal)
8. Kas me keskendume õigele probleemile?
9. Kas meil on vaja vahepeal järele mõelda?
10. Kas me läheneme probleemi tuumale?

2. Selgitavad küsimused

Näiteid ebatäpsetest küsimustest:
1. Mismõttes? (laialivalguv)
2. Mida tähendab “kukub kokku”? (avab ukse pikale seletusele, mis väljub üks küsimus/üks vastus raamidest)

Näiteid täpsetest küsimustest:
1. Kas skaleerumise all on mõeldud horisontaalset või vertikaalset skaleerumist?
2. Kas kokkukukkumise all on mõeldud crashi, hangumist, aeglast reageerimist või midagi muud? (valikvastustega küsimused on üldjuhul paremad avatud küsimustest)
3. Millal see juhtus?
4. Kus see juhtus?
5. Kui tihti see juhtub?
6. Mis on trend?
7. Kui kaua probleem on kestnud?
8. Millist versiooni nad kasutavad?
9. Mis on kasutatavate masinate parameetrid?
10. Joonista graafik, kus on näidatud jõudluse sõltuvus mõjuritest (eeldab, et me oleme põhjuste kategooriast juba ühtteist küsinud)

3. Küsimused eelduste kohta

Eeldus tähendab antud kontekstis midagi, mille tõesus on vajalik selleks, et esialgne väide oleks tõene.

Näiteid:
1. Kas tegemist on viimase, meie poolt toetatava versiooniga? (oluline eeldus, mille ignoreerimine tihti palju aega kulutab)
2. Kas süsteemi kasutatakse sihtotstarbeliselt?
3. Kas probleem on tegelikult meie süsteemis või sellest väljaspool?
4. Kas nende mõistes skaleeruvus on tegelikult mõõdetav?
5. Kas skaleeruvus sellest punktist edasi on oluline?
6. Kas tegemist on ühe konkreetse probleemi või mitme kokkusegatud probleemiga?
7. Kui põhjuseid on mitu, siis kui palju neid on?
8. Kas nende probleemide (või põhjuste) koos vaatlemine omab mõtet?
9. Kas kliendi definitsioon skaleerumisest/kokkukukkumisest on sama, mis meie oma?
10. Milline on nende definitsioon?

4. Kriitilised küsimused

Kriitilise küsimuse eesmärk on teada saada, “kuidas me teame, et info on õige” (sest paljudes olukordades, näiteks situatsioonis, kus keegi meile midagi müüa proovib, ei pruugi see nii olla). Antud näitelause puhul tundub ehk, et me pinnime Kustavit liiga palju ja usaldusliku suhte puhul pole kõiki neid küsimusi vaja küsida, aga kindlasti leiab situatsioone, kus kõik need näited marjaks ära kuluvad.

Näiteid ebatäpsetest küsimustest:
1. On see tõesti nii?
2. Kust sa tead?
3. Miks sa nii arvad?

Näiteid täpsetest küsimustest:
1. Kas kliendi kirjeldatud olukord on tegelikult võimalik? (tegu võib olla moonutatud infoga)
2. Kas olukord on tegelikult spetsifitseeritud parameetritest väljas?
3. Millised andmed neil on?
4. Kes neid andmeid kogus?
5. Kas inimene, kes neid kogus, on meie silmis usaldusväärne (või on tegemist karjapoisiga, kes viiendat korda hunti hüüab?)
6. Kas andmed on statistiliselt pädevad?
7. Kas tegemist on kvalitatiivselt või kvantitatiivselt mõõdetud andmetega?
8. Kas see lähenemine (kvalitatiivne vs. kvantitatiivne) on antud kontekstis korrektne?
9. Kes oli isik, kes Joosepile teate edastas?
10. Miks me peame sellele probleemile reageerima?

5. Küsimused põhjuste kohta

Näiteid ebatäpsetest küsimustest:
1. Mis selle põhjustas?
2. Miks see juhtus?

Näiteid täpsetest küsimustest:
1. Mis oli vahetult “kokkukukkumisele” eelnev sündmus?
2. Millised muud tegurid peavad mängus olema, et eelnenud sündmus mõju avaldaks?
3. Millised faktorid süsteemi mõjutavad (kasutajate arv, kirjete arv, kirjete suurus, võrgu kiirus, võrgutopoloogia, arvutite parameetrid jne)?
4. Millised neist faktoritest soodustavad probleemi esiletulekut?
5. Millised aitavad probleemi vältida?
6. Milline on seos nende faktorite esinemise vahel (korrelatsioon, juhus)?
7. Kas nende faktorite mõju on lineaarne? Polünomiaalne? Eksponentsiaalne?
8. Millised on süsteemis ilmnevad tagasisidetsüklid?
9. Kas me peame uurima mõjufaktoreid omakorda mõjutavaid faktoreid (kaudseid tingimusi)?
10. Kas me peame uurima faktoreid muudest kategooriatest (peale tehniliste näiteks kasutajate harjumused)?

6. Küsimused tagajärgede kohta

Näiteid ebatäpsetest küsimustest:
1. Mis selle tagajärjed on?
2. Ja edasi?

Näiteid täpsetest küsimustest:
1. Milline on mõju süsteemile endale (jääb pärast “kokkukukkumist” ebastabiilseks, stabiliseerub)?
2. Milline on mõju andmetele (kas midagi läheb kaduma)?
3. Kui paljusid kasutajaid see mõjutab?
4. Kui kaua süsteemi taastumine võtab?
5. Millised on muud kõrvalmõjud?
6. Mis on “kokkukukkumise” halvimad võimalikud tagajärjed?
7. Mis on vähim halvad võimalikud tagajärjed?
8. Millised eelpool uuritud tagajärgedest on tavalised (vs. harvaesinevad)?
9. Kas süsteem on mittelineaarne (s.t tagajärjed mõjutavad põhjuseid ja tekitavad võimenduva tagasisidetsükli)? Hoiatav lugu: tegelesin kord veebiserveriga, kus iga timeout’i puhul saadeti kusagile vearaport. Saatmine nõudis aga lisaressursse ja suurendas timeout’ide tõenäosust, mis omakorda põhjustas lisaraportide saatmist jne, kuni ajutisest probleemist sai crash.
10. Milline on mõju meie ärisuhtele?

7. Tegevuskava alased küsimused

Näiteid ebatäpsetest küsimustest:
1. Mida peaks tegema?
2. Kuidas vastata?

Näiteid täpsetest küsimustest:
1. Mida peaksin mina isiklikult tegema?
2. Mida peaks programmeerija Priit tegema (eeldusel, et me oleme kindlaks teinud, et Priit on õige inimene probleemiga tegelema)?
3. Kelle abi Priidul vaja läheb?
4. Millal me selle valmis saaks?
5. Kas me saame Kustavile vastava lubaduse anda?
6. Millised on vahe-eesmärgid (kui parandus on üleantav mitmes osas)
7. Kas parandus on ajutine või pikaajaline?
8. Kuidas sobib paranduse tegemine Priidu järgmise nädala kavadega?
9. Kuidas sobib paranduse tegemine firma üldise strateegiaga?
10. Kas meil on alternatiivseid lahendusi?

Tegelikult tuli pähe veel terve hulk muidki küsimusi, aga kõiki pole mõtet kirja panna, toodud näidetest piisab. Harjumus ja oskus mitmesugustes olukordades selliseid küsimusi küsida aitab nii mõndagi probleemi efektiivsemalt lahendada (lisaks on tegemist hea ajutrenniga).

Harjutamiseks võiks võtta mõne suvalise poleemilise teema (näiteks: “Homoparaad Tallinnas demonstreerib Eesti ühiskonna arengut paremuse (või halvemuse, vastavalt väitleja seisukohale ) poole”) ning selle kohta täpseid, konkreetseid küsimusi küsida, nendele lühidad, konkreetsed vastused välja mõelda ning siis vastuste põhjal küsida uusi uurivaid küsimusi. Vaadake, kui kaua vastas seisev poliitik või müügimees või muu tegelane, kes midagi tõestada püüab, vastu peab

Esimene juhtum. 

Tarkvarafirma Joostes Marss sai hiljuti valmis Hulkuvate Kasside Riikliku Inspektsiooni infosüsteemi uue versiooniga. Pärast paigaldamist selgus aga, et vähemalt klient Kustavi arvates ei kõlba süsteem kassi saba allagi. Parandati-täiendati ja paigaldati uuesti, aga ikka ei kõlba. Veel üks kord ja ikka sama lugu. Lõpuks saadeti Kustavi juurde analüütik Anton, kes viimaks selgeks tegi, mida Kustav tegelikult tahab, aga vahepeal oli möödunud mitu kuud asjatut ajakulu.

Teine juhtum.

Projektijuht Joosep küsib programmeerija Peetrilt, kas töö on valmis. Peeter vastab, et üldiselt on valmis, aga natuke tuleb veel refaktoreerida ja seletab pool tundi, kuidas on väga halb, kui IFoo sõltub IBarist. Järgmisel päeval sama küsimuse peale vastab Peeter, et veel on vaja natuke debugida ning täidab taas Joosepi kõrvad tehnilise žargooniga, kuni viimane ehmunult põgeneb. Nädal hiljem räägib Peeter, et kuna Priidu komponendis on vaja mälulekkeid parandada, ei saa ta ka enda asju üle anda. Joosep on vahepeal Kustavile lubanud, et töö antakse kohe üle ja mõlgutab nüüd musti muremõtteid.

Kolmas juhtum.

Tippjuht Tõnis tahab teada, kas panustada AS HüperKonsultantide pakutavasse uude supermodernsesse tootmismetoodikasse. Analüütikud kiidavad, programmeerijad laidavad, müügimehed näitavad värvilisi slaide, kõik on väga emotsionaalsed ning Tõnise peas valitseb kaos. Lõpuks otsustab Tõnis pakkumise vastu võtta, sest tema naine käib HüperKonsultantide bossi naisega koos spaas.

Neljas juhtum.

Joostes Marss teeb Kustavile vägeva demo ja Kustav kirjutabki alla uue sajamiljonilise lepingu. Hiljem selgub aga, et valminud süsteem ei toeta üldse nii paljusid kasutajaid, kui palju Kustavi asutuses töökohti on, samuti ka mitte nõutavaid andmemahtusid. Teha pole aga midagi, sest vastavaid sätteid pole lepingusse üles tähendatud.

Põhimõtteliselt saab kõiki neid situatsioone lahendada, rakendades õigel hetkel kriitilist mõtlemist ja küsides suure hulga väga konkreetseid ja täpseid küsimusi. Täpsusküsitlemine(Precision Questioning) on üks metoodikaid, mis õpetab selliseid küsimusi süsteemselt esitama, kuigi ma ei tea, kas Eestis keegi selle levitamisega on tegelenud. NB! PQ ei asenda kindlasti tavalist suhtlemist, vaid on lihtsalt üks vahendeid, mida teatud situatsioonides kasutada!

PQ põhineb formaadil üks lühike küsimus/üks lühike vastus, mille põhjal küsitakse järjest uusi küsimusi. Rohkete küsimuste esitamine soodustab kriitilist mõtlemist ning lühike formaat samm-sammulist lähenemist, mis aitab hoida teemat laiali valgumast ja laseb küsitlejal oma peas asjadest selge ülevaate saada.

Tavaelu PQ näited on näiteks ristküsitlemine kohtus, suuline eksam ülikoolis või presentatsioon riskikapitalistidele. Tarkvaraga seotud situatsioonid on mitmesuguste spetsifikatsioonide inspekteerimine, kliendi vajaduste kaardistamine, kriitilises seisus projekti olukorrast ülevaate saamine ja muidugi kõik rahakulutamisega seotud juhtumid.

Ühisteks joonteks on siin:

• Olukord, kus kogu info ei pruugi tingimata tõene olla
• Vigade tegemisel on tõsine hind
• Materjali loomus võimaldab samm-sammulist lähenemist

Näide (Edit: see näide on natuke utreeritud, tegelikkuses on täitematerjali muidugi natuke rohkem, aga infoedastuse seisukohalt jääb mõte samaks):
Küsimus: Kas teine moodul saab neljapäevaks valmis?
Vastus: Jah, tegelikult isegi kolmapäevaks.
K: Ja prototüüp saadetakse Kustavile reedel?
V: Ei, sellega läheb järgmise teisipäevani.
K: Millest see viivitus?
V: Kaks põhjust, Priidul läheb töö ülevaatamisega kauem aega ja kujundajatel pole ikoonid veel valmis.
K: Kas Priidu viivitust oleks saanud ette näha?
V: Ei, tal oli vaja projekt Dünamo jaoks mõned kriitilised vead ära parandada.
K: Kas see võib põhjustada täiendavaid viivitusi?
V: Hetkel ei tea, küsin Priidu käest.
K: Miks ikoonid veel valmis pole?
V: Rudolf libises vannitoas seebi otsas, vigastas kätt ega saanud paar päeva tööle tulla.
K: Mida see viivitus meie jaoks tähendab?
V: Pikas perspektiivis on kõik korras, lühiajaliselt peame paar päeva ületunde tegema.
K: Kas lõpptähtajaks saab kõik valmis?
V: Praeguse arvestuse järgi jah.
K: Kas miski võib selles osas muutuda?
V: Ma olen mõelnud, mis saab, kui Dünamoga muid probleeme tekib.
K: On see tõenäoline?
V: Ei tea, räägin nendega homme ja küsin.
K: Mis on halvim võimalik stsenaarium?
V: Nad jäävad hiljaks ja põhjustavad meile lisaviivitusi.
K: On meil võimalik Dünamo asemel midagi muud kasutada?
V: Probleem pole otseselt nende viivituses, vaid selles, et testijad on siis kõik Dünamo peal ega saa meie projektiga tegeleda.

Ilmselt on selge, et tegemist pole tavalise jutuajamisega, vaid üks pool juhib vestlust väga konkreetse infokogumise eesmärgiga ning teine aitab talle kaasa, vastates konkreetselt ainult sellele, mida talt küsitakse, ilma et tekiks infoüleujutust. Mõistagi on vajalik, et pooled mängivad samade reeglite järgi ning igapäevases tavasuhtluses ei tule selline formaat kõne alla, kuid teatud situatsioonides on täpsusküsitlemine väga vajalik oskus.

Milliseid küsimusi küsida, sellest tuleb juttu järgmistel kordadel, luban vekslina, et suvalise keskmiselt informatiivse lause kohta on võimalik küsida 70 erinevat küsimust