Biz böyle istememiştik!! Bu kelimeyi projelerin teslimi sırasında çok fazla duyarız. Hatta bu durumda proje teslim edilmemiş olur, konu Proje Yönlendirme komitesine taşınır, üst düzey değerlendirme yapılır. Genellikle sonuç; istenilen değişikliklerin yapılması için projenin teslim süresi uzatılır… ‘Biz böyle bir durumla karşılaşmadık, teslim ettiğimiz proje her zaman beklentilerin tamamını karşılıyor’ diyorsanız yazının devamını okumayabilirsiniz.

 PMI (Project Management Institue) der ki; ‘Projeyi planladığınız kapsamda tamamlarsanız, kapanışı gerçekleştirebilirsiniz. Proje kapanmış sayılır.’ Peki yönettiğimiz veya içinde bulunduğumuz projelerde bu gerçekleşiyor mu? Müşterinin isteğini (söylediğini değil) gerçekleştirmediğiniz durumda; ya müşteri tarafından zorla değişikliği yapıyoruz ya da müşterinin sahiplenmeyeceği bir ürünü ortaya çıkarttığınız için bir süre sonra ürünün yok olmasını izliyoruz. Peki proje sonunda bu cümleyi duymamak için ne yapmalıyız? Aklınıza çözüm olarak ‘Agile’ yöntemler gelmiş olabilir fakat henüz Agile bir dönüşüm sürecine girmediniz / giremediniz ve Waterfall yöntem ile ilerlemek zorunda kaldıysanız ne yapmalısınız?

1. Teslim edeceğiniz ürünün hazır bir versiyonu varsa mutlaka müşteriye gösterin, hatta kullanmasına izin verin. Agile projelerde ürünler parça parça teslim edildiği için bu konu çok büyük sorunlara yol açmamaktadır ama Waterfall projelerde kesinlikle ürünün kullanılmasına, fonksiyonel / kullanılabilirlik açıdan incelenmesine izin verilmelidir. Hatta mümkünse projeyi fazlandırıp, ilk versiyonda ürünün sade hali pilot olarak kullandırtılmalıdır. Scrum yapıyor olsanız bile ilk sprint e başlamadan önce ürünü göstermek faydalı olacaktır.
2. Müşterinin proje sırasında, çıkacak ürünle ilgili sorumluluğu almasını sağlayın. Ürünün sahiplenilmesi, sorumluluğunun müşteri tarafından alınması çok önemlidir. Ürünün sahibi olacak paydaşlara, ürünün proje sonunda onlara teslim edileceğine inandırın.
3. Üst yönetim desteği alın. Bu maddeyi birçok yazımda okumuş olabilirsiniz, her yazımda tekrar tekrar yazabilirim. Çünkü üst yönetim desteği projelerin başarısı, kabullenilmesi, doğru yürütülmesi açısından en önemli faktörlerden biridir. Üst yönetim desteği, müşterinin ürüne olan ilgisinin artmasına, daha kontrollü davranılmasına ve iletişimin dengelenmesine sebep olur. İletişimin dengelenmesi ne demek diyebilirsiniz; baskın bir müşteri veya çoğu konuya itiraz eden bir proje ekibindeki dengeleri sağlayan otorite diyebiliriz.
4. Mümkünse projenin her aşamasında referans alınacak dokümanları adresleyin. Günümüzde dokümantasyonun önemini artık hepimiz biliyoruz, projenin her fazında adresleyebileceğiniz, anlaşılabilir ve belirli standartları olan dokümanları oluşturun..

Herkesin beklediği ürünü teslim aldığı projeler yapması dileğiyle…

Merhaba;

