Yazılım Projelerinde Risk Durumu

Yazılım Projelerinde Risk Yönetimi

Büyük çaplı yazılım projelerinin geliştirilmesi pek çok risk içermektedir. Standish Group’un yaptığı ünlü araştırmalar başarısızlıklarla dolu yazılım projelerinin her dönem için büyük bir kabus olduğunu gösteriyor. 2000 yılında “CHAOS: A Recipe for Success” başlığı ile yayınlanan istatistiğe göre yazılım projelerinin sadece %28’i belirlenen özelliklerle, belirlenen bütçe ve zaman içinde tamamlanabildiğini gösteriyor. Bir başka deyişle, istatistiğe dahil edilen binlerce yazılım projesinden %76’sı, belirlenen özelliklerle, belirlenen zaman ve bütçe ile tamamlanamadı, veya tamamen başarısız oldu. Standish group ortaya çıkan tabloyu iyimser bir üslupla “kaos” olarak nitelendirmiş. Yazılım sistemlerinin iş akışını etkileyebildiği sistemlerde bu gerçekten korkutucu bir durum. Örneğin internet üzerinden açık arttırma yapılan eBay firmasının yazılım sisteminin sadece bir kaç saat için servis dışı kalmasının firmaya maliyetini milyon dolarlar ile ölçebiliriz. Konuya Microsoft açısından baktığımızda, ürünlerin belirlenen tarihlerde hazır durumda olmaması veya beklenilen şekilde çalışmaması durumunda firmanın kaybının yine milyon dolarlar seviyesinde (özellikle yeni ürünlerin yayınlanacağı tarihe yetişmemesi durumunda yapılan anlaşma, pazarlama ve reklam faaliyetlerini hesaba katarsak maliyeti yüz milyonlarca dolar olarak) hesaplayabiliriz. Küçük ve orta ölçekli projelerin maliyeti, projenin belirlenen zamanı aşması ile birlikte öngörülen maliyetin üzerine çıkmaya başlar. 10 kişilik bir proje ekibinde 1 çalışanın saatlik maliyeti 100 USD ise, şirket her iş günü için ortalama 40.000 USD harcıyor demektir. Tabi günlük maliyete kaçan fırsatları, kaybedilen satışları ve kazanılan memnuniyetsiz müşterileri de eklemek gerekir ki bu üç unsur, günlük maliyetten çok daha önemli bir kayıptır.

Pek çok firma process-oriented metodolojileri kullanarak gecikme ve başarısızlıkları azaltmayı / ortadan kaldırmayı ummaktadır ancak bu metodolojiler çoğu durumda iş yoğunluğunu ve buna bağlı olarak gecikmeleri arttırırken, nadiren başarı için katkı sağlamaktadır. Bu metodolojiler aynı zamanda çalışma grubunun bir problemle karşılaştığında, bir çözüm üretmeye yönlendirmektedir ancak üretilen çözüm çoğu durumda, çözümün üretilmemiş olmasına göre daha olumsuz sonuçların ortaya çıkmasına neden olur ve kıdemli (senior) yönetim sorunlardan ya ekip belirli bir milestone’ı kaçırdığı zaman, ya da müşteriler hata rapor ettiği zaman haberdar olur ve sorunu çözmek için projenin kapsamını azaltarak veya diğer projelerin kaynaklarını kullanarak çabalarlar. Sonuçta firma projeyi aşırı maliyetli olmasından dolayı sonlandırır.

Bu gibi sorunların ortadan kaldırılması için daha esnek geliştirme deneyimlerine dayanan “Önleyici Risk Yönetimi”nin kullanımı çoğu durumda olumlu sonuçlar verir. Uygulamanın ana fikri, uygulama geliştirme ve yayınlama sürecinde gecikmeye veya projenin başarısız olmasına neden olabilecek tüm adımlarının tanımlanması ve tanımlanan riskin ortaya çıkması durumunda uygulanarak, riski ortadan kaldıracak veya etkisini hafifletecek stratejilerin planlanmasıdır. Proje ekiplerinin riskleri sadece ortaya çıktıkları / gerçekleştikleri anda tanımladıkları ve ortadan kaldırmaya / etkilerini hafifletmeye çalıştıkları prescriptive risk yönetiminin aksine bu sistemde proje ekibi riskleri, geliştirme süreci öncesinde ve geliştirme sürecinde öngörerek karşı stratejilerini planlamaktadır.

