Archive for March, 2008

Mar 30 2008

Täpsusvastamine

Published by Targo under Analüüs, Juhtimine

 target.jpg

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

captain_answer.jpg

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

kernel.jpg

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

info.gif

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?

One response so far

Mar 24 2008

70 küsimust

Published by Targo under Analüüs, Juhtimine, Kliendid

question.jpg

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.

decision.jpg

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?

clarification.gif

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)

assumption.jpg

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?

critical_thinking.jpg

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?

cause.jpg

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)?

effect.jpg

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?

action.jpg

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).

gay_parade.jpg

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 :)

No responses yet

Mar 19 2008

Täpsusküsitlemine

 informationoverload.jpg

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.

questioning_mind.jpg

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 :)

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

Mar 06 2008

Töörühmad ja meeskonnad

Published by Targo under Juhtimine

teamwork.jpg

Organisatsioonijuhid kasutavad endale alluvaid inimesi kirjeldades tihti sõna “tiim” või “meeskond” (siin ja edaspidi loen ma neid sünonüümideks). Tihti pole see inimeste rühm tegelikult meeskond ja alati ei peagi ta seda olema. Võib juhtuda, et “töörühm” on täiesti piisav antud ülesande lahendamiseks.

  • Tiim on väike rühm üksteist täiendavate oskustega inimesi, kes on pühendunud ühisele eesmärgile, tulemustele ja lähenemisviisile, mille eest nad üksteise ees vastutavad. (Jon Katzenbach, Douglas Smith, “The Wisdom of Teams”)

    Siin on väike test kontrollimaks, kas sa töötad töörühmas või meeskonnas:

Töörühm: Meeskond:
Rõhk on ettevõtte eesmärkidel Rõhk on spetsiifilisel tiimi eesmärgil
Üks tugev liider Jagatud juhtimine
Inimesed on sõltumatud Inimesed sõltuvad üksteisest
Erinevad eesmärgid Ühine eesmärk
Individuaalsed tulemused Kollektiivsed tulemused
Mõningane vajadus koostööd teha Vastastikku täiendavad oskused
Vastastikune toetus aitab inimestel isiklikke eesmärke saavutada Tiimi eesmärgid eeldavad vastastikust toetust
Isiklik vastutus juhi ees Isiklik ja vastastikune vastutus

Töörühmad võivad olla väga efektiivsed ja saavutada kõik isiklikud ja ettevõtte eesmärgid, aga kui meil on vaja saavutada ühine eesmärk või vaja ühiselt luua toode, saavutab efektiivne meeskond tavaliselt parema resultaadi kui töörühm.

Efektiivse töörühma tunnused:

  • Tugev, eesmärgipärane juht
  • Tugev isiklik vastutustunne juhi ees
  • Inimesed rakendavad ülesande täitmisel täielikult oma võimeid
  • Avatud ja konstruktiivne
  • Vastastikune toetus ja motiveerimine eesmärkide täitmisel
  • Efektiivsed koosolekud: arutlus, otsustamine, delegeerimine
  • Hästi planeeritud juhtimisprotsess
  • Jagatakse infot ning saadud kogemusi
  • Saavutatakse nii ettevõtte kui ka isiklikud eesmärgid
  • Sõltumatus

Efektiivse meeskonna tunnused:

  • Jagatud juhtimine või tugev autonoomia
  • Korrapärane meeskonna ja indivudaalsete tulemuste ülevaatamine
  • Selge jagatud nägemus
  • Avatud ja usalduslik
  • Vaidlused lahendatakse kiiresti ja muudatuste osas lepitakse kokku
  • Saavutatakse ettevõtte, meeskonna ja isiklikud eesmärgid
  • Vastastikune toetus ja sõltuvus

Suures organisatsioonis tekivad mitmesugused kombinatsioonid, näiteks minu otseses alluvuses töötavad arendajad moodustavad omavahel arvatavasti töörühma, aga nad kuuluvad samal ajal tugevatesse tiimidesse koos oma analüütikute ja testijatega. Oluline on tähele panna, millise situatsiooniga on tegemist, millal kujundada inimestest meeskond või töörühm, ning rakendada vastavaid juhtimisvahendeid.

