--- title: "Yazılım Tahminleri Neden Hep Şaşar ve Ne Yapılabilir?" url: "https://cilginyazilim.com/blog/yazilim-tahminleri-neden-hep-sasar" description: "Planlama yanılgısı, görünmeyen iş kalemleri ve baskı altında verilen sözler: tahminlerin şaşma sebepleri ve aralık tahmini gibi çözümler." published: "2026-11-04T10:00:00+03:00" modified: "2026-11-04T10:00:04+03:00" author: "Çılgın Yazılım" category: "Yazılım Geliştirme" tags: ["proje yönetimi", "agile", "yazılım projeleri", "iletişim", "ekip çalışması", "teknik borç", "risk yönetimi", "yazılım tahminleri", "planlama", "sprint", "story point", "kapsam yönetimi", "ölçüm"] site: "Çılgın Yazılım" language: "tr" --- # Yazılım Tahminleri Neden Hep Şaşar ve Ne Yapılabilir? "İki gün sürer" denen iş neden iki hafta alır? Tahmin hatasının yapısal sebepleri ve daha dürüst tahmin yöntemleri. **Yazılım tahminleri** neredeyse her zaman iyimser çıkar. Bu, tecrübesizlikten kaynaklanan bir acemilik değildir; yirmi yıllık geliştiriciler de aynı yönde şaşar. Sistematik ve tek yönlü bir sapmadan söz ediyorsak, sebep kişisel beceri değil yapısaldır. Bu yazıda tahmin hatasının gerçek kaynaklarını ve tahmini "yalan söylememeye" yaklaştıran yöntemleri ele alıyoruz. ![Tahmin iyileştirme yöntemleri listesi](https://cilginyazilim.com/uploads/blog/2026/07/yazilim-tahminleri-neden-hep-sasar-ozet.png) *Tahminin amacı geleceği bilmek değil, belirsizliği görünür kılmaktır.* ## Neden hep az tahmin ediyoruz? ### Planlama yanılgısı İnsan zihni bir işi tahmin ederken en akıcı senaryoyu canlandırır: her şeyin yolunda gittiği hâli. Ancak gerçek süre, akıcı senaryonun süresi değil, aksaklıklarla birlikte geçen süredir. İlginç olan şu ki aynı kişi başkasının işini daha isabetli tahmin eder — çünkü kendi işinde iyimserlik, başkasınınkinde gerçekçilik devreye girer. ### Görünmeyen iş kalemleri "Bu ekranı iki günde yaparım" cümlesindeki iki gün, genellikle yalnızca kod yazma süresidir. Oysa işin tamamlanması için gerekenler listesi çok daha uzundur: test yazmak, kod incelemesini beklemek ve düzeltmeleri uygulamak, hazırlık ortamında denemek, ortaya çıkan kenar durumları çözmek, dağıtmak ve sonrasını izlemek. Bu kalemler tahmine dahil edilmediğinde, tahmin yanlış değil *eksik* olur. ### Bilinmeyen bilinmeyenler Tahmin, işin ne olduğunu bildiğiniz varsayımına dayanır. Ancak yazılımda işin gerçek şekli, çoğu zaman ona başladıktan sonra ortaya çıkar: entegre olacağınız servisin dokümantasyonu eksiktir, mevcut kodda beklenmedik bir bağımlılık vardır, iş kuralının bir istisnası olduğu kodlama sırasında keşfedilir. Bu belirsizlik tahmin edilemez, ama *hesaba katılabilir*. ### Sosyal baskı Tahmin genellikle nötr bir ortamda değil, cevabın beklendiği bir toplantıda verilir. "Bir ayda biter mi?" diye soran bir yöneticiye "bilmiyorum, üç ay da sürebilir" demek, cesaret gerektirir. Bu yüzden verilen sayı sıklıkla gerçek bir öngörü değil, ortamdaki beklentiye verilen bir cevaptır. ## Daha dürüst tahmin için beş yöntem ### 1. Tek sayı yerine aralık verin "Beş gün" demek, sahip olmadığınız bir kesinliği iddia etmektir. "En iyi ihtimalle 3, muhtemelen 5, kötü giderse 9 gün" demek hem daha doğrudur hem de karşı tarafa risk hakkında bilgi verir. Aralığın genişliği, belirsizliğin ölçüsüdür: çok geniş bir aralık, önce bir araştırma yapılması gerektiğinin işaretidir. ### 2. Sıfırdan değil, benzerinden yola çıkın En isabetli yöntem genellikle en basitidir: "geçen sefer buna benzer bir iş ne kadar sürdü?" Ekiplerin çoğu bu veriyi tutmadığı için her seferinde sıfırdan başlar. Oysa tamamlanan işlerin öngörülen ve gerçekleşen sürelerini kaydetmek, birkaç ay içinde çok değerli bir referans oluşturur. Bu kayıt aynı zamanda hangi tür işlerde ne kadar saptığınızı da gösterir — ve bu sapma oranı, sonraki planlamalar için bir düzeltme katsayısına dönüşür. ### 3. Sayıyı, işi yapacak kişi versin Başkası adına verilen sayılar hem daha isabetsizdir hem de sahiplenilmez. Ayrıca birden fazla kişinin bağımsız değerlendirme yapıp sonra tartıştığı yöntemler (planning poker gibi), tek kişinin öngörüsüne göre belirgin şekilde daha isabetlidir — çünkü farklı sayılar, farkında olunmayan varsayımları açığa çıkarır. ### 4. Belirsizliği önce azaltın Çok belirsiz bir iş için sayı üretmeye çalışmak yerine, önce belirsizliği azaltan kısa bir araştırma (spike) yapmak çok daha verimlidir: "Bu entegrasyonun mümkün olup olmadığını anlamak için bir gün ayıralım, sonra tahmin verelim." Bu, kararı ertelemek değil, öngörülebilir hâle getirmektir. ### 5. Öngörüyü taahhütten ayırın Biri bir öngörüdür, diğeri bir sözdür. İkisi aynı cümleyle ifade edildiğinde, ekip gerçekçi bir sayı vermek yerine tutabileceği söz vermeye başlar — ve bu, sonucu sistematik olarak şişirir veya baskı altında kısaltır. Bu ayrımı açıkça yapmak, kurumsal projelerde en çok fark yaratan iletişim değişikliklerinden biridir. ## Kapsam sabit değilse sayı da sabit olamaz Bu konudaki tartışmaların önemli bir kısmı aslında kapsam tartışmasıdır. İş tanımı süreç içinde büyüdüğünde verilen sayı da geçersizleşir, ancak bu genellikle "tutmadı" diye kaydedilir. Bu yüzden sayıyla birlikte neyin dahil olduğunu ve neyin olmadığını yazmak, sonraki tartışmaların yarısını ortadan kaldırır. Kapsam kaymasının proje başarısızlığındaki rolü için [proje başarısızlığı yazımıza](https://cilginyazilim.com/blog/yazilim-projeleri-neden-basarisiz-olur) bakabilirsiniz. ## Sonuçlar tutmuyorsa neye bakmalı? Sistematik sapmanın kaynağı çoğu zaman kullanılan yöntemde değil, sistemin kendisindedir. Aynı modüle dokunan işler sürekli iki katına çıkıyorsa, orada bir planlama sorunu değil bir sürtünme sorunu vardır — ve bu, ölçülmüş bir teknik borç sinyalidir; [teknik borç yazımız](https://cilginyazilim.com/blog/teknik-borc-ne-zaman-odenir-ne-zaman-tasinir) bu sinyalin nasıl değerlendirileceğini ele alıyor. Benzer şekilde, işlerin çoğu zamanını kod incelemesi beklemekle geçiriyorsa çözüm daha iyi planlama değil, daha kısa inceleme döngüsüdür; bu konuda [kod incelemesi yazımız](https://cilginyazilim.com/blog/kod-incelemesinde-neyi-nasil-elestirmeli) faydalı olabilir. Konu üzerine daha geniş bir tartışma için [Martin Fowler — tahminin amacı](https://martinfowler.com/bliki/PurposeOfEstimation.html) yazısı okunabilir. ## Sonuç Yazılım tahminleri, kişisel dikkatsizlik yüzünden değil, en akıcı senaryoyu canlandıran zihinsel bir eğilim, görünmeyen iş kalemleri ve baskı altında verilen cevaplar yüzünden şaşar. Bunları ortadan kaldırmak mümkün değildir; ama etkilerini azaltmak mümkündür: aralık verin, geçmiş verilere bakın, belirsizliği önce araştırmayla azaltın ve öngörüyle taahhüdü birbirine karıştırmayın. En pratik ilk adım ise ölçmektir. Önümüzdeki iki ay boyunca her iş için öngörülen ve gerçekleşen süreyi kaydedin; bu iki sütun arasındaki oran, ekibinizin gerçek sapma katsayısını size söyleyecektir. ## Sıkça Sorulan Sorular ### Story point mi, saat mi kullanmalıyız? İkisi de farklı sorulara hizmet eder. Puanlar göreli büyüklüğü ve ekip hızını izlemek için uygundur; saat bazlı öngörü ise dış taahhüt gerektiğinde kaçınılmazdır. Asıl belirleyici birim değil, sayının geçmiş verilere dayanıp dayanmadığıdır. ### Öngörüye güvenlik payı eklemek doğru mu? Gizli pay eklemek zamanla güveni zedeler çünkü fark edilir. Bunun yerine belirsizliği aralık olarak açıkça ifade etmek hem daha dürüst hem de daha kullanışlıdır. ### Hiç öngörü yapmadan çalışmak mümkün mü? Bazı ekipler işleri küçük ve benzer boyutlara bölüp akış süresini ölçerek bu sayıları hiç üretmeden çalışır. Bu yaklaşım işe yarayabilir, ancak dış paydaşlara tarih vermek gerektiğinde bir öngörüye yine ihtiyaç duyulur. ### Sonuç tutmadığında ne yapmalı? Suçlu aramak yerine sapmanın kaynağını sınıflandırın: kapsam mı büyüdü, bilinmeyen bir engel mi çıktı, yoksa aynı modüldeki sürtünme mi? Bu sınıflandırma, sayıyı değil sistemi iyileştirir. --- Kaynak: [Yazılım Tahminleri Neden Hep Şaşar ve Ne Yapılabilir?](https://cilginyazilim.com/blog/yazilim-tahminleri-neden-hep-sasar)