En Yaygın 9 Yazılım Proje Riski

Bu hafta sizler için yazlım projelerin karşılaşılan risklerden en yaygın olan 9 tanesini ele alıyorum ve genel olarak yazılım proje risklerine yönelik bir kategori listesi paylaşıyorum. Keyifli okumalar.

Yazılım Proje Risk Kategorileri

Yazılım proje riskleri hem akademik çalışmalarda hem de pratik uygulamalarda farklı şekillerde ele alınabiliyor. Örneğin proje yönetiminin bilgi alanlarını esas alarak riskleri kapsam, maliyet, kalite, takvim, bütçe gibi başlıklarda ele alabilirsiniz. Buna ek olarak ya da alternatif olarak yazılım geliştirme yaşam döngüsünün adımları olan analiz, tasarım, kodlama, test, devreye alma aşamalarını da birer risk kategorisi olarak ele alabilirsiniz. Bunlar haricinde PESTLE tekniği esas alıp kategorilerinizi politik, ekonomik, sosyal, teknik, yasal ve çevre olarak belirleyebilirsiniz.

Ben riskleri öncelikle iki kategoriye ayırmayı tercih ediyorum:

· Dış (harici) riskler

· İç (dahili) riskler

Harici riskler kurumun ve proje yönetiminin dışında kalan risklerdir. Bunları genel olarak şu şekilde listeleyebiliriz:

· Ekonomik dalgalanmalar

· Pazardaki farklılaşmalar

· Müşteri alışkanlıklarının ve gereksinimlerinin değişmesi

· Regülasyona yönelik değişiklikler

· Pandemi, doğal afet, vb. sorunlar

· Rakiplerin beklenmedik aksiyonları

İç riskleriyse yukarıda da bahsettiğim üzere farklı açılardan ele alabiliyoruz. Aşağıda alternatif bir bakış açısından iki seviyeli bir listeyi sizlerle paylaşıyorum:

Operasyonel ve Yönetsel Riskler

• Sorumlulukların net şekilde belirlenmemiş olması
• Yetersiz ya da uygun olmayan kaynak
• Çalışanların işten ayrılması
• Çatışmaların çözümlenememesi
• Önceliklerin doğru belirlenememesi
• İletişimin iyi yürütülememesi
• Verimli ve etkili çalışamama/çalışmama
• Planlamanın ve yürütmenin iyi yapılamaması
• Risk yönetiminin iyi yapılamaması

Teknik / Teknolojik Riskler

• Olgunlaşmamış teknolojilerin kullanımı
• Teknik beceri setine sahip uzmanların az oluşu
• İmplementasyonun karmaşık oluşu
• Modül entegrasyon riskleri

Bütçe Riskleri

• Yanlış bütçe tahminleri
• Maliyetlerin artması
• Kapsamın genişlemesi
• Bütçenin etkin takip edilmemesi

Takvim Riskleri

• Yanlış efor tahminleme
• İlerlemenin yakından takip edilmemesi
• Kapsamın genişlemesi
• Kaynak atamalarının uygun olmayışı

Kapsam Riskleri

• Gereksinimlerin ve paydaş beklentilerinin açık olmayışı
• Altın kaplama
• Kapsam sürünmesi
• Gereksinim enflasyonu

Elbette bu liste de farklı bakış açılarıyla ele alınabilir, buradaki bazı maddeler birleştirilip bazıları daha detaylı ele alınabilir. Benim amacım bu listelerle size risk çalışmalarınızda bir başlangıç oluşturabilmek. Bunu yapabildiysem ne mutlu bana.

Buraya kadar genel olarak risk kategorilerini, alanlarını ve genel başlıklarını inceledik. Bundan sonrasındaysa yazının başlığı olan en yaygın 10 yazılım proje riskini ele alacağız.

En Yaygın 9 Risk

1. Agresif teslim tarihleri

Bazen yazılım geliştirme projeleri çok agresif teslim tarihlerine sahip olurlar. Zaten zor olan yazılım projeleri bir de çok yakın bir tarihe teslim edilmesi gerektiğinde risk katlanarak artar. Bu tip durumlarda gerçekçi bir teslim tarihi belirlemek üzere detaylı bir çalışma yapmanızı öneririm. Böylece karşınızdaki riskin gerçek durumunu görmüş olursunuz. Eğer kapsam ve paydaşlar yeterince olgunsa bu tip durumlarda bazen yeterli kaynak takviyesiyle başarı sağlamak mümkündür. Ama her halükarda sıkı teslim tarihleri sıkı bir takip, çok işi bir iletişim, maksimum paydaş ve yönetim katılımı gerektirir. Riski asla sıfırlayamazsınız ama kontrol altına almanız mümkün olabilir.

