RSS

e-Greške naše svagdašnje

Thu, Dec 17, 2009

ePoslovanje, eSigurnost

e-Greške naše svagdašnje

Ne možete vi toliko istestirati sustav koliko jedan sasvim prosječan korisnik može odigrati “pravi” redoslijed klikova i dovesti sustav do stanja neupotrebljivosti. Pa kako je uopće mogao tamo kliknuti, gdje piše da je trebao kliknuti “taj klik”? Ha?!? Gdje?!! Pa, ne piše nigdje, ali vi ste mu omogućili da on klikne, baš to što u tom trenutku možda “nije trebao”. Zato jer može, jer je ljudsko biće koje je samo po sebi radoznalo. Mi, s druge strane, projektanti i sva sila razvoja, prihvaćamo ovakve greške odmah na nož, kao… loše su za nas. Moš’ mislit’. Programer je ispustio jedan IF-ELSE i to je smak svijeta, njegova kompetencija je narušena, neće nas nikada više moći pogledati u oči. A jeste li čuli za onu, staru – na greškama se uči…? Dakako da jeste, idemo sad na nekoliko primjera vidjeti kako greške okrenuti u našu korist.

U pravilu, velike robusne sustave gotovo je nemoguće istestirati, kombinacija je jednostavno previše a osoba koja testira (tzv. quality assurance manager; da i u te svrhe možete biti menadžer) nakon nekog vremena će ispustiti koju pojedinost i početi ju prihvaćat zdravo za gotovo, ne sluteći kako će korisnik postupiti u datom trenutku. To je ljudski. Kao potvrdu gornje tvrdnje uzmite odavno otrcanu ali i dalje popularnu priču – MS Windows. Ima li grešaka? A, ne nema… Da li su Windowsi izopčeni iz društva? Nisu, čak naprotiv, ljudi ih i dalje kupuju, plaćaju support, nadogradnje…

-

Neki bi rekli…

Neki bi rekli – samo mrtav korisnik je dobar korisnik. Zašto? Jer su isfrustrirani “glupim” pitanjima i prijavama “kvarova” na sustavu. Glupa pitanja ne postoje, kažu, postoje samo glupi odgovori. Također, kažu i sljedeće – bolje biti glup 5 minuta, nego ostatak života.

Kažu još da je bolje spriječiti nego liječiti. Mi ipak ne možemo uvijek spriječiti poneku pogrešku u sustavu, ali možemo dati sve od sebe da ju čim prije “uhvatimo”. Ono što je bitno u sustavima, velikim ili malima, jest da osigurate zapisivanje pogrešaka na neku centraliziranu vama dostupnu lokaciju. Dakle, da zapisujete ponašanje aplikacije u tzv .LOG datoteke.

-

Pomoć putem telefona

Koliko puta ste se našli u situaciji da vas korisnik panično zove, izvan sebe je jer na ekranu nije dobio ono što je trebao, velikim slovima mu piše “GREŠKA”. Vi s druge strane telefona dajete mu upute što bi mogao probati, pa klikni tu pa klikni tamo. Ne ide. Onda se čak upustite u objašnjavanje kako da vam pošalje screenshot trenutnog ekrana. “Prvo nađite tipku Print Screen. Na tipkovnici. Da, Prnt Scrn je to što tražimo. Sad otvorite Outlook, tamo gdje pišete mailove. Stisnite CTRL+V. OK, probajte kroz Edit>Paste. Na hrvatskom ste? Onda je Uredi>Zalijepi. Neće? Hm…

Upuštanje u pružanje pomoći preko telefona osobi sa kratkim živcima to može biti jednako samoubojstvu. Ili, ubojstvu? :) Ovim putem upućujem “dva palca gore” svim osobama zaposlenim u helpdesk-ovima i call centrima. Radite odličan posao, nije vam lako! Ne dajte se, preživjet ćete samo ako u glavi imate jednu misao na pameti – to je samo posao.

-

Panični poziv

Zamislite sad sljedeći scenarij; Korisnik panično zove, izvan sebe je jer na ekranu nije dobio ono što je trebao, velikim slovima mu piše “GREŠKA” (da, ovaj dio se ponavlja). Vi mu kratko odgovarate “U redu, provjerit ćemo sustav i uskoro ćemo vas obavijestiti o daljnjem tijeku rješavanja problema. Hvala, srdačan pozdrav”. I sada na red dolazi onaj neočekivani dio (molim bubnjeve) – spuštate slušalicu. Naravno, ne na bezobrazan način, neka korisnik razumije da je razgovor završen i da mu ne možete dalje pomoći nikakvim uputama preko telefona.