Risklerin Tanımlanması ve Değerlendirilmesi

Risk yönetiminde ilk adım risklerin tanımlanmasıdır ve riskleri ortaya çıkartmak için sormamız gereken ilk soru “Projenin planlanan zamanı aşmasına veya başarısız olmasına ne(ler) neden olabilir?” olmalıdır. Risklerin sınıflandırılması proje grubuna tanımlama sürecinde yol gösterebilir ancak sınıflandırma işleminin gerçekleştirilmesi de son derece uzun ve zahmetlidir. Bununle birlikte her türlü projede karşılaşılabilecek türden bazı risklerin gözden kaçırılması ihtimali söz konusudur. Software Engineering Institute"ın sınıflandırması, örneğin tasarım ve entegrasyon gibi internal proje risklerine odaklanmıştır ve iş gereksinimlerinin değişmesi, platform bağımlılıkları gibi external riskler neredeyse tamamen göz ardı edilmiştir. “Gerçek Projelerde Risk Kategorileri” bölümü bu tür external risklerin projeleri nasıl etkileyebileceğini ele almaktadır.

Risk tanımlamasında risklerin her an değiştiğini kabul etmeliyiz. Proje ekibinin herhangi bir plan yapmadığı riskler her an ortaya çıkabilmektedir. Microsoft Solutions Framework, risklerde meydana gelebilecek değişikliklere ve ortaya çıkabilecek yeni risklere karşı yöneticilerin riskleri sürekli olarak değerlendirmelerini öneren sayılı metodolojilerden biridir.

Risklerin yönetiminde tanımlamadan sonra gelen ikinci adım ise risklerin değerlendirilmesidir. Risk değerlendirmesi, proje ekibinin, proje hedeflerini belirlemesinin hemen sonrasında başlamalı ve tüm proje süresince sürmelidir. Proje ekibi riski tanımladıktan sonra aşağıdaki adımları izleyebilir:

Olası darbeyi öngörün: Riskin uygulamanın test edileceği platformun planlanandan iki hafta geç hazır olabilecek olması olduğunu varsayalım. Eğer ters öngörülen gecikme sürecinden önce başlamak zorundaysa darbe şiddetli olacaktır ancak test işlemini öngörülen gecikmenin sonrasına bırakabiliyorsak etkisi daha hafif olacaktır. Ancak altyapının kurulmasının dağıtım tarihinin sonrasına sarkması riski hala sürmekte ve dikkate alınmalıdır. Olası darbeye göre riskleri derecelendirin: Derecelendirme “yüksek”, “orta” ve “düşük” şeklinde olabilir. Riskin meydana gelme olasılığını hesaplayın: Bunun içinde “yüksek”, “orta” ve “düşük” şeklinde derecelendirme yapmak yeterli olacaktır. Kesin yüzdeler elde etmek ne zorunluluktur, ne de mümkündür. Risklerin bir arada ortaya çıkması durumunda olası darbeyi ve meydana gelme olasılıklarını derecelendirin: İzlenmesi gereken kombinasyonlar; yüksek etki – yüksek gerçekleşme olasılığı, yüksek etki – orta gerçekleşme olasılığı, orta etki – yüksek gerçekleşme olasılılığı, orta etki – orta gerçekleşme olasılığı dır. Major Riskler için olasılık planları yapın: Birden çok planınız, en azından her zaman için bir b ve c planlarınız olmalı. Abartıyor gibi görünebilirim ancak değeri milyon dolarlar ile ölçülen bir projenin başında olduğunuzda bu planları hazırlamaktan “zevk duyacağınızı” garanti ederim :) . Olasılık planları için kaynak gereksinimlerini belirleyin: Bu size her olasılık planınıız için yaklaşık maliyeti öngörebilme imkanı verecektir. Risk bilgilerini “Review Plan”’a ekleyin: Sonrasında sponsor ve development manager’lar ile iletişim kurabilirsiniz. Aynı zamanda olasılık planları ve bu planların maliyetleri ile ilgili bilgileri de ederek herkesin aynı noktada bulunmasını sağlayabilirsiniz. Riskleri proje süreçleri olarak izleyin: Bazı riskler tartışma konusu olabilir. Diğerleri ise daha nadir görülür veya olası etkileri hafifler. Önceki review sonrasında yeni riskler ortaya çıkabilir. Riskleri haftalık raporlarla izleyin. Böylece proje sürecinin tüm üyeleri gelişmelerden eş zamanlı olarak haberdar olur. Risk değerlendirme yaklaşımınızı düzenli olarak değerlendirin ve düzenleyin: Risk değerlendirme ve yönetiminizin etkinliğini gözden geçirmek için post-project toplantılarını kullanın. Süreçleri geliştirmek için mümkün olduğunca fazla feedback toplayın.

