30 sn özet

Önceliklendirme, sınırlı kapasiteyi hangi müşteri problemlerine ve iş sonuçlarına ayıracağımıza karar vermektir. RICE, aday işleri erişim, etki, güven ve efor üzerinden karşılaştıran bir puanlama yöntemidir. Formülü, erişim ile etki ve güvenin çarpımının efora bölünmesidir. Ortak ölçüm kuralları kullanıldığında fikirlerin arkasındaki varsayımları görünür kılar. Ancak puan, stratejik kararın tamamını temsil etmez. Bağımlılıklar, ciddi riskler ve bağlayıcı yükümlülükler ayrıca değerlendirilir. İyi önceliklendirme, ilk sıradaki işi seçmenin yanında, diğer işleri neden beklettiğimizi de açıklayabilmektir.

Neden önemli?

Bir ürün ekibine aynı hafta satıştan müşteri talebi, destekten hata bildirimi ve yönetimden yeni büyüme fikri gelebilir. Hepsi kendi bağlamında önemli görünür. Kapasite sınırlıysa her talebe söz vermek, işleri yarım bırakmaya ve teslimat beklentilerini bozacak bir yük oluşturmaya yol açar. Bu yüzden önceliklendirme, talep listesini düzenlemenin ötesinde kaynak tahsisidir.

Junior bir BA için değerli katkı, talebin arkasındaki problemi ve kanıtı açıklığa kavuşturmaktır. “Toplu düzenleme yapalım” ifadesi tek başına yeterli değildir. Hangi kullanıcıların hangi işi yapamadığı, mevcut çözümün ne kadar zaman aldığı ve hangi sonucun iyileştirilmek istendiği bilinmelidir. Çözüm fikri erken kesinleşirse daha küçük ve etkili seçenekler gözden kaçabilir.

PM, bu problemleri ürünün yönüyle ilişkilendirir; PO ise seçilen işlerin uygulanabilir kapsamını ve sırasını netleştirir. Yönetim açısından kararın değeri, herkesin istediği işi aynı anda başlatmak yerine hangi fırsatın önce ele alınacağını savunabilmektir. Ortak bir puanlama dili bu konuşmaya yardımcı olur. Fakat yanlış hedefe hizmet eden işler tutarlı biçimde puanlansa bile sonuç iyi olmayabilir.

Terim nedir?

RICE dört değişkenin İngilizce baş harflerinden oluşur: Reach, Impact, Confidence ve Effort. Temel hesap şöyledir:

RICE puanı = Reach x Impact x Confidence / Effort

Reach, belirlenen dönemde etkilenecek kullanıcı veya müşteri sayısıdır. Impact, etkilenen her bir kişi ya da hesap için hedeflenen sonucun ne kadar değişeceğine ilişkin tahmindir. Confidence, tahminleri destekleyen kanıta duyulan güveni temsil eder. Effort ise işi tamamlamak için gereken toplam çalışma miktarıdır. Efor arttığında, diğer değerler aynı kalıyorsa puan düşer.

Karşılaştırılabilirlik için aynı dönem, birim ve hedef kullanılmalıdır. Bir işte aylık işlem sayısını, diğerinde çeyreklik müşteri sayısını kullanmak tabloyu anlamsızlaştırır. Benzer şekilde ekip, bir projede etkiyi gelirle, diğerinde kullanıcı memnuniyetiyle puanlıyorsa bu sonuçların nasıl ortak ölçekte değerlendirildiğini açıklamalıdır. Aynı hedefe hizmet eden adayları birlikte ele almak, yorum yükünü azaltır.

Efor için kişi-ay kullanılabilir; ürün, tasarım ve mühendislik çalışması birlikte düşünülür. İki kişinin bir ay çalışması yaklaşık iki kişi-aydır. Bu, işin takvimde iki ay süreceği anlamına gelmez. Beklemeler ve bağımlılıklar teslim tarihini ayrıca etkiler.

Intercom’un anlattığı etki ölçeği 3, 2, 1, 0,5 ve 0,25; güven seviyeleri yüzde 100, 80 ve 50’dir. Bunlar standartlaştırmaya yardımcı olan puanlama tercihleridir. Yüzde 80 güven, istatistiksel bir deneyden hesaplanan başarı olasılığı değildir. Formülde yüzde 80, 0,8 olarak kullanılır.

Puanın ekonomik veya bilimsel kesinlik taşıdığı düşünülmemelidir. Etki katsayısı, müşteriye göre değişen bir sonucun kaba temsilidir. Bir işin 240, diğerinin 220 puan alması, ilkinin kesin olarak daha değerli olduğunu göstermez. Tahmin aralıkları örtüşüyorsa ek araştırma veya daha küçük bir uygulama seçeneği kararı iyileştirebilir.

Gerçek vaka

Intercom’da Sean McBride’ın yayımladığı RICE rehberi, ekibin farklı proje fikirlerini tutarlı biçimde karşılaştırmak için kendi puanlama sistemini geliştirdiğini anlatıyor. Deneme ve iyileştirmeler sonunda dört değişken ve bunları birleştiren yöntem üzerinde karar verilmiş.

McBride, puanların kesin bir uygulama sırası olmadığını da açıklıyor. Bir iş başka bir projenin ön koşulu olabilir; bir özellik belirli müşterilere satış yapabilmek için gerekli görülebilir. Böyle durumlarda düşük puanlı iş önce yapılabilir ve tercih açıkça gerekçelendirilebilir.

