Uzmanına Sor

Günümüz iş dünyasında raporlama dendiğinde anlaşılan bir iş sürecinin durumunun ya da sonucunun, ilgili kişilere, önceden belirlenmiş bir biçimde, önceden belirlenmiş yöntemlerle bildirilmesi anlaşılır. Doğrusuda budur elbette. Ancak bu makalenin konusu teknik raporlamadan ziyade, iş hayatında üstlerin ve ilgili kişilerin bilgilendirilmesi olacak.

İş hayatında hepimiz belirli kişi ya da kurumlara karşı sorumluluk taşırız. Özel şirketlerde üstlerimiz vardır. En üstteysek işletmenin ortakları vardır. Halka açık şirketse çok daha geniş bir kitleye karşı sorumluluk taşırız. Devlet kurumlarında da en alttan en üste doğru ilerleyen bir sorumluluk zinciri olmakla birlikte, en üst noktaya gelindiğinde halka karşı bir sorumluluk vardır. Dolayısıyla bu sorumluluk zincirini en üst basamağı olmayan bir piramit yapısı olarak kabul etmektense, bir çember olarak görmek daha doğrudur diye düşünüyorum.

Peki ister özel bir işletmede çalışalım, ister devlet kurumunda. Raporlama dendiğinde ne anlamalıyız? Raporlamayı kime karşı yapmalıyız? Nasıl yapmalıyız? Sorumluluğumuz sadece raporlamak mıdır? Yoksa yaptığımız işin ve verdiğimiz raporların takipçisi olmak mıdır?

Bu güne kadar yazdığım 200 küsür makalenin hepsinde işe IT gözlüğüyle baktığımı farkettim. Bu makalede bu çerçevenin biraz dışına çıkmak istiyorum. Ancak elbette IT tarafında kazandığım deneyimlerin, iş dünyasına uyarlanabilirliğinden faydalanıyor olacağım.

Başarısızlığın Temel Nedenleri
Bir IT projesinde başarısızlığın en temel nedenlerini düşündüğümde aklıma gelen en önemli neden “zayıf iletişim” oluyor. Peki iletişim nasıl güçlü olur? Sürekli yazışmak ya da konuşmak, güçlü bir iletişim mekanizmasının varlığını mı gösterir? İletişimin sürekliliği ve yoğunluğu kadar, aktarılan bilginin kaliteside önemlidir. Sağlıklı bir iletişimin temel unsurlarını şu şekilde sağlayabiliriz;

• Düzenli iletişim
• Aktarılan bilginin kalitesi
• Aktarılan bilginin anlaşılabilirliği

Çalışma arkadaşlarımızla belirli bir frekansta iletişim kuruyor olmak elbette önemlidir. Ancak iletişimin sıklığından çok, doğru zamanda iletişim kurmak ve paylaşılan bilginin kaliteli olmasını sağlamak önemlidir. Yapılan bir işin durumu hakkında bilgilendirme yaparken aktarılan bilginin kalitesi kadar önemli olan bir başka konu ise karşı tarafın anlamak için fazla zaman harcamasını gerektirmeyecek şekilde sunulmasıdır. İletişim gerektiğinde sözlü olabileceği gibi (sonradan mutlaka yazıya dökülmelidir), gerektiğinde bir email, gerektiğinde bir excel ya da word dosyası gerektiğinde ise daha gelişmiş raporlama araçları kullanılabilir.

Gerektiğinde Yardım İsteyebilmek Önemlidir
Bilginin paylaşımı sadece insanların iş süreçlerinden haberdar olmasını değil, olası problemleri öngörebilmesini ve müdahale edilmesi gereken noktaların belirlenebilmesini de sağlar. Türkiye’de içinde bulunduğum projelerde en sık gördüğüm sorunlardan biri, insanlarımızın yardım isteme konusundaki çekingenliğidir. Nedenleri bu makalenin konusu olmamakla birlikte bu çekingenlik, üst yönetim tarafından zamanında algılanamaması halinde iş süreçlerinin başarısızlığında ciddi rol oynar.

Bu noktada raporlamanın bir başka çeşidinden bahsetmiş oluyoruz. Günümüz iş dünyasında raporlama dediğimizde sadece bir iş sürecinin o anki durumu ya da gidişatı ile ilgili bilgilendirmeyi değil, olası risklerle ilgili bilgilendirmeyi de kastediyor olmalıyız. İleriye yönelik risklere karşı risk yönetim planları oluşturabilmemize olanak tanıdığı için bu raporlamanın değeri, çoğu durumda verilen durum raporlarından çok daha yüksektir.

Yazılı İletişim Önemlidir
Peki raporlama hangi platformda olmalıdır? Eminim şu cümleleri defalarca duymuşsunuzdur;

• Ben söylemiştim
• Biz size bunu şöyle anlatmıştık
• Size nasıl olması gerektiğini x anlatmış olmalı
• X size söylemedi mi?
• Öyle mi konuşmuştuk? Unutmuşum!

