Feb 27 2010

Veel IT-st ja kommunikatsioonist

Published by Targo at 7:00 pm 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

3 Responses to “Veel IT-st ja kommunikatsioonist”

  1. Tambeton 28 Feb 2010 at 11:54 pm

    Brooks’i seaduse kohta on näiteks Steve McConnellil ka alternatiivne arvamus:
    http://www.stevemcconnell.com/ieeesoftware/eic08.htm

    Ei suuda mainimata jätta Joeli kommentaari Ship-It auhinna kohta :)
    http://www.joelonsoftware.com/articles/fog0000000070.html

  2. Targoon 01 Mar 2010 at 12:02 am

    Ma tean jah, et Joelile see auhind ei meeldinud, aga pole nõus tema hinnanguga, et see on 100% intelligentsete inimese solvamine. Olen läbi aegade näinud nii rahvast (sõltumata intelligentsusest, ettevõttest või auhinna tüübist), kes oma auhinnad kapi taha viskavad, kui ka inimesi, kes sealt pealt iga päev tolmu pühivad.
    MSis oli ka üks muidu väga taiplik vend, kes minu tiimist mõni kuu enne projekti lõppu lahkudes uuris, kas ta ikka kuidagiviisi oma tunnustusmärki ei saaks.
    Maitseasi seega.

  3. Tambeton 02 Mar 2010 at 12:46 am

    Tegelikult polnud Joeli tsitaat Microserfsist ka päris korrektne. Tema jutust jääb mulje, nagu oleks grupp programmeerijad üritanud enda Ship-It auhinda hävitada vihast selle vastu. Kui aga lugeda originaali, siis tuleb välja, et nad üritasid hävitada ühe kaastöötaja Ship-It auhinda kadedusest selle vastu (või siis lõbu pärast :) .

    http://www.wired.com/wired/archive/2.01/microserfs_pr.html

Comments RSS

Leave a Reply