Archive for February, 2010

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