No responses yet

Mar 05 2008

Kliima

Published by Targo under Juhtimine

weather.gif

Nagu eelnevalt kirjeldatud, võib inimeste produktiivsus tarkvara tootvas organisatsioonis kõikuda väga suures ulatuses. Suure osa sellest kõikumisest saab võtta kokku terminiga kliima. Kas inimesed tunnevad ennast tööl sombuselt ja depessiivselt nagu igaveses Eesti sügises, lugedes päevi, mis on jäänud kevadeni (ehk siis minuteid tööpäeva lõpuni) või energiliselt ja produktiivselt, soovides anda endast parimat.

Tiimikliimat mõjutavad tegurid võivad olla välised (turusituatsioon, riiklik regulatsioon, võistlevate firmade sammud jne) ja sisemised (töökaaslased, töötingimused, ülemused jne).
Samas on uuringutes selgeks tehtud, et 70-75% kliimat mõjutavatest teguritest sõltuvad töötaja otsesest ülemusest, seega on ülemusel otsene roll produktiivsuse tagamisel.

Siinkohal on muidugi huvitav tähele panna, et paljudel inimestel paljudes organisatsioonides puudub selline asi nagu üheselt määratud alluvushierarhia ja seega ka otsese ülemuse kontseptsioon, selle asemel kasutatakse üht või teist laadi maatriksmudelit. Sellisel juhul jääb kliima eest hoolitsemine mitmete inimeste õlule ja kuna jagatud vastutus on pool vastutust, siis kipub ka ilmastik tiimis tugevasti vahelduma, mis on üks põhjusi, miks mulle isiklikult meeldib rohkem konkreetse alluvusega organisatsioon.

Mõned olulisemad kliima aspektid, mis olenevad otseselt juhist ja mille tagamine peaks olema iga juhi esmaste ülesannete seas:

  • Selgus. Kas inimesed teavad, mida ja miks nad teevad, mis on erinevad jõud ja kes on erinevad osalised, kes mõjutavad projekti ning inimeste karjääri.
  • Paindlikkus. Kui palju on töötajail vabadust oma töö erinevate aspektide üle otsustamiseks, alates töövahenditest ja protsessidest kuni paindliku tööajani.
  • Standardid. Kas inimestele on seatud ühtsed, võrreldavad eesmärgid, mida neilt oodatakse ja mille alusel neid hinnatakse.
  • Vastutus. Kas töötajad tunnevad, et nii nemad ise kui ka nende kolleegid ja juhid on vastutavad oma töölõigu ja konkreetse tulemuste saavutamise eest.
  • Tunnustus. Vastutuse teine külg, kas inimesi tunnustatakse nendesamade tulemuste saavutamise puhul.
  • Tiimitunne. Kas inimesed hoolitsevad kogu meeskonna tulemuste, mitte ainult isiklike saavutuste eest.

Nende aspektide eest hoolitsemine toob tavaliselt kaasa tuntava produktiivsuse ja moraali tõusu.

No responses yet

Mar 02 2008

Staarid

Published by Targo under Programmeerijad

camerondiaz.jpg

Mulle meeldib Cameron Diaz. Tavaliselt on mul üsna kiire ja olen seetõttu filmide osas küllaltki valiv, vaatan enamasti ainult kõrgelt hinnatud filme, aga CD puhul teen erandi ja vaatan teisi ka. Mitte, et see asjana iseeneses kuigi märkimisväärne oleks, aga samamoodi talitavad ka miljonid teised inimesed üle maailma, mistõttu Cameronil on võimalik küsida filmi eest kuni 20 miljonit dollarit. Arvestades, et Charlie’s Angels tõi sisse sadu miljoneid, siis investeering polnud üldse paha.