Bu yazımda; proje yaşam döngüsündeki en önemli adımlardan olan ‘Müşterinin İhtiyacını Anlama’ kısmına değineceğim. ‘Yazılım Projelerinde Kalitenin Önemi’ isimli yazımda da belirttiğim üzere Kaliteli bir yazılım için ihtiyacı doğru anlamak en önemli safhalardan biridir. ‘İhtiyacın doğru anlaşılmaması’ yazılım projelerindeki başarısızlık nedenlerinde büyük bir paydaya sahiptir.

    İhtiyaca doğru odaklanmamızda etkili olduğunu düşündüğüm 5 temel kavram aşağıdadır.

• En önemli konulardan biri; eğer mevcut bir yazılımı müşteriye uyarlamaya çalışıyorsak, müşteriyi dinlerken; ‘müşterinin ihtiyacını kendi yazılımımıza nasıl adapte ederiz’ sorusuna odaklanırız ve ihtiyaca daha şeffaf bir bakış açısından ziyade, yönlendirme yapmaya başlarız. Bu yanlışı yapmamak adına; ihtiyacın çözümünü daha sonra düşünmeliyiz, önce ihtiyacı net olarak anlamalıyız.
• Müşteriden talebi dinlerken;ihtiyacın süslü taraflarına odaklanmayıp, ihtiyacın ana kısmını anlamaya çalışmalıyız. Pareto ilkesi (80’e 20 kuralı) ile baktığımızda; ‘müşterinin ihtiyacının % 80’i, geliştirilecek olan yazılımın % 20’lik kapsamında bulunmaktadır’  diyebiliriz. Bu nedenle asıl ihtiyaç olan % 20 ‘lık kısmı yoğunlaşmalı, kapsamın bu kısmı için daha net çözümler üretmeliyiz.
• İhtiyaca  doğru teknoloji ile uzun vadede çözümler üretmeliyiz. Müşterinin ihtiyacını karşılamak adına, pahalı ama gereksiz teknolojilere yönlendirmek veya tam tersi kısa sürede çözüm adına eski teknolojiler ile çözümler üretmek yanlıştır. Müşterinin yazılım ihtiyacının ömrüne göre; o süre içerisinde maksimum fayda minimum gider sağlayacak bir çözüm üretmeye odaklanmalıyız.
• Eğer şirketin organizasyon yapısı elveriyorsa; müşteri ile yazılım geliştirici arasındaki katmanları minimuma indirmeliyiz. Özellikle büyük firmalarda karmaşık süreçler ve ekipler olduğu için iletişimdeki kanal sayısı artmaktadır. İletişimde kanal sayısı arttıkça; parazit olma ihtimali de aynı oranda artmaktadır. Bu nedenle iletişimdeki katmanları minimuma indirmeli ve ihtiyacın ‘Talep Sahibinden Yazılım Geliştirici’ ye kadar olan döngüsünde parazite yer vermemeli ve ihtiyacın doğru anlaşıldığından ‘Onay alarak’ emin olmalıyız.
• Talebi doğru iletecek kişileri işin içine katmak… Bir önceki madde ile benzer bir konu aslında. ‘Talep sahibi ile Yazılım geliştirici’ arasındaki katmanları minimuma indirmeliyiz demiştik. Fakat öncelikle ‘Talep Sahibi kim?’ sorusunu doğru cevaplamalıyız. Doğru paydaşların talep sürecine dahil olmasını sağlamalı, eğer  doğru paydaşlarını analiz sürecine dahil edilmediğini düşünüyorsak, dahil etmeye çalışmalı, gerekirse bu konuda üst yönetim desteğini almalıyız

Tüm bu maddeleri yazılım geliştirme yöntemi fark etmeksizin uygulamamız daha doğru bir analiz için faydalı olacaktır.

Fizibilite çalışması yürütürken sorgulanması gereken en önemli şey daha önce de bahsettiğimiz “Attığımız taş ürküttüğümüz kuşa değecek mi?” kısmıdır.

