May 10 2010

Inimesed ja juhtimine

Viies osa 2010 kevade projektijuhtimise loengutest. Audiosalvestus.

Originaalslaidid siin.

Slide1

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

Üks kõige ohtlikumaid olukordi inimese jaoks on lahing sõjas. Piirkond on täis suurt kuumust, ohtlikke aineid, ülehelikiirusega ringi lendavaid metallitükke jne.

Samas, kõige olulisem mõjutaja inimese elus on enesealalhoiuinstinkt. Seega, kui sõduritel on vaja näiteks üle mingi lagendiku rünnaku joosta, on see nende jaoks kõige loomuvastasem asi maailmas.

Sellegipoolest, kui antakse vastav käsk, siis sõdurid tõusevad püsti ja jooksevad üle selle lagendiku.

 Miks?

 Peamiselt sellepärast, et neisse on pikkade ja raskete õppuste kestel sisse drillitud absoluutne sõnakuulamine. Nad teavad, et käsk on vanem kui meie ja et nende enda elu pole suures plaanis oluline. USA merejalaväelastel pole lubatud kasutada sõna “mina”.

Põhiväljaõppe käigus õpivad sõdurid oma ülemust kartma rohkem kui surma. Sest ülemus on suur ja hirmus (nagu mina). Ülemus ütleb, et jookse ja sõdur jookseb. Ütleb, et lama ja sõdur lamab. Ütleb, et lenda ja sõdur vehib kõigest hingest kätega, et lendu tõusta.

Paljudele tsiviilelu organisatsioonijuhtidele meeldiks oma organisatsiooni samamoodi juhtida. Et aina käsuta ja kõik kohe teevadki nii, isegi kui see nende isiklikele huvidele või enesealalhoiule vastu käib.

Paljud proovivadki nii teha. Paraku küll mitte väga edukalt. Sõjaväes pole sõduril kusagile pääsu – kui ta jalga laseb, siis püütakse ta kinni, pannakse vangi või lastakse maha. Tsiviilelus saadetakse nõme ülemus aga varem või hiljem pikalt või siis lihtsalt ignoreeritakse teda.

See suhtumine on tegelikult väga levinud, mul on endal ka tihti kiusatus olnud karmi käsutamise abil probleeme lahendada. Ja kui ma kunagi oma vennale rääkisin, et minu  tiimi liikmete töö tulemused ei vasta alati päris sellele nagu ma soovisin, oli tema esimeseks reaktsiooniks: kas sa nende suhtes mingeid sanktsioone ei saa rakendada?

Vabandust, vennas, see asi pole paraku nii lihtne.

Slide1

Slide1

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!

 

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

Slide1

2 responses so far

May 05 2010

Miks Microsoft ei leiutanud Twitterit või Youtube’i

Published by Targo under Innovatsioon, Raha, Tehnoloogia

innovation

Kirjutasin kunagi IBMi teemal, kuidas nad oma kunagise liidripositsiooni kaotasid, aga tegelikult kehtivad samad seaduspärad ka peaaegu kõigi teiste ettevõtete ning tööstusharude puhul.

Clayton Christensen toob oma raamatutes välja järgmise diagrammi:

disruptive innovations

Tehnoloogiline areng toimub siin järgmiste etappide kaupa:

  1. Turul on ettevõtted, mis parandavad pidevalt oma tooteid vastavalt kasutajate soovidele (vasakpoolne “säilitava innovatsiooni” nool). Nad ei tee mitte midagi valesti, vastupidi! Need ettevõtted kuulavad väga hoolega oma kliente, leiutavad oma valdkonnas uusi tehnoloogiaid ja teevad üldse kõiki häid asju, millest me äriraamatutest lugeda võime.
  2. Nende toodete võimekus muutub piisavalt täielikuks, et keskmine kasutaja ei saa uutest täiendustest enam erilist kasu. Mõtleme kasvõi palju aastaid kestnud kurtmisele, et “mis mul sellest uuest MS Office’i versioonist abi on”.
  3. Mingil hetkel tuleb turule samas valdkonnas, aga teistel põhimõtetel töötav toode, mis ei rahulda peamiste tarbijate vajadusi, aga on näiteks oluliselt odavam, lihtsam kasutada vms. Esialgu jääb see vaid kitsasse nišši.
  4. Uus toode täieneb, kuni ta on järjest suurema hulga kasutajate jaoks “piisavalt hea” ning vana toode marginaliseerub äkitselt.
  5. Ring algab otsast peale.

