Continuous Improvement Protocol: ICE/RICE Metodolojisi
ICE ve RICE önceliklendirme skorlaması: ikisinin farkı, skorların kalibrasyonu, Python ile backlog sıralama ve skorlamanın sizi yanılttığı yerler.
Ekiplerde en sık görülen sorun fikir kıtlığı değil, fikir bolluğu. Herkesin elinde bir iyileştirme önerisi var: şu rapor otomatikleşsin, şu kontrol adımı scripte dönsün, şu entegrasyon kurulsun. Asıl zorluk hangisinin önce yapılacağına karar vermek. Bu yazıda kendi projelerimde kullandığım ICE RICE önceliklendirme yaklaşımını anlatacağım: iki skorlama modelinin farkı, skorların nasıl kalibre edileceği ve bence en kritik kısım olan skorlamanın sizi nerede yanıltacağı.
Baştan söyleyeyim: ICE ve RICE sihirli formüller değil. Kötü tahminleri çarpıp bölmek onları iyi tahmine dönüştürmez. Ama doğru kullanıldığında iki şey kazandırırlar. Birincisi, önceliklendirme tartışmasını "kim daha yüksek sesle konuşuyor" düzleminden "hangi varsayımda ayrışıyoruz" düzlemine taşırlar. İkincisi, kararın gerekçesini kayıt altına alırlar; altı ay sonra "bunu neden öne almıştık" sorusunun cevabı bir tabloda durur.
Neden sezgi yetmiyor?
Sürekli iyileştirme kültürünün paradoksu şu: kültür ne kadar sağlıklıysa öneri o kadar çok gelir ve önceliklendirme o kadar zorlaşır. Skorlama olmayan ortamlarda sıralamayı üç şey belirliyor: en son yaşanan kriz, en ısrarcı kişi ve yöneticinin o haftaki gündemi. Üçü de sistematik olarak yanlış yerlere kaynak akıtır.
Benim gözlemim, listeyi puanlamanın asıl değerinin sıralamanın kendisinde değil, puanlama sırasında çıkan konuşmada olduğu. Birisi etkiye 9 verirken diğeri 3 veriyorsa, ortada henüz konuşulmamış bir varsayım farkı var demektir. Skor tablosu o farkı görünür kılar; sayı sadece bahane.
ICE: hızlı ve kaba tarama
ICE üç bileşenin çarpımı: Impact (etki), Confidence (güven), Ease (kolaylık). Her birine 1-10 arası puan verirsiniz, çarpım sıralamayı belirler. Beş dakikada elli maddelik bir listeyi kabaca sıralayabilirsiniz; gücü de zayıflığı da bu hızda.
- Impact: Bu iş yapılırsa hedeflediğimiz metriğe ne kadar katkı sağlar?
- Confidence: Etki ve kolaylık tahminlerimize ne kadar güveniyoruz? Elimizde veri mi var, his mi?
- Ease: Ne kadar az emekle biter? 10 puan "bir öğleden sonra", 1 puan "çeyrek dönem" demek.
ICE'ı iç süreç iyileştirmelerinde tercih ediyorum; küçük ekip, kısa liste, hızlı karar. Örneğin bir üretim firmasında Excel tabanlı kalite kontrolün otomasyonu tarzı işlerin sıralandığı backlog'larda ICE fazlasıyla yeterli.
RICE ve ICE'ın gerçek farkı
RICE dört bileşenli: Reach (erişim), Impact, Confidence, Effort. Formül de farklı: erişim, etki ve güven çarpılır, sonuç efora bölünür. İki yapısal fark var ve ikisi de önemli.
Birincisi, Reach gerçek bir sayıdır: "ayda kaç kişi ya da kaç işlem bu değişiklikten etkilenecek?" Bu, ICE'ın en büyük açığını kapatır. ICE'ta üç kişiyi ilgilendiren bir iyileştirme ile tüm operasyonu ilgilendiren bir iyileştirme aynı etki puanını alabilir. RICE sizi saymaya zorlar ve saymak, tahmini tartışılabilir hale getirir.
İkincisi, Effort çarpan değil bölendir. ICE'ta kolaylık diğer puanlarla aynı ağırlıkta çarpılırken RICE'ta maliyet paydaya iner: iki kat pahalı iş, skoru yarıya düşürür. Bu, "verim" kavramını formüle doğrudan gömer.
Pratik kuralım şu: liste kısa ve işler küçükse ICE, kaynak kısıtı ciddiyse ve işlerin boyutları çok farklıysa RICE. İkisini aynı listede karıştırmayın; skorlar karşılaştırılamaz.
Python ile backlog sıralamak
Skorlamayı Excel'de tutan ekipler gördüm, olur; ama ben küçük bir Python modeli kurmayı tercih ediyorum çünkü aynı listeyi iki yöntemle sıralayıp farkı görmek tek satır oluyor:
from dataclasses import dataclass
@dataclass
class Fikir:
ad: str
etki: float # 1-10: yapilirsa ne kadar fark yaratir?
guven: float # 1-10: tahminlere ne kadar guveniyoruz?
kolaylik: float # 1-10: 10 = cok kolay
erisim: int = 0 # RICE: ayda etkilenen kisi/islem sayisi
efor: float = 1.0 # RICE: kisi-hafta cinsinden maliyet
@property
def ice(self):
return self.etki * self.guven * self.kolaylik
@property
def rice(self):
# RICE'ta guven 0-1 araligina cekilir, efor paydaya iner
return (self.erisim * self.etki * (self.guven / 10)) / self.efor
def backlog_sirala(fikirler, yontem="ice"):
return sorted(fikirler, key=lambda f: getattr(f, yontem), reverse=True)
backlog = [
Fikir("Fatura kontrol otomasyonu", etki=7, guven=8, kolaylik=6,
erisim=900, efor=2),
Fikir("Depo yerlesim optimizasyonu", etki=9, guven=4, kolaylik=2,
erisim=300, efor=8),
Fikir("Haftalik rapor e-postasi", etki=4, guven=9, kolaylik=10,
erisim=15, efor=0.5),
]
for f in backlog_sirala(backlog, "rice"):
print(f"{f.ad:32} RICE: {f.rice:7.1f} ICE: {f.ice:5.0f}")
Aynı üç fikri iki yöntemle sıralayınca tablo tersine dönüyor. Haftalık rapor e-postası ICE'ta listenin tepesine çıkıyor; çünkü çok kolay ve tahmini kesin bir iş, ICE bunu ödüllendiriyor. RICE'ta ise aynı iş en sona düşüyor; çünkü ayda yalnızca on beş kişiye dokunuyor ve erişim çarpana girince kolaylık tek başına kurtarmıyor. Fatura kontrol otomasyonu ICE'ta ikinci, RICE'ta açık ara birinci; depo yerleşimi ise erişimi yüksek olduğu için RICE'ta haftalık raporun önüne geçiyor. Hangi sıralamanın "doğru" olduğu sorusunun cevabı formülde değil, sizin bağlamınızda: kısıtınız ekip zamanıysa RICE, hızla görünür kazanım istiyorsanız ICE konuşuyor.
Skorları kalibre etmek
Skorlamanın en çok ihmal edilen kısmı kalibrasyon. Üç alışkanlık öneriyorum. Birincisi, her ölçek için çapa örnekler belirleyin: "etki 8 dediğimizde kastımız geçen yılki X projesi" gibi. Çapasız ölçekte herkesin 7'si farklıdır. İkincisi, puanlamayı birlikte ve sesli yapın; ayrışan puanlar tartışmanın başlangıç noktasıdır. Üçüncüsü, güven puanını disiplinle kullanın: elinizde ölçüm varsa yüksek, benzer bir işin geçmiş verisi varsa orta, sadece his varsa düşük. Talep tahmini gibi belirsizliği doğası gereği yüksek işlerde güven puanının dürüstçe düşük tutulması, skorun en bilgilendirici parçasıdır.
Bir de puanlama mekaniği var. En iyi sonucu aldığım düzen iki turlu: önce herkes puanlarını kimseye göstermeden yazar, sonra puanlar açılır ve yalnızca en çok ayrışan kalemler konuşulur. Tek turda açık puanlama yapılırsa ilk konuşan kişi çapayı belirler, gerisi ona yakınsar. Ayrıca tabloya bir "gerekçe" sütunu ekleyin: etkiye 8 veren kişi bir cümleyle nedenini yazsın. Bu sütun, geri bildirim döngüsünde tahminin neden tuttuğunu ya da tutmadığını anlamanın tek yolu olacak.
Kalibrasyonun testi de kod ile yapılabilir. Güven puanlarınızı biraz oynattığınızda sıralama tamamen değişiyorsa, sıralamanız sağlam değil, tahmin gürültüsüne yaslanıyor demektir:
import random
from collections import Counter
def duyarlilik_analizi(fikirler, sapma=0.25, deneme=2000, seed=42):
"""Guven puanlarini rastgele oynatip birinciligin
ne kadar el degistirdigine bakar."""
rnd = random.Random(seed)
birinci = Counter()
for _ in range(deneme):
skorlar = []
for f in fikirler:
oynak = f.guven * (1 + rnd.uniform(-sapma, sapma))
skorlar.append((f.etki * oynak * f.kolaylik, f.ad))
birinci[max(skorlar)[1]] += 1
return birinci
# 'backlog' listesi bir onceki ornekten geliyor
sonuc = duyarlilik_analizi(backlog)
for ad, adet in sonuc.most_common():
print(f"{ad:32} denemelerin %{100 * adet / 2000:.0f} kadarinda birinci")
Yukarıdaki backlog'da haftalık rapor ile fatura kontrolünün ICE skorları birbirine yakın; güven puanlarına çeyrek oranında gürültü eklendiğinde birincilik iki iş arasında sürekli el değiştiriyor, depo yerleşimi ise hiçbir denemede öne çıkamıyor. Bu tablodan alınacak ders şu: ilk iki sıra arasındaki fark gerçek bir fark değil, tahmin gürültüsü. İkisini "eşit öncelikli" kabul edip kararı başka bir kritere (stratejik uyum, bağımlılıklar, ekip motivasyonu) bırakmak, sahte bir kesinlikle sıralamaktan daha dürüst. Depo işinin geride kalması ise sağlam bir sonuç; ona güvenebilirsiniz.
Skorlamanın yanılttığı yerler
Şimdi işin sevmediğim kısmı. Skorlamayı yıllardır kullanıyorum ve şu tuzakların hepsine en az bir kez düştüm:
- Sahte hassasiyet: 504 puanlık işin 496 puanlık işten önce gelmesi gerektiği bilgisi formülde yok. Skorlar sıralama aracıdır, ölçüm değil; yakın skorlar berabere demektir.
- Kolaylık önyargısı: ICE küçük işleri sistematik olarak öne çıkarır. Ucuz ve kolay işleri hep önceleyen bir ekip, yapısal sorunlara hiç sıra gelmeyen bir "hızlı kazanım bandına" dönüşür. Büyük işleri parçalayıp parçaları skorlamak bunu kısmen çözer.
- Güven oyunculuğu: Fikri savunan kişi güven puanını da veriyorsa, güven skoru istek listesine döner. Güveni mümkünse fikir sahibi dışındaki birine puanlatın.
- Bağımlılık körlüğü: Skor, işleri bağımsız varsayar. Düşük skorlu bir altyapı işi, yüksek skorlu üç işin ön koşuluysa sıralama yanıltır; temel düzgün kurulmadan üstüne ne koyarsanız koyun pahalıya patlar. Bağımlılık zincirlerini skordan önce çizin.
- Ölçek enflasyonu: Birkaç tur sonra kimse 3 vermez olur; herkes 7 ile 9 arasında dolaşır ve ölçek fiilen üç kademeye iner. Her turda puan dağılımına bakın; ortanca değer sürekli yukarı kayıyorsa çapa örneklerini yenilemenin zamanı gelmiştir.
- Strateji yokluğu: Skor "neyi" sıralar, "neden"i bilmez. Şirket yön değiştiriyorsa geçen çeyreğin etki tanımıyla puanlanmış liste çöptür.
Geri bildirim döngüsünü kapatmak
Skorlamayı sürekli iyileştirme aracına dönüştüren adım burası ve ekiplerin çoğu bu adımı atlıyor. İş bittikten birkaç hafta sonra tahminlerin yanına gerçekleşenleri yazın: etki beklediğimiz gibi miydi, efor tahmini tuttu mu, güven puanımız haklı çıktı mı?
Bu karşılaştırma iki şey öğretir. Birincisi, ekibin sistematik sapmalarını gösterir; çoğu ekip eforu olduğundan düşük, etkiyi olduğundan yüksek tahmin eder ve bunu ancak kayıt tutunca fark eder. İkincisi, çapa örneklerinizi tazeler: bir sonraki puanlama turunda "etki 8" artık somut ve yakın tarihli bir referansa oturur. Döngü kapanmazsa skorlama bir tahmin ritüeli olarak kalır; kapanırsa ekip her turda biraz daha isabetli tahmin yapan bir öğrenme sistemine dönüşür.
Sonuç
ICE hızlı tarama, RICE kaynak verimliliği; ikisi de tahminlerinizin kalitesi kadar iyidir. Formülü kurmak yarım saat, ölçekleri kalibre etmek birkaç tur, geri bildirim döngüsünü oturtmak aylar alır ve asıl değer o son adımda birikir. Sayılara sıralama yaptırın ama kararı sayıya devretmeyin: skor tablosu tartışmanın yerine geçen değil, tartışmayı kaliteli kılan bir araçtır.
Aynı yaklaşım, veri ve otomasyon danışmanlığı işlerinde hem bir iyileştirme backlog'unu sıralarken hem de iç araçların yol haritasını planlarken işe yarar. Kendi ekibinizin backlog'una skorlama disiplini kurmak veya mevcut önceliklendirme sürecinizi gözden geçirmek isterseniz iletişim sayfasından bana yazabilirsiniz.