2. Proje takımı üyelerinin işten ayrılması

Kilit ekip üyeleri de dahil, projedeki ekip üyelerinin işten ayrılması büyük sıkıntılara neden olabilir. Özellikle de iyi bir dokümantasyon kültürünüz yoksa bu risk ciddi derecelere ulaşabilir. Bir takım üyesinin işten ayrılmasının birçok sebebi olabilir. Bunlardan biri de projenin iyi yönetilmemesidir. Siz iyi bir proje yönetimi yapıp çalışmalarınızı etkili bir dokümantasyonla desteklerseniz riskin etkisini azaltmanız söz konusu olacaktır.

Projelerden ayrılan kilit ekip üyeleri de dahil olmak üzere çalışan değişimi, yazılım geliştirmede bir başka önemli risktir. Ekip üyeleri yazılım geliştirme projelerinden ayrıldığında becerilerini, uzmanlıklarını ve proje geçmişlerini değiştirmek zor olabilir. Bu riski şu şekilde azaltabilirsiniz:

3. Sahiplik Eksikliği

Sahiplik eksikliği, proje yöneticisi başta olmak üzere tüm proje takımının, son kullanıcıların, sponsorun veya diğer paydaşların projeyi ya da proje sonucu ortaya koyulacak olan ürünü sahiplenmemesi anlamına gelir. İdeal olan tüm proje paydaşlarının tüm projeyi ve çözümü sahiplenmeleridir. Ancak bunu sağlayamıyorsanız herkesin nelerden sorumlu olduğunu net olarak belirlemek nispeten sorunu azaltacaktır. Ayrıca çevik yöntemlerde kullanıldığı gibi bir ürün sahibi (Product Owner) tanımlamak da sahiplik sorununa yönelik etkili bir yöntemdir.

4. Yetersiz İnsan Kaynakları

Yetersiz insan kaynaklarına yönelik sorunlar iki biçimde karşınıza çıkabilir:

- Takım büyüklüğünün, ekip üyesi sayısının yetersiz olması

- Ekip üyelerinin proje için gerekli donanıma sahip olamaması

Aslında bu iki riski ayrı ayrı da ele alabilirsiniz. Ben burada tek bir başlık olarak tartışmayı tercih ettim.

Birçok risk unsurunda olduğu gibi bu unsur da kapsamın belirlenmesi, bütçe ve tahminlemeye de bağlıdır. Yanlış tahminlemeler sonucu zayıf bir ekiple proje yapmaya çalışmak sizi net olarak başarısızlığa götürecektir. Proje için gerekli yetkinlikleri doğru şekilde belirleyememek ya da başka bir projeden gelecek olan kaynakların projelerinde takılıp kalmaları sık yaşadığımız sorunlardır. Bu riski ortadan kaldırmanın yolu etkili bir insan kaynağı planlaması ve yönetimi gerçekleştirmektir.

5. Düşük Son Kullanıcı ve Paydaş Katılımı

Hem gereksinimlerin analizi, hem beklentilerin ne düzeyde karşılandığının belirlenmesi açısından son kullanıcıların, alan uzmanlarının, sponsorun ve diğer paydaşların projeye aktif olarak katılım çok önemlidir. Toplantıları eksik paydaşlarla yapmak, paydaşlardan gerekli bilgileri zamanında alamamak, aktiviteleri gerekli paydaşlarla yapamamak başarısızlığı garantileyecek ciddi risklerdir.

Şeffa bir proje yönetimi, aralıkları doğru belirlenmiş frekanslarda ilerleme toplantıları daha da iyisi sık teslimatla müşterilere değer katmak onların projeye katılımını artıracaktır.

6. Yanlış Tahminler

Yazılım projelerindeki en büyük zorluklardan biri yapılacak olan işlerin büyüklük ve karmaşıklık tahminlemelerini yapmak ve buna bağlı olarak da eforları doğru olarak belirlemektir. Eforları yanlış belirlemek takvimi ve bütçeyi de yanlış belirlemenize neden olur. Bu da zincirleme bir çöküşe sebep olur.

