Targo tarkvara

Neljas loeng projektijuhtimisest.

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

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.

Kes arvab, et kliendil on alati õigus?

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.

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

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.

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

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:

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.

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

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.

Kolmas loeng projektijuhtimisest.

Siit leiate slaidid. Ja siit audiosalvestuse.

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.

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.

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.

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.

Definitsioonide erisus on peamine segaduse ja kommunikatsiooniprobleemide allikas tarkvaraprojektis.

Definitsioonid tuleb algusest peale paika panna.

Lugu: HR department vs arendaja nimemuutuse teemal.

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

Lõpliku spetsifikatsiooni sisu on tihti tracetav tagasi ärireegliteni.


Tarkvara võib olla nt veebisait või pihuarvutite süsteem vms asi
baba-interface




Näide: tehnoloogiline kitsendus, et me tohime kasutada ainult vaba tarkvara. projekt tehti .neti peale.

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.











Lugu: visioon