Yazılım projelerinde doğru efor öngörüsü için ipuçları

Efor öngörüsünde yanılma sebepleri

Bir yazılımcı, hangi durumlarda efor öngörüsünde yanılacağını düşünür?

1. Proje konusunda yeterli bilgi sahibi olmamak
2. Proje kapsamında planlanan işlerin süreç boyunca değişiklik göstermesi
3. Öngörünün içerdiği zamanın verimsiz kullanılması
4. Hesap edilemeyen noktalarda ortaya çıkan ek istekler
5. Proje sürecinde ortaya çıkan problemler
6. İyimser tahminler

Proje konusunda yeterli bilgi sahibi olmamak

Üzerinde çalıştığınız projeyi mutlaka tanımalı ve sizin açınızdan açık nokta kalmamasına dikkat etmelisiniz. Projeyi her yönüyle sorgulayın. Aklınıza takılan en küçük noktayı bile sorun. Kesin ve net cevaplar alamadığınız her belirsizliği ekibinizle de paylaşın. Kullanıcı senaryolarına ve bilgi mimarisine en az bir tasarımcı kadar hakim olmalısınız. Çünkü bu dökümanlar, sizin bir sistemi oluştururken en önemli referanslarınızdır. Bu dokümanların, sistemin işleyişiyle ilgili soracağınız tüm sorulara cevap verebilmesi gerekir. Bunların yardımıyla iş akışınızı ortaya çıkarabilir, yapacağınız işi hangi noktalarda bölümlere ayıracağınızı netleştirebilir ve proje üzerindeki riskli noktaların önemli bir kısmını proje başlangıcında öngörebilirsiniz.

Proje sürecinde ortaya çıkan değişiklikler, planlanmamış işler

Birçok projenin ilerleyişi sırasında, en başta yapılan çalışmalarda fark edilmeyen sorunlar ortaya çıkabilir ya da sonradan eklenen yeni özellikler veya ek işler istenebilir. Bu durum, hiçkimse tarafından istenmese de maalesef sıkça gerçekleşir. En başta belirlediğiniz efor öngörüsüne uymayan ya da onu aşacak kadar iş yükü çıkabilir. Bu senaryoyu tolere edilebilir olarak görmek, çoğu zaman bu gibi işlerin birikmesi nedeniyle, karşınıza altından kalkamayacağınız kadar büyük bir iş yükü çıkarır. Neyin tolere edilebilir olduğu konusunda kendi başınıza verdiğiniz kararlar, çoğunlukla sorumluluğun da sizde kalmasına sebep olur. Bu biriken işler, projeye ayrılan sürenin sonunda ortaya çıktığında ise artık sizden başka kimsenin yapabileceği bir şey kalmamıştır. Bir projeyi hayata geçirmenin bir ekip işi olduğunu asla unutmayın. Böylesi değişikliklerin getirdiği efor öngörüsü değişimiyle ilgili endişelerinizi o an ekiple de paylaşıp onların da fikrini almayı ihmal etmeyin.

Zamanın verimsiz kullanılması

Verdiğiniz zaman planına sadık kalmak, süreci doğru bir şekilde ilerletebilmek için çok önemlidir. Ancak mesai saati içinde her an aynı performansla çalışamayacağınız gerçeğini de kabul etmelisiniz. Hiçkimse sabit bir performans grafiğiyle tüm gün iş yapamaz. Gün içinde kendinizi yorgun hissettiğiniz ya da konsantre olamadığınız anlar olabilir. Efor öngörüsü verirken bu tür etkenleri dahil etmeden robotik bir tahmin yaptığınızda, plana uyma konusunda ciddi sorunlar yaşayabilirsiniz. Bazen küçük bir problemi çözmek için bile projenin tamamı için ciddi zaman kaybedebilirsiniz. Bu tip etkenler her zaman geçerli olabilecek durumlar. Efor öngörünüzde böylesi esneme paylarını göz önünde bulundurmayı unutmayın.

24 saatte yapacağınızı söylediğiniz bir iş, değişiklik gösterebilmekle birlikte, ortalama 3-4 gün içinde tamamlanacaktır. Sizin bunu 1 günde tamamlamanız ya da 3 gün boyunca hiçbir şey yapmayıp son gün içinde bütün işleri tamamlamak efor öngörünüzün doğru olduğu anlamına gelmez. Bu, size aşırı yorgunluk ve uykusuzluk olarak geri döner.

Benzer hatalar, mesai saatlerinin değerlendirilmesi konusunda da sıklıkla yapılır. Sabah 8 akşam 6 saatleri arasında çalışan birinin, gün içinde tam kapasite 10 saat çalıştığını iddia edebilmesi çok zor. Gün içinde tam olarak kaç saat odaklanmış halde çalışabildiğinizi ya da verimli bir şekilde bir günde kaç saat çalışabildiğinizi bilmeden verdiğiniz süreler, saat bazında doğru olsa bile gün olarak yanlış hesapladığınız için yine hata yapmanıza sebep olur.

