Yazılım Projelerinde Başarı Faktörleri

“Yazılım Projelerinde Başarı Faktörleri” düzenli olarak yayınlanan ve yapılan araştırmalar çerçevesinde BT projelerinin başarı/başarısızlık durumlarının raporlandığı Standish Group tarafından hazırlanan Chaos raporu, BT projelerinin uluslararası düzeyde irdelenmesine büyük katkı sağlamaktadır.

2020’de ABD’deki zayıf yazılım kalitesinden kaynaklı başarısız projeler nedeniyle 260 milyar dolarlık kayıp olduğu tespit edilmiştir.

Standish Group CHAOS raporları’na göre yazılım projelerinin %19’u tamamlanmadan iptal edilmekte ve %47’sine uygulama esnasında itiraz edilerek değişikliğe uğramaktadır. Projeleri başarıya götüren üç faktör;

• iyi bir sponsor,
• iyi bir takım ve
• iyi bir çalışma ortamı

olarak belirlenmiştir. Başka bir deyişle, çoğu projenin teknik olmayan nedenlerden dolayı başarısız olduğu belirtilmektedir.

Sorunun çözümü için yıllar boyunca birçok yaklaşım denenmiş ve sadece yazılım projelerinin üçte biri tamamen başarılı olarak ilerleyebilmiştir.

CHAOS raporundan bazı istatistikleri inceleyecek olursak;

Proje Başarı Faktörleri

1. Paydaş katılımı %15,9
2. Yönetim desteği %13,9
3. Açık/net gereksinimler %13
4. Doğru planlama %9,6
5. Gerçekçi beklentiler %8,2

Proje Zorluk Faktörleri (projenin kusurlu tamamlanmasına sebep olan faktörler)

1. Kullanıcı katkısının eksikliği %12,8
2. Tamamlanmamış gereksinimler %12,3
3. Gereksinimlerdeki değişiklikler %11,8
4. Yönetim desteğinin eksikliği %7,5
5. Teknoloji yetersizliği %7

Proje Başarısızlık Faktörleri

1. Eksik gereksinimler %13,1
2. Kullanıcı katkısının eksikliği %12,4
3. Kaynakların eksikliği %10,6
4. Gerçekçi olmayan beklentirler %9,9
5. Yönetim desteğinin eksikliği %9,3

Projelerde maliyet aşımlarının %150 ila %200, zaman aşımlarının da %200 ila %300 arasında olduğu tespit edilmiştir.

Yazılım projelerinde başarı faktörleri

Yazılım projelerinin fiziksel elle tutulur bir çıktısının bulunmaması ve geliştirilen üründen beklentilerin çok net tarif edilemiyor olması, projelerde yüksek başarısızlık oranlarının oluşmasına sebebiyet vermektedir. Net tespit edilememiş isterlerin varlığı müşteri beklentisinin karşılanmamasına doğal olarak da kullanılmayan ya da ihtiyacı tam olarak karşılamayan ürünlerin üretilmesine sebebiyet vermektedir. Günümüzde, ihtiyacın artık çok daha hızlı bir şekilde değiştiği, mevcut teknolojik gelişmelere hızlı adaptasyonun gerektiğini kabul etmeliyiz. Projelerimizin erken fazlarında detaylı gereksinim analizleri yaparak, diğer fazlarda tespit edilmiş bu gereksinimlerle uyumlu ürünü geliştirmek ve beklentiyi karşılamak gittikçe zorlaşmaktadır. Gereksinimle çok hızlı değişmekte ve kullanıcı/müşteri ihtiyacını her zaman ilk fazlarda ideal şekilde tarif edememektedir. Yazılım projeleri , proje sonunda tek teslimat (single delivery) yönteminden , artırımlı teslimata (incremental delivery) doğru evrilmelidir. Değer üreten ürün parçaları geliştirilerek erken aşamalardan itibaren paydaş görüşleri alınmalı ve beklentiler, gereksinimler düzenli olarak yönetilmelidir. Bu sayede, paydaşın beklentisi karşılanmış olacak ve proje başarısı yükselecektir.

