Prioritization Framework'leri: RICE, MoSCoW, Kano ve Cost of Delay

Sürüm notu: Bu yazıdaki TypeScript kodu Node.js 24.22 (type stripping) ile çalıştırılmış ve TypeScript 6.0.3 ile tip kontrolünden geçirilmiştir.

Önce Tahmin Et

Bookstore ekibinin önünde altı aday iş var ve önümüzdeki çeyrekte hepsini yapacak kapasite yok. Sepet terk çalışmasından çıkan iki fikir (guest checkout, ürün sayfasında kargo ücreti), kayıtlı müşteriler için kart saklama, wishlist paylaşımı, katalog aramasının hızlandırılması ve bir de teknik iş: ödeme sağlayıcısı eski SDK (Software Development Kit) sürümünü üç ay sonra kapatacağını duyurdu, ödeme entegrasyonunun yeni sürüme taşınması gerekiyor.

Ekip RICE (Reach, Impact, Confidence, Effort) ile puanlama yapmaya karar veriyor. Sence ödeme SDK'sının güncellenmesi bu listede kaçıncı çıkar? Bir de şunu düşün: RICE'ın formülünde "üç ay sonra ödeme alamayacağız" bilgisi nereye yazılır?

RICE: Reach, Impact, Confidence, Effort

RICE, Intercom'dan Sean McBride'ın 2018'de yazdığı bir yazıyla yaygınlaştı. Dört faktörden oluşur. Reach, bir dönemde kaç kişiye ya da olaya dokunduğudur; Intercom bunu "bir çeyrekte kaç müşteriyi etkileyecek" diye ölçer. Impact, her bir kişi üzerindeki etkidir ve sabit bir ölçekle verilir: 3 çok büyük, 2 yüksek, 1 orta, 0,5 düşük, 0,25 minimal. Confidence, bu tahminlere ne kadar güvendiğindir: %100 yüksek, %80 orta, %50 düşük; %50'nin altı Intercom'un deyişiyle "tam bir moonshot"tur. Effort ise ürün, tasarım ve mühendisliğin toplam emeğidir, kişi-ay cinsinden.

Skor, Reach × Impact × Confidence ÷ Effort'tur: harcanan zaman başına toplam etki. Yazının kendisi de skorun katı bir kural olmadığını, bağımlılıklar ya da "masada olması gereken" feature'lar yüzünden düşük skorlu işlerin önce yapılabileceğini söyler. Bu uyarıyı aklında tut; birazdan neden önemli olduğunu göreceğiz.

Kod: Aynı Backlog, İki Sıralama

Altı işi TypeScript ile modelleyelim. RICE'ın ölçeklerini tip olarak yazmak, "Impact 1,7" gibi uydurma ara değerleri derleyici seviyesinde engelliyor. Aynı veriye Cost of Delay ve süre bilgisini de ekliyoruz, çünkü ikinci yöntem onları kullanacak:

// RICE (Intercom) ölçekleri: impact 0.25-3, confidence %50/%80/%100
type Impact = 0.25 | 0.5 | 1 | 2 | 3;
type Confidence = 0.5 | 0.8 | 1;

interface BacklogItem {
  id: string;
  title: string;
  reach: number;               // çeyrekte etkilenen müşteri
  impact: Impact;
  confidence: Confidence;
  effortPersonMonths: number;  // ürün + tasarım + geliştirme toplam eforu
  costOfDelayPerWeek: number;  // bin TL / hafta, gecikmenin haftalık bedeli
  durationWeeks: number;       // takvim süresi, kişi-ay değil
}

