Targo tarkvara

Loen Tartu Ülikoolis sel kevadsemestril Neeme Vooluga kahasse Projektijuhtimise ainet. Pidasin just oma esimese loengu ja siin on ka materjalid.

Originaalslaidid saab leida siit.

Olin nii lahke, et tegin loengust ka audiosalvestuse. 1. osa 2. osa 3. osa 4. osa
Vahepeal unustasin diktofoni sisse vajutada, nii et osa jutust on ilmselt puudu. Tulge teinekord loengusse korralikult

Loeng põhines osaliselt ühel minu varasemal ettekandel, aga lisasin ja täiendasin oluliselt materjali.

 

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

 

Juba antiikajal tegid inimesed vaatlusi ümbritsevate protsesside kohta.

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

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.

 

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.

FBI näide: 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.

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.

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.

 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.

 

Need siin on näited, mitte täielik nimistu!

Kes loeb Dilbertit? Lugege kindlasti, kasvõi selleks, et ise mitte samasuguseid jamasid korraldada.

Audiosalvestuse 1. osa lõpp.

 

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

 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.

 

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

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

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

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

 Millal me loeme projekti edukalt lõpetatuks?

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

 

 

 Tuletame meelde seda 24 kuu vs 6 kuu juhtumit eespool.

ˇ

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

Audiosalvestuse 3. osa lõpp.

 

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

Ebaproduktiivne tegevus = haigused, vanade vigade parandamine, koodi ümber kirjutamine aruanded, pausid jne.

 

Arvatakse, et protsess on ka samasugune ebaproduktiivne tegevus.

Millalgi tuleb protsess niikuinii lisada ja see hakkab palju rohkem aega võtma. Samuti hakkab rohkem aega kuluma muudele tegevustele, mis otseselt projekti edasi ei vii.

Protsess võtab alguses aega, aga hiljem saavad osalised asja käppa.

 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.

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!

 

 

 

Aga kui te need asjad kõik ära teete, võib juhtuda, et teil õnnestub tõepoolest kulda teha.

Soovin edu.

Kuulsin mõni kuu tagasi Miha Kralj’i loengut sellest, mis IT-s järgmise 10 aasta jooksul juhtuma hakkab. Nüüd sattusid mulle need slaidid jälle näppu ja kuna tegemist oli tõesti huvitava loenguga, võtan teema ka siin arutusele, segamini oma isiklike mõtetega.

Ajaloost

1960. aastatel oli IBM infotehnoloogia A ja O, nad olid võitmatud ja miski ei saanud neid kõigutada. 1964. aastal tootis IBM ligikaudu 70% kõigist maailma arvutitest.

1990. aastate alguses oli firma aga katastroofi äärel, 1992 oli IBM-i kahjum 8,1 miljardit dollarit, mis oli tollal USA ajaloo rekord.

Mis siis juhtus? Asi polnud selles, et IBM-i inimesed oleks olnud rumalad – IBMis töötas mitmeid Nobeli ja Turingi auhinna võitjaid. Ka mitte selles, et IBMil oleks olnud halb tehnoloogia, ka selles osas on IBM pigem kiidusõnu saanud.

Tegelikult juhtus lihtsalt see, et tehnoloogia, millele IBM oli ise aluse pannud, hakkas muutma ühiskondlikke struktuure. Infotehnoloogia demokratiseerus ja peale kasvas uus põlvkond, kellel oli arvutitega hoopis teine suhe, tehnoloogia oli nende elu igapäevaseks osaks, mitte enam miski, mida valges kitlis onud hooldama ja paigaldama pidid. Tehnoloogia upgrade‘i tagajärjel toimus ka inimeste upgrade. IBM ei osanud seda uut demograafilist gruppi enam kuidagi käsitleda ja kaotas oma liidrikoha.
 

Inimestest

Sama protsess kestab tõusulainena edasi. Vaatleme näitena e-maili. 15 aastat tagasi oli see midagi esoteerilist, millega inimesed tegelesid hobi korras, aga see ei mõjutanud nende elu kuigivõrd. Praeguseks on e-mail lahutamatu osa minu elust, ma ei oska tõesti ette kujutada, kuidas ma ilma e-mailita suheldud saaksin. Ainus minu tuttav inimene, kellel e-maili pole, on ehk minu vanaema ja tema on tõesti juba väga vana. Võib-olla on neid inimesi veel, aga ilmselt peaksin ma neid mingiteks veidrikeks.

Samas ei ole mul näiteks rate.ee kontot. Kui ma selle endale teeksin, siis oleks tegemist lihtsalt mingi katsetusega, kindlasti ei viitsiks ma sinna massiliselt mingeid asju uploadida ja seal oma sotsiaalset elu elada. Aga minu 14-aastasel täditütrel on reidikonto loomulikult olemas. Samuti kõigil tema sõpradel ja üldse kõigil, keda ta oluliseks peab. Ja see ei ole tema jaoks kindlasti mingi katsetus, vaid täielikult integreeritud osa tema elust, täpselt nagu e-mail on osa minu elust. Ja mina olen tema jaoks samasugune vanainimene nagu minu vanaema on minu jaoks. Sul pole reidikontot? Aga… kuidas sa niiviisi elatud saad?

Miha Kralj tõi täpselt samasuguse näite. Kui ta saadab oma 15-aastasele lapsehoidjale e-maili, jääb see tihti nädalaks vastuseta. Kui ta aga jätab kommentaari tüdruku MySpace’i lehele, helistatakse 20 minuti jooksul.