Näiteid taolistest murrangutest, nii minevikus toimunutest kui praegu käimasolevatest:

  • Digitaalfotograafia vs “klassikaline” ehk keemiline fotograafia. Oli aeg, kus digitaalfotograafia kvaliteet oli oluliselt halvem, aga praeguseks on pigem klassikaline film nišitooteks tõrjutud.
  • Peronaalarvutid vs superarvutid. Varased personaalarvutid ei saanud spetsialiseeritud superarvutitele lähedalegi, aga praegu on järjest vähem organisatsioone, kellele enam tavalistest arvutitest ei piisaks.
  • Tulirelvad vs vibud ja nooled. Kõva inglise vibumees oli efektiivsem kui esialgse musketiga relvastatud vastane, aga tulirelvaga treenimine oli lihtsam ning odavam.
  • Aurulaevad vs purjelaevad. Algul olid aurulaevad aeglasemad ja neid kasutati ainult vähese tuulega sisevetel.
  • Telefon vs telegraaf. Telefoni sai algul kasutada vaid kohalike kõnede tarvis.
  • Paber vs pärgament. Pärgament on palju kvaliteetsem, kuid ka palju kallim.
  • Kiirrongid vs lennukid. Olenevalt elanikkonna tihedusest võib pakkuda suuremat mugavust ning kättesaadavust.
  • Eralennukid vs Concorde. Concorde loodi eliidile, kelle aeg oli kulla hinnaga. Siis aga said eralennukid piisavalt odavaks ning kättesaadavaks, et nende kasutusmugavus kaalus üles Concorde’i suurema kiiruse.
  • Laserprinterid vs trükikojad. Mitte nii võimsad, aga väikeste koguste trükkimiseks täiesti piisavad.
  • Plastik vs metall. Eriti algusaegadel nõrgem ja vähem vastupidav, kuid odavam.
  • Raketid vs suurtükid. Algul ebatäpsed, kuid lihtsamad kasutada – praeguseks efektiivsemad ja laiemas kasutuses.
  • Kodukino vs päriskino.
  • Süntesaatorid vs klaverid.
  • Downloaditav muusika vs CD-d
  • Mobiiltelefonid vs tavatelefonid
  • VoIP vs GSM
  • Elektroonilised postkaardid vs paberpostkaardid
  • Mehitamata droonid vs mehitatud sõjalennukid
  • Ultraheli vs MRI ja arvutitomograafia
  • Internetipoed vs tavalised poed
  • LCD vs CRT. Esimesed LCD-d olid oluliselt kehvema kvaliteediga kui CRT-d.
  • Sinu lemmikinternetitehnoloogia vs MS Windows+MS Office
  • jne jne.

Oluline tähelepanek on, et praktiliselt alati süüakse vana tegija turult pea täielikult välja. Näiteks IBM ei tooda enam personaalarvuteid. Miks?

Esiteks: kui meil on tegemist end turul sisseseadnud ettevõttega, on tema käive ja kasum tavaliselt küllaltki kõrged, investoritele on aga vaja kasvu. Väikesel internetifirmal on lihtne igal aastal mitukümmend protsenti käivet kasvatada, aga võtame näiteks Microsofti, mille käive läheneb 60 miljardile dollarile aastas. Et saavutada kahekohalist protsendikasvu, peaks Microsoft endale haarama või kusagilt tekitama uue kümnemiljardilise turu, selliseid aga lihtsalt ei eksisteeri naljalt. Ainuke kindel (aga radikaalseid uuendusi vältiv) kasvumootor on võimalikult hästi olemasolevat turgu teenida ning sellega satumegi ülalkirjeldatud olukorda.

Microsoftis on väga palju väga nutikaid inimesi, kes on kindlasti suutelised Youtube’e või Twittereid leiutama, kuid vastavad turud on (vähemalt esialgu) kaugelt liiga väikesed ning ebahuvitavad. Tegelikult toimub vastupidine: põhisuuna jaoks ebasobivad mõtted juuritakse pigem välja! Siis aga mööduvad aastad ning uute tehnoloogiate darvinistlikust konkurentsist kerkib esile mõni, kellest lähtuvale ohule on äkitselt lootusetult hilja reageerida.