const backlog: BacklogItem[] = [
  { id: "B1", title: "Guest checkout", reach: 12000, impact: 2, confidence: 0.8,
    effortPersonMonths: 3, costOfDelayPerWeek: 60, durationWeeks: 8 },
  { id: "B2", title: "Shipping cost on product page", reach: 30000, impact: 1, confidence: 0.8,
    effortPersonMonths: 0.5, costOfDelayPerWeek: 25, durationWeeks: 2 },
  { id: "B3", title: "Saved cards", reach: 8000, impact: 2, confidence: 0.5,
    effortPersonMonths: 3.5, costOfDelayPerWeek: 30, durationWeeks: 10 },
  { id: "B4", title: "Wishlist sharing", reach: 3000, impact: 0.5, confidence: 0.8,
    effortPersonMonths: 1, costOfDelayPerWeek: 3, durationWeeks: 3 },
  { id: "B5", title: "Payment SDK upgrade before v2 shutdown", reach: 0, impact: 0.25, confidence: 1,
    effortPersonMonths: 1.5, costOfDelayPerWeek: 120, durationWeeks: 4 },
  { id: "B6", title: "Faster catalog search", reach: 25000, impact: 1, confidence: 0.5,
    effortPersonMonths: 3, costOfDelayPerWeek: 20, durationWeeks: 6 },
];

const rice = (i: BacklogItem): number =>
  (i.reach * i.impact * i.confidence) / i.effortPersonMonths;

// CD3: Cost of Delay Divided by Duration
const cd3 = (i: BacklogItem): number => i.costOfDelayPerWeek / i.durationWeeks;

function rank(items: BacklogItem[], score: (i: BacklogItem) => number): Map<string, number> {
  const sorted = [...items].sort((a, b) => score(b) - score(a));
  return new Map(sorted.map((item, index) => [item.id, index + 1]));
}

function report(items: BacklogItem[]): void {
  const byRice = rank(items, rice);
  const byCd3 = rank(items, cd3);
  console.log("id  title                                   RICE   rank |   CD3  rank");
  for (const i of [...items].sort((a, b) => byRice.get(a.id)! - byRice.get(b.id)!)) {
    console.log(
      `${i.id}  ${i.title.padEnd(38)} ${rice(i).toFixed(0).padStart(6)}  ${byRice.get(i.id)}    | ` +
      `${cd3(i).toFixed(1).padStart(5)}  ${byCd3.get(i.id)}`);
  }
}

report(backlog);

// Sahte hassasiyet: tek bir tahmini değiştirince sıra ne kadar oynuyor?
console.log("\nB3 confidence 0.5 -> 1 (someone 'feels sure'):");
report(backlog.map(i => (i.id === "B3" ? { ...i, confidence: 1 as Confidence } : i)));

Node.js 24, yalnız silinebilir TypeScript syntax'ı (tip, interface, type annotation) içeren dosyaları doğrudan çalıştırabiliyor; enum gibi çalışma zamanında kod üreten yapılar kullanmadığımız için ayrı bir derleme adımına gerek yok. Tip kontrolünü yine de tsc ile yapıyoruz; tsconfig.json'daki erasableSyntaxOnly seçeneği, Node'un çalıştıramayacağı bir syntax yazarsak derleyicinin bizi uyarmasını sağlıyor:

{
  "compilerOptions": {
    "target": "es2022",
    "module": "nodenext",
    "strict": true,
    "noEmit": true,
    "erasableSyntaxOnly": true,
    "lib": ["es2022", "dom"]
  },
  "files": ["prioritize.ts"]
}

Gerçek çıktı:

$ npx tsc -p .
$ node prioritize.ts
id  title                                   RICE   rank |   CD3  rank
B2  Shipping cost on product page           48000  1    |  12.5  2
B1  Guest checkout                           6400  2    |   7.5  3
B6  Faster catalog search                    4167  3    |   3.3  4
B3  Saved cards                              2286  4    |   3.0  5
B4  Wishlist sharing                         1200  5    |   1.0  6
B5  Payment SDK upgrade before v2 shutdown      0  6    |  30.0  1

B3 confidence 0.5 -> 1 (someone 'feels sure'):
id  title                                   RICE   rank |   CD3  rank
B2  Shipping cost on product page           48000  1    |  12.5  2
B1  Guest checkout                           6400  2    |   7.5  3
B3  Saved cards                              4571  3    |   3.0  5
B6  Faster catalog search                    4167  4    |   3.3  4
B4  Wishlist sharing                         1200  5    |   1.0  6
B5  Payment SDK upgrade before v2 shutdown      0  6    |  30.0  1

Çıktıyı Okumak