Järgneb üks väga oluline tähelepanek: Kogu see rate.ee/MySpace/Facebook asi pole mitte mingi lastehaigus, millest inimesed läbi kasvavad ja seejärel “normaalset elu” elama hakkavad. EI! See generatsioon jääbki taolisi vahendeid kasutama, vahetades ehk keskkonna millegi “professionaalsema” (nt MySpace->LinkedIn) vastu, aga see jääbki osaks nende igapäevasest elust ja tööst.

• Kümne aasta pärast jõuavad paljud rate.ee põlvkonna liikmed ühiskonnas ja IT-s otsustajate sekka ja ülejäänutel on parem selleks valmis olla, nii oma suhtlemisharjumuste kui ka IT-lahenduste osas.

Mida rohkem suhtlemist toimub virtuaalselt, seda olulisemaks saab inimestele nende virtuaalne identiteet. Internetis avatarina kasutatav pilt saab palju tähtsamaks kui see, millist ülikonda sa kannad. Ja kui me tahame teada, kes hakkab tulevikus näiteks ettevõtteid juhtima, tasub uurida, kes juhivad praegu nt World of Warcrafti klanne. Suure klanni juhtimine pole kaugeltki lihtne ülesanne, paljud sealkasutatavad virtuaalse organiseerimise võimed kanduvad üle virtualiseeruvatesse “päris” asutustesse.

Arvutitest

Töötasin kunagi väikeses firmas, mis pakkus muuhulgas ka interneti sissehelistamisteenust. Riistvara uuendamine käis nii, et osteti eraldi protsessor, mälu, kõvakettad, modemid jne, igaühe puhul parameetreid hoolega vaagides.

Ajad läksid edasi, põlve otsas interneti pakkujad söödi turult välja ja arvutitarnijate hinnakirjadesse ilmusid spetsiaalsed serverarvutid. Kasutajate arvud kasvasid hüppeliselt, varsti polnud ka üksikute serveritega enam midagi teha ja nad organiseeriti algul riiulite ja siis tervete kappide ehk rackidena.

Ja nüüd oleme olukorras, kus suured firmad ostavad korraga terve konteineritäie servereid, see tuuakse kohale raudteevagunil ja ostjal ei ole tegelikult selle konteineri võtit. Kui konteineri jõudlus langeb alla 95%  (ehk näiteks 5% seal sees olevatest CPUdest on otsad andnud!), tuleb kohale tehnik, kes vastavad osad välja vahetab.

Mees ja Koer tüüpi firma muidugi sellist teenust ei tooda ega tarbi ja riistvaratootjate seas on aset leidnud kiire konsolideerumine.

Järgmisel pildil on Miha slaidilt laenatud graafik, mis näitab turul aktiivselt tegutsevaid ja relevantseid riistvaratarnijaid:

• See trend jätkub nii globaalsel kui lokaalsel tasandil – suure tõenäosusega pole mõne aasta pärast enamikku praegu tegutsevatest väiksematest IT-firmadest enam olemas.

Keskkonnast

Tuleme tagasi selle konteineri juurde: peamine tähelepanuväärne detail pildil on kolm jämedat kaablit, mis serverisse sisenevad: need on elekter, jahutusvesi ja võrguühendus, mis iseloomustavad hästi ka järgmisi trende.

Globaalne soojenemine ja keskkonnakaitse on praegu väga poleemilised teemad. Enamasti süüdistatakse keskkonnahädades transporti jms “vanu” majandusharusid. IT-d peetakse trendikaks ja keskkonnasõbralikuks. Tegelikult kulutab IT aga sama palju energiat kui lennundus!

Arvutustehnika arengu peamiseks piirajaks on praegu elektritarve ja sellega kaasnev jahutusvajadus (mis tarbib omakorda energiat). USAs ehitati data centereid omal ajal Floridasse, Californiasse, New Mexicosse… aga enam mitte. Kuna “kolmas toru” ehk võrguühendus on samuti oluliselt jämedamaks muutunud, pole asukoht enam oluline ja osutub võimalikuks valida lokatsiooni tervest maailmast. Põhja-Ameerikas said populaarseks põhjapoolsemad, jahedamad, aga ohtra hüdroenergia piirkonnad. Kui me aga vaatame tervet maailma, siis kust võime leida odava energia, jaheda kliima ja haritud tööjõu? Islandilt.

Gloobuselt vaadates asub Island kenasti Ameerika ja Euroopa vahel ja sobib seega uueks globaalseks keskuseks. Meie jaoks on jutu moraal aga selles, et

• Globaliseerunud maailmas liiguvad raha ja lahendused silmagi pilgutamata kõige soodsamasse asukohta.

Seesama blog, mida te praegu loete, asub tegelikult mingis Hong Kongi serveris. Aga võibolla on ta nüüdseks kolitud näiteks Filipiinidele, mul pole õrna aimugi. 10 aasta pärast teavad vähesed IT-inimesed, kus nende rakendused tegelikult jooksevad, ja mis nendega madalamal tasemel toimub, kõik on virtualiseeritud, rakendused ja andmed on võimalik ühe nupuvajutusega hoopis kusagile mujale ümber tõsta. Tarkvara, mis selle vajadusega ei arvesta, ilmselt kasutusele ei võeta.

Siit koorub välja veel üks tähelepanek: kui me teeme sedasama, mis meie naabergi, paneb konsolideerimise trend meid lõunaks nahka ja ei tee teist nägugi. Mõni suurem tegija tuleb ja pakub sama teenust (olgu see siis riistvara, tarkvara, hosting või muu) suuremamastaabilisemalt ja odavamalt ja meie kliendid ongi läinud. Seega tuleb meil vaadata, mida teised ümberringi teevad… ja siis teha midagi muud.