Yazılımda Maliyet Belirleme
Bu yazı dizisinde “Yazılımda Maliyet Belirleme” konusunu ele alacağım. Geliştirilecek bir işlevselliğin veya bir projenin maliyetinin belirlenmesi (yapılacak işin büyüklüğünü belirleme) işinin nasıl gerçekleştirilebileceğine, iyi pratiklere, maliyet verme işinin maliyetine, tahmin işinin ne kadar gerekli ya da gereksiz olduğuna değineceğiz. Ayrıca geleneksel proje yönetimini kullanan organizasyonlarda karşılaştığım birkaç örneği paylaşacağım.
İşlevselliklerin ya da projelerin maliyeti belirlenirken birkaç yaklaşım dikkatimi çeker:
- Üst yönetim bunun için herhangi bir bitiş tarihi belirledi mi? Sanki üst yönetimdeki kişiler bu projeyi geliştirecek! Tarihi bu kişiler belirlerse işi gerçekleştiren kişiler daha hızlı üretme yetkinliğine kavuşacak gibi-evet, evet…pazara çıkış zamanı vb. şeyleri aklınıza getirdiğinizi biliyorum-… Belki tarih belirlenebilir fakat takımdaki kişilerin görüşleri alındıktan sonra gerçekçi bir tahmin yapılarak.
- Teknik lider ya da mimar olan kişilerden işin büyüklüğü bilgisi istenir. Araştırılmadan ve tahmin yapabilecek kadar bilgi sahibi olunmadan bu soruya cevaplar dönülür.
Aziz Nesin hikayesi olabileceğini düşündüğüm birkaç örnek
Kredi Başvurularının Raporlanması Projesi
Örneklerden ilki kredi başvurularının raporlanması projesidir. Bu proje için verilen maliyeti takım lideri, kaynak yöneticisine 2 kişiyle 22 adam/gün yani 1 ay olarak iletti. Kaynak yöneticisi, Proje Yönetim Ofisi’yle bu bilgiyi paylaştı ve proje planının bu şekilde oluşturulmasını istedi. Maliyet belirlenirken özen gösterilmemiş, yapılacak işler yeterince düşünülmemişti. Takım liderine göre yapılacak iş input ve output tablolarının veri ambarına alınması ve iş zekası aracı üzerinden gösterilmesiydi.
Analist Ağlatan Yöntem
Geleneksel proje yönetimi ile geliştirilecek olan bu projenin ikinci gününde anlaşıldı ki projenin analiz dokümanlarının içi boştu. ☺ İşin garip tarafı işin maliyetini veren takım lideri bu dokümanları açmamıştı. Çünkü açsaydı analiz dokümanlarının sadece adının verildiğini ve içinin boş olduğunu görürdü. Bu konuyla ilgili olarak iş biriminden bir arkadaşın, analist, kodu yazacak kişiler ve takım liderinin olduğu bir toplantı yapıldı. Toplantıda analiste yüklenilmemesine rağmen sorulan ilk soru da ağlamaya başladı. “Bir daha bu projenin toplantılarına katılmayacağım” diye ağlayarak toplantı odasından çıktı. Geleneksel proje yönetiminin statik ve sıkıcı çizgisinde böyle aksiyonlar görmek herkesin biraz adrenalin salgılamasına ve yaşıyor hissetmesine neden oluyor. Ne mutlu!
Bu toplantıdan sonra ilk önce işin analizinin bitirilmesi gerekti. Analizi bitirdikten sonra kodlama başladı. Kodlama başladıktan sonra ilk düşünüldüğü gibi 1 aylık bir iş olmadığı görüldü. Analiz bölümünü 1 ayda bitirebilmiş ve 2 aydır kodlamasıyla uğraşıyorlardı ki iş biriminden analize yardım eden – tek bilgi kaynağı – arkadaş istifa edip işten ayrıldı. Yine çok iyimser olarak zaten işin büyük çoğunluğunun bitirildiği düşünüldü, kalan bölümün hazırlanan analiz dokümanlarında olduğu ve buradan okuyarak kalan bölümün rahatça tamamlanacağı düşünülüyordu. Ne yazık ki bu iyimser düşünce çok naifti ve ömrü uzun olmadı. Analiz dokümanında olmayan ilk konu iş birimindeki arkadaşlara sorulduğunda şimdiye kadar geliştirilenlerin tam tersi olan bir cevap alındı. Konu biraz daha irdelendiğinde neredeyse üç aydır yanlış şeyler yapıldığı ortaya çıktı. Daha sonra ise iş birimi ve geliştirme ekibi arasında çetin bir mücadele başladı. Geliştirme Ekibi:
– Bakın siz böyle olması gerektiğini söylüyorsunuz fakat analizini yaparken arkadaşınız şöyle dedi.
Herkesin İş Yapış Şekli Farklı
Anlaşılan o ki iş biriminde çalışan herkesin kendi tarzında bir iş yapış şekli vardı. Geliştirme ekibi işten ayrılan kişinin iş yapış şeklini analiz etmişti. Bitiyor diye düşünülen proje neredeyse baştan başladı. İş birimi dilinin anlaşılması tek artıydı. Geliştirme ekibi başlanılan konumda değil biraz önündeydi. Bu şekilde bazı bölümler için yeniden analizler yapıldı. Yeni analizlere göre geliştirmeler tamamlandı. Kullanıcı kabul aşamasından dönen hatalar iş birimiyle beraber oturularak çözüldü.
Sonuçta ilk tahmine göre bir ayda bitecek olan proje altı ayı geçtikten sonra üretim ortamına alınabildi. Yani verilen ilk maliyetin altı katı bir zaman geçmişti.
İkinci örneğim ise en az birinci örneğim kadar absürt ve biliyorum ki birçoğumuz bu şekilde çalışmak zorundayız. Bu projelerin içinde yer alarak yaşamaya çalışıyoruz.
Risk Projesi
Bu proje, bir bankanın müşterilerinin, beraber çalıştığı bankaların ve ülkelerin risklerini hesaplayarak geleceğe dair tahminler yapılabilmesini sağlıyordu. Projede dört yüz elliden fazla kaynak tablo ve iş zekası aracı ile alınacak seksenden fazla rapor bulunuyordu.
Bir dış firmaya verilen bu projenin maliyeti ise adam/gün metriğinde dört kişi ile dört ay olarak belirlenmişti. Maliyeti belirleyen kişi konu üzerine Türkiye’nin büyük üniversitelerinden birinde hocalık yapan firmanın büyük ortaklarından biriydi. Öte yandan takım lideri ve kaynak yöneticisi projenin altı kişi ile altı ayda geliştirilebileceğini öngördü. Takım lideri ve kaynak yöneticisinin yanılma paylarını da hesapladığımızda, projenin bitirilme süresi 6 kişi ile 6 ay ve % 600’lük(ilk projede 6 aylık bir projeye 1 ay tahminde bulunduklarını söylemiştim) yanılma payı ile 216 ay olur.
Bunları anlatmamın nedeni, işin uzmanı gibi görülen kişilerin tahminlerinde ne kadar yanılabileceklerini göstermektir.
Bu proje gerçekten dört geliştiriciyle başladı. İlk ayı biraz ortama alışmakla geçirilen projenin ikinci ayına girildiğinde işler yoğunlaştı. Dış firmanın proje yöneticisi geliştirici arkadaşların tepesine bindi! Gece 04:00’lere kadar haftalarca çalışıldı. Üçüncü ayın sonunda ise işin analizi bile bitmemiş, kodlamaya hiç geçilmemişti. Geçen bu süre içinde kazanılan değer sıfırdı.
Bankacılık literatürüne sahip, işi bilen ve kurumda uzun zamandır geliştirme yapan 6 tecrübeli kişiyle 6 ay süre verilen bir projeye, dış firma, 4 yeni mezun ile 4 ay süre verdiğinde iş biriminde çalışan kişilerin bunu sorgulaması gerekirdi.
Bilgi Teknolojileri Organizasyonunuz
Bilgi Teknolojileri organizasyonunuza güvenmiyor olabilirsiniz. Onların beceriksiz ve bir şey bilmediğini, isteklerinizi zamanında karşılayamadıklarını düşünebilirsiniz. Hatırlamanız gereken bugüne onlarla geldiniz ve beceriksiz bile olsalar size bir şeyler üretebiliyor, işlerinizi kolaylaştırabiliyorlar. Diğer bir konu ise dışarıdan bir firma gelecek, size bir ürün geliştirecek ve geliştirme işi tamamlandıktan sonra gidecek. Siz, yine beğenmediğiniz Bilgi Teknolojileri organizasyonunuzla baş başa kalacaksınız. İsteklerinizi yine beğenmediğiniz Bilgi Teknolojileri organizasyonu karşılamaya çalışacaktır. Gördüğünüz üzere Bilgi Teknolojileri organizasyonuna güvenmektense çılgınca tekliflere açık olunabiliyor. Bu da Bilgi Teknolojileri ’ne güvensizliğin ne kadar büyük olduğunu gösteriyor.
Projeye geri dönersek üç ayın sonunda işlerin ilerlemediği bankacılık literatürüne hakim olmayan ve yeni yeni meslek edinmeye çalışan dört kişi ile – buraya özellikle değinmek istiyorum, projenin gecikmesinin nedeni bu arkadaşların eksiği ya da hatası değil tam tersine çok bilmiş hocanın bir bankayı daha müşteri olarak bağlama isteğinde ve buna inanan iş birimi, proje yöneticisi ve proje sponsorundadır- bu işin dört ayda bitirilemeyeceği anlaşıldı. Dış firmanın üstün nitelikli proje yöneticisi kurumda çalışan kişilerden gerekli bilgiyi alamadıklarını, kurumda çalışanlar ile firmalarında projeyi geliştiren kişiler arasında iletişim kanalı olacak tecrübeli bir kişi ile işlerin çok daha kolay bitirilebileceğini iddia etti. Bu tecrübeli kişinin desteğiyle projenin iki ay uzamayla toplamda altı ayda bitirilebileceğini öngördü, elinde veri olmadan!
Steering Toplantısında Kavga
Bu projede birçok gerginlik yaşandı. Proje ilk yılını doldurduğunda bir steering toplantısında firma ortaklarından biri ve iş biriminden bir müdür kavga etti. Dış firma yöneticisi, iş birimi müdürünü yalancılıkla suçladı. Suçlamanın yapıldığı konuysa iş birimi yöneticisinin “bizim böyle böyle isteklerimiz vardı fakat bunların yapılmadığını görüyorum dolayısıyla ben bu projeyi kabul etmiyorum ve ödeme yapmıyorum” demesiydi. Dış firma yönetici ortağı, iş biriminin “böyle böyle istekleri” olmadığını ve bu isteklerin proje kapsamında bulunmadığını söyledi. Yalancılıkla suçlanan müdür çalışan arkadaşlarına dönerek azarlayan bir tonla “bütün yazışmalar tek tek kontrol edilecek ve o e-posta bulunacak” dedi. Haksız değildi, istekleri karşılanmamıştı ve işine yaramayan bir ürünü kabul edemezdi.
Bu projenin geliştirilmesinde on dört farklı kişi çalıştı. Bu sayıya iş biriminden destek verenler, proje yöneticileri ve Bilgi Teknolojiler’inde çalışıp destek verenler dahil değildi. Projede çalışan sayısı sürekli olarak dört-altı aralığında tutulmaya çalışıldı. Projede üç ay çalışan kişi istifa edip kaçıyordu. Sürekli bir proje yöneticisi baskısı, her akşam “hadi size pizza ısmarlayayım da bu akşam biraz şu şu konulara bakalım ve ilerleyelim” yaklaşımı insanları kaçırıyordu. İşin garip tarafı aylarca bu şekilde çalışan kişilere fazla mesai ücreti ödenmiyordu. Motivasyonlarını kaybetmeden ve sosyal hayatları olmadan çalışmaya devam etmeleri bekleniyordu. Muhtemelen projede çalışan dört yazılım geliştiricinin toplam maaşı kadar ücret alan proje yöneticisi işini çok iyi bildiğini ve yaptığını düşünüyordu. Hata sayısı on ikinci ayın sonunda dokuz yüzün üzerinde olan proje on sekizinci ayın sonunda on dört farklı geliştiricinin ortak emeğiyle üretim ortamına alındı.
İsraf
Yapılan çok büyük bir israftan söz etmeden geçemeyeceğim. Bu proje bir veri ambarı projesiydi. Veri ambarı tabloları genelde özet tablolar yapılarak bir iş zekası aracı kullanılarak son kullanıcıya açılır. Farklı iş zekası araçları farklı yapıdaki tablolardan beslenir. Projenin altıncı ayının sonunda iş zekası aracının kurum tarafından değiştirileceği ve şu an kullanılan iş zekası aracı üreticisiyle anlaşamadıkları için bir başka iş zekası aracına geçişin yapılacağı bildirildi. Buna rağmen ne iş biriminden, ne proje yönetim ofisinden, ne steering toplantısına katılan müdürlerden ne de işi geliştiren kişilerden şu soru gelmedi:
– Biz tabloları A ürünü için yapıyoruz. Fakat B’ye geçilecekmiş. Sence de A için geliştirmeyi bırakıp artık B için geliştirme yapmamız gerekmiyor mu?
Bu proje, A aracı için on sekiz ayda geliştirildi. Bu projenin B ürününe göre düzenlenmesi kaç ayda tamamlanabilir?
Böyle okunduğunda gerçek gibi gelmeyen bu örneklerle hepimizin karşılaştığını biliyorum. Arkanıza yaslanın ve yaşadığınız travmayı hatırlamamak için zihninizin en derinlerine gömdüğünüz anıların canlanması için bekleyin. İster kod yazan kişi olun ister analist, ister takım lideri, ister müdür, ister dış firmada çalışan biri olun hepimizin gerçeği bu. Bundan hepimiz mustaribiz, hepimiz sıkıntısını yaşıyoruz.
Bir tahmine ihtiyacınız varsa bunu doğru şekilde yapmak bütün bu sıkıntıları engelleyecektir. Bunun da yolu, her şeyi bildiğini varsaymak ve böyle davranmaktan vazgeçip kısa döngüler halinde, yaşayarak ve yaşadıklarından ders çıkararak ileriye yönelik doğru bir öngörü oluşturmaktır. Yani determinizm değil, deneyciliktir. Bunu yaparken yaptığınızın sadece bir tahmin olduğunu ve mutlak doğru olmadığını, hatalar yapabileceğinizi aklınızdan çıkarmamanızı tavsiye ederim. Hataları daha iyiye ulaşmak için birer fırsat olarak görmelisiniz.
Uzman Görüşü, Benzeşim ve Küçük Parçalara Bölme
“Agile Estimating And Planning” adlı kitabında Mike Cohn, doğruya en yakın tahminin yapılabilmesi için bazı tekniklerden bahseder. Bu teknikler; uzman görüşü, benzeşim, küçük parçalara bölmedir.
Çevik yaklaşımlarda işin maliyetini belirleme konulu bir yazıda iki Aziz Nesin hikayesi anlattığım için kusuruma bakmayın. İçinde yaşadığımız gerçeklerin farkında olmamız gerektiğini düşündüğüm için bu vurguyu yapmak zorundayım. Serinin ikinci bölümünde maliyet belirleme tekniklerini anlatacağım.
Serinin tüm yazılarına erişmek için bağlantıya tıklayabilirsiniz.