Teiseks: edukas ettevõte on tüüpiliselt harjunud toimima olukorras, kus tegevust planeeritakse hoolega. Iga edukas juht teab, et oma turu tundmine on võtmetähendusega, ning keskendab oma tähelepanu sellele, et võimalikult hästi mõista oma kliente, konkurente ning muid faktoreid. Murrangulised tehnoloogiad hakkavad aga tüüpiliselt tegutsema turul, mida praegu üldse ei eksisteerigi, seega pole juhil ka võimalik seda turgu analüüsida ega midagi planeerida! Me kõik teame juhtumeid, kus üht või teist uut tehnoloogiat on taevani kiidetud, kuidas sellest saab kogu maailma tulevik, aga paari aasta pärast ei pole sellest enam kippu ega kõppu kuulda. Sellised näited muudavad iga juhi ettevaatlikuks, kuni taas kerkib esile tehnoloogia, mis osutub ikkagi edukaks, ja hammustab meid tagumikust.

Kolmandaks: suures ettevõttes toimivad tootmisprotsessid pole niisama lihtsalt allapoole skaleeritavad, et väikeses nišis edukalt tegutseda. Sama tootmisviis, mis tagab edu olemasoleval turul, on uuel turul hoopis takistuseks.

Neljandaks (kõige olulisem faktor): ”vanade” firmade kliendid pole muutusest huvitatud. Uus tehnoloogia on esialgu kehvem kui olemasolev ja miks peaks klient halvemale variandile üle minema? Ja nii monopoliseeritaksegi ettevõtte parim ressurss olemasolevate kasumlike klientide teenimiseks, mis takistab meil sisseharjunud rajalt kõrvale astumist.

man_dog

Kui me arvame, et kõik need fenomenid leiavad aset ainult kusagil kaugel, siis eksime – täpselt sama efekt leiab igapäevaselt aset ka Eesti tarkvaraturul. Nimesid nimetamata teame me kõik kohalikul turul tegutsevaid ettevõtteid, mis pakuvad nö täisteenust: suure meeskonnaga tehtavat analüüsi, disaini, programmeerimist ja juurutamist. Neil kõigil tekib mingi miinimumlävi, millest odavamaid projekte ei hakata isegi mitte kaaluma.

Samas noolivad nende turuosa altpoolt pidevalt “Tarkpeade butiik” ning “OÜ Mees & Koer” tüüpi tegutsejad, kes on võimelised sama ülesannet mitte küll nii täielikult, kuid see-eest mitu korda odavamalt või kiiremini lahendama. Mingil hetkel hakkavad aga ka nemad muretsema selle pärast, kuidas oma olemasolevaid kliente võimalikult täielikult õnnelikuks teha, värbavad hulga uusi inimesi ning sama tsükkel jätkub – igaüks avaldab pidevat survet endast toiduahelas kõrgemal paiknejatele.

No responses yet

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

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

Feb 27 2010

Veel IT-st ja kommunikatsioonist

Published by Targo under Projektijuhtimine

science_communication

Jätkuks eelmisele artiklile rääkisin SMITis eelmise aasta lõpupoole veel IT ja kommunikatsiooni teemal, refereerin erinevaid noppeid siin.

Fiasko näide: FBI Virtual Case File System

FBI infosüsteemist on ka varem juttu olnud, kuid meenutan põhilisi fakte:

  • Projekt kestis 2000-2005
  • Osa kolmeosalisest (riistvara, tarkvara ja arvutivõrk) projektist Trilogy
  • Trilogy planeeritud maksumus $380M, tegelikult kulus üle $600M, sellest tarkvarale $170M – kõik maksumaksja raha (võrdle Eesti eelarvetega!)
  • Riistvara ja võrgu hange õnnestusid üldjoontes (kuigi teatava ülekuluga)
  • Tarkvaraprojekt katkestati viie aasta möödumise järel

Miks projekt ebaõnnestus? Põhjustena on mainitud:

  • Puudulik spetsifitseerimine
  • Korduvad spetsifikatsioonimuudatused
  • Korduvad juhtkonnavahetused
  • Mikromanageerimine
  • Brooks’i seadus – hilinevale projektile inimeste lisamine suurendab hilinemist
  • Tarnija ei kutsunud klienti korrale
  • Klient sekkus “kuidas” küsimustesse, selle asemel, et piirduda “mida-ga”

Paneme tähele, et ükski ebaõnnestumise põhjustest polnud tehnoloogiline, kõigi puhul oli tegemist kommunikatsiooniprobleemidega!

