Archive for March, 2010

Mar 25 2010

Tarkvaraprojekti planeerimine

2010 Projektijuhtimise kursuse teine loeng.

Siit leiate slaidid. Ja siit audiosalvestuse.
Vaata ka eelmise aasta materjale.

slide1_w600_h450
slide2_w600_h450

Ma olen üsna kindel, et enamikul teist tuleb kunagi ühel või teisel viisil sellises situatsioonis olla.

slide3_w600_h450
slide4_w600_h450

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

slide5_w600_h450
slide6_w600_h450
slide7_w600_h450

Millal me loeme projekti edukalt lõpetatuks?

slide8_w600_h450
slide9_w600_h450

Aga kes loeb XKCD-d? Ma võtan teid oma kampa!

slide10_w600_h450
slide11_w600_h450
slide12_w600_h450
slide13_w600_h450

Tuletame meelde seda 24 kuu vs 6 kuu juhtumit eespool.

slide14_w600_h450
slide15_w600_h450
slide16_w600_h450
slide17_w600_h450

Mida teha, kui sulle ikkagi survet avaldatakse, et asjad peavad saama kiiremini ära tehtud?

slide18_w600_h450
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

Enne, kui me edasi läheme, arutame, miks järgnevad asjad meile üldse vajalikud on.

slide29_w600_h450
slide30_w600_h450
slide31_w600_h450
slide32_w600_h450
slide33_w600_h450
slide34_w600_h450
slide35_w600_h450
slide36_w600_h450
slide37_w600_h450

Kommunikatsiooniplaani mõte on selles, et keegi ei unune ära ega teki situatsiooni, kus mitme kuu ärel teatatakse, et asjad ei kõlba kusagile ja tuleb ringi teha.

slide38_w600_h450
slide39_w600_h450

Näide: kui meil on olemas nõuete kogumise abivahend, siis see ei tähenda, et meil oleks äkitselt olemas ka adekvaatsed nõuded!
Nõuete saamiseks tuleb endiselt vaeva näha!

slide40_w600_h450
slide41_w600_h450

One response so far

Mar 11 2010

Tarkvaraprojekti alustamine ja riskid

Alanud on taas projektijuhtimise kursus ja siia tekivad minu loenguslaidid – võrreldes eelmise aastaga väikeste muudatustega.

Siit leiate slaidid. Ja siit audiosalvestuse

Vaata ka eelmise aasta materjale.

slide1_w600_h450
slide2_w600_h450

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

Juba antiikajal tegid inimesed vaatlusi ümbritsevate protsesside kohta.

Taigent sai muuta leivaks, savi tellisteks, puid söeks, rasva seebiks.

Mõistagi tekkis neil ka küsimus, et miks ei saaks näiteks raud muutuda kullaks?

Tuhanded alkeemikud nägid selle probleemi kallal sajandite jooksul vaeva. Kuna neil aga puudus arusaam sellest, millest erinevad ained ja materjalid tegelikult koosnevad ning kuidas nende omavaheline vastasmõju tegelikult töötab, ei saanud nende lähenemine ka kuigi süsteemne ja teaduslik olla.

Nad kuumutasid ja aurutasid, filtreerisid ja kondenseerisid, segasid kokku kõikvõimalikke aineid ning kirjeldasid oma tulemusi müstilises, allegoorilises keeles, et “asjasse pühendamata” inimesed millestki aru ei saaks.

Sagedased koostisosad olid näiteks väävel ja elavhõbe, usuti, et kui neid vaid õiges vahekorras lisada, saab nende abil kõike teha.

Ja alkeemikud kallasid ühest purgist väävlit ja teisest elavhõbedat ning laususid veel nõiasõnu peale – habbada-habbada-habbada.

slide1_w600_h450

Inimestel on siiski süüa ka vaja ja alkeemikud pakkusid tihti oma teenuseid kuningatele ja vürstidele, et viimased nende eksperimente rahastaks.

Ahnusel on suured silmad ja seetõttu maksiski nii mõnigi võimukandja alkeemikule heldelt, vähemalt esialgu. Pikapeale sai kuninga kannatus muidugi otsa ja ta hakkas konkreetseid tulemusi nõudma.

Kui muidu enam ennast välja keerutada ei õnnestunud, läks nii mõnigi alkeemik lõpuks võltsimise teed ning seadis üles demonstratsiooni, kus kullakangid olid algul näiteks tinaga kaetud, tina sulatati pealt ära ja nähtavale tuli kuld.

