Birikmiş özellik taleplerine öncelik vermek

Özellik taleplerini takip etmek, nerede yaşadıklarını çözer. Sırada hangisinin gideceğini çözmez, ve ekiplerin gerçekten takıldığı ikinci soru budur. Gruplanmış, etiketlenmiş üç yüz taleplik bir birikim bile hâlâ bir karar kuralına ihtiyaç duyar, çünkü “en çok istenen şeyi yap” ancak iki talep birbirine yakın olana ve üçüncüsünün gürültülü bir savunucusu olana kadar işe yarar, ki bu haftaların çoğunda böyledir. Aşağıdaki çerçeveler aynı soruya rakip yanıtlar değildir. Her biri farklı bir talep türüne uyar, ve hepsi için tek bir çerçeve kullanmak genellikle asıl hatadır.

Özellik taleplerine öncelik vermeyi bir roadmap’e öncelik vermekten farklı kılan nedir?

Bir roadmap kararı stratejiden başlar ve neyin inşa edileceğini sorar. Bir özellik talebi kararı zaten var olan bir talepten başlar ve buna göre hareket edilip edilmeyeceğini sorar, ve ikisi yeterince sık farklı yönlere çeker ki bir talebin yüksek talebi olabilir ve yine de inşa edilmesi yanlış olabilir, veya düşük talebi olabilir ve yine de stratejik bir hesabı açtığı için değerli olabilir. Her talebi bir roadmap oyu gibi ele almak bu kontrolü atlar.

RICE nedir, ve özellik talepleri için işe yarar mı?

RICE bir fikri kapsam, etki, güven ve çaba üzerinden puanlar, sonra karşılaştırılabilir bir sayı elde etmek için ilk üçü dördüncüye böler. Bir ekibin zaten inandığı roadmap fikirleri için tasarlanmıştır, ve zor kısım farklı bahisleri birbiriyle karşılaştırmaktır. Özellik talepleri zaten bir kapsam sayısıyla gelir, isteyen kişi sayısı, ki bu yeni bir roadmap fikrinin genelde sahip olduğu kapsamdan daha somuttur. RICE’ın bir talep karşısında gerildiği yer güven ve etkidir: bir ekip bir talebin gerçek olduğundan emin olabilir ve yine de bir metriği ne kadar hareket ettireceğine dair bir temeli olmayabilir, çünkü zaten bir ismi ve gerçek kullanıcı izi olan bir talep için “etki”, odanın dışında henüz kimsenin görmediği bir fikrin etkisinden farklı bir tahmin türüdür.

RICE’ı ciddi olarak değerlendirilen ve henüz karara bağlanmamış talepler için kullan. Gelen her talebe uygulama; puanlama çabası ancak eşitlik bozucuya ihtiyaç duyacak kadar birbirine yakın olanlarda karşılığını verir.

Gelire göre mi, yoksa kimin istediğine göre mi ağırlıklandırılmalı?

Kimin istediğine göre, ama sadece gelire göre değil. Yenilemeye yakın bir hesap, daha önce eskalasyon yapmış bir hesap, ve talebi devam eden bir anlaşmayı açan bir hesap, düz bir gelir rakamının tek başına yakalayamadığı bir aciliyet taşır, ve deneme kaydından gelen bir talep, yakında gelire dönüşecek bir kararı engelliyorsa yine de önemli olabilir. Gelire göre ağırlıklandırma bunların hesaplanması en kolay olanıdır, ve tam da bu yüzden fazla güvenilmesi en kolay olanıdır: gerçek payı olmayan hesaplardan gürültüyü doğru şekilde kaldırır, ve aynı kolaylıkla hâlâ boru hattında olan çok daha büyük bir hesabı kazandıracak bir talebi de düşürebilir.

Oylar gerçekte hangi rolü oynar?

Zaten var olan talepler için ucuz, sürekli bir sinyal, ve hangi taleplerin en başta var olması gerektiğini keşfetmek için kötü bir yol. Bir oy sayısı sadece talebi zaten bulmuş ve tıklamaya değer bulmuş kullanıcılara ulaşır, ki bu, kamuya açık bir roadmap’in oy toplamının talep kadar görünürlüğü de yansıttığı anlamına gelir: listenin üstüne yakın eski bir talep, kısmen bulunması kolay olduğu için oy toplamaya devam eder, ve daha yeni, eşit derecede gerçek bir talep sıfırdan başlar. Genel roadmap yazısı, oyları roadmap’in tamamen dışında bırakmayı savunur. Oyları, sırayla inşa edilecek bir sıralama olarak değil, gruplanması ve güncelliğe göre ağırlıklandırılması gereken bir girdi olarak ele al. Destek biletleri vs. özellik talepleri oy sayılarındaki diğer kör noktayı ele alır: ona rastlayan kullanıcılar panoyu asla bulamazsa gerçek bir boşluk neredeyse hiç oy üretmeyebilir, buna karşın destekte gürültülü bir şekilde ortaya çıkar.