Mõelgem nüüd, kui Diaze asemel oleks sama rolli mänginud, noh, näiteks Merle Palmiste. Mitte, et ma MP-d kuidagi maha tahaksin teha, aga ilmselt oleks filmi menu olnud vähemalt suurusjärgu võrra väiksem ja see on ka põhjus, miks Merle nii palju raha ei teeni.

merle.jpg

Aga kui filmis oleks olnud näiteks 64 Merle Palmistet, kas see oleks midagi päästnud? Arvatavasti mitte. Samas püüavad mitmed tarkvaraprojektide juhid tihti just nimelt nõnda talitada. Algatatakse võimsa eelarvega suurejooneline projekt ja siis võetakse seda täide viima sada keskpärast programmeerijat. Eelmises artiklis sai juba mainitud, et vahel võib üks programmeerija teha ära sama palju tööd, kui mõnel teisel juhul sada inimest, kuid vahel ei suuda isegi sada inimest luua midagi, mis oleks võrreldav ühe geeniuse tööga.
Näitlejate puhul võib muidugi vaielda, kas nende erinev populaarsus on tegelikult õigustatud, nii et toome konkreetsemalt mõõdetava näite. Tegelen vahel pikamaajooksuga, minu maratonijooksu isiklik rekord on 3:12:11, mis on rahvasportlase kohta täitsa OK. Samas ei tuleks Etioopia koondisele ilmselt kunagi pähe ühe Haile Gebrselassie asemele viiskümmend Targot palgata. Ja niisamamoodi on tarkvara alal asju, millega saavad hakkama vaid vähesed, aga samas on tegu aspektidega, mis annavad ühele produktile võistlejate ees selle üliolulise pisikese edumaa.

Siinkohal puutume kokku ühe ülimalt olulise asjaoluga, mis eristab näiteks tarkvara ja filme paljudest muudest kaupadest. Tarkvara kopeerimise kulu on tootmisega võrreldes olematu ning kui meie staarprogrammeerija on meile selle väikese, kuid olulise eelise andnud, hakkavad inimesed kasutama paremat produkti ja võitja saagiks jääb terve vastav turusegment, tuletagem meelde kasvõi aega, mil Sergei ja Larry internetiotsingusüsteemide maailma pea peale pöörasid.

money.jpg

Nüüd jõuame ühe olulise teelahkmeni, mis tihti tähelepanuta jäetakse: masstoodetud tarkvara ja üksiktellijale tehtav tarkvara on täiesti erinevad maailmad. Masstoodetud tarkvara alal valitsevad väga kõrgelt makstud staarid, samamoodi nagu Hollywoodi massifilmide alal. Microsofti edu kontoritarkvara alal sai suuresti alguse Charles Simonyi palkamisega, kes selle eest ka rikkalikult tasutud sai.
Konsultatsiooniturul, kus tarkvara hakkab kasutama vaid piiratud arv inimesi, pole staarifaktor nii oluline. Samamoodi nagu Eesti galapeole sobib Merle Palmiste külalisena väga hästi ja sinna pole vaja tingimata Hollywoodi staari tuua (kuigi ma arvan, et korraldajad ei ütleks ka sellest võimalusest ära), pole kohalikule bensiinijaamale andmebaasi tegemiseks tingimata vaja superstaari.
Programmeerija produktiivsuse tagamine on muidugi endiselt kriitiline, sõltumata sellest, mida me teeme, aga oluline on tähele panna, et üht liiki turule orienteeritud organisatsioon ei ole niisama lihtsalt ümber kohandatav teisele. Enamiku tarkvarafirmade jaoks on jackpot ikkagi tiražeeritud tarkvara turul, kus liiguvad tõeliselt suured rahad, kuid et seal laineid lüüa, pole võimalik võtta kampa keskpäraseid koodiväänajaid ja neile öelda, et tehke nüüd next big thing valmis, vaja on vähemalt üht staari, kes meeskonda veaks, ning soovitatavalt võiks ka kõrvalosatäitjad Oscariväärilised olla.

3 responses so far