Bu, yöntem geliştirme ve uygulama yaklaşımına ilişkin gerçek bir şirket örneğidir. Yazı, RICE sayesinde elde edilmiş belirli bir gelir veya teslimat artışı raporlamıyor. Dolayısıyla vakayı sayısal başarı iddiasıyla sunamayız. Yönetim açısından çıkarılabilecek ders, karşılaştırma kurallarını oluştururken istisnaların gerekçesini de görünür tutmaktır.

Kaynak: Sean McBride, RICE: Simple prioritization for product managers, Intercom, 5 Ocak 2018.

Varsayımsal örnek

Bir B2B operasyon ürününde hedefin, müşterilerin sipariş düzenleme işini daha az manuel çabayla tamamlaması olduğunu düşünelim. Tüm rakamlar örnek amacıyla oluşturulmuştur. Ekip, aynı çeyrekte etkilenecek müşteri hesabını erişim birimi olarak kullanıyor.

Toplu düzenleme için erişim 400 hesap, etki 2, güven 0,8 ve efor 4 kişi-ay tahmin ediliyor. RICE puanı 400 x 2 x 0,8 / 4 = 160 oluyor. Alternatif olarak önerilen hazır şablonlar için erişim 250 hesap, etki 1, güven 0,8 ve efor 1 kişi-ay. Bu işin puanı 200 oluyor. İlk tablo, daha küçük şablon çözümünü önce değerlendirmeyi destekliyor.

Ancak toplu düzenleme işinin eforu prototip incelemesinden sonra 2 kişi-aya düşerse puanı 320’ye çıkar. Sıralama değişir. Bu örnek, sonucun tahmine ne kadar duyarlı olduğunu gösterir. Ekip bütün puanları tartışmak yerine, kararı değiştiren efor belirsizliğini araştırmaya odaklanabilir.

Aynı listede veri kaybına yol açan bir hata varsa bu işi düşük erişim nedeniyle bekletmek doğru olmayabilir. Riskin şiddeti ve gerçekleşme olasılığı ayrı değerlendirilir; düzeltme için kapasite ayrılır. Böylece RICE, benzer iyileştirme seçeneklerini karşılaştırırken kritik risk kararını da görünmez hâle getirmez. Seçilen geliştirme tamamlandığında manuel işlem süresi ve hatalar izlenerek başlangıçtaki etki varsayımı sınanır.

Yaygın 3 hata

  1. İstenen sıralamayı elde etmek için puanları ayarlamak

Bir fikrin savunucusu erişimi yükseltip eforu küçültebilir. Formül bu yanlılığı ortadan kaldırmaz; sadece sayıya dönüştürür. Her tahmine veri kaynağı eklemek ve ekiplerin birbirinin varsayımlarını incelemesini sağlamak gerekir. Tahmin değiştiğinde eski değer ve değişiklik nedeni korunmalıdır.

  1. Erişimi toplam kullanıcı sayısıyla eşitlemek

Özelliğin herkese açık olması, herkesin ondan etkilenmesi anlamına gelmez. İlgili iş akışına giren, ihtiyaç taşıyan ve çözümü kullanabilecek grup araştırılmalıdır. Aynı müşteri birden fazla projede sayılıyorsa projelerin toplam faydasını basitçe toplamak da yanıltıcı olabilir.

  1. Puanı kapasite ve bağımlılıklardan ayrı okumak

En yüksek puanlı iş, o dönemde mevcut olmayan bir uzmanlığı gerektirebilir. Önce yapılması gereken altyapı çalışması veya başka ekibin teslimatı bulunabilir. Seçim yapılırken uygulanabilir sıra ve toplam kapasite kontrol edilmelidir. Beklenen etkiyle gerçekleşen etki arasındaki fark da sonraki tahminleri beslemelidir.

Mini uygulama/şablon

Karar hedefi
Bu dönemde hangi müşteri veya iş sonucunu iyileştiriyoruz?
Problem
Kim, hangi durumda, hangi güçlükle karşılaşıyor?
Aday çözüm
Problemi ele alacak en küçük anlamlı seçenek nedir?
Reach
Aynı dönemde kaç benzersiz birim etkilenecek?
Impact
Hedef sonuç üzerindeki kişi veya hesap başına etki tahmini.
Confidence
Tahminleri destekleyen veri, görüşme ve teknik inceleme.
Effort
Gerekli rollerin toplam çalışma miktarı ve belirsizlik aralığı.
RICE puanı
Ortak kurallarla hesaplanan karşılaştırma değeri.
Bağımlılıklar
İşin başlaması veya tamamlanması için gereken koşullar.
Zorunluluklar
Puan sırasından ayrı değerlendirilmesi gereken risk veya taahhüt.
Karar kaydı
Seçim, bekletilen seçenekler ve gerekçeler.
Doğrulama
Teslimat sonrasında ölçülecek sonuç ve gözden geçirme zamanı.

Üç adayla başlayın. Puanları hesaplamadan önce ölçüm kurallarında anlaşın. Sıralamayı en çok değiştiren varsayımı belirleyip kısa bir araştırmayla sınayın. Son kararı, puanla birlikte gerekçesi ve kapasite koşullarıyla kaydedin.

Formül için ek kaynak: Atlassian, RICE template.

İlgili terimler

Product Strategy, Product Roadmap, Product Backlog, Opportunity Cost, Impact Mapping, WSJF, MoSCoW, Cost of Delay, Dependency Management, Product Discovery