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…

Analiz, karmaşıklığın çözümlenmesidir. Bütünü parçalara ayırırken oluşturulan her parçanın da anlamlı olmasına dikkat edilmelidir. Hepimizin çok iyi bildiği analitik bakış açısı herkes için en önemli yeteneklerden bir tanesidir.

Gereksinim Analizi

Daha önce olgunlaşmış bir fikir gerekliliğinden ve bu fikrin fizibilitesinin yapılmasında bahsetmiştik. Bu aşamalar; iş birimi, talep sahibi, proje sponsoru, iş analisti veya proje yöneticisi tarafından yapılabilir.

Bir sonraki aşama ise gereksinim analizidir. Fikri analiz edip gereksinimleri netleştirmek ve bir yazılım projesi için yazılımcılara ne yapılması gerektiğini ifade etmek bu aşamada yapılması gerekendir. Bu aşamada en azından bir kez duyduğumuz tümdengelim (genelden özele) bakış açısı olmalıdır. Analiz bu açıdan Black-box’tan White-box’a uzanan bir süreçtir. (Analiz sürecinden bu şekilde bahsederken, testin ise tam tersi bir süreç olarak özelden genele ilerlemesi -tümevarım- gerektiği hatırlanmalıdır.)

Gereksinim analizini yaparken önemli olan öncelikleri doğru belirlemektir. Waterfall bir projede oluşturulacak çözümün tamamı için yapılacak analiz, agile süreçler söz konusu olduğunda doğru şekilde bölünmelidir. Agile için doğru bölünme ise Core’u doğru belirleyerek, bu core üzerine modüller şeklinde bir yapı oluşturmaktır. Bu yaklaşım tüm paydaşların işini kolaylaştıracak ve tüm ölçümlemelerin (değer, performans) daha doğru olmasını sağlayacakır. Core, çalışacak en küçük parçayı ifade ederken üzerine eklenecek her bir modül de çalışabilir ve UAT’ye (User Acceptance Test) çıkabilir parçalar olarak seçilmelidir.

Gereksinim analizi yazılım geliştirme sürecinin ilk aşamasıdır. Bu analiz genel bir kapsam planlayıp, bu kapsamın sınırlarına sadık kalınarak da yapılabilir veya bu ara popüler olduğu şekliyle adam/gün bazlı faturalandırma ile çalışan şirketler için sürekli iteratif ve sonu görünmeyen biçimde ilerleyen bir süreç de olabilir. Eğer sonu görünmeyen bir süreç ile çalışılıyorsa en azından nerede durulup, oluşturulan projenin bir değer olarak sunulacağı mutlaka kararlaştırılmalıdır. Yoksa işi yapanın da projenin de performansı ölçülemez.

Gereksinim Türleri

Gereksinimler farklı başlıklarla değerlendirilebilir. Bu farklı başlıklardan en popüler olanlar aşağıda listelenmiştir ve tamamı tek bir analistin sorumluluğunda olmayabilir.

• İş / Kullanıcı Gereksinimleri (Business Requirements) (İş analisti tarafından yapılır)
• İşlevsel Gereksinimler (İş analisti tarafından yapılır)
  • Fonksiyonel Gereksinimler
  • Fonksiyonel olmayan Gereksinimler
• Yazılım Gereksinimleri (Software Requirements) (Teknik analist veya yazılımcı tarafından yapılır)
  • Mimari Gereksinimler
  • Yapısal Gereksinimler
  • Sistemsel Gereksinimler

İlgili başlıkların tamamı veya daha fazlası hakkında internette fazlasıyla bilgi bulunmaktadır. Özellikle geçiş gereksinimleri mutlaka ortaya konulmalıdır. Bu analizler; user story, use case, aktivite/veri akış diyagramları, etkileşim diyagramları gibi farklı teknikler ile ortaya konulabilir. Scrum ile ilerleyen ve zaman kısıdının fazla olduğu projelerde timeboxing gibi teknikler uygulanabilir.