Kui nad aga sellega vahele jäid, oli karistus tavaliselt karm. Tihti rakendati sama karistust, mis valeraha tegijate puhul, ehk kallati õnnetule alkeemikule sulatina kurku.

Väga, väga ebameeldiv.

slide4_w600_h450

Aeg läks edasi. Matemaatikal oli tegelikult juba antiikajast saadik päris korralik ja range teaduslik põhi all olnud. Renessansi ajal tegi Galilei oma katseid, talle järgnesid Torricelli, Blaise Pascal ja Robert Hooke ja füüsika sai endale samasuguse range põhja.

Lõpuks jõudsid Robert Boyle, Lavoisier, Lomonossov ja Mendelejev ka keemiale range põhja loomiseni ja alkeemikute aeg oli lõppenud.

Sarnaselt juhtuvad revolutsioonid ka teistes teadustes, nad käivad alguses läbi oma “alkeemia faasi”, kus keegi täpselt ei tea, mida ta teeb. Vähehaaval saadakse asjad korda ja meil tekivad konkreetsed seadused, reeglid ja valemid.

Infotehnoloogia vallas käib tarkvaraprojektide juhtimise praktika käib praegu täpselt nagu alkeemia. Projektijuhid teavad, et tarkvara tegemiseks on vaja raha ja programmeerijatele meeldivad kohvijoogid. Ja nii nad lisavadki projektile erinevates vahekordades raha ning kofeiini, täpselt nagu vana aja alkeemikud lisasid erinevatele ainetele väävlit ja elavhõbedat. Ja siis lähevad kliendi juurde ja teevad kliendile habbada-habbada-habbada.

Ja nagu alkeemikute puhulgi, on üsna tõenäoline, et ilma teaduslikuma lähenemiseta lasete te üsna palju projekte kas põhja või viite kuidagi katse-eksituse teel lõpule.

Kui te seda piisavalt palju teete, siis lähevad teie projektiliikmed, ülemused ja kliendid samamoodi närvi nagu keskaegsed kuningad ja nendes tekib soov teid mingil väga ebameeldival viisil hukata.

Praeguse loengusarja eesmärk on teid sellest hullust saatusest päästa, ehk et keegi ei tuleks teile sulatinaga kallale.

See, et te kõik olete tulnud kuulama loengut projektijuhtimisest, ei tähenda veel, et te saate tingimata projektijuhiks, aga suure tõenäosusega hakkate te mitmesugustes tarkvaraprojektides mingis rollis osalema. Võib-olla tellija, võib-olla täitja poolel, vahest programmeerijana, vahest analüütikuna, vahest suure ülemusena.

Sellegipoolest, kuna projektijuhid on projektides kesksel kohal, puutute te nendega kindlasti kokku ja siis on väga hea, kui teil on olemas mingid praktilised nõuded, mida neilt projektijuhtidelt soovida ja kui nad sellega hakkama ei saa, siis saate ise esile astuda ja vajalikud asjad ära teha.

slide5_w600_h450
slide1_w600_h450
slide1_w600_h450
Projektiga tegelejad rajasid süsteemi lähtudes tavaliste kontoritöötajate kogemustest, inimestel on tööjaam, kohtvõrk, andmed jooksevad kõik andmebaasist jne. Ainult et FBI agendid ei ole tavalised kontoritöötajad, nad liiguvad “objektidel” ringi ja neil on vaja andmeid kaasa võtta ning ka offline’is sisestada. Ja keegi ei tulnud ka selle peale enne, kui süsteemi juurutama hakati. Kui palju võtab aega olemasolevale süsteemile turvaliste offline-võimaluste juurdepookimine, võib igaüks ise nuputada, kuid antud projekt katkestati (selle ja paljude, paljude muude probleemide tõttu) pärast 170 miljoni dollari maksumaksja raha kulutamist. Kui vajadused oleks tuvastatud õigeaegselt, oleks kogu süsteemi loodud hoopis teistel alustel ning tohutu hulk aega oleks jäänud raiskamata.

slide2_w600_h450
Projektijuhi roll on tihti arusaamatuste ja segaduse allikaks.

Juhtkonna stereotüüp: klient ja programmeerija ei tohi kokku saada, projektijuht kaitseb neid teineteise eest

Tehniku stereotüüp: projektijuht on mingi pintsaklipslane, kes tegelikult asjadest midagi ei tea ja keda asjadest eemal hoida

