Bu iş ne zaman biter? Yazılımda tahmin, olasılıklı öngörü ve savunulabilir teslim tarihi

"Bu iş ne zaman biter?" sorusunun savunulabilir cevabı tek bir tarih değil, iki tarihtir: "12 Ekim'de yüzde 50, 26 Ekim'de yüzde 85 ihtimalle." Tarihlerin kaymasının sebebi çoğu zaman ekibin yavaş çalışması değil, üç alışkanlıktır. Tek sayılı bir tahmin yolda sessizce taahhüde dönüşür, ekip bitmiş işlerinin gerçek sürelerini hiç ölçmez, listeye sonradan eklenen işler öngörüye hiç yansımaz. Bu üçü düzeltildiğinde tahminleriniz sihirli biçimde isabetli olmaz; tahmine olan ihtiyacınız azalır, çünkü kendi verinizden öngörü üretebilir hâle gelirsiniz.

Tahmin, hedef ve taahhüt üç ayrı şeydir

Steve McConnell'in yaptığı ayrım bu tartışmanın temeli. Tahmin, işin ne kadar süreceğine dair öngörüdür ve doğası gereği tek sayı değil, bir aralık ya da olasılık dağılımıdır. Hedef, iş tarafının arzu ettiği sonuçtur: "kasımdaki fuara yetişsin." Taahhüt ise belirli bir kapsamı belirli bir kalitede belirli bir tarihte teslim etme sözüdür. Taahhüt tahminle aynı olabilir, ondan daha iddialı da daha temkinli de olabilir.

Sahada en sık gördüğümüz kaza bu üçünün aynı toplantıda birbirine karışmasıdır. Yönetici "bir tahmin verin" der, aslında bir taahhüt ya da hedefi tutturacak bir plan ister. Ekip iyi niyetle "üç ila altı hafta" der, karşı taraf not defterine "üç hafta" yazar. Kimse yalan söylemedi, ama artık ortada kimsenin kabul etmediği bir söz var. Kelimeleri ayırmak bedava ve etkili: hangi cümlenin tahmin, hangisinin taahhüt olduğunu yazılı olarak belirtin.

Asıl sorun yanılma payı değil, aşırı güven

Magne Jørgensen'in Journal of Systems and Software'de yayımlanan 2004 tarihli derlemesi, yayımlanmış anketlerin tipik olarak yüzde 30 civarında bir efor aşımı bildirdiğini yazıyor. Bu rakam aslında iyi haber: yüzde 30 planlanabilir bir sapmadır. Aynı derlemedeki ikinci bulgu daha rahatsız edici. Bir yazılımcı yüzde 90 güvenle "gerçek süre şu en az ve en çok değerlerinin arasındadır" dediğinde, gerçek süre o aralığın içinde ancak yüzde 60 ila 70 oranında çıkıyor. Yani verdiğiniz aralık, verirken hissettiğinizden belirgin biçimde dar.

Kuyruk tarafında durum daha sert. Bent Flyvbjerg ve Alexander Budzier'in 2011'de Harvard Business Review'da yayımladığı çalışma 1.471 bilişim projesini inceledi. Ortalama maliyet aşımı yüzde 27 çıktı, ki bu yukarıdaki rakamla tutarlı. Ama altı projeden biri "kara kuğu" davranışı gösterdi: ortalama yüzde 200 maliyet aşımı ve neredeyse yüzde 70 takvim aşımı. Buradan çıkan yönetim kuralı tahminle değil, portföyle ilgili: ortalamaya göre plan yapabilirsiniz, kuyruğa göre yapamazsınız. Tek bir riskli programa şirketin bütün bütçesini ve tek bir tarihi bağlamayın. Tahmindeki şaşma payının sözleşme tarafındaki sonuçlarını sabit fiyat ve zaman-malzeme karşılaştırmasında ayrıntılı ele almıştık.

Rakamı vermeden önce bütçeyi duymayın

Tahmin isterken hedef tarihi ya da bütçeyi söylemek, aldığınız cevabı etkiler. Jørgensen ve Stein Grimstad'ın laboratuvar çalışmaları sayısal çapaların tahminler üzerinde güçlü etki bıraktığını gösteriyor. Aynı ekibin 2011'de IEEE Transactions on Software Engineering'de yayımladığı saha deneyi ise daha temkinli bir tablo çiziyor: 46 dış kaynak firmasına aynı beş projenin tahmini ücret karşılığı yaptırıldı, firmalar rastgele biçimde ya orijinal şartnameyi ya da değiştirilmiş bir sürümü aldı (kısaltılmış metin, müşterinin düşük bütçe beklentisine dair bilgi, kısa geliştirme süresi kısıtı). Sahadaki etki büyüklükleri laboratuvardakinden çok daha küçük çıktı, birçoğu istatistiksel anlamlılığa bile ulaşmadı.