Tulemuseks oli, et 11. septembril 2001 saatsid FBI agendid kahtlusaluste fotosid ja muud materjali endiselt faksi või kirja teel kuna puudusid piisavalt turvalised, heakskiidetud ja põhisüsteemiga liidestatud e-maili saatmise võimalused. Arvestades veel asjaolu, et juba ammu enne projekti algust olid FBI süsteemid lootusetult vananenud, oleks efektiivsem IT ehk üldse rünnakuid vältida aidanud ning maailm oleks tänapäeval hoopis teistsugune.

Möödarääkimise näide: erinevad edukriteeriumid

Tänapäeval on popp rääkida, kuidas IT-ettevõtted pakuvad teenust. Aga mida see tähendab? Vaatleme üht teist teenust: reisilennundust.

airline_ad

Nägin kunagi lennufirmade juhtide arvamusküsitlust, kus nad leidsid, et teenusekvaliteedil pole viga midagi, tuues argumentidena:

  • Inimesed saavad (üldjuhul) punktist A punkti B
  • Lennukid ei kuku (tavaliselt) alla
  • (Liiga palju) lende ei katkestata

Ja ongi kõik korras!?

flying_coach

Tegelikus elus olen mina ilmselt üks miljonitest ja miljonitest inimestest, kes lendamist vihkavad. Minu (üldse mitte ülinõudlikud) edukriteeriumid on hoopiski:

  • Lend on mugav (sealhulgas ka lennueelne ja -järgne kogemus!)
  • Ma ei kannata liigset kahju (lennud ei hiline, minu pagas ei lähe kaduma)
  • Teenus on terviklik (praegu pean lennujaama, lennuki, pagasi, lennujaamatranspordi jne osas eri inimetega sekeldama)

Viimasele aspektile on mõned nišitegutsejad ka pihta saanud. Nt Virgin pakub täisteenust koduuksest koduukseni ja saab selle eest ka oluliselt kõrgemat hinda küsida.

Samamoodi on tarkvaraturul tellija jaoks tohutu piin tegeleda eraldi riistvara, hostingu ja tarkvara pakkujatega selle asemel, et ühest ja samast kohast täisteenust saada.

Telefonimängu näide

telephone_game

Kommentaarid on vist liigsed, me kõik oleme sarnases situatsioonis olnud.

telephone_game2

Või siis mustema huumoriga näide. Aga eks sedagi ole piisavalt juhtunud, et projektist on mingid inimesed lahkunud ja seejärel “eit teadis, aga eit suri ära”.

Prioriteetide näide: erinevad soovid

See kolmnurk on ilmselt kõigile tuttav:

time_scope_quality

Teooria ütleb, et meil pole võimalik kõiki kolme tippu korraga fikseerida, kusagile peab jääma mingi vabadusaste. Tegelikkuses aga nõuab tellija, et kõik peab nui neljaks fikseeritud olema.

Ja tulemuseks on, et:

  • Kui kõik on prioriteet siis tegelikult pole ükski asi prioriteet
  • Antakse järele aspektis, mis on raskemini mõõdetav, ehk siis kvaliteedis.

Komplitseeriva asjaoluna on meil tihti mitmed huvigrupid, igaüks tirimas projekti erinevas suunas.

swan-and-pike-and-crab

Positiivsem näide: Microsoft Office

Office’i divisjon Microsoftis kasutab ülaltoodud probleemide vältimiseks üsnagi drakoonilist prioritiseerimist:

  • Tähtaeg on kuningas
  • Järgmise Office’i versiooni tähtajad võivad olla 2 aastat ette fikseeritud
  • Mitukümmend allüksust elab sama rütmi järgi (planeerimine, analüüs, disain, koodikirjutamine, stabiliseerimine, beeta, release)
  • Kui tähtaja ja kvaliteedi kriteeriume mingis etapis ei saavutata, jäetakse vastav feature lihtsalt tootest välja

Muidugi ei pea iga tarkvara just niiviisi tegema, aga vähemalt on siin ranged reeglid, mille järgi tegutseda ja edu saavutada.

Microsofti DNAs on üldse väga tähtsal kohal idee sellest, et “teeme asjad ära”. Mul endal on mälestuseks näiteks selline jurakas:

shipit

