Yazılımda Tahmin Neden Zor — Ve Daha İyi Nasıl Yapılır

"Bu özellik ne kadar sürer?"

Manager soruyor, sen düşünüyor, "İki hafta" diyorsun. Üç hafta sonra hâlâ bitmemiş, manager de gergin, sen de stresli, ekip de pataklanıyor.

Tahminler her zaman yanlış çıkar. Bunun sebebi senin yetersiz olman değil. Yazılım problemleri tarafından gizlenen tahmin tuzaklarıdır. Bu yazıda 13 yıllık deneyimimden çıkardığım: neden zor, nasıl daha az kötü yapılır.

Neden zor

1. Cone of uncertainty

Bir projeye başlarken sahip olduğun bilgi: %20-30. Görünmeyen %70-80, ilk hafta yapacağın işlerle ortaya çıkar. Tahmin verirken, bilmediğin şeyleri tahmin etmiş olursun. Bu garanti olarak yanılır.

Klasik araştırma: bir yazılım projesinin başlangıcında verilen tahmin, gerçeğin 0.25× ile 4× arasında bir noktada olur. Yani 1 ay tahmini, 1 hafta da bitebilir, 4 ay da. Cone "daralır" — proje ilerledikçe tahmin doğruluğu artar.

Bu fizik. İnsan yetersizliği değil.

2. Bilmediğin için planlamadığın şeyler

Yeni bir özellik yazıyorsun. Tahmin: 5 gün. Sonra:

• Üçüncü taraf API'si yanlış doc, fiilen 4 saat değil 4 gün takılırsın
• Mevcut kod tabanı senin sandığın gibi değil, refactor gerektiriyor
• Test ortamı bozuk, 1 gün düzeltmek gerek
• Ekip arkadaşı izinli, soramadığın bir konu var

Bunların hiçbirini tahmin verirken bilmiyordun. Hiçbirine planlama yapmadın. Hepsi gerçek.

3. Optimizm bias

İnsan beyni doğal olarak iyimserdir. "Bu fonksiyonu yazmak 2 saat sürer" düşüncesi, geçmiş deneyimde benzer fonksiyonların gerçekten 6 saat sürmüş olduğu gerçeğini bastırır.

Tüm developer'lar bu bias'a sahip. Senior'lar daha az ama hâlâ sahipler.

4. Tahmin değil taahhüt sayılır

Manager tahminini söyleyince plan haline gelir. Sen "iki hafta tahmin ediyorum, 4 hafta da olabilir" desen bile, senior'a 2 hafta hatırlanır. Beklentiler oluşur. Hâlbuki tahmin, taahhüt değildir.

Bu sosyal dinamik tahminlerin değerini bozar. Kimse "iyi tahminci" olmak istemez, çünkü iyi tahmin mücadelelerinin kazandığı değil, başarısızlıklarının cezalandırıldığı bir oyun.

Nasıl daha az kötü yapılır

1. Aralık ver, nokta verme

"5 gün" yerine "3-7 gün". "4 hafta" yerine "3-6 hafta".

Aralık dürüstlüktür. Cone of uncertainty'i ifade eder. Manager ilk başta direnirse, açıkla: "tek nokta vermek bana yalan söyletir, bu daha doğru".

2. T-shirt sizes (S/M/L/XL)

Saat ve gün ölçümü çok hassas, çoğu zaman gereksiz. Bunun yerine:

• S: bir gün ya da daha az (basit fix, küçük UI değişikliği)
• M: 2-3 gün (orta karmaşıklıkta özellik)
• L: 1 hafta (büyük özellik, bütünleşmeler)
• XL: 2+ hafta (büyük iş, planlamadan emin değiliz)

XL gördüğünde, böl. XL'i daha küçük parçalara bölmek mümkün değilse, bir prototip yap önce — gerçek tahmini sonra çıkarsın.

3. "İnşaat süresi" + "tampon"

Tahminin kendisini iki kısım olarak ver:

• İnşaat süresi: kod yazma, test yazma. 5 gün.
• Tampon: bilinmeyen şeyler, gözden kaçanlar, bug'lar. 2-3 gün.

Toplam: 7-8 gün.

İnsanlar tampon kavramını yıllar sonra öğrenirler. Daha erken öğrendiğinde tahminlerin %30 daha doğru olur.

4. "İlk deney" stratejisi

Tahmin verilemeyecek belirsizlik varsa: "1 günlük spike yapayım, sonra söyleyim". Bu aktif olarak cone of uncertainty'i daraltma.

Sonuç: 1 gün sonra tahmin daha sağlam. Manager bekliyor ama gerçek bilgiye dayanıyor.

5. Düzenli reset

Hafta başında: bu hafta neye gücüm yetiyor? Hafta sonunda: gerçekte ne yaptım? Aralarındaki fark bir sonraki hafta için kalibrasyon.

3 ay sonra:

• "1 günlük tahmin verdiğim işler genelde 1.5 gün sürüyormuş"
• "Bilmediğim API'larla iş 3× tahminden uzun sürer"
• "Refactor işlerini hep eksik tahmin ediyorum"

Bu kişisel kalibrasyon, gelecekteki tahminleri keskinleştirir.

Manager iletişimi

Tahmin disiplini bir taraflı iş değil. Manager'ın da rolü var.

İyi manager:

• Tahmini "ne kadar sürer?" diye sorar, "kaç güne biter?" demez
• Aralık'ı kabul eder
• Süresi aştığında anlamak ister, suçlamaz
• Her sprint sonu kalibrasyon yapar

Kötü manager:

• "Verdiğin tahmin neden yanılttı?" der
• Tahmini sözleşme gibi tutar
• Süre aştığında ekibi suçlar

Eğer kötü manager'la çalışıyorsan, kendini koru: tahminleri açık aralık + tampon ile yaz, yazılı, e-posta veya ticket'ta. "Nokta tahmin" verme.

Sonuç

Yazılım tahmini doğru olmaz. Daha az yanlış olabilir.

Aralık ver, t-shirt size kullan, tampon ekle, belirsizliği görüşle daralt, kendini düzenli kalibre et. Bu 5 alışkanlıkla 1 yıl çalışan bir engineer, tahminin doğruluğunda büyük fark yaratır — manager'ı için hayatı kolaylaştırır, kendi stres seviyesini düşürür.

Tahmin sadece sayı değil, iletişim aracı. Belirsizliği iletmek, sayı vermekten önemli.