Yazılım sektörü nispeten yeni diyebileceğimiz, şurada olsa olsa 40 – 50 yıllık bir geçmişi olan, ancak son 20 – 25 senede daha yoğunlaşmış ve son zamanlarda yapay zekâ, dijitalleşme ve mobilizasyon sayesinde çok daha fazla ilerlemiş bir sektördür. Bu sektöre rahatlıkla “yeni” diyebiliriz, çünkü örneğin inşaat sektörü gibi eski sektörler 2000 senedir var ve çok daha net ve oturmuş süreçlere sahip. “Yazılım sektörü olgunlaştı mı?” derseniz, bence hayır. Sürekli yeni metodolojiler ve yaklaşımlar ile kendisini geliştiriyor.

Bu makalede bence bu sektörde henüz tam olgunlaşmamış olan bir konuyu, proje ve ürünler için zamansal tahminleme bahsini ele alacağız. Ancak zamansal tahminlemenin teknik boyutu konusunda bilimsel metotları tartışmayacak veya bu bilimsel metotların eksik / fazla noktalarına değinemeyeceğiz. Bunun yerine işin psikolojik ve hissiyat tarafına odaklanıp, bilimsel olmayan yönleri ele alacak ve sektörde bulunanların karşılaştığı ama genelde yazıya dökülmeyen bazı durumları irdeleyeceğiz.

Tahminin Ortaya Çıkışı

Bir proje ancak kendisine atanmış bütçe dahilinde ve söz verilen zaman aralığında tamamlanmışsa başarılı kabul edilir. Söz verilen zaman aralığı kelimesi çok önemlidir, buradaki söz neye göre verilir? Söz verirken nelere dikkat edilir? Gerçekten tüm parametreler irdelenerek ve proje büyüklüğüne göre mi verilir?

Tahminleme, en çok bilinen yöntemlere (Top-Down Estimate, Bottom-Up Estimate, Analogous Estimating, Parametric Estimate gibi) göre, yani bilimsel bir şekilde yapılması gerekir ama genelde öyle yapılmaz. Bazen hedef tarih CEO’nun aklındaki lansman tarihi de olabilir, sponsor olan GMY’nin doğum günü de olabilir veya bir devlet büyüğünün doğum günü de olabilir (Üstten Gelen Tahminler). Bazen de tamamen firmaların rekabetinden dolayı ortaya bir tarih çıkabilir (Rekabetsel Tahminler). Fixed Price bir ihalenin alınmış olması da tahmini kısıtlayabilir, yani tahminin içerisinde bütçe kısıtı vardır (Bütçe Kısıtlı Tahminler). Ya da bazen alttaki herhangi bir proje sorumlusunun hırslı bir karakter olduğu için verdiği veya üst yönetime karşı iyi bir intiba sağlamak için verdiği zorlama bir tarih de olabilir (Fazla Zorlayıcı veya İyi İntibaya Yönelik Tahminler). Bu tip bilim dışı örnekleri çoğaltmak mümkün.

Tahmini Talep Eden ve Tahminleme Yapan Kişinin Durumu

Yazılım tahminini yaparken bir tahmini talep eden kişi, bir de tahminleme yapan kişi vardır. Tahmini talep eden kişi bir proje veya bir ürün nedeniyle bunu sorar. Yani bütçesi bazen net, bazen ortalama olarak belli, ne koysam ne alırımın hesabı kabaca yapılmış, başa baş noktası nedir, kâr nasıl olur, sermaye kârlılığı nedir gibi konulardan üç aşağı beş yukarı geçmiştir. Böylece tahmin küçük firmalarda sermayedarın kendisi, büyük firmalarda ise bir proje yöneticisi / ürün yöneticisi vs. vasıtasıyla ilgili teknik kişiye veya ilgili teknik takıma sorularak yapılır veya bu şekilde yapılması gerekir. Ancak tahmini talep eden kişi bilimsel olmayan yaklaşımlar veya proje kısıtları nedeniyle birçok kez tahmini köşeye sıkıştırma eğilimine girer. Özellikle aşırı hedef odaklı karakterler bunu çok yaparlar.

