Hirm kasutajakesksuse ees

Olen viimasel ajal sattunud huvitavasse olukorda - rääkides tarkvaraarendajatele kasutajakesksete meetodite kasulikkusest, olen pidanud alustama selgitamisest, et see ei ole teie peksmise tööriist :). See ajendas mind kirja panema mõned faktid ja tõdemused, millega oma töös ikka ja jälle kokku puutun.

1. Head kasutatavust pole enamjaolt võimalik saavutada loomulikust intelligentsist (reeglina ei kehti väga väikeste süsteemide kohta)

Kasutajakeskset süsteemi disainitakse läbi teadmise süsteemi kasutajate tegelikust elust, harjumustest, oskustest ja eesmärkidest. Selleks on eraldi töövõtted, mis teevad ka suurte ja keerukate süsteemide disainimise võimalikuks. Arvamustele ei ole siin reeglina kohta. Kui klient ja teenusepakkuja ei ole omavahel nendes töövõtetes kokku leppinud, ei ole neid ka projektis võimalik teha ja tulemus kannatab.

2. Kasutajakesksete meetodite eesmärk on ennetada kasutatavuse probleeme

Kasutajakesksete disainimeetodite rakendamine peale süsteemi väljatöötamist ei oma enam mõtet, sest kõik vead on juba ammu tehtud ja kasutatavust ei olnud selle süsteemi jaoks defineeritud. Mida varem kasutatavusele ja kasutajakesksusele mõelda, seda kvaliteetsem tuleb süsteem ning seda vähem kulub aega ümbertegemisele.

(Vahemärkus: jah, läbi kasutatavuse testimise saab ka projekti lõpus teha asju paremaks, aga nagu kõik kvaliteediga seotud tegevused, on kvaliteedi "sisse testimine" kõige vähem tõhus töömeetod.)

Projekti lõpus nentida, et süsteem ei ole kasutatav, on ebameeldiv ja vahest hakkab ka rahakotile. Klient on õnnetu ja arendusfirma ei saa enam suure tõenäosusega samalt tellijalt tööd. Rääkimata nendest inimestest, kes panid hullemal juhul mitu aastat oma elust millegi loomisele, mille parema meelega maha salgaks.

3. Hinnata süsteemi eelnevat kokkuleppimata nõuete vastu ei tee süsteemi kasutajasõbralikumaks, vaid tekitab tüli ja ebakvaliteetse tarkvara loomist

Ideaalne näide on kasutatavuse hinnangu lülitamine üleandmise ja vastuvõtmise üheks kriteeriumiks.
Muidugi, mina kui konsultant ei ütle ära võimalusest raha teenida, kuid kasutajakesksete tööde lülitamine projekti ainult kellegi töö hindamiseks, hetkel kui süsteem peaks valmis olema, ei paista kuidagi võimalusena eelarves ja ajagraafikus püsimiseks.

Küll on see ideaalne võimalus alustada kliendil tarnijaga läbirääkimisi: te kas teete veel hulga tasuta tööd või jääte oma tasust ilma. Kuna tavaliselt ei ole lepingus täpsustatud kasutatavuse nõudeid, pingutab teenusepakkuja sellel perioodil pigem enda kaitsmise nimel selle asemel, et keskenduda töö ettevalmistamisele üleandmiseks ning tulemuseks saame lihvimata käki, mis võetakse vastu (tavaliselt hiljem) ja mis justkui enam-vähem töötaks. Kõik on pettunud ja halb maik ka suus.

Kui soovida kvaliteetset ja ka kasutatavat tarkvara, peaks selles osas klient ja teenusepakkuja koostööd tegema, lülitades eesmärgipõhiselt vastavaid töid projekti juba väga varajases staadiumis.

4. "Talupoja mõistus" ei ole laialt levinud mõistuse vorm ja "tädi Maali" metsast on lihtsalt fiktiivne persoon(a), kes tuleb mängu siis, kui müüakse uut süsteemi või tülitsetakse (st arutelu ilma faktideta, mis on juba kontrolli alt väljunud)

Olgem ausad, eeldamine ja mõistmatus on inimkonna hukatus :). Kui kasutatavuse juures midagi eeldatakse, on see sama hea kui ütelda: "Ma ei osanud nõudeid püstitada aga see, mille te valmis tegite, nendele nõuetele ei vasta."

Kasutajakesksed töövõtted ei lahenda küll kõiki tarkvaraprojektidega seotud probleeme, kuid kindlasti aitab kaasa kvaliteetsete töötulemite loomisele.

Konkurents on tihe ja võimalus kvaliteetset tööd teha, peaks olema tarkvaraarendajale ahvatlev eelis :). Kliendi esindaja, kes juhtis igati õnnestunud tarkvaraprojekti, on aga iga tellija unistus ning alati oma töötulemite poolest esile tõstetud (kui muud kasu sellest tunnustusest pole, siis palgatõusu arutelul ikka argument ;))

www.twn.ee