Görev Analizi Neyi Kaçırır: Hedef Bileşimiyle Özellik Üretmek

Görev analizi kullanıcının bugün ne yaptığını iyi anlatır. Yarın ne isteyeceğini anlatmaz. Hedef bileşimi, eldeki hedefleri bir avuç genel mekanizmayla çarparak henüz kimsenin talep etmediği özellikleri önceden görünür kılar. Yöntem işe yarıyor, ama ürettiği liste sandığından çok daha uzun çıkıyor.

Görev analizi neyi kaçırır

Görev analizi üç şeyi netleştirir: kullanıcı sistemde ne yapmak istiyor, hangi adımlardan geçiyor, nerede tıkanıyor. İlk sürüm için bundan iyisi yok. Gözlem olmadan yazılan özellik listesi tahminden ibarettir, tahminin maliyetini de sonra ödersin.

Sorun şu: analiz fotoğraf çeker. ARPANET uzaktaki bir makineye bağlanmak için kurulmuştu, trafiğin ağırlığı e-postaya kaydı. Kullanıcılar sistemi tasarımcının haritasında olmayan bir yere taşıdı. Aynı şey küçük ölçekte her projede olur: destek kayıtlarına bakarsan insanların ürünü hiç düşünmediğin bir iş için kullandığını görürsün.

Pratik sonuç: analizi bitirince durma. Eldeki hedef listesini bir sonraki adımda hammadde olarak kullan.

Hedef çarpı metahedef

Hedef bileşimi tek satırla şu: kullanıcının somut hedefini al, genel bir metahedefle birleştir, çıkan isteğin sistemde karşılığı var mı diye bak. “Mesaj gönder” hedefini “aynı işi birden fazla nesneye uygula” metahedefiyle birleştirirsen “birden fazla alıcıya gönder” çıkar. Karşılığı yoksa kullanıcı aynı işi beş kez tekrarlıyor demektir.

Yöntemin kıymeti burada: kimsenin dile getirmediği eksikleri, kullanıcı şikâyet etmeden önce yakalıyorsun.

Genelleştirme mekanizmaları

• Çoğullama: bir işlemi tek hamlede birden çok nesneye uygulamak. Toplu seçim, toplu etiketleme, toplu gönderim.
• Yeniden kullanım: bir kez kurulan şeyi tekrar çağırabilmek. Şablon, kayıtlı filtre, kopyala-ve-düzenle.
• Süper hedefleme: bir işlevin daha büyük bir işin alt adımı olması. E-posta gönderme işlevinin raporlama ve bildirim modüllerinin içinden çağrılabilmesi gibi.

Üçüncüsü en çok atlananı. Bir işlevi yalnızca kendi ekranından erişilebilir yazarsan, altı ay sonra onu başka bir akışın içinden çağırmak için ya kopyalarsın ya baştan yazarsın.

Entegrasyon: iş tek oturuşta bitmiyor

Kullanıcı bir işi yaparken araya başka bir iş girer. Çok pencere, kopyala-yapıştır, sürükle-bırak hep bunun için var. Arayüzün bir ekranda tek göreve kilitlemesi, insanı o görevi dışarıda bir not uygulamasında parçalamaya zorlar.

Yarıda bırakılan iş de aynı başlığa girer. Taslağı otomatik kaydet, sekme kapanınca veri gitmesin, ertelenen işlem için zamanlama bırak. Bir eylemin çıktısının başka bir eyleme girdi olabilmesi de öyle: dışa aktarma, bir listenin sonucunu doğrudan bir filtreye besleme, raporu olduğu gibi paylaşabilme. Son halka otomasyon, yani insanın hiç dokunmadığı tekrarlar.

Kullanıcı kontrolü ve geri almanın gerçek maliyeti

Kontrol mekanizmaları dört soruya cevap verir: işlem şu an ne durumda, sonucu ne oldu, daha önce ne yaptım, bundan başka hangi yolu seçebilirim. Bunlar pahalı değil, çoğu zaman sadece var olan durumu arayüze taşımak gerekiyor.

Beşincisi, geri alma, listede diğerleriyle eşit ağırlıkta durur ama değildir. Yerel durumda geri alma ucuzdur: değişikliği bir yığına yazarsın, geri sararsın. İşlem dışarıya çıktıysa, yani e-posta gönderildiyse, ödeme geçtiyse, webhook tetiklendiyse, geri alma diye bir şey kalmaz; yapabileceğin tek şey göndermeyi birkaç saniye geciktirip o aralıkta iptale izin vermektir (arayüzde bir düğmenin durması, işin arkada gerçekten geri alınabildiği anlamına geliyor sayılması bana fazla iyimser geliyor).

Yani tasarım kararı alırken ayır: geri alınabilir işlemler ile geri alınamayanlar aynı tasarım kalıbını paylaşmaz. İkincisinde doğru hamle onay ekranı değil, gecikmeli kuyruk.

On iki mekanizma, yüz yirmi aday

Yukarıda sayılanları toplayalım: genelleştirmede üç, entegrasyonda dört, kullanıcı kontrolünde beş. On iki mekanizma. Görev analizinden on hedefle çıktıysan, bileşim sana 120 aday özellik verir. Hiçbir ekip 120 özellik yazmaz, bu listenin yarısı da zaten anlamsızdır.

Bu yöntemin sınırı tam burada: hedef bileşimi bir üretme yöntemi, bir önceliklendirme yöntemi değil. Listeyi uzatır, sıralamaz. Sıralamayı başka yerden getirmen gerekir.

İşe yarayan filtre iki soruluk. Kullanıcı bu işi şu anda elle mi yapıyor, yani bir kaçış yolu bulmuş mu? Ve bunu ne sıklıkta yapıyor? İkisine de “evet, sık” diyorsan yap. Kaçış yolu var ama ayda bir kullanılıyorsa bekletebilirsin. Hiç kimsenin denemediği kombinasyonlar ise aday olarak kalsın, gelecek sürümde destek kayıtlarına bakıp tekrar sor. Bileşim listesinin değeri yazdığın özelliklerde değil, altı ay sonra gelen talebi gördüğünde “bunu zaten düşünmüştük” diyebilmende.