Her müşteri başka bir özellik istiyor: ürün yol haritası nasıl önceliklendirilir?

Özellik taleplerini sıraya koymanın yolu daha iyi bir puan tablosu değil, yazılı bir karar kuralıdır: bir talep hangi kanıtla yol haritasına girer, hangi bütçeden harcar ve kim onaylar? Bu üç soru yazılı değilse liste kendiliğinden en yüksek sesli müşteriye göre dizilir. Sonucun nasıl göründüğünü ölçen veri de var. Pendo'nun 2019 Feature Adoption Report çalışması, ürünü bir yıldan uzun süredir kullanan 615 aboneliğin verisine bakıp ortalama bir yazılımda özelliklerin yaklaşık yüzde 80'inin nadiren ya da hiç kullanılmadığını söylüyor. Daha eski ve çok daha küçük bir örneklem, Standish Group'tan Jim Johnson'ın XP 2002 konuşması, dört kurum içi uygulamada yüzde 64 vermişti; Mike Cohn o rakamın dört projeden geldiğini ve genelleştirilmemesi gerektiğini hatırlatıyor. Rakamlar tartışmalı, yön tartışmalı değil: yazılan kodun büyük kısmı kimsenin açmadığı ekranlara gidiyor.

Talebi değil, problemi kaydedin

Müşteri size çözüm söyler: "Excel'e aktar butonu koyun." Kaydedilmesi gereken şey o buton değil, butonun arkasındaki iş. Müşteri aktardığı dosyayla ne yapıyor, haftada kaç kez yapıyor, şu an nasıl idare ediyor ve bunu yapamazsa ne oluyor? Çoğu zaman cevap "muhasebeye aylık mutabakat listesi gönderiyorum" çıkar ve doğru çözüm aktarma butonu değil, zaten var olan rapora bir filtre eklemektir.

Talep formunuzda şu alanlar olsun: kim istedi (kişi ve hesap), hangi işi yapmaya çalışıyor, bugün nasıl idare ediyor, ne sıklıkta karşılaşıyor, olmazsa ne kaybediyor, hangi sözleşme ya da yenileme buna bağlı. Çözüm önerisi ayrı bir alanda dursun, zorunlu olmasın. Teresa Torres'in fırsat-çözüm ağacı yaklaşımındaki ayrımın pratik karşılığı budur: aynı fırsata genelde birden fazla çözüm bağlanır, en ucuzunu seçebilmek için fırsatın yazılı olması gerekir.

Tek liste yerine kapasite kovaları

Hatalar, sözleşmeyle taahhüt edilmiş işler, müşteri talepleri ve stratejik bahisler aynı sıralı listede yarıştırıldığında kazanan hep aynıdır: acil olan. Stratejik iş hiçbir zaman "bu hafta acil" olmaz, bu yüzden hiçbir zaman sıranın başına gelmez.

Pratik çözüm, çeyrek başında kapasiteyi kovalara bölmek. Örneğin mühendislik kapasitesinin bir kısmı müşteri taleplerine, bir kısmı ürün stratejisine, bir kısmı teknik borç ve bakıma, kalanı planlanmamış işe ve hatalara ayrılır. Oranlar sizin işinize göre değişir, önemli olan oranın baştan konuşulup yazılması. Böylece her talep tüm ekibin zamanıyla değil, kendi kovasındaki diğer taleplerle yarışır. Satış ekibi de "bu özellik neden girmedi" sorusunun cevabını somut bir yerde görür.

RICE: tartışmayı sayıya çevirmek

Aynı kova içindeki talepleri sıralamak için en yaygın araç RICE. Sean McBride'ın Intercom blogunda 5 Ocak 2018'de yayımladığı tanım şöyle: Reach, belirli bir dönemde kaç kullanıcıyı etkiliyor (çeyrekte kaç hesap gibi, tahmin değil gerçek ürün verisi). Impact, etkilenen kişi başına etki: 3 (çok büyük), 2 (büyük), 1 (orta), 0,5 (düşük), 0,25 (çok düşük). Confidence, tahminlerinizin ne kadar desteklendiği: yüzde 100 (yüksek), yüzde 80 (orta), yüzde 50 (düşük); yüzde 50'nin altı McBride'ın deyimiyle tam bir kumardır. Effort ise ürün, tasarım ve geliştirmenin toplam kişi-ayı. Skor: Reach × Impact × Confidence ÷ Effort.

