Kurumsal Kullanılabilirlik: Alıcı ile Kullanıcı Aynı Kişi Değil

Kurumsal yazılımın kötü olmasının sebebi tasarımcı yokluğu değil. Ürünü seçen kişi onu kullanmıyor, kullanan kişinin de değiştirme yetkisi yok. Bu ayrımı hesaba katmadan yürütülen kullanılabilirlik çalışması, doğru bulguyu yanlış kişiye anlatmakla bitiyor.

Satın alma kriteri ile kullanım kriteri örtüşmüyor

Satın alma tarafı özellik listesine, entegrasyon kolaylığına, güvenlik denetiminden geçip geçmediğine ve fiyata bakıyor. Kullanan taraf ise günde kırk kez tekrarladığı akışın kaç tıkla bittiğine bakıyor. İki liste aynı toplantıda karşılaşmıyor.

Yapılacak şey bulguyu tercüme etmek. "Bu ekran kafa karıştırıyor" cümlesi satın alma tarafında karşılık bulmuyor; "bu form günde şu kadar kez dolduruluyor, üç alan otomatik gelse kişi başı şu kadar dakika geri geliyor" cümlesi buluyor. Ölçümü yapmadan bu cümleyi kuramazsınız, o yüzden ölçüm ilk iş.

Üç seviye, üç ayrı ölçü

Bireysel kullanıcı, ekip ve kurum. Bu üçlü ayrım işe yarıyor ama tek başına bir şey söylemiyor; her seviyenin kendi ölçüsü olmalı.

• Birey: görev tamamlama süresi ve hata sayısı.
• Ekip: bir işin bir kişiden diğerine geçerken beklediği süre.
• Kurum: destek talebi hacmi, yeni çalışanın eğitim süresi, lisans başına gerçekten aktif kullanıcı oranı.

Üçü birden iyileşmiyor. Bireysel arayüzü sadeleştirirken ekip görünürlüğünü kaybettiğiniz, ya da merkezî yönetimi güçlendirirken bireyi izin duvarına çarptırdığınız oluyor. Hangisinin lehine karar verdiğinizi yazılı tutun, sonradan tartışma çıkıyor.

Hata mesajı en ucuz iyileştirme

Hata kodlarını sıklığa göre sıralayın. Düzeltilecek metin listesi genelde ilk sayfada bitiyor, çünkü destek yükünün büyük kısmını birkaç tekrar eden mesaj üretiyor. Metin değişikliği bir sürümde çıkar; süreç değişikliği aylar sürer. Sıralama bu yüzden yapılıyor.

İşe yarayan bir mesaj üç şeyi söylüyor: ne oldu, neden oldu, şimdi ne yapılmalı. "Beklenmeyen bir hata oluştu" üçünü de söylemiyor ve doğrudan destek hattına yazılmış bir davetiye işlevi görüyor.

Sürüm uyumsuzluğu bir takvim sorunu

Farklı departmanların farklı sürümlerde kalması kaçınılmaz. Sürüm farkını genelde arayüzü sürümleyip istemcileri serbest bırakarak çözerim; herkesi aynı gün güncellemeye zorlayan planlar kâğıt üstünde kalıyor.

Bunun bedeli şu: aktif tuttuğunuz her sürüm ayrı bir test yükü. Bu yüzden eski sürüm bir geçiş penceresi olarak tanımlanmalı ve pencereye bitiş tarihi yazılmalı. Tarih yazılmadığında sürüm sayısı hiç azalmıyor, sadece artıyor.

Testi kurumun içinde nasıl kurarsınız

Katılımcı bulmak kurumda dışarıdakinden kolay. Zor olan takvim ve yöneticinin onayı. Oturumu yarım saatte tutun, kişinin kendi masasında ve kendi gerçek verisiyle yapın. Laboratuvara götürdüğünüzde asıl görmek istediğiniz şey kayboluyor.

Saha gözleminin verdiği tek şey de bu: telafi davranışları. İkinci ekranda açık duran eski sistem, kâğıda alınan not, aynı veriyi elle iki yere girmek. En çok işe yarayan işaret ise şu: kullanıcıların Excel'e kaçtığı her nokta, sistemin eksik bıraktığı bir özelliktir. Orada ne yaptıklarına bakın, gereksinim dokümanı zaten orada duruyor.

Neyi önce düzelteceksiniz

Sıralamayı üç çarpanla yapın: sorun kaç kişiyi etkiliyor, kişi başına ne sıklıkta çıkıyor, her seferinde ne kadar zaman ya da kaç hata üretiyor. Bu çarpımın üstünde kalanlar önce, kozmetik olanlar en sona.

Tek istisna kilitleyen hatalar. Nadir çıksalar da işi tamamen durduruyorlarsa listenin başına alınmalı, çünkü kullanıcı bir kez alternatif yol icat ettiğinde sorunu düzeltseniz de o yola devam ediyor. Toplam sahip olma maliyeti tartışması da buradan çıkıyor; ayrı bir başlık değil, bu sıralamanın toplamı.