Daha önce de bahsetmiştik; isterseniz bir Startup proje olsun, isterseniz mevcut bir yazılıma ek bir modül veya özellik ekleme olsun fizibilite çalışması yapılmalıdır. Fizibilite çalışmasının büyüklüğü ve ayrıntısı, yapılacak projenin büyüklüğüne göre değişebilmektedir. Dolayısıyla aylarca bir araştırma da gerektirebilir veya ilgili piyasayı bilen bir grup ile tartışma şeklinde de yapılabilir ama illa ki yapılacak işin getirisi ve götürüsü değerlendirilmelidir. (Fayda/Maliyet Analizi) Eskilerin deyimiyle Hilal-i Ahmer’e çalışmıyoruz illa ki bir gelir ve/veya fayda oluşturmalıyız.

Bu aşamaya kadar projenizin olgunlaşmış bir fikir haline gelmesi gerektiği değerlendirmiştik. Dolayısıyla bu fikrin ürün olarak sonuçlanması için ne kadar süre ve bütçe gerekir ve bu gider karşılığında ne kadarlık bir gelir veya fayda beklentiniz var, ana teması ile oluşturulan fizibilite çalışması yolumuzu aydınlatacaktır. Proje Yönetiminin %75 oranında planlama işi olduğunu ve fizibilitenin planlamanın temelini oluşturacağını da unutmamak gerekir.

Nasıl Yapılır?

Bahsettiğim gibi nasıl yapılacağı çalışmaya göre değişir. Genel birkaç başlık ve yöntem vererek örneklendirmek daha iyi anlaşılmasını sağlayacaktır. Özellikle Startup bir proje yapacaksak mutlaka değerlendirilmesi gereken birkaç başlığı belirtmek, yatırımcı aranmaya başlandığında nelerin mutlaka olması gerektiği konusunda da fikir verecektir. Bu aşamada parayı veren eli kendiniz olarak düşünüp “ben olsam para verir miydim?” diye düşünerek, gerçekçi ve ayakları yere basan bir çalışma yapmak önemlidir. Şişirilmiş bir fizibilite ile çalışmak en çok kendinizi kandırmak olur. Zaten şişirilmiş bir fizibilite ile yatırımcı bulabiliyorsanız kendi saadet zincirinizi kurabilirsiniz.

Şimdi sıfırdan yapılacak ve yapmak için yatırımcı bulmanız gereken bir proje için olduğunu düşünerek kademe kademe gidelim:

1. Özet ve Kapsam: Anlaşılacağı üzere olgunlaşmış fikrin ve kapsamının bir özeti bu aşamada mutlaka hazırda olmalıdır ki inceleyen kişiler (yatırımcı/karar verici) projeniz hakkında fikir edinebilsin.
2. Teknik Analiz: Kodlama dili/framework seçimi gibi kriterleri baştan belirlemek büyük avantaj sağlayacaktır. Teknik değerlendirmeyi projenizin en başında bir kere yapmak ve know-how’ı değerlendirmek büyük katkılar sağlayacaktır.

Modüler Yapı: Mümkünse proje modüller halinde bölünebilir ve araştırılabilir olsun. Böyle bir bölümlendirme hem proje çekirdeğini (Core diyelim) doğru belirlemeyi hem de fazlara bölmeyi sağlayacaktır. Günümüz dünyasında yazılıma para vermemek için elimizden geleni yaptığımız düşünülürse yazılımı mümkün olduğunca ucuz tutmak modülleme ile sağlanır.  Core ücretsiz veya çok düşük ücretli tutulurken, eklenen her modül küçük bir ek ücret ile sunulabilir. Bundan sonraki her başlık core ve modüller için ayrı ayrı yapılabilir ve büyük projeler için bunu yapmak büyük fayda sağlayacaktır.

Aynı zamanda önceliklerin belirlenmesi de bu aşamada yapılmalıdır. Öncelik belirlemede MoSCoW methodunu örnek olarak verilebilir.

MoSCoW Metodu: Must, Should, Could, Won’t olarak başlıklara bölerek proje önceliklerini belirlemek amacıyla kullanılan bu metottur. Bu metot ile bölünmüş projenin zaman ve maliyet analizleri her başlık için ayrıca yapabilir ve Won’t kısmı netleştirilebilir.

