Archive for April, 2010

Apr 27 2010

Kasutajad ja spetsifitseerimine

Neljas loeng projektijuhtimisest.

Siit leiate esialgsed slaidid. Audiot sedapuhku ei olnud – ebaõnn. Võite vaadata eelmise aasta vastavat sissekannet.

Slide1_w600_h450
Ka tänane loeng on suurel määral analüüsist. Aga isegi kui te ise olete ainult projektijuht ja analüüsiga ei tegele, peaksite ikkagi teadma, mis toimub ja kuidas on õige asju teha.
Slide2_w600_h450

Slide3_w600_h450

Slide4_w600_h450

Slide5_w600_h450

Slide6_w600_h450

Slide7_w600_h450

Kes arvab, et kliendil on alati õigus?

Slide8_w600_h450

Slide9_w600_h450

Slide10_w600_h450

Slide11_w600_h450

Slide12_w600_h450
Slide13_w600_h450

Slide14_w600_h450

Olen tihti näinud spetsifikatsioone, mis on lihtsalt üks laam teksti lehekülg lehekülje järel.

Et kui juhtub A, siis kirje B peab liikuma asukohta C.

Välja arvatud juhul kui on täiskuuneljapäev, siis tuleb kirjest D lahutada 15% ja liigutada ta asukohta E

Siis tuleb meil veel liita kokku kirjed F ja G ning saata nad teise süsteemi.

Ja siis kaob kilpkonnaonu vee alla ja mullid tõusevad pinnale. Ja mullid teevad ai-tummer-ker-kommer-ker.

Ja esimese lehekülje lõpuks jäävad kõik lugejad magama.

Slide15_w600_h450
Slide16_w600_h450
Slide17_w600_h450
Slide18_w600_h450
Slide19_w600_h450
Slide20_w600_h450
Slide21_w600_h450
Slide22_w600_h450
Slide23_w600_h450
Slide24_w600_h450

1.Paneme paika mingi konkreetse eesmärgi 2.Esitame küsimuse, “kuidas me teame, kas me oleme eesmärgile jõudmas” 3.Konstrueerime vastava mõõdiku
Slide25_w600_h450

Paljude mõõdikute lähteandmed saa ajaarvestussüsteemidest.

Kunagi ma arvasin, et ajaarvestussüsteemid on kuradist, sest programmeerijaid ei tohi hinnata selle põhjal, kui palju aega nad projektile kulutavad.

Aga ajaarvestussüsteemi primaarseks eesmärgiks pole mitte see, kui palju inimene aega kulutab ja kui kaua ta kontoris istub, vaid hoopis see, millele me organisatsioonina oma ressursid kulutame.

Antud juhul oleks mõõdikuks see, et taskidel, mis on ajaarvestussüsteemis, on olemas ka vastavad väljad selle jaoks, mis sorti hooldusega on tegemist.

Slide26_w600_h450

Äärmiselt oluline tähelepanek: Neid mõõdikuid ei tohi kasutada inimeste töötulemuste hindamiseks!

Slide27_w600_h450
Slide28_w600_h450
Slide29_w600_h450
Slide30_w600_h450
Slide31_w600_h450
Slide32_w600_h450

2 responses so far

Apr 19 2010

Tilk tõrva meepotis

Published by Targo under Juhtimine

bad_apple

Võrreldes seitsme ahvi looga, mille autentsus päris verifitseeritud polnud, kirjutan seekord täiesti pädevast organisatsioonikäitumislikust uurimusest.

Meil kõigil on olnud töökaaslasi, kes ümbritsevate inimeste elu ja motivatsiooni rikuvad. Loodusest on teada, et kui tünnis üks õun mädanema läheb, pole ka teistel pikka pidu. 

Samas arvatakse enamasti, et üksikisiku ja grupi vastuolu puhul pannakse üksikisikud pigem rühma poolt paika, mitte vastupidi. Grupikuuluvus on lõppude lõpuks väga tugev inimesi suunav ning motiveeriv jõud, mida on uuritud aastakümneid. Selgub aga, et mitmesugustest iseloomuomadustest kerkivad üles kolm, mis levivad nakkusena läbi terve grupi. 

