- Yazılım projelerinde kesin süre tahmini yapmak imkansızdır ve çoğu iş, öngörülemeyen “bilinmeyen işler” tarafından belirlenir
- Tahminler mühendisler için değil, yönetimin siyasi aracı olarak kullanılır; proje önceliklerini ve bütçe dağılımını belirlemede rol oynar
- Pratikte işi tanımlayan şey tahminin kendisidir; ekipler, verilen süre içinde mümkün olan teknik yaklaşımı bularak çalışır
- Etkili tahmin için mühendisler siyasi bağlamı anlama, bilinmeyen riskleri değerlendirme ve birden fazla uygulama senaryosu sunma konularına odaklanmalıdır
- Bu yaklaşım, kesinlikten çok güvene ve gerçekçi iş birliğine önem verir ve organizasyon içindeki karar alma yapısını anlayan mühendislik yetkinliğini öne çıkarır
Yazılım tahmininin kurgusal doğası
- Sektörde, yetkin ekiplerin yeterli çabayla doğru takvim tahmini yapabileceğine dair “nazik bir kurgu” vardır
- Gerçekte mühendislerin çoğu kesin tahminin mümkün olmadığını bilir
- Bazı ekipler tişört bedeni yaklaşımıyla tahmin yapar, ancak bu da sonunda zaman birimlerine çevrilip yönetim katmanına iletilir
- “İlk tahmini ikiyle çarpıp üzerine %20 ekleyin” gibi gerçekçi olmayan sezgisel kurallar da kullanılabilir
Tahmin neden imkansızdır
- Küçük ve net işler öngörülebilir olsa da, projelerin çoğu belirsiz ve karmaşık sistemlerde yürütülür
- Örnek: Basit bir bağlantı metni değişikliği 45 dakikada tahmin edilebilirken, büyük ölçekli sistem değişiklikleri edilemez
- Programlamanın büyük bölümü keşif odaklı bir araştırma faaliyeti olduğundan, yalnızca önceden plan yaparak gerekli işleri bilmek mümkün değildir
- Geçmişteki merkezi mimari tasarım yaklaşımı başarısız olmuştur; kararları gerçek kodla çalışan geliştiriciler vermelidir
- Sonuç olarak bilinen işler toplamın yalnızca %10’unu oluşturur; kalan %90, bilinmeyen alanlar nedeniyle tahmin edilemez
Tahmin, mühendisin değil yönetimin aracıdır
- Tahminin ekip verimliliğini artırmakla ilgisi yoktur; birçok verimli ekip tahmin yapmadan da çalışır
- Yönetim, tahminleri istediği sonuca göre ayarlamaya çalışır; uzun takvimler kısaltma baskısı görür, kısa takvimlere ise tampon eklenir
- Yalnızca teknik olarak imkansız projeler istisnai biçimde daha gerçekçi değerlendirmelere yol açabilir
- Organizasyon içinde ilginin düşük olduğu alanlarda ise biçimsel süreçler aynen sürebilir
- Bu nedenle tahmin, mühendis olmayan kişilerin projeleri seçip iptal etmesi için kullanılan siyasi bir araç olarak işler
Tahmin işi tanımlar
- Yaygın kanının aksine, önce iş değil tahmin belirlenir, sonra buna uygun teknik yaklaşım seçilir
- Örnek: “PDF ile sohbet etme” özelliğini 6 ayda geliştirmekle 1 günde geliştirmek tamamen farklı yaklaşımlar gerektirir
- Zaman kısıtı, kod tasarımının derinliğini ve kalitesini belirler; mühendisler de verilen süre içinde mümkün olan çözümü seçer
Gerçekte nasıl tahmin yapılır
- Önce siyasi bağlam anlaşılır; projenin önemi ve beklenen takvim kavranır
- Ardından zaten belirlenmiş süreyi temel alarak mümkün yaklaşımlar araştırılır
- Bilinmeyenler (unknowns) arttıkça tahmin büyür ve yaklaşımın kapsamı daraltılmalıdır
- Son aşamada kesin süre yerine risk değerlendirmesi ve birden fazla uygulama senaryosu sunulur
- Örnek: Her şeyi doğrudan çözmek, bazı bölümleri dolanmak, başka ekiplerden destek istemek
- Mühendisin rolü “ne kadar sürer?” sorusunu yanıtlamak değil, “verilen sürede hangi yöntemler mümkün?” sorusuna cevap bulmaktır
İtirazlar ve yanıtlar
- Bazı mühendisler belirsiz koşullarda tahmin yapmaktan kaçınır, ancak bu durumda tahmini teknik olmayan kişiler yapar
- Yönetimle iş birliği kurmadan her zaman karşıt bir tutum almak verimsizdir ve güveni zayıflatır
- Baskı hissetmeyen ekipler, büyük olasılıkla yalnızca organizasyon içinde ilgi dışında kalan alanlarda çalışıyordur
Sonuç
- Gerçekte yöneticiler, zaten akıllarında olan bir takvimle ekibe gelir ve ekip bu çerçevede mümkün teknik çözümü arar
- Tahmin, yöneticiler arasındaki bir pazarlık aracıdır; yalnızca imkansız projeler istisnai olarak gerçeği iletmenin yolu olur
- Doğru tahmin, kesin sayı vermekten çok riskleri ve seçenekleri ortaya koymayı içermelidir
- Yazılım işlerinin kesin tahmini imkansızdır; başarılı tahmin ise bilinmeyen riskleri fark edip onları yönetebilme becerisine dayanır
2 yorum
> Önce siyasi bağlamı kavrayıp projenin önemini ve beklenen takvimi anlamak
> Ardından, zaten belirlenmiş süreyi temel alarak mümkün olan yaklaşımları araştırmak
Oho
Hacker News görüşleri
Biraz şaka yollu proje tahmin ölçeğimi paylaşıyorum
İç projelerde (ör. tedarikçi geçişi gibi kullanıcıyı etkilemeyen işler) yöneticiyi ikna edebileceğim kadar süre biçiyorum
Kullanıcıyı etkileyen projelerde (ör. yeni özellik ekleme) ROI pozitif kaldığı sürece devam ediyorum
Dış partnerlerle işbirliği gerektiren projelerde teslim tarihini satış ekibi belirliyor, mühendislik ekibi de o takvime uydurmak için MVP tanımını hafifçe ayarlıyor
Neden kimsenin planning poker ya da story point konuşmadığını merak ettim
Mükemmel değil ama oldukça iyi bir yöntem. Her iş sprint içinde bitmeli, büyükse bölünmeli
Tüm ekip üyelerinin puan konusunda uzlaşması gerekiyor ve bu süreçte asıl tartışma değeri ortaya çıkıyor
Birkaç ay sonra ekibin hızı oturuyor ve yaklaşık ±10% doğrulukla öngörü yapılabiliyor
Sihir değil ama düzenli olarak değer teslim etmeyi ve her sprintte maliyet/fayda dengesini yeniden gözden geçirmeyi sağlıyor
Yeni katılan biri aynı bilette bile 2 kat veya daha uzun sürebiliyor
Üstelik organizasyonlar PR incelemesi 24 saat içinde bitsin gibi kurallar koyarak gerçeklikle arayı açıyor
Geliştiriciler ve QA birlikte karmaşıklığı karşılaştırarak tahmin yapıyor, QA da test zorluğunu ya da otomasyon ihtimalini değerlendiriyor
Bu sayede geliştirme hızı metriği istikrarlı oluyor ve sürüm bazlı tahminler de oldukça isabetli çıkıyor
Ancak tüm ekibin en küçük birim hakkında ortak anlayışı varsa ve bu zamanla dönüştürülebiliyorsa anlamlı olur
Sonuçta o durumda doğrudan zamanı kullanmak yeterli olduğundan puanın kendisi gereksiz kalıyor
Ben “2 saat, 2 gün, 2 hafta, 2 ay, 2 yıl” ölçeğinde sorular sorarak güven aralığına dayalı tahmin yapıyorum
Aralık fazla genişse daha küçük parçalara bölüyorum; bu da mümkün değilse bilgi toplamak için zaman harcamaya değip değmeyeceğine karar veriyorum
Değmiyorsa projeyi iptal ediyorum
Sonucu net tanımlayıp fikri ayrıntılı adımlara bölersen gerçekçi tahmin yapmak mümkün oluyor
Bir işi gün ya da hafta düzeyinde bölemiyorsan henüz yeterince planlanmamış demektir
Böyle durumlarda sürekli farklı yaklaşımlar deneyip öğrenme süreci yaşandığı için tahminin zor olduğunu düşünüyorum
Basit süre tahmininden çok eylem odaklı düşünmeyi sağlıyor
Eskiden sadece parolaları düz metinden hash’e taşımak işini bir sprintlik sanmıştım ama gerçekte 6 ay sürdü
Müşterinin parolaları büyük/küçük harf duyarsız kullandığını bir video sayesinde öğrendik
Üstelik PHP imajı silinmişti ve buna build hatası da eklendi
Tahmin yapmak her zaman keyifli bir macera
Gerçek proje verilerine dayanarak bütçe aşımı istatistiklerini gösteriyor
BT projeleri ortalama %73 aşım ile nükleer atık depoları, Olimpiyatlar ve hidroelektrikten sonra en kötü alan
BT projelerinin %18’i %50’den fazla aşıyor ve bunların ortalama aşım oranı %447
Sonuçta çoğu sektörde tahminlerin yapısal olarak iyimser olmak zorunda kaldığını gösteriyor
Birçok mühendis ve yöneticinin tahminlerini geçmiş proje metriklerine dayandırmaması bana ilginç geliyor
Ekibin throughput verisine bakarsan kabaca süreyi ve güven aralıklarını (%90, %70, %50 gibi) hesaplayabilirsin
Böylece dış paydaşlara da olasılıksal bir bağlam sunulabilir
Ama birçok mühendis bunu idari yük olarak görüyor
İyi uygulama aralıklı tahmin kullanmaktır; PERT yaklaşımında olduğu gibi en iyi, beklenen ve en kötü üç senaryo modellenir
En iyi teknisyenler kendi zaman tahminlerinde aşırı özgüven göstermeye daha yatkın oluyor
Herkes ayrı ayrı tahmin edip sonra %20 düzeltme uygulamak oldukça iyi sonuç vermişti
Yönetim takvimi dayatırsa o sürede mümkün olan kapsamı anlatmak ya da kapsam netleştikten sonra yeniden tahmin önermek gerekir
Not: PMI PMP, PMBOK içindeki Lessons Learned Repository
Tahmin hatalardan öğrenir, dayatma ise tersine verimlilik baskısına dönüşür
Ben tahmini bir müzakere süreci olarak görüyorum
Araba donanımı gibi Economy, Mid-tier, Luxury olmak üzere üç seçenek sunuyorum
İş tarafı her zaman 3 numaranın işlevselliğini ve 1 numaranın bütçesini istiyor; ben de sonunda duruma göre ayarlıyorum
#1 planını hazır tutarsan kriz anında hızla geçiş yapılabiliyor ve müzakere sırasında kestirme yolun bedeli görselleştirilebiliyor
Bu sayede paniğe kapılmış PM ya da yöneticilerin irrasyonel kararlarını birçok kez engelleyebildim
Ben FAANG ölçeğinde büyük dağıtık sistemlerle uğraşıyorum; burada doğru tahmin yapmak neredeyse imkansız
unknown-unknowns çok fazla ve sadece prototip bile muazzam veri ve zaman gerektirebiliyor
Bu yüzden tahminden çok belirsizlik yönetimine odaklanıyorum
En güvenilir yöntem benzer projelerle karşılaştırmak
“Bu, X projesinden %20 daha karmaşık, o halde %20 daha uzun sürer” gibi
Ama bunun için geçmiş projelerin gerçek süre verisini düzenli tutmak gerekiyor
Başta “tahmin imkansızdır” görüşüne karşı çıkmak istemiştim ama aslında daha önemli olanın organizasyondaki rol olduğunu fark ettim
Ekip tahmine göre kapasiteye bakıp bunun imkansız olduğunu söylese bile takvim değişmiyor
Sonuçta işi kapsam daraltma ya da kalite taviziyle takvime uyduruyorsun
Bu yüzden “tahmin işe yaramaz” demek belki daha doğru
Tahminde asıl meselenin muğlaklık (ambiguity) olduğunu düşünüyorum
UI ince ayarı gibi küçük görünen ama gerçekte yaparken öğrenilen işler çok fazla
Tersine büyük bir değişiklik bile net tanımlanmışsa hızlı bitebiliyor
LLM çağında süreyi belirleyen şey değişimin büyüklüğünden çok belirsizlik düzeyi olacak