İki yöntem en üstte neredeyse anlaşıyor: ürün sayfasında kargo ücreti (B2) RICE'ta birinci, CD3'te (Cost of Delay Divided by Duration) ikinci. Çok kişiye dokunan, ucuz ve sepet terk problemine doğrudan bağlı bir iş; hangi yöntemi kullansan öne çıkar. Bu, framework'lerin en faydalı olduğu durum: bariz olanı hızlıca onaylamak.

Asıl fark en altta. Ödeme SDK güncellemesi (B5) RICE'ta 0 puanla sonuncu, CD3'te 30 puanla birinci. RICE açısından bu iş hiçbir müşteriye yeni bir şey sunmuyor; reach'i sıfır. Ama üç ay sonra eski SDK kapandığında Bookstore hiç ödeme alamayacak. RICE'ın dört faktöründe "zaman" diye bir şey yok; bir işin bugün mü yoksa altı ay sonra mı yapılmasının fark etmediğini varsayar. Baştaki sorunun cevabı bu: RICE'ın formülünde deadline'ın yazılacağı bir yer yok.

Programın ikinci kısmı sahte hassasiyeti gösteriyor. Kart saklama (B3) için confidence %50 iken RICE skoru 2.286 ve sıralamada dördüncü. Toplantıda biri "bence bundan eminiz" deyip confidence'ı %100 yaptığında skor 4.571'e çıkıyor ve iş katalog aramasının önüne geçiyor. Hiçbir yeni bilgi gelmedi; yalnız bir kişinin hissi değişti. Confidence'ın tek bir sayıyla bir işi listenin ortasından yukarı taşıyabilmesi, bu faktörün neden kanıtla verilmesi gerektiğini gösteriyor: görüşme, veri ya da test sonucu yoksa %50'nin üstüne çıkma.

Cost of Delay ve CD3

Cost of Delay (CoD) bir sorudan doğar: bu işi bir hafta geç yaparsak ne kaybederiz? Donald Reinertsen "The Principles of Product Development Flow" (2009) kitabında bu soruyu ürün geliştirmede ekonomik kararların merkezine koyar; Black Swan Farming'deki Joshua Arnold ve ekibi de kavramı pratiğe döken yazılarıyla bilinir. CoD, value ile aciliyeti tek bir sayıda birleştirir: haftada 60 bin TL kaybettiren bir iş, haftada 3 bin TL kaybettiren bir işten önce gelmelidir.

CD3, CoD'yi işin süresine böler. Mantığı şudur: iki işin CoD'si aynıysa, kısa olanı önce bitirmek toplam kaybı azaltır, çünkü uzun işi beklerken kısa işin kaybı da birikir. Bookstore'da ödeme SDK güncellemesi haftada 120 bin TL'lik bir risk taşıyor (kapanış tarihinden sonra kaybedilecek siparişler) ve dört haftada bitiyor; CD3'ü 30. Guest checkout'un CoD'si de yüksek (haftada 60 bin TL) ama sekiz hafta sürüyor; CD3'ü 7,5.

Bu sayıların nereden geldiği, CD3'ün hem gücü hem zayıflığı. Gücü, tartışmayı "hangisi daha önemli?" sorusundan "bunu bir hafta geciktirmenin bedeli ne?" sorusuna taşıması; bu soru, finans ve satış ekipleriyle aynı dili konuşmayı sağlar. Zayıflığı, CoD tahmininin de bir tahmin olması. Ama en azından tahminin varsayımları ("eski SDK kapanırsa günde şu kadar sipariş kaybederiz") açıkça yazılır ve tartışılabilir. Arnold'un yazıları ayrıca CoD'nin zamanla nasıl değiştiğini anlatan aciliyet profillerine dikkat çeker: SDK güncellemesinin CoD'si kapanış tarihine kadar düşük, o tarihten sonra çok yüksektir.

SAFe'in (Scaled Agile Framework) WSJF'si (Weighted Shortest Job First) aynı fikrin bir varyantıdır: CoD'yi kullanıcı ve iş değeri, zaman kritikliği ve risk azaltma/fırsat etkinleştirme bileşenlerinin göreli puanlarından hesaplar ve iş büyüklüğüne böler. Para birimi yerine göreli puan kullanması uygulamayı kolaylaştırır, ama "bir hafta gecikmenin bedeli ne?" sorusunun netliğini de biraz kaybettirir.