Dr. Will Phelps Rotterdam School of Managementist korraldas järgmise katse:

Hulk üliõpilasi organiseeriti väikestesse rühmadesse, kus nad pidid 45 minuti jooksul lahendama ülesandeid ning võtma vastu lihtsaid juhtimisalaseid otsuseid. Edukaimale tiimile oli ette nähtud lahe auhind, nii et kõik olid motiveeritud endast parimat andma.

Osalejate teadmata oli mõnes rühmas aga värvatud isik, kes tegi küll ülesannet kaasa, aga näitas selle juures üles üht kolmest negatiivsest joonest:

jerk

1) Tülinorija tegi teistele häbistavaid märkusi nagu: “nalja teed või?”, “tead sa üldse ärist midagi?” jne. Ka õiendas ta kaaslaste kallal, et nende töö pole piisavalt hea, kuid ei soovitanud ühtki alternatiivi.

wally

2) Laiskleja pani vahepeal jalad lauale ning saatis sõbrale SMSi. Või siis võttis kotist võileiva ning sõi seda. Teistega suheldes kasutas väljendeid nagu “ükspuha” või “mul vahet pole”.

iiah

3) Depressiivne pessimist istus pea maas ja tegi nägu, nagu oleks tema kass just ära surnud. Edasi kurtis ta, et nende ülesanne pole huvitav ning seadis kahtluse alla, kas sellega saadakse üldse valmis.

Kuigi rühmades olid üldiselt tublid ja andekad inimesed ning “tõrvatilk” ei jätnud iseendast tööd tegemata, avaldas tema lisamine dramaatilist mõju. Inimesed hakkasid vaidlema ja tülitsema, vähem suhtlema ja infot jagama. Samuti aga võtsid nad üle vastavad negatiivsed jooned. Tülinorija puhul hakkasid ka teised norima, aga mitte esialgset norijat, vaid ka kõiki teisi. Laiskleja puhul muutusid ka teised ükskõikseks ning pessimisti puhul kaotas kogu rühm oma esialgse erksa hoiaku ning vedeles lihtsalt, pea laual. Varem või hiljem ütles keegi midagi sellist nagu “ah, teeme lihtsalt midagi ära ja lähme”.

Kokkuvõttes oli paljude katsete järel “tõrvatud” rühmade keskmine produktiivsus 30-40% madalam kui teistel! Will Phelps kirjutab veel, et ka mitmetes päris töökohtades läbiviidud uurimuste alusel pole tiimitöö tulemuste ennustamisel parimaks näitajaks mitte parima liikme võimekus ja isegi mitte keskmise tiimiliikme võimekus, vaid kõige halvema, kõige nõrgema liikme oma!

Inimesed, kes nii käituvad, ei tee seda enamasti pahatahtlikult. Tegeliku elu tülinorija arvab näiteks, et ta lõõbib niisama ja loob kamraadlust. Phelpsi eksperimendis teised inimesed tihti naersid tülinorija naljade peale, aga kui neilt hiljem küsiti, kas nad tahaks veel selles tiimis töötada, oli nende vastuseks kindel ei. Pessimist arvab, et ta on lihtsalt aus, aga viib sellega ikkagi teiste energiataset alla jne.

Igal juhul küsin nüüd endalt tihti pärast selle uurimusega tutvumist, kas ma näitan üles üht neist kolmest joonest? Ja kui teie organisatsioonis on keegi taoline, juhtige küsimusele tähelepanu, enne kui terve tünnitäis õunu hukas on.

2 responses so far

Apr 15 2010

Vajadused ja nõuded

Kolmas loeng projektijuhtimisest.

Siit leiate slaidid. Ja siit audiosalvestuse.

slide1_w600_h450
Tänane loeng on suurel määral analüüsist. Aga isegi kui te ise olete ainult projektijuht ja analüüsiga ei tegele, peaksite ikkagi teadma, mis toimub ja kuidas on õige asju teha.
slide2_w600_h450

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

Kui ma veel ise vaene üliõpilane olin, kärutasin vahel maailmas ringi häälega. Üldiselt lahe kogemus, sest rahvas, kes hääletajaid peale võtab, on üldiselt väga kenad inimesed.

