Yazılım Proje Geliştirme ve Maintaince Maliyet Hesabı

Yazılım geliştirme süreçleri nispeten her zaman maliyet’lidir. Buradaki “nispeten” kelimesi biraz fazla ya da gereksiz gibi duruyor değil mi? Gelin olmadığını konuşalım. 

Not: Bu makalede sadece yazılım geliştiricileri dikkate alacağız, tester, analist vs ilgi alanımızda değil.

İster kurumsal ister bir startup olun yeni bir uygulama geliştirmek her zaman pahalıdır. Çünkü bu uygulamaya sadece yatırım yapılacaktır. Yani bu uygulamanın şirkete bir getirisi olmayacağından yazılım geliştirme süreci her zaman pahalı görünecek, göze batacaktır.

Ancak yazılım geliştirme süreçleri tamamlandıktan ve uygulama müşteriye satıldıktan sonra daha çetrefilli bir süreç başlamaktadır. Maintaince. 

Bir yazılımı birkaç ay ya da birkaç yılda tamamlayabilirsiniz. Doğru ve karlı bir kazanç için bu yazılımdan en az 5-6 yıl para kazanmalısınız. Yani bu yazılım a 5-10 yıl destek vermek zorunda kalabilirsiniz.  

İşler tam olarak burada kızışıyor ve karışıyor. Maintaince döneminde tüm yazılım geliştirme ekibi proje üzerinde çalışmaya devam edecektir. Muhtemelen müşteri sayısına bağlı olarak bu ekip büyüyecektir.

Yazılım projesi doğru kurgulanmamış ise Maintaince dönemindeki maliyetler geliştirme dönemindekinden çok çok daha büyük boyutlara ulaşacaktır. Maliyetlerin bir nebze artmasında problem görmesem de genel de çok çok fazla artmaktadır. 

Yazlım para getiriyor ise Maintaince dönemindeki bu maliyetler genelde ve çok çabuk göz ardı edilir. Şeytanın/paranın tatlı yüzüne kanmamak lazım. 🙂

Yazılımı geliştirirken TDD, waterfall, agile bilmem ne olmak üzere tüm fantastik ve popüler metodolojileri kullandınız. Bunu tüm toplantılarda, konferanslarda kasıla kasıla anlatınız. Şöyle acar development yaptık, böyle acar takımlarımız var dediniz. Ama yazılımı, yazılımın içerisinde ve dışarısında destekleyecek ekosistemi doğru kurgulamadınız. Geçmiş olsun.

Yazılımı destekleyecek bu sistemler nelerdir. İçeride exception handling, loglama; dışarıda log monitoring, performance monitoring ve daha bir çok sistem sayabiliriz.

Bir çoğunun hemen atladığını görür gibiyim. Biz de çok güçlü bir devops ve devops toolbox u var. O nedenle bunlar bize işlemez, dediniz. İyi de kardeşim exception handling ve loglama yapmamışsın. Dünyanın en iyi sunucuları en iyi devops cuları olsa ne olacak?

Arkadaşlar, şahsi tecrübelerime göre;

1. yazılımcı ların %80 ‘i exceptionhandling nedir bilmiyor ve yapmıyor.

2. yazılımcı ların %90 ‘ı logging nedir bilmiyor, yapmıyor ve en kötüsü loglama yapmayı gereksiz görüyor.

Elinizde dünyanın en iyi devops toolları server’ları da olsa onları beslemez, data göndermezseniz hiç bir işe yaramazlar. 

Bu durumda Maintaince şöyle bir ortama dönüşür. Müşteri bir hata bildirir. Yazılımcı “ben aynı senaryoyu tekrar edemiyorum, yaratamıyorum bu nedenle çözüm üretemiyorum” der. 

Böylece backlog’ta çok ciddi iş birikmesi oluşmaya başlar. Çığ gibi büyüyen backlog’u gören vasıfsız yönetici ekip sayısının yetersiz olduğunu düşünür ve yeni takım üyesi ya da çalışan arayışına başlar. Buradaki vasıfsız kelimesi önemli, üzerinde düşünün.

Birkaç yıl önce bir firmadaki arkadaşlar bir hatayı gözümün önünde 45 gün boyunca aramışlardı. Sonrasında bana sorduklarında birlikte tartıştığımızda sistemde hata yok gibi görünüyordu.  Log, error gibi verileri istediğimde öyle bir verinin olmadığını söylediler. 🙂 Loglama gereksiz vakit kaybı imiş, acar paşalar böyle demişti.

Takım ilgili metodun giriş ve çıkışına basit de olsa console ‘ a da olsa log basmalarını rica ettim. Log satırları yazıldı, acar devops ekibi hemen yayına aldı. Hepi topu 1 saat içerisinde hatanın o sistemden kaynaklı olmadığı dış sistem kaynaklı olduğu ortaya çıktı.

45 gün çözülemeyen bir gizem bir problem, 1 saatte çözüldü. Çılgınca geliyor değil mi? Hayır gelmemeli, gerçekten doğru yaklaşımlarla tasarlanana ve geliştirilen yazılım projelerinde bu tip hızlı çözümler oldukça olağandır. Biz gecikenlere kızıyoruz aslında. 🙂

Toparlarsak, TR ve Globalde birçok firma ile yakın çalışma fırsatım oldu. Hepsindeki ortak nokta geliştirme süreçlerindeki ve sistem kurgularındaki yanlışlardan dolayı Maintaince kuyusunda kaybolmuş olmalarıydı.

Rakam vereyim de ilgililerin dikkatini tam çekelim. Sayısı 1000 kişi bulan şirketlerin yaptığı işi doğru kurgulanmış bir ekosistem de 300 kişi yapabilir. Hadi risk payı koyalım dediniz 400 kişi yapabilir.

İnanmadınız mı? Deneyelim, ben ispatlamaya hazırım!

Buraya kadar major sorunları listeledin peki çözümleri nelerdir? diyebilirsiniz. Basit bir araştırma ile hepsini tek tek çözebilirsiniz. Çözemediniz mi? Vaktiniz yok mu beleş danışmanlık buraya kadar. Gidin iyi bir danışman bulun o sizin için yapsın.

Sevgiler

Alper