Etkili bir tahminleme için ilk olarak kapsam ve gereksinimleri netleştirmelisiniz. Tahminlemeyi uzman bir ekiple yapmak da işinizi garantiye almanızı sağlar. Daha da iyisi bir ya da iki yıllık tahminler yerine birkaç haftalık tahminler yapmaktır. Yapılan tüm istatistiki çalışmaların da gösterdiği üzere kısa süreli küçük şelale projeleri ve çevikle yönetilen yazılım projeleri daha başarılı olmaktadır.

7. Kapsam Tanımında Hata

Kapsam tanımı, projenin ve ürünün içerisine nelerin girdiğini, nelerin dışarıda kaldığını belirler. Bütün planlamalar kapsam tanımına dayanır. Bu nedenle burada yapacağınız bir hata bir önceki maddede ele aldığımız tahminleme hatalarına o da planlama hatasına neden olacaktır. Sonrasında projeyi başarıyla tamamlamanız ancak bir mucize sayesinde gerçekleşebilir.

Kapsam tanımı, değişen gereksinimler, belirsiz taleplerle başa çıkmanın en pratik ve kendini ispatlamış yolu çevik yazılım geliştirme yaklaşımlarını uygulamaktır. Bunun haricinde etkili bir iş analiz süreci yürütmek ve deneyimli iş analistleriyle çalışmak da bu alandaki risklerinizi azaltacaktır.

8. Düşük Kod Kalitesi

Düşük kaliteli kod birçok anlama gelebilir. Kodun okunması zor olabilir, yani diğer geliştiricilerin gözden geçirmesi veya değişiklik yapması zor olabilir. Acele edilmiş ve test edilmeden yayınlanmış olabilir, bu nedenle hatalarla doludur. Mimari tasarım hataları ya da veritabanı tasarım hataları söz konusu olabilir. Birden çok yazılım uzmanı tarafından geliştirilen kodlarda belirli bir standart olmadığında da kod kalitesi düşebilir. Yazılımcılarınız tecrübesiz olabilir ya da deneyimli olsalar bile hızlı kod yazmaları istendiği için kod kalitesi düşebilir.

Düşük kod kalitesi riskini azaltmak için yapılabilecek en önemli şey bir kodlama standardı oluşturmaktır. Eğer kurumun böyle bir standardı yoksa mutlaka proje için bir standart belirlenmelidir. Ayrıca makul aralıklarla yapılan kod gözden geçirmeleri de kod kalitenizi artıracaktır. Ayrıca işlevsel testler haricinde birim testi, entegrasyon testi gibi farklı testler gerçekleştirilerek de kodunuzun ve yazılımınız kalitesin artırabilirsiniz.

9. Yetersiz Risk Yönetimi

Yarının problemleri bugünün riskleridir. İleride karşınıza çıkabilecek sıkıntıları önceden belirleyip gerçekleşme ihtimallerini ya da etkilerini azaltmaz, gerçekleşirlerse ne yapacağınızı belirlemezseniz ciddi sıkıntılar yaşayabilirsiniz.

Listemizdeki son risk, risk yönetiminin kendisidir. Risk yönetimi yapmazsanız ya da yetersiz risk yönetimi yaparsanız önceden belirleyip etkilerini azaltabileceğiniz ya da ortadan kaldırabileceğiniz potansiyel problemleri hazırlıksız bir haldeyken karşınızda bulabilirsiniz. Devekuşu gibi kafanızı kuma gömerek risklerden kurtulamazsınız.

Pekiyi ne yapmanız gerekir? Elbette etkili bir risk yönetimi uygulamalısınız.

Sonuç

Yazılım projeleri doğaları gereği zorlu ve risklidir. Gereksinimler bulanık ve değişken, paydaşların katılımı ve takılımın performansı çok net olarak ön görülemez. Planlamaya esas olan tahminlemelerin tutturulması çok zordur. Böyle bir ortamda başarılı olmak için yapılması gereken kritik şeylerden biri de etkili bir risk yönetimidir. Etkili bir risk yönetimi yapmak için de bu alandaki risk kategorilerini ve kritik riskleri bilmek gerekir.

Bu yazıda yazılım projelerindeki risk sınıflarını ve en sık karşılaşılan riskleri ele aldık. Bunlar elbette işin sadece belirli bir kısmı. Yaptığınız projenin türüne, iş alanına, teknolojiye göre birçok farklı riskten bahsetmek mümkündür.

Yazıda göremediğiniz ama size sıkıntı yaşatan tespitleriniz varsa bizimle yorum olarak paylaşın. Birlikte tartışalım.

Hoşça kalın, sağlıkla kalın

Originally published at https://www.linkedin.com.