MoSCoW ve Kano

Her önceliklendirme bir sayı üretmek zorunda değil. MoSCoW, Dai Clegg'in 1994'te Oracle'da geliştirdiği ve sonra DSDM (Dynamic Systems Development Method) ile yaygınlaşan bir kategori yöntemidir: Must have, Should have, Could have, Won't have (this time). Sabit tarihli bir teslimde kapsamı konuşmak için iyidir: 27 Kasım kampanyası için "kupon girişi Must, kampanya banner'ının A/B testi Could." Zayıf yanı, her şeyin "Must"a kaymasıdır; Must kategorisine bir kapasite sınırı koymazsan, kategoriler hiçbir şeyi ayırmaz.

Kano modeli ise Noriaki Kano'nun 1984'te ortaya koyduğu, müşteri memnuniyetini feature'ın varlığına göre sınıflayan bir modeldir. Must-be feature'lar yokken müşteriyi rahatsız eder, varken fark edilmez: siparişin onay e-postası. One-dimensional (performance) feature'lar ne kadar iyiyse memnuniyet o kadar artar: teslimat hızı. Attractive feature'lar beklenmez, varsa memnun eder: kitabın içinden bir bölümü önizleyebilmek. Indifferent feature'lar kimsenin umurunda değildir, reverse feature'lar ise bazı kullanıcıları rahatsız eder. Kano, kategorileri her feature için "bu özellik olsaydı ne hissederdiniz? olmasaydı?" diye eşleştirilmiş sorulardan oluşan bir anketle belirler.

Kano'nun geliştiriciye en faydalı uyarısı, kategorilerin zamanla kaymasıdır: bugünün attractive feature'ı, rakipler de yaptıkça yarının must-be'si olur. Kargo ücretini ürün sayfasında göstermek, birçok büyük e-ticaret sitesinin yaptığı bir şey olduğu için Bookstore müşterileri açısından artık bir must-be'ye yakın; yokluğu fark ediliyor.

Teknik Borç ve Platform İşi Nasıl Puanlanır?

B5'in RICE'ta sıfır alması bir istisna değil, bir kalıp. Teknik borç, altyapı ve platform işleri doğrudan bir müşteriye dokunmadığı için kullanıcı odaklı framework'lerde hep sona düşer, ta ki bir gün bir incident olana kadar. Üç yaklaşım işe yarar.

Birincisi bu işleri Cost of Delay ile ifade etmek. "Ödeme SDK'sı kapanırsa haftada 120 bin TL" gibi bir risk, RICE'ın göremediği şeyi görünür kılar. Aynı şey daha sessiz borçlar için de yapılabilir: "Sipariş servisindeki bu modülün değiştirilmesi her feature'a ortalama üç gün ekliyor" cümlesi, gecikmenin bedelini geliştirici zamanıyla söyler.

İkincisi kapasite ayırmak. Birçok ekip kapasitesinin sabit bir yüzdesini (yaygın bir başlangıç %15–20) teknik işlere ayırır ve o kapasitenin içindeki önceliği mühendislere bırakır. Bu, her teknik işi tek tek ürün işiyle yarıştırma ihtiyacını ortadan kaldırır.

Üçüncüsü teknik işi bir outcome'a bağlamak. "Katalog aramasını Elasticsearch'e taşımak" bir output'tur; "arama sonuç sayfasının p95 (95. percentile) yanıt süresini 1,8 saniyeden 400 milisaniyeye indirmek" bir outcome'dur ve ürün metric'leriyle ilişkisi kurulabilir.

HiPPO ve Framework'ün Rolü