En gürültülü müşteri ne zaman kazanır, ve bu bir sorun mu?

Bazen, ve bu sadece kimse fark etmediğinde bir sorundur. Sık sık eskalasyon yapan, ayrıntılı biletler yazan veya ekipteki biriyle doğrudan hattı olan bir müşteri, talepleri eşit derecede geçerli ama daha sessiz bir müşteriden daha hızlı görülecektir, ve bunu hiç kontrol etmeyen bir önceliklendirme süreci, en güçlü davası olanı değil, en çok ısrar edeni sistematik olarak kayıracak demektir. Gürültülü müşteriler düzeltilmesi gereken sorun değildir; talepleri genellikle gerçekten önemlidir. Düzeltme bir alışkanlıktır: birikimi periyodik olarak kaynağa göre gözden geçir ve aynı avuç içi kadar hesabın son zamanlarda gönderilenlerin çoğunu açıklayıp açıklamadığını kontrol et, ve bunun gerçek talebin nerede olduğuyla eşleşip eşleşmediğini sor.

Bir önceliklendirme kararı nasıl bir yanıta dönüşür?

Buradaki her karar hem kazananlar hem de kaybedenler üretir, ve ikisi de sadece açıklamasız bir durum değişikliği değil, gerçek gerekçeyi adlandıran bir yanıtı hak eder. Bir özellik talebi nasıl reddedilir kaybeden bir talebe, jenerik bir ret gibi okunmak yerine ilişkiyi sağlam tutan bir şekilde ne söyleneceğini ele alır. Tüm bunları en başta mümkün kılan gruplama ve etiketleme işi özellik talebi takibi yazısında ele alınır; önceliklendirme yalnızca zaten kaydedilmiş ve karşılaştırılabilecek kadar iyi gruplanmış talepler üzerinde işe yarar.

FAQ

Özellik taleplerine öncelik vermek için en iyi çerçeve nedir? Hiçbiri tek başına değil. En gürültülü sinyali bulmak için ham sayıları, kısa bir ciddi aday listesini karşılaştırmak için RICE’ı, ve stratejik bir hesaptan gelen sessiz talebin daha gürültülü ama daha az önemli bir grubu geride bıraktığı durumları yakalamak için bir gelir veya hesap kontrolünü kullan.

Özellik talepleri roadmap fikirleriyle aynı şekilde mi önceliklendirilmeli? Hayır. Roadmap fikirleri stratejiden başlar; özellik talepleri zaten var olan bir talepten başlar. Onları birlikte puanlamak, iyi savunulmuş ama az mevcut talebi olan stratejik bir bahsin, sadece daha fazla kişinin istediği bir talep karşısında sürekli kaybetmesine neden olur.

Genel bir roadmap’teki oylar talebi doğru şekilde yansıtır mı? Sadece talebi zaten bulmuş kişiler arasında. Daha eski, daha görünür talepler, arkalarında daha yeni bir talep için gerçek talebin ne kadar olduğuna bakılmaksızın daha hızlı oy toplar, bu yüzden oy toplamlarını sırayla inşa edilecek bir sıralama olarak değil, gruplanmış ve güncelliğe göre ağırlıklandırılmış bir sinyal olarak ele al.

Özellik talebi öncelikleri ne sıklıkla yeniden değerlendirilmeli? Sadece biri eskalasyon yaptığında değil, sabit bir döngüde. Talepleri yeniden gruplayan ve ağırlıklandırmayı yeniden kontrol eden aylık veya üç aylık bir geçiş, gönderilenlere hakim olan bir avuç hesap gibi, saf reaktif bir sürecin kendi kendine asla ortaya çıkarmadığı sapmaları yakalar.

Bu yazıdaki teknik iddialar bağımsız olarak kontrol edilmedi. Yanlış bir şey varsa bize söyle, düzeltelim.

changeloop'ta ilgili sayfalar: Geliştirici dokümantasyonu, Changelog araçları karşılaştırması