İş Nerede Bekliyor? Akışı Görünür Kılan Dört Metrik

Bir organizasyonda “işler neden bu kadar uzun sürüyor?” sorusu sorulduğunda cevap genellikle “çok yoğunuz” olur. Herkes meşgul, takvimler dolu, panolar kalabalık. Ama müşteri açısından bakınca iş yavaş ilerliyor. Bu çelişkinin sebebi basit: İşin büyük kısmı üzerinde çalışılırken değil, beklerken geçiyor. Kimse boş durmuyor; iş boş duruyor.

Beklemeyi görmek için daha fazla rapora değil, doğru birkaç metriğe ihtiyaç var. Kanban Rehberi bunları dört temel akış ölçüsü olarak tanımlar. Bu yazıda her birinin neyi anlattığını, nasıl okunacağını ve en sık yapılan hataları sahadan örneklerle ele alıyoruz.

1. Devam eden iş (WIP): Aynı anda kaç işle uğraşıyoruz?

Tanım: Başlamış ama henüz bitmemiş iş öğelerinin sayısı.

WIP, akışın en çok göz ardı edilen ama en güçlü kaldıracıdır. Bir ekip aynı anda ne kadar çok işe başlarsa, her iş o kadar yavaş biter. Bunun sebebi bağlam değiştirme, bölünmüş dikkat ve işlerin birbirinin önünü kesmesidir.

Sahada sık gördüğümüz tablo şu: Beş kişilik bir ekibin panosunda “devam ediyor” sütununda yirmi iş var. Herkes dört işi aynı anda yürütüyor ve hiçbiri bitmiyor. Bu durumda ilk iyileştirme yeni bir araç ya da yeni bir rol değil, WIP limiti koymaktır: “Bu sütunda aynı anda en fazla altı iş olabilir.” Limit dolunca yeni işe başlamak yerine takılan işi bitirmeye yardım edilir.

Daha az başla, daha çok bitir.

2. Döngü süresi (Cycle Time): Bir iş başladıktan sonra ne kadar sürede bitiyor?

Tanım: Bir iş öğesinin başlangıçtan bitişe kadar geçen süresi.

Döngü süresi müşteri deneyimine en yakın metriktir. Bir talep “başladı” dendikten sonra kaç günde teslim ediliyor? Burada ortalamaya değil dağılıma bakmak gerekir. Ortalama döngü süresi 6 gün olan bir ekipte işlerin bir kısmı 2 günde, bir kısmı 30 günde bitiyor olabilir. Müşteriyi asıl etkileyen o uzun kuyruktur.

Döngü süresini bir dağılım grafiğinde (scatterplot) göstermek en iyi yöntemdir. Yatay eksende bitiş tarihi, dikey eksende gün sayısı. Grafik üzerinde %50, %85 ve %95 çizgileri çizdiğinizde ekibinize ve paydaşlarınıza şu cümleyi kurabilirsiniz: “İşlerimizin %85’i 9 gün ya da daha kısa sürede bitiyor.”

Kanban Rehberi bu cümleye hizmet seviyesi beklentisi (Service Level Expectation) der: bir süre ile bir olasılığın birleşimi. Rehberdeki örnek “iş öğelerinin %85’i 8 günde biter” şeklindedir. Tahmin yerine geçmiş veriye dayanan bu cümle, “ne zaman biter?” konuşmasını çok daha sağlıklı hâle getirir.

3. Throughput: Belirli bir sürede kaç iş bitiriyoruz?

Tanım: Birim zamanda biten iş öğesi sayısı.

Throughput, ekibin teslim kapasitesini gösterir. Haftalık ya da günlük sayılır. Story point gibi tahmine dayalı birimler yerine biten işin sayısını kullanmak, ölçümü basit ve tartışmasız kılar. İş öğeleri benzer büyüklükte tutulduğunda bu sayı şaşırtıcı derecede iyi bir öngörü aracına dönüşür.

Throughput’un en değerli kullanımı tahmindir. “Bu 40 işlik kapsam ne zaman biter?” sorusunu geçmiş throughput verisiyle olasılıklı olarak cevaplayabilirsiniz. Bunu ilerleyen yazılarımızda Monte Carlo simülasyonuyla ayrıntılı ele alacağız.

4. İş öğesi yaşı (Work Item Age): Devam eden iş ne zamandır açık?

Tanım: Bir iş öğesinin başladığı andan bugüne kadar geçen süre.