HiPPO (Highest Paid Person's Opinion), yani odadaki en yüksek maaşlı kişinin fikri, önceliklendirmenin en güçlü gayriresmî yöntemidir. Önceki yazıdaki genel müdürün one-click checkout talebi bir HiPPO örneğidir. Framework'lerin asıl değeri burada ortaya çıkar: fikri reddetmek için değil, diğer fikirlerle aynı kurallarla değerlendirmek için. One-click checkout RICE'a girdiğinde reach'i yalnız kayıtlı ve kartı saklı müşterilerdir ve bu bilgi, tartışmayı bir hiyerarşi meselesi olmaktan çıkarır.

Ama framework'ler karar vermez, kararı destekler. Bir RICE tablosunu toplantıya "sıralama bu, tartışma bitti" diye getirmek, HiPPO'yu bir tabloyla değiştirmekten ibarettir. Tablo, varsayımları görünür kılmak ve tartışmayı en çok belirsizlik olan sayılara yönlendirmek için vardır.

Üretimde Dikkat

Skorları tek seferlik değil, yaşayan sayılar olarak tut. Ürün sayfasında kargo ücreti fikrinin reach'i, 07. yazıda event'lerle ölçeceğimiz gerçek ziyaretçi sayısından gelmeli; tahmin yerine ölçüm geldiğinde skor güncellenir. Backlog aracında RICE alanları açıp bir kere doldurulan, sonra hiç dokunulmayan skorlar, birkaç ay sonra yanlış bilgi taşır.

Effort'u ekibe sor, tek kişiye değil. RICE'ın paydası kişi-ay cinsinden toplam emektir ve bu tahminin en iyi kaynağı işi yapacak ekiptir. Effort ile CD3'teki süre aynı şey değildir: üç kişinin bir ayda yaptığı iş üç kişi-ay efor ama bir aylık süredir.

Sıralamanın hassasiyetini kontrol et. Bizim kodumuzda olduğu gibi, belirsiz bir parametreyi makul aralıkta değiştirip sıralamanın değişip değişmediğine bakmak, hangi kararın sağlam, hangisinin kırılgan olduğunu söyler. Kırılgan bir karar için daha fazla kanıt topla.

Sık Düşülen Tuzaklar

İlk tuzak sahte hassasiyet: confidence'ı kanıtsız %80 yazmak, impact'i 1,5 gibi ölçekte olmayan bir değerle vermek, skorları ondalık basamaklarıyla tartışmak. RICE skoru bir tahminin tahminidir; 4.167 ile 4.571 arasındaki fark, girdilerin belirsizliği yanında anlamsızdır.

İkinci tuzak framework'ü tartışmayı bitirmek için kullanmak. "RICE böyle diyor" cümlesi, sayıların arkasındaki varsayımları tartışmayı engellerse framework amacının tersine çalışır.

Üçüncüsü tek framework'e her işi sokmak. Kullanıcıya dönük fikirler, sabit tarihli zorunluluklar ve teknik borç aynı formülle karşılaştırılamaz. Bookstore örneğinde RICE ile CD3'ü yan yana koymak, tek başına hiçbirinin göremediği B5'i görünür kıldı.

Dördüncüsü skorlamayı discovery'nin yerine koymak. Bir fikrin impact'ini bilmiyorsan, onu puanlamak yerine 03. yazıdaki gibi ucuz bir assumption testiyle öğren. Prioritization, elindeki bilgiyle en iyi kararı vermektir; eksik bilgiyi sayıyla kapatmak değildir.

Küçük Bir Deneme

★☆☆ Programdaki B6'nın (katalog araması) confidence'ını 0.5'ten 0.8'e çıkar. RICE sıralaması nasıl değişiyor? Bu değişikliği haklı çıkaracak kanıt ne olurdu?

★★☆ Programa üçüncü bir sıralama ekle: WSJF. Her iş için 1–10 arası user-business value, time criticality ve risk reduction puanı ver, toplamı iş büyüklüğüne böl. Sıralama CD3'e mi yoksa RICE'a mı daha çok benziyor?

★★★ Kendi ekibinin backlog'undan altı iş seç, en az biri teknik borç olsun. Hem RICE hem CD3 ile puanla ve iki sıralamanın en çok ayrıştığı işi bul. Ayrışmanın sebebini bir paragrafla yaz ve ekibinle tartış.

Hangi işin önce geleceğine karar verdik. Bir sonraki yazıda bu kararları paydaşlara nasıl anlatacağımızı konuşacağız: tarihli feature roadmap'lerinin neden sürekli kaydığını, Now-Next-Later ve outcome roadmap'lerini ve Shape Up'ın appetite fikrini Bookstore'un 2027 ilk yarı roadmap'i üzerinden göreceğiz.