Proaktif ÖnlemeÖnleyici risk yönetimi üç önemli alanda proaktif yönetim gerektirir: insan, süreçler ve kontrol sistemleri. 

İnsanÜçünün içinde insan en önemli etkendir. Eğer işbirliği içinde olmazlar ve birbirleriyle çalıışmak konusunda isteksiz olurlarsa, projeler genellikle başarısız olur. İncelediğim bazı projelerde; insanlar, daha iyi karar verebilme gücü, proglamlama ve risk yönetimi becerileri konusunda eğitilmesinin proje başarılarında oldukça yardımcı olduğu bilinmektedir. Bu beceriler, daha iyi karar verebilme ve daha iyi zamanlama gücünü doğurmaktadır; sonuç olarak 80 saatlik bir zaman dilimi kazanılmış ve stres seviyesi azaltılmıştır. Projeleri son günlerine kadar yetiştirme hedefi takım ruhunu yaratmış bu da insanların birbirlerine daha sabırlı olmasını ve problem çözmede daha istekli olmalarını sağlamıştır. Diğer bir yandan da projeleri son güne yetiştirmek için sürekli bir mücadele içinde olmak takım içinde kötü niyete neden olabilir. Stres artar, insanların birbirlerine daha az sabırlı olduğu gözlenir ve birbirlerine karşı daha az yardımcı olurlar. Herkes sadece projenin son gününe ve dağ gibi olmuş problemlere odaklanır ve yönetim projeyi tamamlamak için acil bir durum yaratana kadar herşey daha kötü gidecektir.

SüreçlerProsesler aynı zamanda risk yönetimini etkilemektedir. Esnek, değişikliklere kolay adapte olabilen prosesler, proje ekibinin değişikliklere daha kolay yanıt vermesini sağlamaktadır. Bunlar olmadan, projeyi belirli bir izde tutmak son derece zordur. Eğer her gereksinim değişikliğini onaylamak için bir grup toplantısı gerekiyorsa ve bu toplantılar haftada sadece bir defa yapılıyorsa, proje ekibi yeni fikirleri nasıl deneyecek? Pek çok projede proje gruplarının, önceden belirlenmiş bir gereksinim üzerinde yaptığı çalışmaların tamamının, gereksinim değerlendirme toplantısı sonrasında gereksinimlerin değiştiğinin görülmesi üzerine boşa gittiğini, bununda motivasyonun bozulması başta olmak üzere pek çok olumsuz unsuru tetiklediğini görmekteyiz. Varolma nedenleri proje sürecinde faydası olmayan unsurları ortadan kaldırmak olan Exteme programming, feature-driven programming ve lean programming gibi agile metodları bu olumsuz etkilerden kaçınmamıza katkıda bulunurlar. Bu metodlar, gereksinim değişiklikleri ile birlikte çalışmak için düşük maliyetli yöntemler sunmaktadırlar. Detaylı gereksinim dokumanları yerine, uygulama geliştiriciler ve müşteriler arasında daha yakın iletişim kurarak gereksinimlerin net olarak yorumlanarak karşılanmalarını sağlarlar. Aynı zamanda birden çok versiyonun geliştirilmesini, böylece kullanılabilir kodun mümkün olan en kısa sürede kullanılabilir hale gelmesini önerir. Böylece kullanıcılardan, proje ekibinin daha verimli bir geliştirme süreci oluşturmalarına katkı sağlayacak feedbackler toplanabilmesini sağlar. Son olarak bu metodlar, otomatize edilmiş test senaryolarına odaklanarak bir sürümden sonraki sürüme kadar geçen süreçteki bug"ları sürekli olarak denetler. Özetle agile metodları gereksinimlerin çok hızlı değişebildiği durumlarda son derece iyi sonuçlar elde edilmesini sağlayabilmektedir.

