Yazılım Projelerine Zaman Ekseninde Bakış

2.384

Maalesef çok şey var…

Toplum olarak bazı işlere bakışımız popülaritenin ötesine geçemiyor. Proje YönetimiAnaliz (İş, Gereksinim vs.), Risk YönetimiStratejik Yönetim ve hatta Stratejik Proje Yönetimi (Program, Portföy vs.) gibi başlıklar çok popüler ve herkesin fikri olan konular ama bu başlıkları zaman ekseninde değerlendiren ve en azından meraklısına temel bilgi sağlayacak kadar yöntemleri örnekleriyle ortaya koyan Türkçe kaynaklar bulmak maalesef çok zor.

Zaman Ekseninde Bakış

Kavram kargaşası olmaması açısından içerik olarak IT projeleri referansı ile ilerleyeceğimizi ve verilen örneklerde bir fikrin, ticari bir ürüne dönüşmesi için geçen süreçleri inceleyeceğimizi belirtmek gerekmektedir. Genel bir metodolojiden bahsedeceğimizden ve her başlıkta kullanacağımız terimler ilgili alanın önde gelen standartlarından alınacağından, içerikte ayrıntılı açıklanmayan her kavramı daha sonra araştırarak ayrıntılı fikir edinebilir.

İş İhtiyacı (Business Need)

Bir StartUp proje ile de başlasak, sipariş usulü mevcut bir yazılıma ek bir modül de geliştirsek ilk düşünmemiz gereken bu çalışmanın bir ihtiyacı gideriyor olmasıdır. Özellikle büyük şirket yapılarında bu ihtiyaçlardan fazlasıyla var ve sürekli bir talep gelmesi söz konusu. Dolayısıyla bu gibi büyük yapılanmalarda talep yönetimi apayrı bir yapılanma olarak karşımıza çıkmaktadır. Yine büyük yapılanmalarda çok fazla proje önerisinin gelmesi, stratejik seçimler yapılması zorunluluğunu doğurmaktadır.

Hal böyleyken hep orada olan iş ihtiyacının gündeme taşınması öncelikli iştir ve ilgili ihtiyaç sahiplerini ilgilendirir. Bu ihtiyacı nasıl gidereceklerini düşünmelerinin ilk aşaması ise kendi aralarında bir çözüm (business solution) bulmaya çalışmalarıdır. Hepimizin yaşadığı yanındakine sormak olayı bile business solution örneği olarak sayılabilir. Eğer bir iş çözümü bulunamaz ve farklı çözüm alternatifleri aramaya başlarlarsa ikinci aşama olarak bu ihtiyacın belirli bir olgunluk seviyesine ulaşması gelir. Eğer bu olgunluk olmazsa yazılım projelerinde bir çoğumuzun çok iyi bildiği “ne istediğini bilmiyor” şikayetini sıkça duyacağız demektir. Olgunluktan kasıt ise en özet olarak ne yapılması istendiğini sorduğunuzda yanıt alabilmenizdir.

Unutmayalım hepimizi işimizi kolaylaştırmayı ve daha rahat çalışmayı istiyoruz dolayısıyla ihtiyaç hiç bitmeyecektir. Bu bağlamda düşündüğümüzde bu ihtiyaçlara yönelik çalışmaya değip değmeyeceğini de mutlaka ölçümlemek gereklidir ve iş ihtiyacının bir sonraki basamağı olan fizibilite burada devreye girer. Daha basit bir örnekle açıklayayım; bir bankada finansal risk yönetimi yapmaya çalışıyorsunuz, yönettiğiniz risk büyüklüğü yıllık 15 milyon TL ve bu alanda hazır yazılımlar var ve işinizi yapacak bir yazılımın yatırım maliyeti 55 milyon TL. Hal böyleyken bu yatırımı yapılmaz çünkü az çok finansal yönetim yapanların anladığı üzere yaptığınız her yatırımın mevduat faizlerinin üstünde bir getirisi olmalıdır.

Anlaşılacağı üzere yeterli olgunluğa ulaşmış bir iş ihtiyacını gidermek için ilk yapılması gereken fizibilite çalışmasıdır. Her şirket, her birey, hepimiz kar için çalışıyoruz. “Attığımız taş ürküttüğümüz kuşa değecek mi?” değerlendirmesi hangi alanda ne iş yaparsak yapalım en önemli başlıktır.

Yeterli olgunluğa ulaşmamış ihtiyaçlara yönelik (“hele bir başlayalım da”) projelerde çalışmak, ne yapacağını bilmeden çalışmaya çalışmaktır. Projenin bir yere varmayacağını çalışan herkes hisseder, çoğu zaman ne yapacağını bilmeden vakit geçirir ve mutsuz bir proje ekibi kaçınılmazdır. Dolayısıyla geliştirmeye ihtiyaç duyanlar, analist veya proje yöneticisi -bu aşamada hangisi veya hangileri görevliyse- üzerinde çalışılan ihtiyacı belirli bir olgunluğa eriştirmek zorundadır.

Kısa bir fizibilite çalışması ve maliyet tahmini yapmadan çalışmaya başlamak ise ne kazanacağını öngörmeden çalışmaya başlamaktır. İhtiyacını kendisi yaratan mükemmel bir fikir yoksa çalışılan proje (IT projelerinin çoğunluğu gibi) rafa kalkacak ve verilen emek boşa gidecek demektir. Sonrasında rafa kalkan proje yeniden gündeme gelse bile refactoring gibi maliyetlerin doğmasına yol açacak ve motivasyon düşüklüğüne neden olabilecektir. Dolayısıyla her proje yöneticisi ve analist için çalıştığı alanda fizibilite çalışmasının nasıl yapılabileceğini bilmek çok önemlidir.

NOT: İş analizi konusunda birkaç basamak ilerledikten sonra iş ihtiyacı ve fizibiliteden başlayıp canlıya geçiş ve sürekli iyileştirme (continuous improvement) ile son bulan ve idealde ve gerçekte nerelerde çalışıldığını gösteren genel bir iş analizi zaman ekseni çizim paylaşacağım.

Yorum yaz

Email adresiniz yayınlanmayacaktır.