Geleneksel proje yönetim yaşam döngüsünde, şelale yaklaşımında, yazılım projelerimiz genellikle analiz, tasarım, geliştirim, test, devreye alma şeklinde fazlardan oluşur ve her fazla detaylı çaışmalar yapılarak paydaş onayları ile bir sonraki faza ilerlenir. Örneğin, analiz fazında detaylı gereksinim tespit çalışmaları yapılır, yazılım/sistem gereksinim dokümantasyonu hazırlanır (SRS), hazırlanan belgenin müşteri onayıyla bir sonraki faz olan tasarım fazına geçilir. Çalışan nihai ürün devreye alma aşamasında son kullanıcının ilgisine sunulur ve ürüne dair ilk uygulama pratikleri ve kullanıcı tepkileri projenin son aşamalarında alınır. Geleneksel yaşam döngüsü, isterlerin çok net tanımlanabildiği, geçmişte benzer proje deneyimlerine sahip olduğumuz durumlarda oldukça doğru bir yöntem olarak yer almaktadır.

Artık globalleşen dünyanın ve çok hızla gelişen teknolojinin de etkisiyle, yazılım ürünlerinden müşterinin beklentisi oldukça yükselmiştir. Artık, daha iyisi, daha hızlısı, daha kolay kullanımlı olanı gibi hep bir “daha” ile karşı karşıyayız. Yazılım projelerin başarısızlık oranını geçmiş beş ve on yıllık istatistiklerle kıyasladığımızda artış içerisinde olduğunu gözlemliyoruz. Çevik (agile) yaşam döngüsünün ve iş analistliği  (business analysis) yöntemlerinin ilk olarak yazılım sektörü için ortaya çıkmış olması şaşırtıcı değildir.

İş analizi, bir problemin çözümü ya da bir fırsatın tespitinde gereksinimleri doğru/eksiksiz belirleme, modelleme, analiz etme, tasarım alternatifleri üretme, gereksinimi izleme ve doğrulama, ve yönetmek için yol ve yöntemleri kapsamaktadır. Bir “gereksinim mühendisliği” olarak tarif edebiliriz. Müşteri beklentisinin/gereksinimlerin doğru tespit edilememiş olmasının en temel başarısızlık nedeni olduğunu istatistiklerde de görmekteyiz. Proje ekibimizde yer alan iş analisti arkadaşlarımızın müşterinin sesi olarak prototpleme yöntemlerini de kullanarak gereksinimleri tespit etme, modelleme ve analiz etme çalışmalarını yürütmektedirler. İş (business) ve geliştirim (development) tarafındaki paydaşlar arasında bir köprü oluşturu ve beklentinin doğru karşılanmasını sağlatmak için çalışırlar. İş analizi yaklaşımı uluslararası enstitüler tarafından da belirlenmiş olup bu bağlamda sertifika programları mevcuttur. PMI-PBA – Profession in Business Analysis , Proje Yönetim Enstitüsü tarafından verilen iş analistliği sertifikasıdır. IIBA-International Institute of Business Analysis tarafından da CBAP ve CCBA olarak iki seviyede iş analistliği sertifikaları verilmektedir.

Günümüzde çok sık duyduğumuz çevik dönüşüm ya da çevik yönetim (agile) de ilk olarak yazılım sektörü bünyesinde doğmuş olup, artık tüm sektörlere uyarlanmış bir yönetim yaklaşımıdır.