Nadalje, spajate se na sustav, otvarate .LOG datoteke i tražite zadnje zapise o greškama korisnika koji vas je nazvao. Vi ste naravno bili domišljati pa ste u .LOG datoteku zapisali sve potrebne informacije iz vremena nastanka greške koje vam mogu dalje pomoći pri rješavanju iste (datum, vrijeme, trajanje, prethodne radnje, itd). Tu bi završio ovu horor priču. Daljnji tijek odvijanja je nebitan za ovu temu.

Naravno, mogli ste napraviti i sljedeće. Na ekranu pored teksta “GREŠKA” ispišete jedinstvenu oznaku (npr. broj) greške koja se dogodila. Na ovaj način odmah po primitku poziva korisnik vam kaže koja greška se dogodila, pa ćete imati kakav odgovor iz rukava i možda riješiti problem istog trena. Možda. No, na ovaj način (bez .LOG datoteke) ostajete bez opisanog slijeda događaja koji je doveo do greške.

-

greske

Greške koje nisu fatalne

Imamo i drugu vrstu grešaka. One koje nisu fatalne prirode, omogućuju daljnji rad no usporavaju korisnika kod pokušaja da odradi sljedeći korak. To su zapravo upozorenja, a ne greške.

Npr. korisnik klikne gumb “Snimi promjene” a iskoči mu upozorenje – “Snimanje nije moguće jer unesena cijena proizvoda nije u ispravnom formatu”. Klasičan primjer problematike sa decimalnim zarezom i točkom za tisućice. Korisnik tada ispravlja unos te zatim pokušava ponovo snimiti promjene, i tako sve dok unos ne bude ispravan. No, korisnik ovime ne biva zaustavljen u daljnjem poslu, može ga nastaviti, neće vas (vjerojatno) zvati zbog toga. No ometen je i misli su mu pobrkane. Umjesto da se preda završavanju svog posla on se praktički bori sa aplikacijom. Ovakva upozorenja ja bi također zapisivao u .LOG datoteku. Nakon X vremena kada količina zapisanih upozorenja naraste, išao bi analizirati što je to mučilo moje korisnike. Gdje su najviše promašili…?

Ako vidim da rade jednu te istu grešku, svakako ću razmisliti da način rada sa specifičnom cjelinom izmjenim, prilagodim očekivanjima korisnika. Jer ja sada znam da oni npr. stalno upisuju zarez za tisućice a točku za decimale. OK, oni koriste taj sustav, prilagodit ću njihovim potrebama, zašto bi uvijek forsirao “ispravan” način? Možda u ovom konkretnom primjeru ne bi zamjenio uporabu zareza i točke, no ono što bi napravio jest neka druga vrsta validacije unosa – “IF na prvom mjestu zarez AND na zadnjem mjestu točka THEN automatski zamjeni mjesta zarezu i točki”.

Možda bi u nekim slučajevima bolje rješenje bilo implementirati masku za unos koja bi “fizički” upravljala unosom brojeva u polje. Ne znam, odlučite samo što je najbolje, ja vam samo savjetujem da pratite korisnika te sukladno njegovom ponašanju konstantno prilagođavate sustav njegovim potrebama. Nećete pogriješiti.
Ne zaboravite da će vaš sustav ispasti puno bolji u očima novog korisnika ( potencijalnog kupca vašeg rješenja ) kada vidi da ste odmah u startu predvidjeli poboljšanja iz prakse njegove industrije.

Ocjena 3.50 od 5
, , , ,

Autor teksta:

Darko Martić - ukupno napisanih 11 tekstova na eBizMags.

Iako od malena fasciniran modernim tehnologijama pokušava ih spustiti na niži odnosno jednostavniji nivo, smatrajući da ne smijemo biti robovi tehnologije već da istu koristimo isključivo kao alat za jednostavnije rješavanje problematike. Stručno obrazovanje završava na Tehničkom veleučilištu u Zagrebu uz koje od samog početka započinje i sa prvim zaposlenjima na kojima stiče kvalitetna radna iskustva. Od kraja 90-ih pa sve do danas usmjerava se na razvoj e-projekata započevši u mladim danima kao dizajner-programer kako bi s vremenom nadopunio znanje širim vještinama tog područja kao što su SEO, usability, arhitektura web odredišta, itd. Trenutno radi kao Savjetnik za dokumentacijske sustave u King ICT na razvoju enterprise-level DCTM rješenja baziranih na web tehnologijama. www.martic.net

Kontaktiraj autora

Vas Komentar