Olen ise kuulnud programmeerijat halvustavalt mainimas “projektijuhtide invasiooni Eesti tarkvaramaastikul”. Probleem jällegi selles, et kui näiteks programmeerija töö on ka praktikas viidud küllaltki teaduslikele alustele, siis projektijuhid on tihti endiselt alkeemikud. Tegelikult on ka projektijuhtidel olemas täiesti teaduslikud reeglid, kuidas üht projekti edukalt lõpuni viia, täpselt nagu meil on olemas reeglid selleks, kuidas võrrandisüsteemi lahendada.

slide1_w600_h450
slide4_w600_h450
Iga risk mõjutab potentsiaalselt meie lõpptähtaega.
Riskid on potentsiaalselt vahetatavad aja vastu – projektiplaani saab lisada aega riski maandamiseks.
Alternatiivina saame riskifaktori lahendada enne projekti algust

slide5_w600_h450
Lugege lihtsalt neid teste ja mõelge, mida teha, et teie projekt mõnesse sellisesse auku ei kukuks.
Teadmiste omandamisel 70:20:10 suhe: 70% töö käigus omandatav, 20% raamatute lugemine jm iseseisev töö, 10% formaalsed koolitused, sealhulgas praegu siin loengus istumine! Selleks, et reaalselt mõni projekt ära teha, läheb teil tarvis palju rohkem teadmisi, kui see praegune loengukursus teile anda suudab -> lugege kindlasti oluliselt juurde, kursuse kodulehel on soovitatavat lugemismaterjali.

Aga kui te kunagi peaks minuga koos mõnd projekti tegema ja seal projektijuhina tegutsema, siis ma kindlasti eeldan, et te olete Software Project Survival Guide’i või mõne muu ekvivalentse raamatu läbi lugenud, muidu ei võta ma teid tõsiselt.

slide12_w600_h450
slide13_w600_h450
slide14_w600_h450
slide15_w600_h450
Need siin on näited, mitte täielik nimistu!

slide16_w600_h450
slide17_w600_h450
slide18_w600_h450
Riske pole kunagi võimalik täielikult välistada, aga neid saab oluliselt maandada kasutades vastavaid “filtreid”.

slide19_w600_h450
slide20_w600_h450
Kui kliendi ärilised eesmärgid jäävad täitmata, on nad lõpuks ikka õnnetud. Isegi kui teostaja oma raha kätte saab, võib projekti lugeda ebaõnnestunuks, kui keegi seda tegelikult kasutama ei hakka.

slide21_w600_h450
slide22_w600_h450
Loe lähemalt, Practical Project Initiation, lk 42-43
Huvide näiteid: juhtkond tahab suuremat käivet, andmesisestajad tahavad vähem käsitsitööd -> vähem vigu, müügiagendid tahavad kiiremat ligipääsu andmetele
Eelkujundatud suhtumiste näiteid: Andmesisestajad kardavad, et peavad mingitele uutele koolitustele minema, süsadminid arvavad, et ainult Solaris on õige asi
Võiduläve näiteid: Juhtkond tahab, et meie veebisait pakuks rohkem võimalusi kui konkurentide oma. Andmesisestajad tahavad automaatset veaparandust, andmebaasi administraatorid tahavad 3x suuremat andmebaasimahtu
Piirangute näiteid: juhtkonna eelarve on max 4 miljonit, andmesisestajatel on vanad arvutid ja uus kood peab nendel jooksma, samuti pole neil eelarves raha koolituseks

slide23_w600_h450
Sponsor on see, kelle käes on rahakott. Tema maksab nii minu laste leiva kui ka peadirektori Ferrari eest.

slide24_w600_h450
Kiviat diagram
Tihti juhtub, et tellija või mõni suur ülemus ütleb

slide25_w600_h450
Ma olen üsna kindel, et enamikul teist tuleb kunagi ühel või teisel viisil sellises situatsioonis olla.

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

slide28_w600_h450
slide29_w600_h450
slide30_w600_h450
Millal me loeme projekti edukalt lõpetatuks

slide31_w600_h450
slide32_w600_h450
Aga kui te saate need kõik valmis, on tulemuseks kuld.

4 responses so far

Mar 01 2010

Kuidas kirjutada CV-d

Published by Targo under Juhtimine, Programmeerijad

cv-mistakes

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.

dilbert_hiring

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.

7 responses so far