Offshore Projelerde Uzaktan Kullanıcı Testi Neyi Çözer
Offshore ekiple yürüyen projelerde kullanılabilirlik sorunu genellikle ekibin nerede oturduğuna bağlanır. Asıl mesele mesafe değil, kullanıcıyla ekip arasındaki geri bildirim yolunun uzunluğu ve sözleşmenin neyi teslim edilebilir saydığı. Uzaktan test bu yolun bir kısmını kısaltır, hepsini değil.
Coğrafya bir açıklama değil
Konuyla ilgili eski metinlerin ortak refleksi, Hindistan ya da Çin'deki ekiplerin insan-bilgisayar etkileşimi geçmişinin zayıf olduğunu söylemek. Bu iddia bugün zor savunulur; o pazarların kendi büyük ölçekli dijital ürünleri var ve oradaki tasarım ekipleri aynı literatürü okuyor.
Aynı sorun aynı şehirdeki iki ofis arasında da çıkıyor. Ekip kullanıcıyı hiç görmemiştir, gereksinimi bir tabloda madde madde alır, teslim eder, arada kimse "bu ekranda ne yapmaya çalışıyordu" diye sormaz. Kullanılabilirlik burada kayboluyor. Uzaklık bunu hızlandırır, üretmez.
Heuristik değerlendirme neden en zayıf halka
Uzaktan yöntem listelerinde heuristik değerlendirme hep başa yazılır: kullanıcı toplamak gerekmez, birkaç uzman arayüzü kurallara göre gezer, rapor çıkar. Aynı listeler hemen ardından uzmanların kullanıcı davranışını yakından bilmesi gerektiğini ekler. Offshore projede eksik olan tam olarak budur. Yani listenin ilk maddesi, çözmesi beklenen sorunun kendisine dayanıyor.
Yöntemi çöpe atmak gerekmiyor, yerini değiştirmek gerekiyor. Heuristik değerlendirmeyi kullanıcı testinin yerine değil öncesine koy; geri dönüşü olmayan işlemler ve klavyeyle gezilemeyen alanlar gibi bariz hataları temizler, böylece gerçek katılımcının kırk dakikası bunlara harcanmaz.
Uzaktan testin iki biçimi
Moderasyonlu oturumda katılımcı kendi bilgisayarında görevi yaparken kolaylaştırıcı izler ve soru sorar. Sebebi görürsün. Bedeli takvimdir: iki ülke, iki saat dilimi, bir de gözlemci grubu aynı saatte buluşacak. Sekiz katılımcılık bir turu planlamak çoğu zaman testin kendisinden uzun sürer.
Moderasyonsuz testte görevleri ve soruları önceden yazar, katılımcının kendi zamanında yapmasını beklersin. Takvim sorunu biter, karşılığında "neden" sorusunu kaybedersin. İkisini birbirinin alternatifi saymak yerine sırayla kullan: geniş bir moderasyonsuz turla nerede takıldıklarını bul, ardından üç dört moderasyonlu oturumla neden takıldıklarını sor.
Kaç katılımcı meselesi
"Beş kullanıcı yeter" cümlesi bu alanda fazla rahat dolaşıyor. Arkasındaki hesap açık: her katılımcının sorunların ortalama üçte birine denk geldiği varsayılırsa beş kişide bulunan oran yüzde 85'e yakın çıkıyor. Bu bir doğa yasası değil, bir model, ve girdisi olan o üçte birlik oran ekranın karmaşıklığına göre oynuyor.
Tek bir akışı test ediyorsan beş kişi gerçekten yeterli. Rolleri ayrışmış bir kurum içi uygulamada, mesela yönetici ile saha çalışanının bambaşka ekranlar gördüğü bir sistemde, beş kişi çoğu zaman tek rolün beş temsilcisi oluyor ve kalan roller hiç görülmüyor. Böyle bir projede katılımcı sayısını değil tur sayısını artır: iki haftada bir beş kişi, altı ayda bir otuz kişiden daha çok hata yakalar, üstelik yakaladığını düzeltecek zaman da kalır.
Kaydı sürüme bağla
Uzaktan testin kayıt tarafı genelde "hepsini kaydedelim" diye çözülüyor, sonra kimse üç saatlik videoyu açmıyor. Oturum kaydını göreve ve derleme numarasına göre isimlendir, bulguyu da geçtiği saniyeyle birlikte yaz. Üç hafta sonra "bu hata hangi sürümde vardı" sorusu bir arama sorgusuna dönüşür, arşiv taramasına değil. Bunu üç satırlık bir isimlendirme kuralıyla çözersin, ayrı bir araç almana gerek yok.
Ölçüm tarafı da aynı disiplini istiyor. WebPageTest gibi araçlarla farklı ülkelerden yükleme süresi ölçebilirsin ve offshore projelerde bu adım genelde atlanıyor: ekip sayfayı kendi ağında hızlı görüyor, kullanıcı üç bin kilometre öteden ilk ekranın gelmesini bekliyor. Görev süresi ölçtüğün bir testte ağ gecikmesini ayırt edemezsen, tasarım hatası sandığın şey aslında bekleme olabilir.
Sözleşmede yoksa yapılmaz
Bunların hepsinin üstünde duran şey sözleşme. Sabit kapsamlı, teslimatı madde madde tanımlanmış bir offshore anlaşmasında kullanıcı testi hiçbir maddenin karşılığı değildir; ekip testi yaparsa kendi cebinden yapar, çıkan bulguyu uygulamak da kapsam değişikliği sayılır. Bu yapıda kimse test istemez, istese bile ikinci kez istemez.
Yapılacak şey, test turlarını ve düzeltme payını sözleşmede ayrı kalem olarak yazmak: kaç tur, hangi katılımcı profili, bulgular hangi sürede ele alınacak. Ekibin nerede oturduğunu değiştiremezsin, ama bulgunun bir işe dönüşüp dönüşmeyeceğini imza aşamasında belirlersin.
Kaynak