Sekka sattus muidugi ka igasuguseid imeinimesi. Oli näiteks üks tegelane, kes ise ka ei teadnud, kuidas täpselt oma sihtkohta jõuda, tema meetodiks oli lihtsalt kohalike käest juhiseid küsida. Mina ei olnud kahjuks kohalik ja eriti aidata ei osanud. Kohalikku keelt ei tundnud me ka keegi ja nii juht seletaski inimestega käte ja jalgade abil. Ise oli ta küllaltki joviaalses tujus ja valis küsimiseks ka rahvast, kelle adekvaatsus minu meelest kõvasti soovida jättis, aga kes olin mina, et teda selle eest kritiseerida, eks.

Ja nii me tiirutasime ja tiirutasime, kuni lõpuks kulus mõnekümne kilomeetri läbimiseks mitu tundi.

Sel ajal oli mul küll teine elustiil ja rohkem aega kui praegu ja viivitusest polnud väga hullu, aga mõnes teises olukorras oleks see küll harja punaseks ajanud.

 Tegelikult on meil siin ilmne analoogia tarkvarategemisega. Me võime tarkvaraprojekti ka läbi viia selliselt, et teema natuke midagi, siis küsime suvaliselt inimeselt instruktsioone, siis teeme jälle natuke, küsime mõnelt teiselt inimeselt jne. Mis te arvate, milliseid ajahinnanguid me sellise meetodi kasutamise korral saame anda?

 Või siis võime hankida endale kaardi.

slide3_w600_h450

Ma olen ise suur kaartide ja kaarditarkvara fänn, katsun alati võimalikult suurt navigeerimisvõimekust omada, kui kusagil käin või sõidan.

Tänapäeval on selleks head võimalused, veebis ja GPS seadmetes olevad kaardid ütlevad meile minuti täpsusega, kuhu me mis ajaks jõuame.

 Ja tarkvara on ka parem teha, kui meil on täpne instruktsioon ees, et nüüd teeme seda ja siis toda. Ajahinnangutest rääkimata.

slide4_w600_h450

Tegelikus elus juhtub aga, et meie tarkvara valmistamise instruktsioonid on pigem sellised. Natuke parem kui turbanis vanamehelt saadud instruktsioonid, aga mitte väga.

Ja ajahinnangud on ka muidugi vastavad.

 Tänane loeng ongi sellest, kuidas oma kaart võimalikult täpseks saada.

slide5_w600_h450

Definitsioonide erisus on peamine segaduse ja kommunikatsiooniprobleemide allikas tarkvaraprojektis.

Definitsioonid tuleb algusest peale paika panna.

slide6_w600_h450

Lugu: HR department vs arendaja nimemuutuse teemal.

slide7_w600_h450

Nõuded tegelikult omaette pikk teema, sestap siin kaetud lühidalt.

slide8_w600_h450

slide9_w600_h450

slide10_w600_h450

slide11_w600_h450

Lõpliku spetsifikatsiooni sisu on tihti tracetav tagasi ärireegliteni.
slide12_w600_h450
slide13_w600_h450
Tarkvara võib olla nt veebisait või pihuarvutite süsteem vms asi
baba-interface
slide14_w600_h450
slide15_w600_h450
slide16_w600_h450
slide17_w600_h450
Näide: tehnoloogiline kitsendus, et me tohime kasutada ainult vaba tarkvara. projekt tehti .neti peale.

slide18_w600_h450
Kui mõni neist osadest jääb alguses kirjeldamata, ei pääse me sellest ikkagi – lõpuks tuleb ta lisada ja see võib tähendada olulist projekti ümbertegemise kulu.
slide19_w600_h450
slide20_w600_h450
slide21_w600_h450
slide22_w600_h450
slide23_w600_h450
slide24_w600_h450
slide25_w600_h450
slide26_w600_h450
slide27_w600_h450
slide28_w600_h450
slide29_w600_h450
Lugu: visioon
slide30_w600_h450
slide31_w600_h450
slide32_w600_h450
slide33_w600_h450

No responses yet