Çevik manifesto 2001 yılında yayınlanmıştır ve küçük iterasyonlarla değer yaratacak şekilde işleri tamamlamak, kullanıcıya üretilmiş ara ürünü sunmak, geri bildirimlerle bir sonraki iterasyonları planlayarak artırımlı bir şekilde ilerleme sağlanmaktadır. Müşteri ile işbirliği ön plandadır. Geliştirim ekibi, otonom bir ekiptir, kendi kendisini yönetebilen ve organize olabilen bir ekiptir. İterasyonlar çerçevesinde tamamlanacak olan işin taahütü yapılır ve ilgili zamanda işlerin tamamlanmasını sağlayacak şekilde takım olarak birarada işbirliği içinde çalışmalar yürütülür. Çevik yaşam döngüsü, Ar-Ge projelerinde, gereksinimlerin çok sık değişme ihtimalinin bulunduğu projelerde, yazılım projlerinde oldukça ideal bir yaklaşımdır. Çevik ve klasik yaşam döngüleri ile yönetilmiş projelerin başarı ve başarısızlık istatistiklerini de Chaos raporundan elde edebiliyoruz.  Değer odaklı, artırımlı teslimatın, müşteri işbirliği odağında çalışmanın ve prototipleme başta olmak üzere bir çok iş analizi yöntemelerinin kullanımı ile başarılı projelere doğru ilerleyeceğimiz kaçınılmazdır. Projelerimizde melez(hibrit) yaklaşımlarla , hem çevik hem de klasik yaşam döngülerinin birbirini bütünleştirdiği ve güçlendirdiği çözümlerle ilerlemenin katkısını gözlemliyoruz.

Yazılım projelerinde karşımıza çıkan bir diğer yaklaşım da “DevOps” tur. “The Cost of Poor Software Quality in the US: A 2020 Report” , “Düşük Yazılım Kalitesinin Maliyeti” raporunu incelediğimizde; çevik ve Devops yaklaşımlarının birbirini bütünleştirdiği sürekli değişim, entegrasyon ve devreye alma mantığının yazılım süreçlerindeki gerekliliğini görüyoruz.

Bir çok BT pazarında, geliştiricilerin küçük, artırımlı değişiklikleri sürekli test ettiği, günlük, saatlik hatta anlık olarak üretim sistemlerinde canlıya geçişin sağlandığını gözlemliyoruz. Bu yaklaşım “DevQualOps” olarak adlandırılmaktadır ve Agile+DevOps yaşam döngüsü boyunca uygun bir kalite düzeyi sağlanmaktadır. DevSecOps, güvenlikte kalitenin bir alt faktörü olduğundan DevQualOps’un bir alt modelidir.

Bu DevQualOps modelinde yer alan özellikler;

• Birçoğu ölçülebilir olan tanımlanmış kalite hedefleri
• Yazılım kalite mühendisliğinde (SQE) daha geniş ve daha stratejik bir ekip rolü
• Kalite seviyesi ölçümü ve trend analizleri
• Sürekli süreç iyileştirmenin bir parçası olarak kusur önleme uygulamaları
• Teknik borcu kontrol etmek ve karmaşıklığı azaltmak için planlı yeniden düzenleme
• Her yinelemede planlanan hata bulma ve düzeltmeler (bug-fix)
• Süreçteki kilit noktalarda kalite kapıları (quality gate)
• Dahil edilen tüm bileşenlerin (özellikle açık kaynaklı yazılım) statik ve dinamik analizi

“Başla, tanımla, ölç, yönet” yaklaşımı, kuruluşun kalite ve başlangıçlara yönelik “her şey yolunda” yaklaşımlarından kurtulmasını sağlamaktadır. Kaliteyi ölçme yeteneği, kaliteli yatırımların işletmeye ve müşterilerine ne kadar iyi fayda sağladığını ölçmenin nihai testidir.

Projelerimizde, kaliteden ödün vermeden, müşteri beklentileri ile uyumlu, muhtemel değişikliklere çabuk tepki verebilen, adaptasyonu yüksek, geri bildirimlerle beslenen, paydaş işbirliğinin ön planda tutulduğu yaklaşım modellerini uygulayabilmek başarılı yazılım projelerinin anahtarı olarak karşımıza çıkmaktadır.

-Yazılım Projelerinde Başarı Faktörleri

– Selda BARBAROS,PMP®,RMP®

Proje Yöneticisi – Eğitmen – Danışman

Eğitim ve danışmanlıklarımız için bize ulaşın!