Archive for the 'Juhtimine' Category

Sep 24 2008

Arendajate arengust

 evolution.jpg

On arenguvestluste aeg. Praegu on neljas aasta, mil see ülesanne minu ametijuhendis seisab, ja panen sel teemal lõpuks mõned kogutud mõtted kirja.

Tarkvara tellija seisukohalt näeb projekt välja umbes selline:

tellija_vaade1.jpg

Ehk siis nad eeldavad, et saavad mingi raha eest kaetud ära erinevate valdkondade kompetentsi mingite tarkvarakomponentide osas. Erinevaid komponente võib teostada sama või erinevad inimesed, eeldame siinkohal lihtsuse mõttes, et iga ruutu täidab erinev inimene.

Kui meil tuleb nüüd tööle ilma eelneva kogemuseta nooremarendaja, on tema kompetents tegelikult selline:

arendaja1.jpg

Selge see, et tellijale selline valgete laikude jätmine ei meeldi, sellepärast aitavad meie uut arendajat üldjuhul kolleegid kõrvalruutudest, näiteks inimesed, kes seonduvaid komponente haldavad, annavad tehnilist nõu, analüütik hoiab asjal rohkem silma peal jne.

arendaja2.jpg

Igal inimesel tekib mingi ala, mille raames ta projekti üldist käiku mõjutab. Ja kuna tellija maksab meile lõppkokkuvõttes kogu ruumi täitmise eest, on kasu, mida inimesed projektile toovad, otseselt seotud nende mõjuala suurusega. Teisisõnu, kui palju on teistel teda ümbritsevatel inimestel temast abi, võrreldes sellega, kui palju teised peavad teda järele aitama.

Tegelikus elus tuleb neid dimensioone veel juurde, näiteks saavad inimesed oma mõju avaldada projektijuhtimise ja kliendiga suhtlemise liinis, aga põhimõte jääb samaks.

Ja tavaliselt ei jää inimesed igaveseks ajaks abivajajaks, vaid arenevad nii kaugele, et täidavad oma valdkonna adekvaatselt ära ja hakkavad ise pigem teistele nõu andma:

areng.jpg

Mis on jutu moraal:

See mudel annab meile ka automaatselt meetodi inimeste tulemuste ja kasutoomise hindamiseks. Meil pole vaja lugeda koodiridu ega bugisid ega function pointe ega spetsifikatsioonilehekülgi ega laua taga istutud tunde. Kõik need mõõdikud illustreerivad vaid pisikest lõiku sellest, mida inimene tegelikult teeb, kui paljude teiste projektiosalistega ta suhtleb ja millist kasu ta neile saab tuua, rääkimata asjaolust, et need andmed on väga kergesti võltsitavad :)

Vaja on ainult vestelda kõnealuse inimese kaastöötajatega erinevatest dimensioonidest (arendaja puhul näiteks teised arendajad, tema lähim analüütik, testija, projektijuht, klient jne) ja küsida, millist kasu on inimene X teie vaatekohalt nii projektile kui ka teile endale toonud, ning me saamegi hea pildi sellest, kes on tegelikult väärtuslik, kes mitte.

Kokkuvõtlikud järeldused:

  1. Arendaja loomulik karjääriprotsess on, et ta vajab aja jooksul vähem kõrvalist abi ja hakkab järjest rohkem aitama teisi. Esimeseks sammuks on siin üldjuhul oma loomuliku ruudukese äratäitmine ning teiseks laienemine mõnda kõrvalasuvasse, vastavalt isiklikele huvidele ja projekti vajadustele.
  2. Igal inimesel tuleb ette loomulik piir, millest alates ainult omaenda kitsas töövaldkonnas opereerimine pole piisav, et igal aastal palka juurde küsida, kuna ta on iseenese ruumi lihtsalt ära täitnud. Samas on igas projektis alati küllaga valgeid laike, mille täitmisega rohkem kasu tuua.
  3. Ja kõige olulisemana minu isiklik põhireegel arenguvestluste osas: inimese väärtus projektile on võrdeline talle töökaaslastelt osaks saava respektiga.

No responses yet

Jun 02 2008

Tarkvaraprojekti Maslow hierarhia

car_cliff.jpg

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:

maslow_human1.gif

Laiendades sama ideed tarkvaraprojektile saame aga sellise diagrammi:

maslow_software1.gif

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.

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

4 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

« Prev