Iga valminud ja turule läinud toote eest, mille tegemisel inimene osaleb, saab ta vastava märgi. Lihtne värk, aga märgiks sellest, kuidas igal sammul rõhutatakse tulemuseni jõudmist.

3 responses so far

Jan 10 2010

IT – mitte tehnoloogia, vaid kommunikatsioon

Kuna head inimesed Eesti Päevalehes on oma reklaamirahad ilmselt kätte saanud, panen ka siia oma läinudsügisese intervjuu materjalid. Parandasin ära ka mõned toimetamise/valestimõistmise apsud (irooniline, kas pole).

Tiiu Laks oli kena inimene, kes mind intervjueeris.

Communication

— Kuidas sulle tundub, kas Eestis on nii kõrge infotehnoloogia tase, kui siin tavatsetakse arvata?

— Oleneb, millisel tasandil me vaatame – kas riiki tervikuna, inimesi eraldi või IT-spetsialiste. Vastus on iga grupi puhul natuke erinev.

— Näiteks e-riik, mille üle eestlased uhked on?

— Rahvusvaheliselt on Eesti võib-olla kõige olulisem omadus see, et Eesti on hästi väike. Kui Eestis elada, siis ei anna sellest endale ehk nii väga aru, aga kui käia maailmas ringi ja sõita ühest linnast teise, siis märkad, et selles või tolles linnas elab sama palju inimesi kui terves Eestis, mõnes teises jälle kolm korda rohkem inimesi kui Eestis. See on tegelikult üsna haruldane, et nii väike riik on olemas.

Nii on meil ka infotehnoloogilises mõttes võimalik väledamalt reageerida ja igasuguseid asju teha. Teinekord me kirume Eesti bürokraatiat, aga kujuta ette suurriiki, kus riigiaparaat on sada korda suurem kui Eestis. Sada korda suurema ametnikkonnaga riiki e-riigiks muuta on üsna lootusetu projekt.

Sest mida rohkem on süsteemi kasutajaid, mida rohkem eri huvisid, mida keerulisem on protsess, seda raskem on seda IT-projekti läbi viia. Ühel hetkel kasvab keerukus nii suureks, et projekti ei ole võimalik mõistliku ajaga täide viia.

Ameerikas on olnud selliseid kolossaalseid ebaõnnestumisi IT-vallas. Tihti tuuakse näiteks FBI. FBI tahtis endale infosüsteemi, kus oleksid kõik nende menetlused ja kriminaalasjad ning igal agendil sellele ligipääs. Projekti peale kulutati müstilisel hulgal raha, sadades miljonites dollarites, mis on rohkem kui terve Eesti avaliku ja erasektori IT-kulutused ma ei tea mitme aasta peale kokku. Ja sellegipoolest asi lihtsalt ei läinud käima.

Eestis on neid asju lihtsam läbi viia, on lihtsam e-riigi taolist süsteemi käivitada. Selle pärast vaatavadki välismaalased, et ohoo. See võtab neil suu lahti, et kodanikul on võimalik riigiga kõik asjad kodunt lahkumata korda ajada. E-valimised on paljudele muidugi täielik ulmeteema, aga kas või sellised lihtsad toimingud, nagu ID-kaardiga allkirja andmine. See on väga lahe.

— See tähendab siis ju, et Eestil pole mõtetki üritada kas või e-pileti süsteemi näiteks Poola eksportida, sest süsteem ei hakka suuremas kohas tööle?

— Oleneb. See on natuke erinev, kas luua süsteem nullist või käivitada väljatöötatud lahendus uues kohas.

Paljud IT-lahendused jäävad tihti selle taha, et hakatakse nullist tegema ja tahetakse, et süsteem rahuldaks kõigi huve, et kõik inimesed saaksid kohe kõike teha. Just siin mängib rolli, kas meil on 50 või 500 või 5000 ametnikku ehk erinevat soovi. Väga tihti jääb kõik selle taha, et hammustatakse liiga suur tükk, alahinnatakse ülesande keerukust ja ülehinnatakse enda võimeid. Ühel hetkel saab jõud lihtsalt otsa.

Aga kui süsteem on juba olemas ja on selge, mis töötab ja mis mitte, siis sealt samm-sammult edasi minna on oluliselt lihtsam. Kuigi ka sel puhul võib mingil hetkel keerukuse piir vastu tulla.

— Eesti on siis IT-lahenduste inkubaator?