Bu cümlelerin onlarca benzerini duymuşsunuzdur. Dikkat ederseniz hepsinin ortak özelliği “sözlü iletişim”e dayanmasıdır. Sözlü iletişim elbette önemlidir. Hatta bazı durumlarda iletilmesi gereken bilginin, yazıya dökülmesine zaman olmayabilir. Ancak bu, bu bilgi aktarımının daha sonra yazıya dökülmemiş olmasına bahane değil. Sözlü iletişimin yazıya dökülmesi, ‘sekreter işi’ olarak görülür genelde. Bu kesinlikle yanlış bir görüştür. Bu hem sizin, hem karşı tarafın korunması için son derece önemli bir iştir. Konuşulanların yazıya dökülmesi yukarıda bahsettiğim cümlelerin duyulmasını engelleyecek, yani iki tarafın birbirini doğru anlamasını garanti edecektir. Bununla birlikte gerekli durumlarda kendinizi ve kurumunuzu savunmanız için son derece güçlü bir dayanak olacaktır.

Savunmak?
Malesef evet. Ama işler sadece bizim ülkemizde böyle yürümüyor. Dünyanın hangi ülkesinde iş yaparsanız yapın, işler istendiği gibi gitmediği anda insanlar bir ‘suçlu’ arıyor. Hatta kendilerini bu suçlu arayışına o kadar kaptırıyor ki, ortadaki istenmeyen durumun düzeltilmesine harcamaları gereken değerli zamanı, birbirlerini suçlayarak geçiriyorlar. İşte bu noktada gereksiz tartışmalara bir son verebilmenin ve işin nasıl planlandığını, mutabakatın nasıl olduğunu ortaya koymanın en iyi yolu, iletişimi yazılı hale getirmektir. Bu ‘yazılı hal’, işin detaylarının tartışıldığı aşamalarda toplantı notları ve emailler, daha ileri aşamalarda proje planları ve emailler, daha ileri aşamalarda ise ilerleme raporları, emailler ve benzeri dokümanlar olacaktır. Elbette bu saydığım ‘yazılı hal’ler çeşitlendirilebilir.

Verileri Merkezileştirmek
İletişimi yazılı hale getirmek tek başına yeterli değildir. Verileri merkezileştirmek ve ihtiyaç duyan kişinin, ihtiyaç duyduğu veriye, ihtiyaç duyduğu anda, kolayca ulaşabilmesini sağlamak gerekir. Elbette bu bilgi merkezine erişim çeşitli yetkilendirmelerle olabilir. Ancak onlarca inbox’ta ve diskte toplanmış, binlerce email ve doküman arasından istenilen bilgiye ulaşmak, sözlü iletişimin egemen olduğu iş süreçlerinde doğru bilgiye ulaşmaya kıyasla sadece ‘biraz’ daha kolaydır.

Kurumlar, iş süreçlerinde oluşan bilgileri, doğru bir sınıflandırma ile, yüksek erişilebilirlik sağlayan ve iş süreçlerinin üyelerinin arama yapmasına olanak veren bir altyapı ile merkezileştirmelidirler.

Ve tekrar raporlamak
Uzun iş süreçlerinde isteyelim ya da istemeyelim çok miktarda veri oluşur. Bu veriler farklı kullanıcılar tarafından, farklı zamanlarda oluşturulur. Bu verilerin, gerekli zamanlarda özetlenerek, ilgili kişilerle paylaşılması gerekebilir. Örneğin bu bilgiler bir proje toplantısı öncesinde projenin durumu ile ilgili bilgiler kronolojik olarak toplanarak bir durum raporu oluşturulabilir. Ya da bir proje teklifi öncesinde, yapılan görüşmelerde ve analizlerde ortaya çıkan bilgiler derlenerek zaman, iş gücü ve maliyet hesaplaması yapılmasında kullanılabilir.

Bu yazılı iletişim mimarisi doğru tasarlandığı ve uygulandığı taktirde sadece sağlıklı bir iletişim ve raporlama mekanizması görevi görmekle kalmayacak, bize farklı iş süreçlerini kıyaslama ve iş süreçlerindeki hatalarımızı daha net görerek önlem alabilme imkanı verecektir.

Bu makalede kendi deneyimlerimden yola çıkarak, iş hayatında raporlama ve yazılı iletişimin önemine değinerek doğru bir yazılı iletişim mimarisinin nasıl olması gerektiğini ve doğru bir yazılı iletişim mimarisinin sağlayacağı faydaları vurgulamaya çalıştım. İdeal sistemi tasarlamak belki bir defada yapılabilecek bir şey değil ve belki her kurum için ideal sistemin özellikleri farklılık gösterecektir. Ancak temel özelliklerin ortak olacağı ve bu tür bir yapının ve çalışma modelinin oluşturulması için harcanacak zaman ve iş gücünün geri dönüşünün çok hızlı olacağını ve bu sürecin kuruma maliyetinin çok ötesinde bir getirisi olacağını öğrenmemiz gerekiyor. IT sektörü başta olmak üzere pek çok alanda çok büyük ve hızlı ilerlemeler kaydediyoruz. Bu büyüme sırasında, bazı alışkanlıklarımızdan vazgeçerek iş süreçlerimizi yeniden modellememiz gerektiğini, umarım olumsuz deneyimlerle karşılaşmadan farkedebilir ve harekete geçebiliriz.

Paylaş

Hide Sites

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.</LI>

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çler
Prosesler 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 Sistemleri
Proje 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: </I>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.<I> </I>

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.

Paylaş

Hide Sites