Gereksinimler belirlenirken kullanıcı arayüz (UI) ihtiyaçları göz ardı edilmemelidir. Bir mock-up uygulaması veya daha basit olarak visio çizimi ile arayüz ihtiyaçları kolayca ifade edilebilir.

Püf Noktalar

Analiz soru sorma işidir. En iyi analist doğru soruları sorandır. Analist için bir diğer önemli nokta ise nerede duracağını bilmektir çünkü sorarak asla dibi bulunmaz bir kuyuya dalmaya başlamış olabilir. Durulacak noktaları doğru belirlemek de analizde ne kadar yetkin olunduğunu ifade etmek için büyük önem arz etmektedir.

Gözlem gücü bir diğer önemli noktadır. Bunu bir örnek ile açıklayayım; bir programı değiştirmeye karar veren bir firmada mevcutta kullanılmakta olan  programın geliştirilebilecek yönlerine dair bir araştırma yaptığınızı düşünelim. Son kullanıcının yanına gidip, “bir görebilir miyiz nasıl çalışıyorsunuz” dediniz. Kullanıcı “başlat>tüm programlar” programı açmaya koyuldu. Analistin ilk düşünmesi gereken “Masaüstünde bir kısayolu yok, demek ki çok kullanılmıyor” olmalıdır.

Bütün projelerin gereksinimleri vardır. Burada önemli olan proje paydaşlarının ihtiyaçlarını, isteklerini ve beklentilerini (needs, wants, expectations) doğru adresleyebilmektir. Bunu yaparken varsa tespit edilen riskleri de belirtmek işin başında beklenmedik durumların ortaya konulmasını sağlar. Analiz aşamasında ortaya konulmasa bile analizi okuyan ilgililerin nerede risk olduğunu göreceği kadar açık bir analiz oluşturmak proje hızını ve projeye analist katkısını arttıracaktır.

Gereksinimleri toplamada; workshoplar, brainstorming aktiviteleri, mind maps, anketler, gözlemleme, grup kararları, tarihsel kayıtları inceleme, benchmark gibi farklı teknikler kullanılabilir. Hangi teknik (veya teknikler) ile ilerleneceği proje özelinde seçilir.

Analiz dokümanınızı mümkün olduğunca kısa ve anlaşılır tutmak ise analistin misyonu olmalıdır. Hazırlanan analiz ile eğer yoksa kapsam onayı alınacaktır ve tüm paydaşlar yapılan analiz ile projeye hakim olacaklardır. Hiç kimse iş hayatında 900 sayfalık bir analiz dokümanını okumaz. Dolaysıyla her paydaşa ilgilendiği alana dair yeterli bilgiyi sunarken kimseyi doküman okuma yükü altında ezmemek gerekir. Hazırlanan analizi okumak yerine, analiste sormak daha kolay gelirse; proje süresince bu yük analistin omzunda kalacak demektir.

Yeterli detay düzeyine de kısa bir örnek vererek ve değerlendirmenize bırakayım. Daha önce üzerinde çalıştığım bir projede hücresel gösterim ve hücre dolu/boşun renk ile ifade edilmesi şeklinde bir çalışma vardı. Yazılımda ilk gelen prototipi incelediğimizde dolu hücrelerin yeşil, boş hücrelerin ise kırmızı ile ifade edildiğini gördük. Yani bazen çalıştığınız insanlar tüm insanlığın kabullerine (meşgul kırmızı, uygun yeşil) kırmızı ile yeşili ters kullanarak meydan okumak isteyebilir.

Analizde asıl olan neye ihtiyaç olduğunu doğru anlamak ve anlatmaktır. Bir teknik kullanımı bilmek gibi konular her zaman ikinci planda olmalıdır. Yazılım dünyasına aşina olanların bildiği üzere; bir metodoloji, teknik ya da framework’ü yapılması gereken işin önüne geçirmeye çalışmak, bilişim sektörünün insanları yıpratmasının en büyük sebebi ve saçmalığıdır.