Çözülmesi gereken yeni problemler

Yazılım konusunda ne kadar bilgili ve tecrübeli olursanız olun, mutlaka üzerinde çalıştığınız projede bir yerde takılıp kalabiliyorsunuz. Aslında tecrübenin esas devreye girdiği nokta da tam olarak burası. Panik halinde ne yapacağını şaşırarak etrafta dolaşmak yerine, gerçekten tecrübeli olan biri sakince önce sorunu doğru şekilde anlamaya çalışıp sonrasında sırayla çözüm yollarını deneyerek sonuca ulaşıyor.

Her ne kadar önceden bir planlama yapsanız da mutlaka bir noktada öngöremediğiniz hataların çıkabileceğini kabul etmelisiniz. Kendi iş yapış şeklinize bağlı olarak bu tip sorunlarla ne sıklıkla karşılaştığınızı ve bu sorunları ne kadar sürede çözebileceğinizi tahmin edebilirsiniz. Ayrıca sorunların genellikle hangi noktalarda çıktığı konusunda da önceden tahminlerde bulunabilirsiniz. Bunu önceden kestirebilmenizi sağlayacak sihirli bir değnek maalesef yok. Her şeyin mükemmel gideceği varsayımıyla, ortaya çıkabilecek bu tip sorunlar için efor öngörünüzde bir esneklik yoksa, bu sorunlarla uğraşırken yaşadığınız panik havası daha da fazla olacak ve normalde harcamanız gereken zamandan daha fazlasını kaybedeceksiniz.

İyimser tahminlerle yanılmak

İyimserlik yazılımcılar için kesinlikle bir meslek hastalığı olarak tanımlanabilir. Bazen yaptığınız bir işin çok iyi olması için uğraşırsınız. Ortaya çıkan sonuç beklenenden daha iyi olsa bile, aynı zamanda taahhüt ettiğiniz süreyi de çok ama çok fazla aşmışsanız, maalesef yaptığınız iş bu gecikmenin gölgesinde kalacaktır. 

İyimserlik hastalığı projeyle ilgili başkalarını bilgilendirirken ağzınızdan çıkan kelimelerde bile etkisini gösterir. Çalıştığım bir projede, hangi aşamada olduğumuzla ilgili sorulan her soruya en az 5 defa “sadece” diye başlayan  cümleler kuruyordum. Bitti ama sadece A iş kaldı. Bitti, ama sadece B işi kaldı. Bu çok kötü bir durum çünkü sadece dediğiniz şey 2 gün sürebiliyor. Bu da proje genelindeki sapmayı daha da artırıyor.

Doğru bir efor öngörüsü için yapılması gerekenler

Yukarıdaki durumları göz önünde bulundurarak, bunların proje sürecine etkisini en aza indirmek için neler yapabiliriz?

Gerçekçi olun

İnanın, iyimser olmanın kimseye faydası yok. Her ne kadar iyi niyetli olarak projenin durumunu ya da müşteri isteklerini düşünerek efor öngörüsü verdiğinizi düşünseniz de işin sonunda eğer taahhüt ettiğiniz planlamaya sadık kalamazsanız iyimserliğinizin bir anlamı olmayacak. Kullanıcı senaryoları gibi yönlendirici dokünmanları kullanarak işi, gerçekçi efor öngörüleriyle ayrıntılı ve detaylı bir şekilde bölümlere ayırın. Bu bölümlerin ne kadar sürede tamamlanacağıyla ilgili zaman birimlerini ayrı ayrı ekleyin ve toplamda ne kadar süreceğini çıkartın.

Gerçekçi olma konusunda iki önemli nokta var: Sizden efor öngörüsü istendiğinde hemen cevap vermeniz gerektiği anlamına geldiğini düşünmeyin. Öngörünüzü paylaşmak için de bir efor harcamanız, projeyle ilgili dökümanları incelemeniz ve bir planlama yapmanız gerektiğini unutmayın. Eğer zamanlamalara dikkat eden bir ekiple çalışıyorsanız, hiç kimse sizden böyle bir şey beklemez, aksine hemen verdiğiniz efor öngörünüzün garip olduğunu ve tamamen farazi bir tahmin olduğunu bileceklerdir.

Zaman planı yapmaya başlarken “Ne zamana bitmesi gerekiyor?” sorusunu asla sormayın. Önceliğiniz, bu işi sizin ne kadar sürede bitirebileceğinizi ortaya çıkarmak olmalı. Sonrasında bu işin ne zamana kadar bitmesi gerektiği konusunu ekip olarak konuşabilirsiniz.

Efor öngörülerini ekip olarak değerlendirin