— Eestis on suhteliselt vähe programmeerijaid. Hästi raske on öelda, kes neist on millisel tasemel. Hulk tudengeid lõpetab igal aastal informaatika eriala Tartu ülikoolis ja tehnikaülikoolis. Kuid mitte kõik lõpetajad ei jää tingimata selle eriala peale. Aga lisaks on hulk rahvast, kes ei ole programmeerimist koolis õppinud, kuid töötavad sel alal.

Kokkuvõttes – suurusjärk jääb umbes samaks.

Aga maailma mõõtkavas on neid ikka vähe. 10–15 aasta peale kokku on seda kaadrit tekkinud ikka suhteliselt vähe. Mõnes rahvusvahelises suurfirmas (Microsoftiga ma ei hakka võrdlemagi) töötab mitukümmend korda rohkem programmeerijaid kui terves Eestis.

See tähendab, et meil ei ole võib-olla võimalik teha nii suuri, vägevaid ja seinast seina IT-lahendusi. On oluliselt vähem spetsialiseerumist ja oluliselt rohkem seda, et üks inimene peab ära tegema seitse eri ülesannet, milleks suurkorporatsioonis oleks seitse inimest. Loomulikult ei ole tal siis võimalik tööd nii põhjalikult teha. Eestlastel on tekkinud harjumus väiksemate jõududega teha valmis töötav lahendus, mis ajab asja ära.

Võib-olla Saksamaal kirtsutatakse nina, et teete seal kümne inimesega projekti, mis projekt see sihuke ka on. Aga enamiku e-riigi lahendusi on loonud maailma mõistes väga väikesed meeskonnad. Struktuurne probleem on lihtsalt Eesti üks eripära – Eesti on väike, siin on vähe inimesi ja kõik probleemid tuleb lahendada nende inimestega, kes siin on.

Kuna inimesed peavad tegelema rohkem igasuguste üldiste küsimustega, siis on spetsialiseeritus väiksem. Ma ise olen ka täielik universaal – ma teen kõike, müügitööst kuni tehniliste ülesanneteni. Kui kõrvutame Eesti ja mõne muu maa spetsialisti, on sügavust Eesti omal arvatavasti vähem. Samas on rohkem oskust, kuidas pisikese ajavaru, ressursi ja meeskonnaga midagi valmis saada. Kas see on hea või halb? Sõltub olukorrast.

— Nii et see on omamoodi väärarusaam, et IT-valdkond on üks meie suurema potentsiaaliga ekspordiartikleid?

— Ma ei tea, kuivõrd realistlik ekspordiartikkel see on, aga sellist promo eksporditakse küll kõvasti. Ma arvan, et see hakkab ennast kindlasti ära tasuma. Kui on teada, et Eestis on kõvad programmeerijad, kes teevad lahedaid asju, on see kõva plusspunkt juhul, kui näiteks Inglismaal peab keegi otsustama, kas palgata inimene Eestist või Malaisiast. Lihtsalt selle seose tekkimine ja otsustajateni jõudmine võtab natuke aega. Aga kindlasti on selline maine pingutust väärt.

— Sa lugesid Tartus informaatikatudengitele tarkvara projektijuhtimise kursust. Mida tudengitega töötamine sulle uue IT-põlvkonna kohta ütles või näitas?

— Ma arvan, et inimesed on üle maailma põhiolemuselt samad – ühesugune võimekus ja IQ. Lihtsalt digitaalses elus muutuvad olud väga kiiresti.

1960. aastatel oli IBM infotehnoloogia A ja O, nad olid võitmatud ja miski ei saanud neid kõigutada. 1990. aastate alguses oli firma aga katastroofi äärel, 1992 oli IBM-i kahjum 8,1 miljardit dollarit, mis oli tollal USA ajaloo rekord. Asi polnud selles, et IBM-i inimesed oleksid olnud rumalad (IBM-is töötas nobeliste ja Turingi auhinna võitjaid), ega ka selles, et IBM-il oleks olnud halb tehnoloogia.

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äeva osa, mitte enam miski, mida valge kitliga onud hooldama ja paigaldama pidid. Tehnoloogiauuenduse tulemusel toimus ka inimeste uuenemine. IBM ei osanud uut demograafilist gruppi enam kuidagi käsitleda ja kaotas liidrikoha.