Somut örnek: çeyrekte 400 hesabı ilgilendiren, orta etkili (1), orta güvenli (0,8) ve 2 kişi-aylık bir iş 160 puan alır. Aynı çeyrekte 40 hesabı ilgilendiren, çok büyük etkili (3), yüksek güvenli (1,0) ve 1 kişi-aylık bir iş 120 puan alır. İki iş birbirine yakın, yani sıralamayı puan değil tartışma belirleyecek. RICE'ın asıl faydası da bu: "bence bu daha önemli" cümlesini "sence kaç hesabı etkiliyor" sorusuna çeviriyor.

Zayıf halka Effort tarafında. Kişi-ay tahmini yanlışsa skor da yanlıştır ve yanlışlık ondalıklı sayılarla sunulduğu için ikna edici görünür. McBride'ın kendi uyarısı da bu yönde: RICE katı bir kural değil, bağımlılıklar ve pazarda olmazsa olmaz sayılan işler düşük puanla da öne alınabilir. Tahmin tarafını sağlamlaştırmak isterseniz olasılıklı öngörü yazımızdaki yöntem burada da işe yarar.

Zaman baskısı varsa WSJF

RICE zamanı umursamaz. Oysa bazı işlerin değeri takvime bağlıdır: sezon açılışına yetişmeyen kampanya modülü, entegrasyon ortağının yayın tarihine yetişmeyen API, yasal yürürlük tarihine yetişmeyen fatura alanı. Burada SAFe'in WSJF yaklaşımı daha iyi çalışıyor: göreli gecikme maliyetini göreli iş büyüklüğüne bölüyorsunuz. Gecikme maliyeti üç bileşenden toplanıyor: kullanıcı ve iş değeri, zaman kritikliği, risk azaltma ya da fırsat açma.

Formülün bir yan etkisi var ve bilerek kullanılmalı: küçük işler bölen küçüldüğü için yukarı çıkar. Bu, büyük bir işi anlamlı parçalara bölmenin sıralamayı değiştirmesi demektir. Parçalama gerçekse bu doğru davranıştır, kâğıt üzerinde bölüp aynı anda yapıyorsanız kendinizi kandırırsınız.

Kano: her talep aynı türden değil

1984 tarihli çalışmasında Noriaki Kano, özellikleri memnuniyete etkilerine göre ayırdı. Kano modelinde olması gereken (must-be) özellikler yoksa müşteri ciddi şekilde rahatsız olur, varsa kimse memnun olmaz; tek boyutlu özelliklerde memnuniyet verdiğiniz kaliteyle doğru orantılı artar; çekici özellikler yokken kimse şikâyet etmez, varken beklenmedik bir memnuniyet yaratır.

Bunun önceliklendirmedeki karşılığı net. Olması gereken bir özelliği RICE ile puanlamayın, zaten yapmak zorundasınız; puanlama yalnızca kaybedeceğiniz anlaşmayı geciktirir. Çekici özellikler ise zamanla olması gerekene dönüşür. Kurumsal müşteriler için tek oturum açma (SSO) bunun tipik örneği: beş yıl önce ayrıcalıktı, bugün satın alma listesinde zorunlu satır.

Sabit tarih varsa MoSCoW

Tarihin sabit, kapsamın esnek olduğu projelerde RICE yerine MoSCoW daha pratiktir. Agile Business Consortium'un tanımına göre Must Have, olmazsa projenin iptal edilmesi gereken en küçük kullanışlı küme; Should Have, önemli ama çözümü yaşatan (gerekirse geçici çözümle); Could Have, ana payanda, yani tarih sıkışınca ilk düşen; Won't Have ise bu dönem için kapsam dışı olduğu yazılı olarak kabul edilen iş.

Asıl kıymetli kısım oranlar. Aynı kaynak Must Have işinin efor olarak tipik olarak yüzde 60'ı aşmamasını, Could Have havuzunun ise yüzde 20 civarında tutulmasını öneriyor; çünkü tarih baskısı geldiğinde payandanız o yüzde 20'dir. Sık yapılan hata, oranı efor yerine madde sayısı üzerinden uygulamak. Yirmi maddenin on ikisini Must işaretlemek, o on ikisi eforun yüzde 90'ını tutuyorsa hiçbir koruma sağlamaz. Şartname yazarken ve sabit fiyatlı sözleşmelerde bu ayrımı baştan kurmak, projenin sonundaki pazarlığı kısaltıyor.

Büyük müşterinin tek talebi

En zor karar burada veriliyor: cironuzun önemli bir kısmını tek başına taşıyan müşteri, başka kimsenin istemediği bir özellik istiyor. Reddetmek riskli, yapmak ürünü eğiyor.