Teknik ekip veya teknik bir kişi ise işi tahminler. Tahmin ederken de genelde “şu kadar süre içerisinde tahmini iletin” diye sıkıştırılır, yani bir işe muhtemelen kısıtlı bir süre vermek için, yine süre kısıtlı bir iş yapmanız gerekecektir. Burada “çok verirsek yöneticimiz / iş verenimiz bunu fazla bulacaktır”, “az verirsek de işi yaparken sıkıntı yaşarız” gibi psikolojik durumlar oluşabilir. Eğer amir işin teknik boyutunu biliyorsa, bu sefer süre konusundaki tahmin hatalarını rahat anlar. Ancak takımın paralelde yaptığı aktiviteleri göz ardı eder veya haberi yoksa bu durumda takıma baskı kurarak yanlış da yönlendirebilir. Bu durumda teknik takım artık bu işler böyle oluyor herhâlde havasına girip “ne vereyim abime” yaklaşımına geçiş yapar. “Bunları ben de yaşadım” dediğinizi duyar gibi oldum şu an.

Agile gibi modern yaklaşımlarda ise tahminleme konusu için işi daha küçük parçalara ayırıp ona süre veya efor tahmini verme metodu seçilmiş olsa da o meşhur master planlar hep vardır ve şirketler genelde mikroyu makroya uydurmak için ellerinden geleni yaparlar. Mikrolar, bu canavar makrolar tarafından yutulmak istenirler, bazen de yutulurlar. Bu nedenle takım yavaş yavaş agile ritüellerinden bile vazgeçmeye başlar.

Tahmine Uyması Gereken Kişilerin Durumu

Tahminin %100 bir kesinlik arz edemeyeceği çabucak unutulma eğilimindedir. Adı üstünde, “tahmin”. Ancak tahmin genellikle şirketlerde vaat gibi algılanır ve bazen özür kabul edilmez ve o tarih tutturulması için elden gelen her şeyin yapılması istenir. “Tutturamayacaktınız madem en başından daha mantıklı bir süre söyleseydiniz” gibi duygusal proje yönetim yaklaşımları da ortaya çıkabilir. “Bu işi şu kadar sürede yapmak zorundayız” cümlesinin muhatabı da tahmine uyması gereken kişilerdir (“sınız” ile karşıyı işaret eden ekler değil de “yız” gibi hep birlikteyiz tarzı cümleler yumuşatma cümleleridir ama sonuçta işi yine proje ekibi yapar :))

Bir de tahmine uyması gerekenler tahminleme yapanlardan değil ise bu durumda tahminleme yapanların kulakları bol bol çınlatılır. Oysaki tahminleme sürecine mümkün olduğunca tüm paydaşlar dahil edilerek bu gibi bir durumun oluşmasının önüne geçilmelidir.

Tahminlemelerde yapılan önemli bir hata ise kişilere göre değil de işe göre tahminleme yapmaktır. Eğer örneğin alt alta 100 tane for döngüsü açıp 1’den 100’e kadar ekrana çıktı veren bir kod yazacaksanız tüm developer’lar için bu efor hemen hemen aynıdır (bu bile değişir ki code snippet konusunda bile çok hünerli developer’lar vardır). Ancak iş UI’dan başlayıp backend’e gidip, veri tabanı manipülasyonu vs. içeriyorsa veya karışık bir security sorunu çözüyorsanız tahmine uyması gereken Ahmet veya Fatma’nın işi yapıyor olması işin süresini değiştirecektir. Bu işin çok fazla parametresi vardır. Fabrikada kutu paketleme gibi %99 ne kadar süreceği bilinen bir şey değildir yazılım işi.

Tahmin Tutar Mı?

Küçük işlerin tahminleri genelde tutsa da genel ürünün tahmini ekseriyetle proje sonlarına doğru güncellenir ve nihai tahmin neredeyse hep başarısız olur. Başarılı oldu dediğinizde ise hep bazı feature’lar sonraki fazlara bırakılmıştır. Çünkü herkes pazara çıkma derdindedir. Yani iş önce büyük bir hedef ile başlar, sonra eldeki ile pazara çıkmanın daha doğru olacağına ve rakiplerden önce davranmak gerektiğine karar verilir. Bu da normaldir.

Sonuç

Gerçekten çok parametreli bir konuyu ele aldık. Peki bu kadar düşünceden sonra, işin başında normal süreyi vermek gerektiğini mi anlamalıyız? Bu da doğru değildir. İnsanın sınırları ve kapasitesi bazen çok yukarı çıkabileceği için, iş daha gerçekçi ve uzun süre yerine daha zorlayıcı ve kısa sürede de bitebilir. Aşağıdaki grafik bu cümleyi görsel olarak açıklamaktadır. Önden sıkı hedef verilen ve her ne kadar tutmayacağı belli olan bir işin, normal bir hedefe göre daha önce biteceği (genelde) ortadadır. Ancak burada dikkat edilecek mevzu işin psikolojik bariyerini aşıp, takımın veya kişilerin dağılmasına neden olmamaktır.