Sama protsess kestab tõusulainena edasi. E-postist on saanud elu lahutamatu osa. Kogu see Rate.ee, Facebooki ja Orkuti asi pole mingi lastehaigus, millest inimesed välja kasvavad. See põlvkond jääbki selliseid vahendeid kasutama, vahetades ehk vaid keskkonna millegi „professionaalsema” 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-alal otsustajate sekka. Mina kuulun pigem e-posti põlvkonda, aga praeguste 16–20-aastaste jaoks on suhtlusvõrgustikud elu.

Inimesed on üldiselt samasugused, aga kommunikatsiooni-viisid ja kuidas igapäevaseid asju tehakse – see muutub arvatavasti pidevalt ja jääbki muutuma.

Kui ma üliõpilastega rääkisin, siis mõni leidis, et kirjandus, mida ma soovitan, on anakronistlik – nendel on uued iidolid peale kasvanud. Ma mõtlesin, et mis mõttes:  ma rääkisin ju ainult kümme aastat vanadest asjadest.

— Kas on ka mingid põhitõed, mis jäävad?

— Kindlasti. Siin tuleks rääkida, millega infotehnoloogia tegeleb… Väga paljudel inimestel on arusaam, et asi on tehnoloogias – mida vingem tehnoloogia, seda parem. Kõik probleemid on lahendatavad veel enama ja parema tehnoloogiaga, siis saab kõik korda.

Tegelikult on infotehnoloogia kõige suurem probleem hoopis infos, täpsemalt kommunikatsioonis. Ühes servas on ärimehed, kes tahavad raha teenida, teises masin, millele tuleb ülesandeid anda. Need on kaks absoluutselt erinevat maailma. Äriidee peab minema kõigepealt meeskonnale, kes peab selle konkreetsetesse sammudesse ümber panema. Peab olema IT-inimene, kes saab aru ärireeglitest ja peab olema võimeline äriidee mingisse vormi valama ja selle olemust detailselt analüüsima. Spetsifikatsioonist saavad omakorda aru programmeerijad, kes teevad selle arusaadavaks arvutile. Nii et selles ülesandes on väga mitu tõlkimise kihti.

IT-projektid võivad tihtipeale ebaõnnestuda seetõttu, et sellessamas „telefonimängus” läheb infot vahelt kaduma või see moondub. Niisiis – süsteem, mis valmis tehakse, võib hästi töötada, aga teeb täiesti erinevat asja kui see, mida inimene alguses tahtis.

Seetõttu ei ole tõhus IT-ettevõte tingimata see, kellel on kõige võimsam tehnoloogia, vaid see, kes suudab võimalikult hästi hallata tõlkimist. Kõige hinnatumad ja vajalikumad inimesed ei ole need, kes valdavad hullult tehnoloogiaid (mis on informaatikatudengite sage eksiarvamus), vaid need, kes suudavad haarata võimalikult laia osa ärimehe ja masina vahelt.

Ideaalne IT-mees on see, kes suudab rääkida firma direktoriga ja selle põhjal programmi kirjutada, aga selliseid inimesi peaaegu pole.

— Aga kui vaadata kas või popkultuuris levivaid IT-inimeste stereotüüpe, siis nad ei ole just väga suhtlusaltid…

— Selles probleem ongi. Selleks et selle masinaga töötada… see tuleb paremini välja teatud isiksusetüübil. Sellepärast ongi tüüpilises projektis kliendi nimel äriinimene ja äriprojektijuht, IT-inimesed ja IT-projektijuht ning täitja nimel projektijuht, süsteemianalüütik, süsteemiarhitekt ja programmeerija.

Kui rääkida karjäärist IT-alal, siis võtmeküsimus enamiku IT-inimeste jaoks on, kas nad suudavad end sellest patsiga asotsiaalse poisi stereotüübist välja murda ja rohkem suhelda või mitte.

— Millisena sa IT tulevikku näed?

— Ma ei usu, et näiteks Bill Gates ja Steve Jobs mõtlevad, kuhu võiks IT minna, või otsustavad, kuhu seda liigutada. Need muutused algavad enamasti kasutajatest, alt üles. Peamine on see, et IT demokratiseerumine jätkub.

Kui mõelda kas või Wikipedia fenomenile, siis seal on sündinud sünergia tehnoloogia ja inimeste vahel. Tehnoloogia loob uusi võimalusi ning hakkab inimeste elus suuremat rolli mängima. Muidugi oleneb inimesest, kes harjub sellega kiiremini, kes aeglasemalt. Iga järgmise põlvkonnaga – isegi mitte põlvkonna, vaid kümnendiga – moodustab tehnoloogia inimelust suurema osa, inimeste ja tehnoloogia põimumist on rohkem, mis tekitab uue sotsiaalse tellimuse uute tehnoloogiate järele, mis võimaldaksid suhtlust veelgi kasvatada.

