Yazılım mühendisliği açısından verimlilik – 2

* Yazılım projesi özelinde düşünürsek ara zamanda hesaplanamıyor olması ara zamanda projede değer üretilmediğini göstermez mi?. Günümüzde kullanabilecekleri yazılımı projenin sonunda görmeye razı olacak müşteri var mi?

Projeyi planlayanın parçalara ayırması (bunu baştan yapması) gerekli.
Mesela modüller halinde....
Her modülün üretimin aşamasındaki yeri zaman cetvelinde başlangıç ve bitiş olarak belirtilir. Bu tahmini süreler; planlamacının işidir.

Müşterinize modülleri süreç devam ederken sunabilirsiniz.
Ama hedef matrisinde bunlar yapan departmanın hanesine eklenir.

* Bu kullandığınız yönteme göre değişir. Waterfall bir süreçte hatalı olduğu doğrudur. Fakat yazılımı adım adım oluşturuyorsanız ve her adımda kullanılama hazır, kaliteli yazılım üretiyorsanız her adimin verimliliğini müşteriye verilen değer toplamı olarak ölçebilirsiniz.

Planlama ve öngörü (tahmin) ile bunu yaparsınız...
2 hafta sonra modül1, 4 hafta sonra Modül2 bitecek der, ve yapacak ekibe bir verimlilik hedefi koyabilirsiniz.
Ama aynı anda paralel çalışan ekiplerde senkronize üretimi kaydıran ekipler, sadece kendi verimliliklerine değil tüm projenin verimliliğine zarar verir.
Birçok ekiple çalışıyorsanız, senkronizasyonu dengelemek, bazen planlamacılıktan zor olabilir.

* Bu tanımın içinde yazılımı kullanacak müşterinin tatmini ölçülmeli eklenmeli mi? Bir işin bitti denmesi ve verimlilik hesaplarına katılması müşteri tatmin kriteri önemli değil mi?

Matriste departmanlar dizisine; test departmanı gibi implemantasyon işini de ekleyebilirsiniz. Planlama ekibi projeyi müşteriye giydirecek olan departmanı da planlamış olmalıdır. Bunu ayrıca belirtmeye gerek duymamıştım.

Müşteri tatminine yönelik yapılacak ek işçilikler bu şekilde eklenemez.
Bu ek işçilikler; ancak minör versiyon uygulaması gibi görülebilir.
Ve ek bir proje gibi oluşturulacak yeni bir matris ile hesaplanmalıdır.
Bu durumda: P projesi için P' ek külfeti oluşur. Müşteri bununla da tatmin olmazsa ikincil iyileştirmeler P'' .... devam eder.

Verim = |XYZ| - |X'Y'Z'| - .... şeklinde olur.

Toplam iyileştirme kaybı. Projenin faydasını geçerse işte o zaman işi batırmışsınız demektir.
Bu durumu tekstil sektörüne yönelik yazılım üretiminde ne yazıkki çokça görüyorum.

Müşteri tatminini sağlamada en başta tanımladığımız planlama ekibine ve bu ekibin çekirdeğini oluşturacak süreç analizcilerine (Buna diğer sektörlerde "Proses tasarımcısı" da deniyor.) Çok iş düşüyor.
Ne yazık ki planlamacıların verimsizliği en tehlikeli verimsizliktir.
Ve hesaplanamaz.
Bunu genelde çok sayıda proje sonrasında şirket verimi şeklinde gözlemlemek mümkündür.
Ki bu durumda işler kötüye gitmişse çok geç kalınmış demektir.

* * *

Bir de ek olarak şunu belirteyim:

Bazı süreç akışlarında;
Bir departman, iş yapabilmek için diğer bir departmanın çıktısını kullanabilir.
Mesela
sizin, fırıncıya
fırıncının un fabrikasına
un fabrikasını çiftçiye
bağlantısı gibi.

Çiftçi mahsulü geç toplarsa bu size bir silsile şeklinde yansır.

Bir departmanın, başka birkaç departmanın çıktısını, girdi olarak alması durumunda iş daha da karmaşıklaşır.
Ama çözülemez bir denklem değildir.

Benzer bir süreç rOi de ve iRR de de uygulanır.
Aslında proje bazında hesaplanacak rOi ve iRR de verimlilik denkleminde yer almalıdır.

Ama burada sadece süreçten bahsettik.
Hep sevgi ile kalın.

Murat SEVGİ

Sözlük:
rOi: (Return Of Investmen) Yatırımın geri dönüşü süresini ifade eder.
Bu konuda daha ayrıntılı bilgiyi http://muratsevgi.blogspot.com/2007/01/yatirim-projelerinde-roi-nin.html adresinde bulabilirsiniz.
iRR: (Internal Rate Of Return) İç kaynakların geri dönüşünü ifade eder.