Ne zaman biter? sorunsalı
Yazılım projeleri için zaman tahminleme yöntemleri
Yıllar önce çalıştığım bir firmada 6 haftada bir günü planlamaya ayırıp tüm gün post-it notların duvara yapışık kalması için savaş veriyorduk. Bu sıkıcı günü eğlenceli hale getirmek için açık büfe kahvaltılar mı dersiniz, bir sürü oyunlar mı dersiniz hepsini denemiştik. Hatta bu toplantılar ofiste değil, bir otelin balo salonunda yapıyorduk ve güne her takım 6 haftalık başarılarını sunarak başlıyor sonrasında da bu toplantıdan ne beklediklerini anlatıyorlardı. Sonra post-it notlara elimizdeki büyük işleri yazıyor ardından da ekiplerin birbirlerine olan bağımlılıklarını gözden geçiriyorduk.
Bu toplantıların en stresli zamanı sonundaki “Ne zaman biter?” kısmıydı. Özellikle büyüme aşamasındaki bir firmada çalışıyorsanız takımların birbirine olan bağımlılıkları, herhangi bir küçük projeyi bile karmaşık bir entegrasyon projesine dönüştürebiliyor. Yine bu toplantıların birinde, önemli bir proje hakkında firmanın CTO’su Daniel’a beklenen o can alıcı soruyu sordu: “Ne zaman biter?”. Dan’ın cevabı otelin balo salonunda biri ölmüş gibi bir sessizlik yarattı: “İyimser olursam 2 ay, kötümser olursam 5 ay, ama gerçekçi olursam bilmiyorum 🤷♂️”.
Dan, verdiği cevabın bu kadar büyük bir sessizlik yaratacağını düşünmemiş olacak ki kısa bir süre sonra arkasına dönüp salonda hala birileri var mı diye kontrol ihtiyacı hissetmişti.
Bence Dan söylediğinde haklıydı. Gerçekten de projenin ne kadar süreceğini bilmiyordu, zaten bir günlük yorucu bir maratonun ardından bunu kestirmek için yeterli bir zamanı da yoktu. Fakat bu bizi gerçekten süre tahmini konusunda durdurmalı mıydı? Yani sormak istediğim soru aslında, süre tahmini yapmanın gerçekten bir faydası yok mu?
İsterseniz bu sorulara cevap aramadan önce gelin süre tahmini yapmanın neden zor olduğunu biraz tartışalım.
Unutmadan! Codefiction Akademi adı altında Deniz İrgin ile birlikte yepyeni bir Teknik Liderlik eğitimine başlıyoruz. Ayrıca, blog’u okuyanlara özel %25 indirimle! Ay sonuna kadar “TBLOG25” kodunu kullanarak eğitime indirimli kayıt olabilirsiniz!
Günümüzdeki yazılım problemlerini düşündüğümüzde, bir çok hareketli parçadan ve çok karmaşık teknolojilerden oluştuğunu görüyoruz. Dolayısıyla geliştirme yaparken, çoğu zaman yapılacak geliştirmenin yan etkilerini kestirmekte zorlanıyoruz. Çünkü bu bağımlılıkların bilinçsel olarak hesaplayamayacağımız kadar çok kombinasyonu olabiliyor. Tabii işin içine bir de insan psikolojisi girdiğinde, iyimserlik eğilimi (optimism bias) ile birlikte başımıza gelecek kötü senaryoları düşünmek de çok zorlaşıyor. Bu yüzden çoğu zaman bir projeye başlarken, her şeyin her zaman iyi gideceğini düşünüyoruz. Ancak kuvvetle muhtemelen, hiçbir zaman hiçbir şey iyi gitmiyor ve karşımıza sürekli farklı sorunlar ve sonrasında daha da başka sorunlar çıkıyor. Daha önce sizlere yazılımcılar için proje yönetimi adlı yazıda belirsizlik konisinden bahsetmiştim. İşte şimdi ona referans vererek yeniden aynı konuyu biraz daha derinlemesine inceleyeceğim.
Kaçıranlar için kısa bir özet vermek gerekirse, yukarıda saydığım sebeplerden dolayı optimum bir yazılım projesinde zaman ilerledikçe yani projenin sonuna yaklaştıkça zaman tahminlerinin daha iyiye gittiğini gözlemlemek mümkündür. Yani eğer çok iyi tanımlı bir proje değilse -ki böyle bir proje ne gördüm ne duydum- süre tahmini konusunda ancak ve ancak projenin sonu yaklaştığında iyi olmaya başlarız. Peki bu bilgiyi nasıl pratiğe uygulayabiliriz?
Bir projeye başlarken belirsizlikleri ve riskleri iyi analiz etmek ve bunları önceliklendirerek işe başlamak o proje için en önemli hazırlıktır desem yeridir. Böylece projenin başlangıcında bu belirsizlikleri hedefleyerek, tahmin edilebilir işleri ileriye bırakırsınız. Yani optimum dengeyi sağlayabilirsiniz.
Bunu şöyle de düşünebilirsiniz, elinizde cam bir kavanoz olsun. Bu kavanozu büyük ve küçük taşlarla ve kum ile en optimize şekilde doldurmak istiyorsunuz. Eğer kavanozu önce kum ile doldurursanız, belirsizliği yani büyük taşların sığıp sığmayacağını sona bırakmış olursunuz. Eğer şanssızsanız, -ki büyük ihtimalle her zaman öyle olduğunuzu varsayın- büyük taşlar kavanoza sığmayabilir.
Alternatif olarak büyük taşlarla kavanozu doldurmaya başlayıp ardından küçük taşları ve en sonunda kumu yerleştirmeye başlarsanız kavanozu daha optimize bir şekilde doldurmanız mümkün olur. Ya da en kötü ihtimalle artanlar büyük taşlar değil, kum ya da küçük taşlar olacaktır.
Bu benzetmedeki büyük taşlar, belirsizliği olan iş paketleri ve kum ise ne olduğunu bildiğimiz tahmin edilebilir iş paketleri diyebiliriz.
Bunu projeye uygularsak öncelikle başlanması gereken işler genelde en belirsiz olan işlerdir böylelikle projede tahmin edilebilirliği arttırmış oluruz. Ancak insanlar doğası gereği ilk başta en kolay ya da tahmin edilebilir işlerle geliştirmeye başlarlar. Böylece aşağıdaki gibi belirsizlik konisi elde etmiş oluruz.
Yani belirsizlik zaman içinde azalıyormuş gibi bir yanılgı yaratıyor olsa da sonra tekrar artmaya devam edecektir. Halbuki optimize olmak istediğimiz projenin belirsizliğinin zaman içinde azalmasıydı. Bu projeler genelde upuzun bir kuyruğa sahip projelerdir. Yani proje kırmızı dairenin olduğu yere gelene kadar çok güzelken, bir anda uzamaya başlar. Hatta öyle olur ki, proje hiç bitmez. İşte kırmızıyla işaretli yer, dağın arkasında bulutlardan dolayı daha önce görmediğimiz daha yüksek ikinci tepeyi keşfettiğimiz andır. Bundan sonrası artık sürekli “iki hafta kaldı” bekleyişine dönüşmeye başlar ve bununla birlikte ekip güven kaybetmeye başlar. Yöneticiler huzursuzlanmaya başlarlar, stres artar ve “kebabına fazla mesailer” hayatımıza geri döner.
Bu gibi projelerde, kırmızı daireden bir kaç hafta sonra, özellikle tecrübesiz ya da iş bilmez yöneticilerle çalışıyorsanız size ilk soracakları soru “Daha fazla yazılımcı eklersek işler hızlanır mı?” olacaktır. Bir noktadan sonra risk almaktan korkarsanız dümeni yöneticiye verirsiniz ve o da sahte bir kontrol hissiyle hayatına devam eder. Ancak projeye yeni birilerini eklemek çoğu zaman iletişim anlamında daha fazla karmaşıklık getirmekle birlikte işleri daha da zorlaştıracak ve belki de içinden daha zor çıkılacak bir hale dönüştürecektir.
Peki süre tahmini yapmayalım mı o zaman?
Bence yapalım. Ama süre tahminlerinin aslında neden birer “deadline” olmaması gerektiğini anlamışsınızdır diye düşünüyorum. Dan’in de söylediği gibi, gerçekçi olmak gerekirse aslında bilmiyoruz.
Süre tahmini yapmanın en önemli getirisi bu riskleri tartışmak ve belirsizlikleri ortaya çıkartmaktır. Çünkü çoğu zaman bu tartışmaların derinine inmek için detaylı bir şekilde düşünmek gerekmekte, bir tahmin yapmak da bu tartışmaların hızlı bir şekilde ilerlemesine yardımcı olmaktadır.
Özetlemek gerekirse;
Yazılım projeleri belirsizliklerle doludur.
İnsanların çoğu zaman iyimserliğe eğilimleri vardır. Başlarına kötü bir şey geleceğine ihtimal vermek istemezler. Bu yüzden bütün süre tahminleri yanlıştır.
Sağlıklı bir proje yönetimi için, belirsizliğin ya da zorluğun fazla olduğu yerlerden projelere başlamak gerekir.
Süre tahmini yapmanın, eğer deadline olmadığı göz önünde bulundurulursa, projeye faydası vardır.