Interneti algusaegadel poleks tänased sotsiaalsed võrgustikud Rate.ee, Facebook, Orkut olnud mõeldavad, sest interneti kasutajaid oli lihtsalt nii vähe. Aga nüüd, kui neid on kõvasti rohkem, on ka rohkem inimesi, kes kulutavad teatud tunnid nädalas internetis olemise peale. Nii on tekkinud sotsiaalne tellimus – näiteks kohvikus lobisemas käimise asemel saab nüüd suhelda sotsiaalses võrgustikus. See protsess läheb kindlasti edasi. Mis kuju see täpselt võtab, ei julge ma ennustada. Aga ma arvan, et pääsu sellest ei ole.

— Kaugele see minna võib? Skeptikud väidavad ju, et paradoksaalselt tekitavad sotsiaalsed võrgustikud antisotsiaalsust, inimesed ei suhtle enam…

— Kindlasti killustab see ühiskonda. 30 aastat tagasi ei saanud ükski radikaal (ükskõik, kas poliitikas, usu- või muus valdkonnas) kohvikus oma hulludest mõtetest rääkida, ta rahustati enne maha. Tänapäeval aga on väga lihtne leida interneti abil üle maailma endasuguseid radikaale, kes jagavad sinu mõtteid. Ja siis nad võimendavad vastastikku üksteist. Seega – selle asemel et radikaalid rahuneksid, annab internet neile ohtralt võimalusi end veel rohkem üles kütta.

Kui luusida ringi vandenõuteoreetikute, usuhullude või äärmuspoliitikute foorumites, paneb imestama, kust sellised inimesed tulevad. Sotsiaalne grupeerumine hakkab toimima hoopis teisi dimensioone mööda – samas majas elamine muutub oluliselt vähem tähtsaks kui see, et me käime samas foorumis.

Mul pole õrna aimugi, kas see on hea või halb ja mis mõõdupuuga seda peaks mõõtma, aga see on vältimatu ja sellele ei saa kuidagi kätt ette panna. Ühed struktuurid asenduvad teistega ja uued struktuurid on mitmes mõttes teistsugused, seal on oluliselt kitsam spetsialiseerumine, on oluliselt vähem sotsiaalset kontrolli, kas või radikaalide korralekutsumiseks. On muidugi ka positiivseid näiteid, kas või see, et inimesed „tulevad kokku” ja kirjutavad Wikipediat vms, mis on võimalik ainult tänu internetile.

— Euroopa Komisjoni tellitud uuringu järgi ei ole eurooplased nõus interneti sisu eest maksma, osa neist ka siis mitte, kui tasuta kvaliteetinternetti polekski.

— Kui palju neid ikka on, kes toodavad internetisisu raha teenimiseks? On tuhandeid inimesi, kes kirjutavad blogisid, mis on väga huvitavad ja sisukad ja sugugi mitte halvemad kui New York Timesis või Economistis ilmuvad artiklid. Sellepärast, et neil on sisemine tung seda teha.

Samamoodi võime rääkida muusikast. Suured muusikafirmad võitlevad hambad ristis internetipiraatlusega. Aga on selles midagi hullu, kui need suured firmad peaksid ära kaduma ja selle asemel oleks meil miljon korda rohkem võimalusi sõltumatute muusikategijate loominguga tutvuda?

Kultuuriski toimub tohutu killustumine. Selle asemel et meil oleks viis suurt valikut, on meil 5000 mikroskoopilist valikut.

— Aga kes võidab piraatide ja intellektuaalse omandi kaitsjate sõja?

— Ma arvan, et tehnoloogiliselt ei ole piraatlus põhimõtteliselt kontrollitav. Needsamad suured muusikafirmad ei ole peaaegu mingit edu saavutanud. Tõenäoliselt ei ole võimalik midagi teha. Meie moraalne seisukoht ei puutu seejuures asjasse.

Maailmas ei ole sellist jõudu, mis suudaks peatada info leviku. Täpselt samuti nagu tehnoloogilise arengu ja uute sotsiaalsete väärtuste tekkimise.

4 responses so far

« Prev - Next »