3. Zaman ve Maliyet Analizi: Projeyi gerçekleştirmek için elbette maliyetler olacak. Maliyetleri kalem kalem belirleyip bütçelemek sapmaların da erken farkına varmayı sağlayacaktır. Kodlama (işçilik), Server vs ne maliyetiniz varsa belirtmek gerekmektedir. İşçilik maliyetini belirtmek için zaten kabaca bir zaman tahmini yapılmalıdır. Örneğin biz iki yazılımcı ile bu işi bir yılda yaparız derseniz 24 adam/ay olarak maliyet ortaya çıkmış demektir. (tabi düzenli değil mevcut işiniz dışında çalışacaksanız ona göre bir tahminleme gerekmektedir.) Bu değerlendirme yapıldığında kabaca bir zaman ve maliyet tahmini bulunmakta ve bütçeyi belirleyecek referans bilgiler gösterilebilir durumdadır. Şu an projenin başlangıç (initiation) aşaması ve PMI (Project management Institute) der ki proje tahminlerinde (özellikle de maliyette) başlangıçta yapılan tahminler genellikle -%25 ile +%75 arasında değişiklik gösterebilmektedir. Yani hem zaman hem de maliyet yönünden buffer da belirlenmelidir.
4. Pazar Analizi: Projeyi bitirdiniz, peki satabilecek misiniz? Kullanıcılar alternatifler varken sizin projenizi kullanacaklar mı? Mutlaka acaba satabilir miyiz, satarsak hangi platformda satacak, nasıl reklam yapacağız soruları düşünülmelidir. Kısacası pazarlama kanalları belirlemeli ve ne kadar sürede geri dönüş alınabileceği düşünülmelidir.

Bu ana başlıkları değerlendirmek için sıfırdan kurulan bir işletme veya sıfırdan yapılma bir proje olsun farklı alt başlıklarda analiz teknikleri mevcuttur. Özellikle SWOT Analizi, PESTLE Analizi, Porter 5 Güç Modeli öne çıkan metotlardır. Biri veya daha fazlası kullanabileceği gibi, bu metotlarda yapılan proje ile ilgisi olmayan başlıklar değerlendirmeden çıkarılabilir. Bahsedilen bu metotlarla ilgili ninternette fazlasıyla kaynak mevcuttur. Sadece çoğunluğunun işletmeler hakkında olduğunu gözden kaçırmayıp, proje için de kullanılabileceğini akıldan çıkarmamak gerekir.

Mümkünse usta bir yatırımcı gibi her noktada (zaman, maliyet, pazar gibi) Take Profit (TP – Kar al) ve Stop Loss (SL – Kaybı durdur) noktaları da belirlenmelidir. Ne kadar devam edip nerede çekilineceğinin bilinmesi her şeyin plana uygun olmasını sağlayacaktır. En nihayetinde Dark Kmight filminde Joker karakterinin de söylediği gibi bir şey plana uygun gidiyorsa kimse paniklemez.

Fizibilite çalışması yapılırken en çok yapılan hata iyimserliktir. Maliyeti ve zamanı iyimser tahmin etmek, pazar analizinin doğru yapılmayarak yatırım geri dönüşlerinin hızlı ve yüksek olacağını düşünmek gibi iyimserlikler ileride projenin rafa kalkmasına ve bıkkınlık oluşmasına neden olacaktır.

NOT: SWOT, PESTLE ve Porter 5 Güç gibi yöntemler genellikle işletmeler için yapılırken projeler için yapılabileceği es geçilmektedir.

Maalesef çok şey var…

Toplum olarak bazı işlere bakışımız popülaritenin ötesine geçemiyor. Proje Yönetimi, Analiz (İş, Gereksinim vs.), Risk Yönetimi, Stratejik 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.