Dinamik methodlar kullanılan yazılım projeleri daha başarılı ve daha kullanılabilir olmaktadır. Sürekli kullanıcı girişine ve çalışan yazılımın tekrar tekrar uygulanmasına odaklanılmasıgereksiz vakit ve güç kaybını engeller. Takım üyelerinin yakın etkileşimi, proje üstünde tüm takım üyelerinin payı olması anlamına gelir. Sorumlu olduğum bir projede yayınlarımız başka bir projenin yayınlarıyla aynı anda gelmiştir. Bu da, az çalışanı olan destek takımı için bazı problemler yaratmıştır. Bu çatışmayı bazı takım üyelerine ek destek sağlayarak ve yayın turunu değiştirerek çözdük  

Kontrol SistemleriProje ekiplerinin, risk yönetimi de dahil olmak üzere projenin her bölümünü gözlemleyen ve ölçümlendiren bir mekanizmaya gereksinim duymalarından dolayı yönetim kontrol sistemleri oldukça önemlidir. Yeterli ve başarılı bir gözlem ve ölçümlendirme bir projeyi kurtarabileceği gibi, zayıf ve yetersiz yapılacak gözlem ve ölçümlendirme çalışmaları projelerin başarısızlığına neden olabilir. Pek çok proje sürecinde, proje ekibinin bir riski gözardı etmesine rağmen, kontrol sisteminin proje grubunu, çok geç olmadan risk için önlem almak zorunda bıraktığı durumlarla karşılaşıyoruz. Örnek vermek gerekirse bir projede firmanın professional-services ekibinin, yazılım grubunun bazı güvenlik varsayım ve önlemlerini sorgulaması, yazılım grubunun projenin bazı ilgili bölümlerini yeniden gözden geçirerek çeşitli değişiklikler yapmalarına neden olmuştu. Bir diğer proje sürecinde ise, firma üst yönetimi, proje sürecinde firmanın ürünlerinin uluslararası pazara sunulmasında yaşanan bazı problemlerden dolayı kaygı duymaya başlamıştı. Tüm proje ekipleri farklı tarih ve riskler raporluyordu. Tüm bunlar, üst yönetimin firmanın yapmaya çalıştığı şeye daha dikkatli bakmasını ve yapılanları daha detaylı yargılamasını tetikledi. Süreçler daha yakından izlendiğinde, tüm ekiplerin (pek çoğu doğru olmayan) farklı teknikler uyguladığı görüldü. Eğer yönetim bu uyumsuzluğu gözden kaçırmış olsaydı, harcanan tüm efor, para ve zaman boşa gitmiş olacaktı.

Şimdi proje süreçlerinde karşılaşabileceğimiz risk kategorilerine kısaca göz atalım.. 

Pek çok risk sınıflandırma yöntemi, projeleri ciddi anlamda etkileyebilecek dış riskleri gözden kaçırmaktadır. Aşağıdaki liste, günümüz projelerinde sıklıkla karşılaştığımız risk kategorilerini listelemektedir. Esnek bir geliştirme süreci, ilk üç kategorideki risklerin etkisini hafifletmeye yardımcı olmalıdır. Proje ekibinin gereksinimlerin tanımlanmasında, sistem tasarımlarının veya platformların düzenlenmesinde serbest kalması, ileride çeşitli riskleri beraberinde getirecek başarısız ortaklıkların çevresinde dönüp durmasına göre çok daha iyidir.

Gereksinimler: Belirsiz, netleştirilmemiş gereksinimler her zaman için projeler açısından risk anlamına gelmektedir. Bu en sık karşılaşılan ve başarısızlığa uğramış, gecikmiş projelerde yaşanan en temel problemlerden biridir. Rekabete koşulları ve yapılan yeni anlaşmalar her zaman için kurumların yazılım sistemlerinin değişmesi ihtiyacını ortaya çıkartmıştır. Kullanıcılar, ihtiyaç duydukları fonksiyonları sunan optimum yazılımı kullanana kadar akıllarında canlandıramazlar ve bu gereksinimlerin belirsiz ve değişikliğe açık olmasına neden olur.