Verdiğiniz öngörülerin, tümüyle sizin işinizle alakalı olsa da, aslında bütün ekibi etkilediğini unutmayın. Efor öngörülerini mutlaka çalıştığınız ekip ile birlikte belirleyin. Özellikle backend ve frontend olarak iki farklı yazılım süreci varsa, efor öngörüsü konusunda her iki ekibin de ortak hareket etmesi çok önemli. Bireysel olarak verdiğiniz kararların, projenin geri kalanını nasıl etkilediğini de bilmelisiniz. Aynı zamanda, planlamaya uymayan noktaları bütün ekiple birlikte optimize etmeniz çok daha kolay olacaktır.

Test ve proje yönetim süreçlerini de düşünün

En sık yapılan hatalardan birisi de yazılım geliştirme süreciyle ilgili efor öngörülerine, süreç içindeki değerlendirmeleri, test süreçlerini, testler sonucunda ortaya çıkacak hataların düzeltilmesiyle ilgili harcanan zamanları en başta dahil etmemektir. Bu yazılım geliştirme sürecine dahil edilmese de proje sonunda harcanan süreye dahil edilir. Yazılım geliştirme içine dahil edilmese bile, mutlaka test süreci adıyla bu adımlar için de bir efor öngörüsü paylaşın. Bu, belki de tahmin edilmesi en zor olan kısımdır. Test ve sonrasındaki bugfix süresi tahmin edilebilir değil, ancak yine de bu işler için de hatırı sayılır bir zaman ayırmanız gerektiği gerçeğini göz ardı etmeyin. Önceki çalışmalarınızda harcadığınız süreler size bir referans olabilir.

Zaman aralıkları ve sprintler halinde çalışın

Efor öngörülerinizi kısa vadeli tutmaya çalışın. 1 ay sürer, 3 ay sürer gibi herhangi bir dayanağı olmayan tahminler hiçbir zaman gerçeği yansıtmayacak. En ayrıntılı ve doğru öngörülerin, ortalama 30-40 saat arasında verilebileceğiyle ilgili görüşler var. Bu yüzden sprintler halinde çalışmak işinizi kolaylaştıracaktır. Bir sprintteki küçük bir sapmayı, bir sonraki sprint içinde düzeltmek, bunun proje sonunda bir çığa dönüşmesini baştan engellemenizi sağlar.

Efor öngörüleriniz için birim zaman belirleyebilirsiniz. Örneğin; bir birimlik zamanı 0.5 saat (30 dakika) tanımlayabilir, bunun katları halinde öngörü paylaşabilirsiniz. Bu yaklaşım size, kısa süreli zaman harcayacağınız işler için de bir referans noktası sağlayabilir.

Kendinizi test edin

İyimser tahminlerden vazgeçip kendinize ve ekip arkadaşlarınıza karşı gerçekçi olun. Bu yazıda değinilen şeylerden hiçbiri sorununuza maalesef kesin bir çözüm olamayacak. Bunları, zaten denemiş ve işe yaramayacağını da düşünüyor olabilirsiniz. Haklısınız. Ancak bu yine de imkansız olduğu anlamına gelmiyor. Doğru planlama, tamamladığınız her işten sonra kendi adınıza bütün süreci gözden geçirmenize ve hatalarınızı tespit edip düzeltmek için yeni yollar denemenize bağlı.

Aşağıda Stack Overflow ve Quora‘dan, yazılımcıların nasıl doğru zamanlama verebileceğiyle ilgili tartışmalara ait iki linke yer verdim:

• How to respond when you are asked for an estimate?
• How important it is to accurately estimate software projects?

Benzer platformlarında yer alan efor öngörüsü odaklı tartışmaları incelemenizi tavsiye ederim. Diğer yazılımcıların kendi süreçlerini nasıl test ettiği, bunlardan neler öğrendiği, öngörü paylaşma ile ilgili sorunları nasıl aştığı konusunda size daha fazla ışık tutacağını düşünüyorum.

Yazılım projelerindeki belirsizlikler her zaman var olmaya devam edecek. Her zaman umulmadık bir yerde çıkan sorunlarla boğuşurken bulacağız kendimizi. Ama bu işi yapma sebebimiz de aslında çoğu zaman bu değil mi? Bir sorunla boğuştuktan sonra bulduğumuz çözümün bize yaşattığı heyecan bu işe hâlâ devam etmemizi sağlayan güç aslında.

Efor öngörüleriyle ilgili sorunlar, işimiz sorun çözmek iken, çoğu zaman işimizin hayatımızın bir numaralı sorunu haline dönüşmesine sebep olabiliyor. Problem çözmenin keyfini yaşamaya devam edebilmek ve ayrıca gerçekçi ve net bir planlamayla çalışabilmek için doğru efor öngörüleri geliştirme konusunda kendimizi zorlamalıyız. Böylelikle zamanımızı sonsuz döngüye girmiş süreçler içinde harcamak yerine öğrenmenin asla sonlanmadığı yazılım dünyasında daha keyifli geçirebiliriz.