UX Yol Haritasında Önceliklendirme: Beş Yöntem, Hangisi Ne Zaman

Önceliklendirme yöntemleri sıralamayı üretmez, tartışmayı düzenler. Aynı backlog'u Impact-Effort matrisine, RICE'a ve Kano'ya sokun, büyük ihtimalle üç farklı sıra çıkar. Yöntemi seçerken sorulacak soru hangisinin daha doğru olduğu değil, elinizde hangi bilginin eksik olduğu.

Impact-Effort matrisi: en hızlısı, en kırılganı

İki eksen, dört kutu. Yüksek etki ve düşük efor kutusundaki işler önce yapılır, düşük etki ve yüksek efor kutusundakiler listeden düşer. Yarım saatte kurulur, herkes katılabilir, sonucu bir bakışta anlaşılır.

Kırılganlığı efor ekseninde. Bir işin eforunu, o işi yazacak kişi tahmin etmiyorsa matris bir dilek listesine döner. "Kullanıcı avatarı ekleyelim" kutucuğu tasarım tarafında küçük görünür; arka planda dosya yükleme, boyutlandırma, depolama ve moderasyon anlamına geliyorsa küçük değildir. Matrisi kuran toplantıda geliştirici yoksa çıkan haritanın hangi kutusuna güveneceğinizi bilemezsiniz.

Etki eksenini de sorgulamak gerekir. Çoğu ekipte etki puanı, o özelliği en çok kimin savunduğuyla ilişkili çıkıyor.

Yapılabilirlik, arzulanırlık, sürdürülebilirlik skor kartı

Üç kriter üzerinden 1-10 puanlama yapılır: teknik olarak mümkün mü, kullanıcı istiyor mu, iş modeline uyuyor mu. Matristen daha bütünsel bir tablo verir, özellikle iş tarafının itirazlarını süreç içine aldığı için.

Uygulamada iki sorun çıkar. Birincisi ortalamaya kaçma: kimse 2 ya da 9 vermek istemez, her şey 5 ile 7 arasına yığılır ve sıralama tesadüfe kalır. Buna karşı puan aralığını daraltmak işe yarar, örneğin 1-3-9 gibi üç değerle çalışmak. İkincisi, asıl kararın kriterlerin ağırlığında saklı olması. Sürdürülebilirliği arzulanırlığın iki katı ağırlıklandırdığınız anda sonucu büyük ölçüde belirlemiş olursunuz, ve o ağırlık tartışması genelde hiç yapılmaz.

RICE: sayı verir, kesinlik vermez

Formül basit: erişim, etki ve güven çarpılır, efora bölünür. Ürün ekipleri arasında yaygın olmasının sebebi, farklı büyüklükteki işleri tek bir ölçekte karşılaştırılabilir hâle getirmesi.

Buradaki problem aritmetik. Üç tahmini çarpıyorsunuz ve tahminlerin hatası da çarpılarak büyüyor. Erişim iki kat, etki iki kat, efor iki kat şaşarsa skorun sekiz kat şaşması mümkün. Güven çarpanının formüle konmuş olması aslında bunun itirafı; yöntemin kendisi diğer üç sayıya güvenmediğini söylüyor.

Sıralamayı RICE skorunun ondalık basamağına bağlamam. İki iş arasında iki kattan az fark varsa o ikisini aynı kefede sayıp kararı başka bir gerekçeyle vermek daha dürüst. Yöntem, 40 maddelik bir listeyi 8 maddeye indirmekte iyi; o 8 maddeyi kendi içinde sıralamakta değil.

MoSCoW: netlik kolay, disiplin zor

İşler dörde ayrılır: olmazsa olmaz, olması gereken, olsa iyi olur, bu sefer değil. Sabit bir zaman kutusuyla, sprint ya da sürüm planıyla birlikte kullanıldığında iyi çalışır. Zaman kutusu yoksa hiçbir işe yaramaz, çünkü "bu sefer değil" sepetinin anlamı ancak bir "sefer" tanımlıysa vardır.

Yöntemin bilinen hastalığı zorunlu listesinin şişmesi. Herkes kendi maddesini oraya taşımak ister ve liste sonunda backlog'un aynısı olur. Pratik bir sınır koymak gerekir: zorunlu işlerin toplam eforu sürümün kapasitesinin yarısını geçiyorsa sorun önceliklendirmede değil, kapsamdadır. O noktada sıralamaya devam etmek yerine sürümü bölmek doğru hamle.

Kano modeli: doğru soruyu sorar, pahalıya sorar

Kano, özellikleri kullanıcı memnuniyetiyle ilişkisine göre ayırır. Temel beklentiler yokken rahatsızlık yaratır, varken fark edilmez. Performans özellikleri yatırım arttıkça memnuniyeti doğrusal artırır. Cezbedici özellikler beklenmediği için memnuniyeti sıçratır, ama zamanla temel beklentiye dönüşür. Bu son nokta modelin en değerli tarafı: bugün rakipten ayrıştıran özellik iki yıl sonra yokluğu şikâyet edilen özellik olur.

Maliyeti anket tarafında. Sınıflandırma, her özellik için iki soru sormayı gerektirir: özellik varsa ne hissedersiniz, yoksa ne hissedersiniz. Yirmi özellik kırk soru demektir ve bu uzunlukta bir anketin son üçte birinde verilen cevaplar dikkat kaybı yüzünden güvenilirliğini yitirir. Yani Kano'yu tüm backlog'a uygulamak, tam da güvenmek istediğiniz veriyi bozar. Yöntemi ekip içinde anlaşmazlık çıkan beş altı özelliğe uygulamak, kırk maddeyi taramaktan daha iyi sonuç verir.

Hangisini ne zaman

Liste uzun ve kimse nereden başlayacağını bilmiyorsa Impact-Effort matrisi yeter, tek şartla: efor tahminini işi yapacak kişi versin. Karar birden fazla ekibi ilgilendiriyor ve iş tarafının itirazı varsa skor kartı, tartışmayı kriterler üzerinden yürüttüğü için daha iyi. Çok sayıda benzer büyüklükte iş varsa RICE eleme için kullanılır, sıralama için değil. Sabit süreli bir sürüme hazırlanıyorsanız MoSCoW. Bir özelliğin gerçekten fark yaratıp yaratmadığı tartışılıyorsa Kano.

Yöntemlerin hiçbiri, ekibin varsayımlarını düzeltmez. Yanlış bir etki tahmini RICE'a girdiğinde daha güvenilir görünen bir yanlış tahmin olarak çıkar. Önceliklendirme toplantısından çıkan sıra, o toplantıdaki en zayıf tahmin kadar sağlam.