Teknoloji: Geliştirme sürecinin bir noktasında (genellikle sürecin orta ve sonrasında kalan bölümlerinde) geliştirme grubu kullanılan teknolojinin sistem gereksinimlerini tam olarak karşılayamayacağını farkedebilir. Örneğin takım üyeleri kullandıkları veritabanı sisteminin kolay bir şekilde hasar görmeyeceğini düşünebilir ancak sistem geliştirildikçe kullanılan veritabanı sisteminin verilerin hasar görmesine neden olabilecek çeşitli hatalar içerdiğini farkedebilir ki bu noktada, böyle bir alanda yaşanacak değişiklik, proje için ölümcül olabilir.

İş: İş süreçlerinde verilen kararlar pek çok riski beraberinde getirebilir. Bir vendor ile yapılacak anlaşma, beklenen platformun oluşmasını sağlamayabilir veya projenin bir bölümünü veya proje için çeşitli kaynaklar sağlayan bir iş ortağı ile yaşanacak sorun projenin ilerleyişinin yavaşlamasına hatta sorunun ciddiyetine bağlı olarak durmasına dahi neden olabilir.

Politik: Bunları, üstesinden gelmesi en zor olan riskler olarak tanımlayabiliriz. Büyük organizasyonlar, büyük aileler gibi davranmaya mecburdur. Ancak pek çok nedenden dolayı ailenin bazı üyeleri, bütçenin kısıtlanmasına veya tamamen kaldırılmasına hatta projenin tamamen iptaline neden olacak adımlar atabilir. Bu tür durumlara karşı planlar hazırlamak, sonradan pek çok olumsuz sonuç doğurabileceğinden dolayı son derece zordur. Elbette yaptığınız karşı planların yine bu kişilerce öğrenilmesi, ayrı bir risk unsurudur.

Kaynaklar: Bir projenin ihtiyaç duyduğu insan, para veya donanım kaynaklarını alamaması belirlenen takvimin dışına çıkılmasına neden olduğu gibi, projede çalışanların moralinin kaybolmasına da neden olur. Her zaman için alternatif kaynakların belirlenmesi bu gibi sorunların ortadan kolayca kaldırılmasını sağlayacaktır.

Beceriler: Bu riskler proje ekibinin kullanılacak teknoloji veya üzerinde çalışılacak iş süreçleri hakkında yeterli bilgi sahibi olmamasından kaynaklanırlar. Eksik kalan bilgi ve beceriler konusunda proje ekibine gerekli eğitimlerin verilmesi veya danışmanlık desteği sağlanması riskin ortadan kalkması için yeterli olacaktır.

Dağıtım ve Destek: Proje ekibi uygulamanın dağıtımını gerekli altyapının zamanında hazırlanamamış olmasından, destek ekibinin eğitim ve destek için hazır olmaması gibi nedenlerden dolayı planlanan zamanda deploy edemeyebilir. Deployment ekibinin proje ekibinin ve geliştirilen projenin yaptıklarıyla ilgili fikir sahibi olmaması, bu tür risklerin ortaya çıkmasına neden olan en genel unsurdur ve çok kolay bir çözümü vardır: proje sürecinde çalışacak tüm ekiplerin birbirleri ile iletişim içinde olmasını sağlamak.

Entegrasyon: Uygulama geliştiricilerin en sık karşılaştığı gereksinimlerden biri, geliştirilecek olan uygulamanın, farklı uygulamalar ile entegre çalışmasını sağlamaktır. Yetersiz iletişim ve yanlış anlaşılmalar yapılan çalışmaların sonunda uygulamaların bir arada beklenen şekilde çalışmaması ile sonuçlanabilir. Bu sorunu ortadan kaldırmanın en kolay yolu, yeterli iletişimi sağlamak ve mümkün olan durumlarda entegrasyon işlemini uygulamaların geliştirme sürecinde gerçekleştirmektir.  