Yani çapa etkisi her koşulda çalışan bir kanun değil. Ama önlemi bedava olduğu için almamak için sebep yok: tahmini isteyin, alın, sonra bütçeyi ve hedef tarihi konuşun. Aynı dikkati sözel çerçeveye de gösterin. Bir işi "ufak bir ekleme" diye tarif etmek ile "yeni bir modül" diye tarif etmek aynı iş için farklı tahminler üretir.

Ölçmediğiniz şeyi öngöremezsiniz, ölçmek de iki tarih demek

Kanban Kılavuzu'nun Mayıs 2025 sürümü dört akış metriği tanımlıyor ve dördü de aynı iki veri alanından türüyor:

• WIP: başlamış ama henüz bitmemiş iş sayısı.
• Throughput: birim zamanda biten iş sayısı. Puan toplamı değil, işin tam sayımı.
• İş yaşı: işin başladığı andan bugüne geçen süre.
• Çevrim süresi: işin başladığı andan bittiği ana kadar geçen süre.

Kılavuz "başladı" ve "bitti"nin ne anlama geldiğini ekibin kendi iş akışı tanımında yazmasını istiyor. Bu detay önemsiz görünür ama öngörünün kalitesini doğrudan belirler: "başladı" kimine göre kartın açılması, kimine göre ilk commit'tir ve ikisi arasında haftalar olabilir. Tek şart herkesin aynı çizgiyi kullanması. Bu iki tarihi toplamayan ekip her yeni soruda sıfırdan tahmin üretmek zorunda kalır, üstelik her seferinde aynı iyimserlikle.

Ortalamayla bölmek plan değil, yazı tura

Kalan 40 iş var, haftada ortalama 5 iş bitiyor, demek ki 8 hafta. Aritmetik doğru, öngörü olarak kullanışsız. Ortalamayla üretilen bir tarih en iyi ihtimalle yüzde 50 civarında bir ihtimaldir, yani gerçekleşme şansı yazı turayla aynıdır, üstelik dağılımın kötü tarafını tamamen görmezden gelir.

Monte Carlo yaklaşımı aynı veriyi çok daha dürüst kullanır. Geçmiş 8 ila 12 haftanın haftalık biten iş sayısını alın. Bu değerlerden rastgele, yerine koyarak çekin ve 40 işi bitirene kadar kaç hafta gerektiğini sayın. Bunu on binlerce kez tekrarlayın. Elinizde tek bir sayı değil, bir dağılım olur: yüzde 50, yüzde 85 ve yüzde 95 tarihleri. Bir tablo hesabında yarım saatte kurulur, hazır araçları da var.

Veri seçiminde tek kural şu: geleceğe benzeyeceğine inandığınız geçmişi kullanın. Ekip iki ay önce kurulduysa üç aylık geçmiş yoktur. Ekibin yarısı değiştiyse ya da iş tipi tamamen farklılaştıysa eski veriyi kesin, altı aydan eski veriyle çalışmayın.

Persentil dilini kurumda yerleştirin

Kanban Kılavuzu'nun servis seviyesi beklentisi dediği şey tam olarak budur: bir süre ve ona bağlı bir olasılık. Kılavuzdaki örnek "işlerin yüzde 85'i sekiz gün veya daha kısa sürede biter" biçiminde. Yeterli geçmiş veri yoksa iyi bir tahminle başlayıp veri biriktikçe düzeltmenizi öneriyor.

İş tarafına iki tarih vermek ilk bakışta kaçamak gibi görünür, pratikte tam tersi olur. Tartışma "tarih tuttu mu tutmadı mı" olmaktan çıkar, "hangi ihtimalle çalışıyoruz" hâline gelir. Fuar tarihine bağlı bir teslim için yüzde 85'i, iç bir iyileştirme için yüzde 50'yi seçmek artık iş tarafının bilinçli kararıdır. Ekip de kaybettiği şeyi geri alır: aralığın alt ucunun taahhüt diye not edilmesi biter.

Tarihi bozan şey çoğu zaman WIP

Little Yasası üç metriği tek formülde birleştirir: ortalama çevrim süresi, ortalama WIP bölü ortalama throughput'tur. Aynı anda 24 iş açıksa ve haftada 8 iş bitiyorsa ortalama çevrim süresi 3 haftadır. Aynı ekip aynı hızda çalışmaya devam ederken açık iş sayısını 12'ye indirirse çevrim süresi 1,5 haftaya iner. Kimse hızlanmadı, sadece sıra kısaldı.

Formülün geçerli olması için sistemin dengede olması gerekir: uzun vadede giren iş ile biten iş sayısı eşitlenmeli, başlanan her iş eninde sonunda bitmeli. Bu şart sağlanmadığında formül değil, gerçeğin kendisi bozuktur. Geciken projelerin önemli bir kısmında ekip yavaş değildir, aynı anda sekiz şeye başlamıştır.

Yüzde kaç bitti sorusunu bırakın, iş yaşına bakın