Üç ayrı seçeneği birbirine karıştırmayın. Birincisi, talep gerçekten genelse ürüne girer ve herkese açılır. İkincisi, yalnızca o müşteriye özgüyse ücretli özel geliştirme olarak ayrı kalemle fiyatlanır ve bakım sorumluluğu destek sözleşmesinde yazılı hale gelir. Üçüncüsü, davranış farkı küçükse konfigürasyonla ya da özellik bayrağıyla tek kiracıya açılır. Kaçınmanız gereken dördüncü yol da var: kodun içine müşteri adıyla koşul yazmak. Çok kiracılı mimaride bu yöntemin faturası birkaç sürüm sonra, kimsenin dokunmaya cesaret edemediği bir dosya olarak geliyor.

Hayır demenin yazılı bir yolu olsun

Reddedilen taleplerin en kötü işlenme biçimi sessizliktir. Müşteri talebi iletir, cevap gelmez, üç ay sonra aynı talebi satış görüşmesinde tekrar açar ve bu kez şikâyet olarak açar.

Cevabın üç parçası olsun: kararın ne olduğu (şimdi değil), nedeni (hangi işin önüne geçemedi), ve kararı değiştirecek şey (kaç müşteri daha isterse, hangi veri gelirse yeniden bakılır). "Şimdi değil" cevabı, gerekçesi yazılıysa "hayır" cevabından çok daha iyi karşılanır. Talep kaydını müşterinin görebileceği bir yerde tutmak da tekrarlı soruları azaltır, ama bunu yapıyorsanız kaydı güncel tutmak zorundasınız; altı ay dokunulmamış bir talep listesi, listenin olmamasından daha kötü sinyal verir.

Yol haritası tarih listesi değil

Ürün yol haritasını çeyreklere bölünmüş tarih tablosu olarak yayımladığınız anda, tahmin olan her şey taahhüde dönüşür. ProdPad'in kurucusu Janna Bastow'un yaygınlaştırdığı Now / Next / Later biçimi bu yüzden işe yarıyor: ProdPad kendi yol haritasında Now'a çözümü belirlenmiş ve kaynak ayrılmış problemleri, Next'e hâlâ keşif ya da tasarım aşamasındaki problemleri, Later'a henüz şekillenmekte olan fikirleri koyuyor. Uzaklaştıkça belirsizlik artıyor ve bunu format zaten söylüyor.

Tarih vermek zorunda olduğunuz durumlar var: entegrasyon ortağı, fuar, yasal yürürlük. O zaman tek bir tarih değil, aralık verin ve hangi varsayımla verdiğinizi yazın.

Yayına aldıktan sonra ölçün

Önceliklendirmenin en çok atlanan adımı, kararın doğru çıkıp çıkmadığına bakmak. John Cutler'ın 2016'da ortaya attığı "özellik fabrikası" tanımının ilk maddesi de buydu: ekip ürettiğini ölçmüyorsa fabrikadadır.

Ucuz bir kural işi çözüyor: her özellik kaydına, geliştirme başlamadan önce başarı ölçütü ve gözden geçirme tarihi yazın. "Bu özelliği kullanan hesap oranı sekiz hafta sonunda yüzde 20'yi geçsin" gibi. Ölçebilmek için olay takibinin yerinde olması gerekiyor, bu da ürün analitiği tarafındaki hazırlığa bağlı. Trafiğiniz karşılaştırmalı test için yetmiyorsa A/B testi yazımızdaki alternatifler devreye girer. Gözden geçirmede benimsenme beklenenin çok altındaysa iki seçeneğiniz olur: nedenini araştırıp bir kez daha denemek ya da özelliği kaldırmak. Üçüncü seçenek, yani kimsenin kullanmadığı ekranı sonsuza kadar taşımak, her sürümde test ve bakım maliyeti olarak geri geliyor.

Bu çeyrekte yapabilecekleriniz

• Talep formunu değiştirin: çözüm alanını isteğe bağlı yapın, "bugün nasıl idare ediyorsunuz" ve "olmazsa ne kaybediyorsunuz" alanlarını zorunlu yapın.
• Kapasiteyi kovalara bölün ve oranları yazılı hale getirin; müşteri talebi, strateji, bakım ve planlanmamış iş aynı listede yarışmasın.
• Bir sonraki planlama toplantısında ilk on talebi RICE ile puanlayın, sıralamayı değil tartışmayı kayda geçirin.
• Reddedilen talepler için üç parçalı cevap şablonu yazın ve son altı ayda cevapsız kalmış talepleri bu şablonla kapatın.
• Önümüzdeki sürüme giren her özelliğe başarı ölçütü ve gözden geçirme tarihi ekleyin; takvime o tarih için toplantı koyun.