Diğer üç metrik geçmişi anlatır; iş öğesi yaşı ise bugünü. Döngü süresi ancak iş bittikten sonra hesaplanabilir. Bir iş 40 gündür takılıyorsa, döngü süresi grafiğinde onu ancak bittiğinde görürsünüz; o zaman da iş işten geçmiş olur.

Bu yüzden iş öğesi yaşı, günlük toplantının en iyi rehberidir. Panodaki her kartın üzerinde kaç gündür açık olduğunu gösterin. Yaşı, hizmet seviyesi beklentinizi aşmaya yaklaşan işleri işaretleyin. Günlük toplantıda ilk soru şu olsun: “En yaşlı işimiz hangisi ve onu bugün nasıl ilerletiriz?”

Sahadan bir gözlem: Bir ekibin panosunda aylardır kimsenin dokunmadığı onlarca iş öğesi bulmak sık rastladığımız bir durum. Bu işler ya kapatılmalı ya da gerçekten önceliklendirilmeli. Yaşlanan iş, gizli bir borçtur: Hem panoyu kalabalıklaştırır hem de “yapılacak” diye bekleyen paydaşlarda yanlış beklenti oluşturur.

Dört metrik birbirine nasıl bağlı?

Bu dört ölçü birbirinden bağımsız değildir. Akış teorisinde Little Yasası olarak bilinen ilişki, sistem görece istikrarlı olduğunda şunu söyler:

Ortalama döngü süresi = Ortalama WIP ÷ Ortalama throughput

Yani throughput’u değiştirmeden WIP’i yarıya indirirseniz, ortalama döngü süresi de yaklaşık yarıya iner. Ekibe daha hızlı çalışmasını söylemek yerine aynı anda daha az işe başlamak, işleri daha hızlı bitirmenin en ucuz yoludur.

Akış verimliliği: Bir iş, ömrünün ne kadarında üzerinde çalışılıyor?

Dört temel metriğe ek olarak sıkça kullandığımız bir gösterge daha var: akış verimliliği. Bir işin toplam süresinin ne kadarında aktif olarak üzerinde çalışıldığını gösterir. Kanban topluluğunda sık dile getirilen bir referansa göre akışa odaklanmayan ekiplerde bu oran %15 civarındadır; yani iş, ömrünün yaklaşık %85’ini bekleyerek geçirir. %40’ın üzeri iyi kabul edilir.

Akış verimliliğini ölçmek için panonuzda bekleme durumlarını ayrı sütunlar olarak göstermeniz gerekir: “Test için bekliyor”, “Onay bekliyor”, “Dış ekipte”. Bu sütunlar görünür hâle geldiğinde beklemenin nerede biriktiği tartışmaya gerek kalmadan ortaya çıkar.

Sık yapılan hatalar

• Metrikleri kişileri karşılaştırmak için kullanmak. Akış metrikleri sistemi ölçer, kişileri değil. Bireysel performans aracı olarak kullanıldığında veri bozulur.
• Sadece ortalamaya bakmak. Ortalama, uzun kuyruğu gizler. Dağılıma ve yüzdeliklere bakın.
• “Başladı” ve “bitti” tanımlarını netleştirmemek. Ölçümün başladığı ve bittiği noktalar ekip içinde açıkça tanımlı olmalı.
• Metriği hedefe dönüştürmek. “Döngü süresi 5 günün altına inecek” hedefi, ekipleri işleri yapay olarak bölmeye ya da erken kapatmaya iter. Metrik bir soru sormanızı sağlamalı, cevap yerine geçmemeli.

Nereden başlamalı?

1. Panonuzun “başladı” ve “bitti” noktalarını netleştirin.
2. Bekleme durumlarını görünür sütunlar olarak ekleyin.
3. Her kartın üzerinde iş öğesi yaşını gösterin.
4. İki haftalık veri biriktikten sonra döngü süresi dağılımına ve throughput’a bakın.
5. WIP limitini koyun ve etkisini birkaç hafta izleyin.

Çoğu araç (Jira, Azure DevOps ve benzerleri) bu verileri zaten tutuyor; eksik olan genellikle veri değil, verinin düzenli olarak okunduğu ve karara dönüştüğü bir ritim. Akış ölçümü ve Kanban koçluğu yaklaşımımızı hizmetlerimiz sayfasında bulabilirsiniz. İşinizin nerede beklediğini birlikte görmek için ücretsiz 360 değerlendirmeyle başlayabiliriz.