Günlük toplantıdaki "yüzde kaç bitti" sorusu bilgi taşımaz. Yüzde 90 haftalarca sürebilir, çünkü kalan yüzde 10 genelde entegrasyon, gözden geçirme ve düzeltmelerdir. İş yaşı ise bilgi taşır ve manipüle edilemez, çünkü tahmine değil takvime dayanır.

Kullanımı basit: bugün açık olan her işin kaç gündür açık olduğunu listeleyin ve çevrim süresi persentillerinizle karşılaştırın. İşlerin yüzde 85'i sekiz günde bitiyorsa, 12 gündür açık duran iş şu anda zaten geç kalmıştır. Bu, gecikmeyi teslim gününde değil, hâlâ müdahale edilebilecekken görmenizi sağlar. Sürekli entegrasyon ve otomatik testin olmadığı yerde bu işaretler geç gelir; küçük ekipler için dağıtım hattı kurmak öngörünün ön koşuludur.

Öngörüyü asıl bozan şey: listeye sonradan eklenenler

Her öngörü, kapsamın sabit olduğu varsayımıyla verilir. Kapsam sabit kalmaz. Yeni istek gelir, bir iş açıldığında ikiye bölünür, gözden kaçmış bir bağımlılık üç yeni iş doğurur. Ekip sözünü tutar, tarih yine kayar, kimse sebebi konuşmaz.

Çözüm ölçmek: haftada listeye kaç yeni iş ekleniyor ve başlanan işlerin kaçı bölünüyor? Bu iki oranı bilen ekip Monte Carlo öngörüsüne kalan iş sayısını bir çarpanla büyüterek girer ve tartışmayı doğru eksene taşır. Soru "yavaş mıyız" değil, "kapsam altı haftada ne kadar büyüdü" olur. Cevap belliyse karar iş tarafına döner: ya tarih ya kapsam. MVP kapsamını belirlerken tarihi sabitleyip kapsamı değişken bırakma yaklaşımı tam da bu yüzden işe yarar.

Dış görüş: en iyi referans sınıfınız kendi geçmişiniz

Referans sınıfı öngörüsü, Daniel Kahneman'ın 2002'de Nobel ekonomi ödülü kazanan karar teorisi çalışmalarına dayanır. Fikir basit: planlanan işin içine bakmak yerine (içeriden görüş), ona benzeyen geçmiş işlerin gerçekte nasıl sonuçlandığına bakmak (dışarıdan görüş). Flyvbjerg ve arkadaşlarının kamu projelerindeki talep tahmini sapmalarını gösteren çalışmasının ardından Amerikan Planlama Derneği 2005'te bu yöntemi resmen benimsedi ve planlamacıların yalnızca geleneksel tahmin tekniklerine dayanmamasını önerdi.

Yazılımdaki karşılığı gösterişsiz ama etkili. "Bu iş geçen yıl yaptığımız muhasebe entegrasyonuna benziyor, o 11 haftada bitmişti" cümlesi, "sanırım 4 hafta sürer" cümlesinden daha iyi bir başlangıç noktasıdır. Tek şartı var: bitmiş işlerin gerçek sürelerini bir yerde tutuyor olmak. Çoğu ekipte bu veri zaten iş takip aracının içinde duruyor, sadece kimse bakmıyor.

Uzman tahmininin hâlâ en iyi araç olduğu yer

Dürüst olmak gerekirse geçmiş veri her zaman yoktur. Yeni kurulmuş bir ekip, ilk defa yapılan bir iş tipi, daha önce hiç dokunulmamış bir eski sistem: bu durumlarda elinizde referans sınıfı yoktur ve uzman tahmini hâlâ en iyi araçtır. Jørgensen'in aynı derlemesi bunu da söylüyor, uzman tahminini formal modellerle değiştirmeyi destekleyen güçlü bir kanıt bulunmuyor.

Ama benzer işleri tekrar tekrar yapan bir ekipte durum tersine döner. Orada geçmiş veri uzman tahminini geride bırakır, kimsenin öğle arasını almaz ve tartışmayı kişiselleştirmez. Eski bir sistemi kademeli yenilerken ilk birkaç dilimin gerçek süresi, kalan dilimler için elinizdeki en değerli veri hâline gelir.

Bu haftaya sığan ilk adım

Üç iş yeterli. Birincisi, iş takip aracınızdan son 12 haftanın haftalık biten iş sayısını çıkarın; puan değil, adet. İkincisi, bugün açık olan işleri yaşlarına göre sıralayın ve en yaşlı üçünü bugünkü toplantıda konuşun. Üçüncüsü, sıradaki teslim için tek tarih yerine iki tarih verin ve yanına hangi kapsamı varsaydığınızı yazın.

Bu üçü elinizdeyken bir sonraki "ne zaman biter" sorusuna vereceğiniz cevap tahmin olmaktan çıkıp ölçüme dayanır. Kendi rakamlarınızı çıkarmakta ya da öngörüyü kurumdaki karar süreçlerine oturtmakta yardım isterseniz, mevcut verinize bakıp nereden başlanacağını birlikte belirleyelim.