Takvim ve Zamanlama: Çeşitli unsurların gerekli oldukları anlarda hazır olmamasından kaynaklanan takvim ve zamanlama sorunları proje maliyetine en fazla olumsuz katkıda bulunan konuların başında gelir. Bu tür sorunları yaşamamanın tek yolu doğru ve başarılı bir planlama süreci sonrasında tüm alt süreçleri gerçek zamanlı olarak izlemek ve takvimin dışına çıkılmasına neden olacak her durumun önüne geçilmesidir.

Bakım ve İyileştirme: Şirket dokumantasyonun yetersiz olması ve destek ekibinin yeterli hazırlığı yapmamış, gerekli eğitimleri almamış olması durumunda uygulamayı doğru olarak yönetemez, geliştiremez. Gerekli eğitimler ve dokumantasyon hazırlığı için gerekli zamanın planlanması bu tür riskleri ortadan kaldıracaktır. Esnek bir proje sürecinde, proje yöneticilerinin eğitim, dokumantasyon ve destek için yeterli iş gücünü, zamanı ve bütçeyi tahsis etmemesi, işlerin kötüye gitmesine neden olacaktır. 

Tasarım: Hatalı tasarımlar uygulamaların kullanılabilirliğini ve performansını düşürecektir. Esnek bir geliştirme sürecinde kullanıcılardan alınacak feedbackler dikkate alınır ve bu feedbackler doğrultusunda tasarım iyileştirmeleri gerçekleştirilerek bu tür riskler ortadan kaldırılabilir.

Elbette bu gibi öngörülebilecek riskler söz konusu olduğu gibi, öngörmenin pek mümkün olmadığı ancak geliştirme sürecini aksatabilecek virüs saldırıları, şirket ofisine yapılacak bir saldırı (paranoya mı? J ) gibi pek çok durum söz konusu olabilir. Bu tür beklenmedik durumlarla başetmek için mümkün olduğunca paranoyak davranarak söz konusu olabilecek her türlü riski, gerçekleşme olasılığına bakmaksızın listelemek ve olası çözüm planlarını, en uygun back-up stratejisini hazırlamak en yerinde hareket olacaktır. (Bu konuda paranoyanın ulaştığı seviyeyi vurgulayabilmek adına bir bankanın uyguladığı back-up planından kısaca bahsedeyim. Banka ilk olarak bir şubesinin herhangi bir nedenden dolayı tamamen yok olması durumunda en az veri kaybını nasıl sağlayabileceğini, bunun bir adım sonrasında şubenin bulunduğu ilin yok olması durumunu, sonrasında şubenin bulunduğu ülkenin yok olması, son olarakta şubenin bulunduğu ilin bulunduğu ülkenin bulunduğu kıtanın yok olması durumunu hesaba katarak buna göre bir yedekleme ve geri yükleme stratejisi kurmuş durumda.. Sanırım bu uygulamanın yanında benim şirket ofisine saldırı olasılığını dikkate almam normal karşılanabilir.)

Beklenmedik riskler her zaman için projelerimizi tehdit etmekte ve önemli gecikmelere hatta başarısızlıklara neden olabilmektedir. Günümüz IT projelerinde doğru uygulanacak risk yönetimi, beklenmedik nahoş sürprizlerle karşılaşmamak için proje yöneticilerinin gözardı etmemesi gerek bir uygulama. Esnek proje süreçleri risklerin öngörülmesini, karşı planların hazırlanmasını ve uygulamaya konmasını kolaylaştıran proaktif risk yönetimini kullanmaktadır. Proje sürecine ihtiyaç duyulan esnekliği kazandırmanın yolu ise proje ekibinin becerilerinin arttırılmasından geçmektedir. Aynı zamanda projelerde en efektif planlama, ölçümleme ve paylaşımın gerçekleştirilebilmesi için en uygun kontrol & yönetim sistemlerinin kullanılması gerekmektedir. Buraya kadar ele aldığımız konular ve bunlara eklenebilecek pek çok madde ile birlikte proje süreçleri beklenmedik durumlara karşı daha hazır hale getirilerek projelerin en başta bahsettiğimiz istatistiklerde başarısız olarak tanımlanan projeler arasında yer alması önlenebilir.

Döküman Arama

Başlık :

Kapat