NE VEREYİM ABİME

Çok sıkça duyduğumuz bir karşılama konuşmasıdır:

“-Ne vereyim ağğbime!”

“-Ne vereceksin bana!”

Özellikle restoran ve kafelerde garsonlarla mekanın müdavimleri arasında bu tür diyaloglar gerçekleşir. Önceden oluşan tanışmışlığın ve samimiyetin bir ifadesidir aslında. Bunu ünlü komedyenlerimizden Cem Yılmaz da bir gösterisinde esprili şekilde kullanmıştı. Garsonluk; hizmet sektörünün en önemli mesleklerinden birisidir. Restoranların, kafelerin veya benzeri yerlerin müşteriye bakan yüzüdür. En kaliteli malzemelerden, en kaliteli yemekleri yapsanız bile asık suratlı, sevimsiz ve iletişimsiz bir garson hizmet veriyorsa her şey boşa gidebilir. Kimi zaman vasat bir mekan, sırf garsonlarının hizmet kalitesi nedeniyle tercih edilebilir. Bu nedenle, müşteri ile garson arasında sıkı bir iletişim bağı vardır, olmalıdır.

Projelerimizde de müşterilerimiz önemlidir. Müşteri memnuniyetini sağlamak ve devam ettirmek projenin başarısı için önemli kriterlerden birisidir. Üründen veya hizmetten memnun olan müşteri, sonraki projelerin ortaya çıkması için fırsat yaratacaktır. Bu yaklaşımla ele alınırsa, proje ekibimiz de müşterilerimize hizmet veren garsonlar gibi düşünülebilir.

 

“Proje yöneticisi bir garson gibi davranabilir mi, davranmalı mıdır?!”

 

Soru çok basit gibi görünse de cevabı çok derinlik içermektedir. Bütün projeler en az bir gereksinimden, ihtiyaçtan veya talepten ortaya çıkar. Dolayısıyla her projenin en az bir müşterisi vardır, olmalıdır. Projelerimizde müşterilerimiz kimi zaman bir kişi veya kurum olabilir, kimi zaman da toplum, ülke veya tüm dünya olabilir. Projenin gereksinimlerini elde etmek, ortaya çıkarmak çok önemli bir süreçtir. Projenin kapsam yönetimi buna bağlıdır. Gereksinimlerin detaylandırılması, belirsizliklerin giderilmesi ve en sonunda müşteri ile anlaşılması gerekmektedir. Fakat bu hiç de öyle kolay işler değildir!

Gereksinimleri belirlemek için yapılan toplantılarda ya da çalışmalarda hemen müşterinin istekleri alınmak istenir. Bununla birlikte, proje yöneticisi veya sistem/gereksinim sorumlusu ya da analisti müşterilere “Ne istersiniz efendim” diye yaklaşmamalıdır. Müşteriye “ne istersiniz?” diye sorulduğu zaman onlar da “ne vereceksin bana!” diye bir beklenti içine girer. İşte burada tehlikeli bir döngüye girilebilir..

“-Ne istersiniz efendim?”

“-Şunu isterim, böyle olsun”

“-tabii, başka ne istersiniz?”

“-ayrıca şu da olsun”

“-bunu şöyle ister misiniz?”

“-aa evet öyle olsun..”

 

Proje gereksinimlerini elde ederken; maliyet, zaman ve kaynak kısıtları düşünülerek yaklaşılması gerekir. Müşterilerimizin istekleri sınırsızdır ancak kaynaklarımız sınırsız değildir. Bu nedenle her bir gereksinim için bu kısıtlara göre etki analizi yapılmalıdır.

İyi şeyler söylüyoruz da, bunları yapmak hiç de kolay değil!

Bir yandan müşteri memnuniyetini arttırmaya çalışırken, diğer yandan da projenin kısıtları arasında sıkışıp kalıyoruz. Bir tahterevallinin iki ucu gibi konular bunlar. Dengeyi bulmak ve korumak çok zor.  Bunun için 3 farklı yöntem önereceğim:

• ·         Konsept çözüm sunma
• ·         Alternatif çözümler arasında tercih
• ·         İşbirlikçi çözümler üretme

Konsept çözüm sunma yönteminde müşterimize elimizdeki hazır çözüm(ler) önerilir. Bunu bir restoranda tek tip yemek sunulmasına benzetebiliriz. Garsonun müşterilerine “bizde sadece çöp şiş bulunuyor, yanında bir ikramlarımız olur” demesi gibidir. Burada müşteri seçim yapmak durumunda kalmamaktadır. Bazı müşteriler bunu tercih ederler. Çünkü konsept bellidir. Çöp şiş yemek yerine kuru fasulye, pilav isteyemeyecektir. Projelerimizde de eğer güçlü ve sağlam bir çözümümüz varsa, müşterimizi bu konuda ikna etmek iyi bir yöntem olabilir. Ancak sunulan yöntem iyi ve hatasız değilse, sonucu fiyasko olacaktır. Elimizdeki argümanlara güvenmediğimiz sürece konsept çözüm yönteminden uzak durulmalıdır.

Alternatif çözümler arasında tercih yapma yönteminde ise müşterimize birkaç çözüm yöntemi arasından seçim yapması istenir. Ancak burada önemli nokta müşterinin seçim yaparken ne kadar özgür bırakıldığıdır. Eğer sunulan tercihler birbirine yakın ve benzer kısıtlara sahipse, müşterinin tamamen özgür tercih yapması istenebilir. Bu durum, müşterinin bir mağazada mavi, siyah, kırmızı renkli kazaklardan istediğini seçmesine benzetilebilir. Sonuçta maliyet, zaman ve kaynak açısından çok farklılık yoksa müşterimiz istediğini seçebilmelidir. Bazen ise müşteriler en uygun çözümü seçmesi konusunda yönlendirilirler. Bu durumda en avantajlı çözümün yanında en dezavantajlı çözümler sunulur. Buna “hastayı ölümle korkutup, sıtmaya razı etme” denilebilir. Ancak elimizdeki çözümlerin maliyet, zaman ve kaynak analizleri doğru yapılmadığı zaman alternatifler arasından tercih yapma yöntemi sıkıntı yaratacaktır. Bir anda hiç istenilmeyen bir çözümün tercih edilmesiyle karşılaşılabilir.

İşbirlikçi çözümler üretme yönteminde ise çözüm, müşteri ile birlikte üretilir. Böylece gereksinimlerin analiz edilmesinde müşterinin katılımcı olması sağlanır, analiz sonucuna göre müşteriden çözüm konusunda da önerileri istenir. Karşılıklı bir uzlaşmaya varana kadar bu süreç işletilir. Bu yöntem hem zaman alması hem de çok fazla değişiklik yapılması gerekebileceği için sıkıntılı olabilir. Ancak yüksek müşteri memnuniyeti açısından en avantajlı yöntemdir. Özellikle çevik proje geliştirme yöntemlerinde bu yaklaşım tercih edilmektedir.

 

“Ne vereyim ağbime” demek proje yönetiminde her zaman uygun değildir. Yoksa;

“Bindik bir tahterevalliye, gidiyoruz kıyamete..” olabilir.

 

Bardağın Dolu Tarafı

Bardağın Dolu Tarafı

Dünya amansız bir salgının pençesinde kıvranırken, ülkemizde de bazı önlemler alınmaya çalışılıyor. Ancak toplumsal farkındalığın yeterince sağlandığını söylemek çok zor. Eskiden gelen "bize bir şey olmaz" veya "bize bulaşana kadar çaresini birileri bulur" anlayışı nedeniyle bilerek veya bilmeyerek salgının yayılmasına sebebiyet oluyorlar. Devletin bazı kısıtlamaları da bunu önlemekte yetersiz kalabiliyor. Sanırım daha sıkı önlemler alınacak. Virüsün dünya üzerinde ekonomik, siyasi ve toplumsal birçok yapıyı ve dengeyi yerinden sarsacağını görmek çok kolay. Şimdiden Avrupa Birliği içinde birbirlerine yeterli destek vermeyen ülkelerin, birbirlerini suçladıklarını görüyoruz. ABD bu konuda Çin'i suçluyor. İngiltere virüsle savaşta geç kalmakla suçlanıyor. Buna benzer başka görüşler vs..




Bundan birkaç ay öncesine kadar dünya farklı konular konuşuyordu. Tüm dünya dijital teknolojileri ve teknolojilerin tüm dünyayı nasıl küreselleştirdiğini överek anlatıyordu. Her konferansta Steve  Jobs amcadan örnekler verilerek, mobil dünyada yazılan birkaç teknolojik gelişmeyi ağızlarından sular akıtarak anlatıyorlardı. Sanki tüm dünya hipnotize olmuş bir halde, "neden biz bunu yapamadık" diye hayıflanıyordu. Google, Facebook, Linkedin, Instagram ve diğerleri herkesin dilindeydi.. "Abi küçücük çocuk bir yazılım yazmış, binlerce dolar kazanmış" diye birbirlerini motive etmeye çalışan gençler vardı.

Teknoloji uzmanlarının katıldığı bir seminerde, yine benzer şekilde dijital teknolojilerin hayatımızı ne kadar değiştirdiğini konuşuyorduk. Orada bir uzmanla aramızda geçen sohbette; "dijital teknolojilerin, üretim ve somut araştırma-geliştirme çalışmaları yapılmazsa yetersiz olacağını, illa ki üretim ve fabrikaların olması gerektiğini" anlatmaya çalışmıştım. Karşımdakiler ise yine Facebook ve Google örneklerini vermeye devam etmişlerdi.  Bir virüs çıktı, gündemi değiştirdi.

Herkes neden sağlık teknolojilerine önem verilmediğini, neden aşı fabrikalarımızın olmadığını, nasıl ilaç üretebileceğimizi konuşmaya başladılar. Somut bir şeyler üretemiyorsak, sayısal teknolojiler yetersiz kalıyor. Her zaman aynı şeyi söyleyeceğim: Fabrika ve üretim yapmamız şart!

Geçmişteki bir yazımda Maslow Teorisi ve İhtiyaçlar Piramidi konusuna değinmiştim. Burada belirttiğim gibi piramidin tabanında fizyolojik ihtiyaçlar vardır. Açlık, susuzluk gibi yaşamsal gereksinimler bu kategoridedir ve insanın yaşamını sürdürebilmesi için en önemli olanı bu ihtiyaçlardır. Fizyolojik ihtiyacını gidermemiş bir kişi için diğer ihtiyaçların bir önemi yoktur. Yani aç veya susuzken dijital teknolojiler anlamlı olmayabilir. İkinci basamak güvenlik ihtiyacıdır. Burası dış tehlikelerden korunmayı içerir. Bu ihtiyaç, korunma, barınma, kural ve yasalara uyma gibi gereksinimlere dayanır.

Bugün geldiğimiz noktada salgın bizim yaşamımızı etkiliyor ve korunma gereksinimimizi ortaya çıkarıyor. Tüm insanlık yaşamsal ve korunma gereksinimlerini garantiye almadığı sürece sonraki gereksinimlerin karşılanması yeterli olamayacaktır. Bir virüs çıkar ve piramidin tabanına kadar bizi indirir.

Bu virüs salgının bazı faydaları olacağını ümit ederek, bardağın dolu tarafına bakmak istiyorum. Eğitimin aksamaması için geliştirilen uzaktan eğitim teknolojilerinin kullanılması çok önemlidir. Klasik okulda eğitim konusunun gelecekte tamamen ortadan kalkıp, uzaktan eğitim imkanları sağlanırsa; yeterli eğitim alamayan taşradaki öğrenciler için fırsat eşitliği sağlanacaktır. MEB'in bu konuyu daha ciddiye alıp, salgın gibi olağanüstü durumlar dışında da kullanılabilirliğini değerlendirmesi uygun olacaktır. Kim bilir, bu sayede taşrada bir köydeki çocuk da, büyük şehirlerdeki diğer öğrenciler gibi kaliteli bir eğitime erişim imkanına sahip olacaktır.

Bardağın dolu olan diğer tarafı ise, tamamen kapitalist düzenin kurallarına göre biçimlendirilmiş ekonomik sistemlerin, dışarıdaki diğer ülkeleri de dikkate alması gerektiğidir. Dünyamızda artık hiçbir devlet diğerlerinin sorunlarından bağımsız değildir. Çin'de çıkan bir salgın İngiltere'de, İtalya'da İspanya'da veya diğer gelişmiş, teknoloji zengini ülkeleri derinden etkileyebilmektedir. Bize bir şey olmaz demek artık imkansız. Bugün Çin'de çıkan salgının benzeri gelecekte Afrika'nın bir ülkesinde veya Güney Amerika'nın  dağlarında çıkabilir. Avrupa ve ABD bundan sonra bizi ilgilendirmez diyemeyecektir.

Dünya artık küçük bir köydür ve ülkeler birbirine ulalı evlerdir. Bir evde çıkan yangın, tüm köyü sarabilecektir. Bu nedenle, kapitalist düzenin ortaya koyduğu "ezebileceğin kadar ez, hatta yok et" anlayışının sonuçları bir gün sizi de vuracaktır. Çin'deki salgın sırasında Avrupa önlem almayı gerek bile görmedi. İran'a sıçradığında da sessiz kaldı. İtalya'ya sıçrayınca kısmen düşünmeye başladı. Şimdi ise tüm dünya etkilendi. Trilyonlarca dolar yatırım yapılsa da bu salgının yarattığı yıkımın üstesinden gelmek zorlaşacaktır. Çünkü güçlünün de üstesinden gelen minik güçlü bir varlıkla mücadele ediliyor.

Dünyanın savaş ve öldürücü silah teknolojilerine yaptığı yatırımları, sağlıklı bir dünya için yapmasının farkına varılmıştır. Bugün en gelişmiş silah sistemleri virüsü yok edemiyor.

Bardağın dolu tarafından bakmanın zamanı geldi. Umarım artık vahşi gelişmiş ülkelerin anlayışlarını revize edeceği günler de gelecektir.

Güzel günler göreceğiz, inanıyorum.

Etkili Analistlerin Davranışları -3

Not: 2002 yılında yazdığım ve yayımlanan bir makalemi paylaşmak istedim

Etkili Analistlerin Davranışları -3

Başarılı bir analist olmak için gereken bazı önemli özellikleri sıralamaya devam ediyoruz.  

İşbirliği Ortamı Yaratma

Yazılım geliştirme sürecinde, kullanıcılar, geliştiriciler, pazarlamacılar ve yöneticiler arasında zoraki de olsa bazı ilişkilerin doğması sağlanır. Bütün bu gruplar birbirlerinin yaptığı işin değerini anlamayabilir veya işe verdikleri öneme,  kısıtlarına ve ihtiyaçlarına inanmayabilir. Gerçekte ise birçok ortak amaç ve zorluklara sahiptirler. Bütün bu gruplar aynı iş ortamında çalışmaları nedeniyle sistemin getirilerinden baştan sona ortak bir şekilde faydalanacaklardır. Ürünün başarısı için tüm bu grupların birbirlerini tetiklemesi gerekecektir. Herşeyin kazanmak-kazanmak  felsefesi için yapılması gerekir. Kazanmak-kazanmak başarımı için ise öncelikle dürüst olmak gerekecektir. Proje ekibindeki tüm grupların, yöneticiden geliştiriciye kadar herkesin bilgi paylaşımında bulunması gerekecektir. Böyle bir ideal ortamı sağlamak elbette zordur ama mantıksız kişileri bir araya getirmek, işbirliği ortamını baştan yok etmek demektir.

Öncelikle iş gereksinimlerini tanımlamak, müşteri ve geliştiriciler için beklenilen kazançların daha fazla açığa vurulmasını sağlayacaktır. Tüm katılımcılar da projenin maliyeti ve kısıtları hakkında dürüst olup, bilgi paylaşımına fazlaca katkıda bulunacaklardır. Analistler, müşterinin zaman planı ve maliyetlerini gerçekçi bulmaz ise bunun sebepleriyle birlikte açıklamasını yapması gerekecektir. Anlamsız maliyetlendirme ve zaman planı, tüm paydaşların teknoloji, zaman ve kaynak açısından alacağı tüm kararlarını etkileyecek ve beklentilerini değiştirecektir. Bu noktada analistin proje yönetimi ile iletişimli olarak geri beslemelerde bulunması gerekecektir.

Analistin müşteri ile konuşmak için zamanının olmaması veya neler istenildiğini biliyor zannetmesi düşünülecek şey değildir. Analist müşteri ortamındaki anahtar konumdaki tüm kişilerle uygun işbirliği ortamını hazırlamak zorundadır. Müşteri temsilcileri, kendilerinden tam olarak ne istendiği belirtilmedikçe, katılımcı olmak konusunda tereddütlü davranabilirler. Bu durumda müşteri temsilcilerine katılım konusunda bir yazı yazıp, her seviyedeki işbirlikçilerle görüşmek ve onları ortamın içine çekmek istenmelidir. Vizyon dokümanı, doğru kişilerle konuşmayı seçmeyi sağlar ayrıca müşteriye ürün daha anlaşılır kılar.Yetersiz kullanıcı katılımı projeyi başarısızlığa götüren temel nedenlerden biridir. Bu noktada gereksinim görüşmeleri için zaman harcamak istemeyen dik kafalı kullanıcı ve yöneticilere dikkat etmek gerekir. Yetersiz kullanıcı katılımı nedeniyle problemler yaşanılan önceki projeleri hatırlamak ve müşterilere örnekler sunmak çözüm açısından yardımcı olacaktır. Hemen hemen her organizasyonda yeni sistemin istenilenleri karşılamayacağı, kullanılabilirliğinde sorunlar yaşanacağı, performans sorunları oluşacağı şeklinde kötümser hikayeler yaratılır. Kullanıcı ihtiyaçlarının yeterince anlaşılması ve paylaşılması, projenin başarımını da etkileyecektir.

Becerileri Yenileme ve Etkinleştirme

Gereksinim analistinin temel fonksiyonu, geliştirici ile müşteri arasıdaki projeye olan bakış açılarından kaynaklanan boşlukta bir köprü görevi görmektir. Yetenekli bir analist, iletişim kurabilme, basitleştirebilme, kişiler arası becerilere sahiplik ve teknik açıdan işin etki alanına hakim olabilme yeteneklerini kendisinde toplamalıdır. Çok iyi bir programcı ile sisteme hakim bir kullanıcının bir analist olabilmesi için uygun hazırlıktan geçmesi gerekir. Bütün bu üstün özellikler analist olmak açısından yeterli olamamaktadır. Kazanılması gereken bazı önemli yetenekler şunlardır:

•    Kolaylaştırıp, basitleştirebilme
•    Görüşme Teknikleri
•    Dinleme yeteneği
•    Yazma yeteneği
•    Organizasyonel yetenekler
•    Kişiler arası beceriler
•    Modelleme yeteneği

Etkili bir analist, elindeki araçların hangisini nerede kullanıp kullanmayacağını iyi bilir.  Bu araçlar çok geniş bir yelpazeye dağılmıştır. Örneğin, içerik diyagramı, veri-akış diyagramı, UML gösterimleri bu araçlardandır ve bir analistin koleksiyonunda gerektiğinde kullanılmak üzere beklemelidirler. Etkili bir analist yolu üzerindeki engelleri tespit edip, uygun araçları seçerek bu engelleri ortadan kaldırmaya çalışır. Bunlara rağmen tecrübenin yerini hiçbir şey  tutamaz. Tecrübeli bir analist tarafından yazılacak bir gereksinim dokümanı, acemi biri tarafından yazılacaktan iki kat daha hızlı ve daha az hata içerecek şekilde yazılır. Geliştiricilerinin gereksinimleri yazabileceğini isteyen bir organizasyon ise, kalite ve organizasyon yapısından gitgide uzaklaşır.

Yazılım ürünleri için gereksinimler, analist şapkası giymiş birinin toplaması için ortada yayılmış durumda beklememektedir. En azından gereksinimler kullanıcıların, geliştiricilerin kafalarında çekip çıkarılmak ve uygun formlara dönüştürülmek için beklemektedirler. Gereksinimler, kullanıcıların ihtiyaçlarını belirlemek konusunda yardımcı olan, kullanıcıların ne istediklerini ortaya çıkarıp, geliştiricilerin de ihtiyaçlarına göre bunları düzenleyen bir analist tarafından keşfedilmeye ihtiyaç duyarlar. Gereksinim analistlerinin projede az ama önemli bir rolü vardır.

Kaynaklar: 

 Habits of Effective Analysts /Karl E. Wiegers - Process Impact www.processimpact.com 

To Be Reqirements Analyst /Karl E. Wiegers -Process Impact www.processimpact.com

Etkili Analistlerin Davranışları -2

Not: 2002 yılında yazdığım ve yayımlanan bir makalemi paylaşmak istedim

Etkili Analistlerin Davranışları -2

Başarılı bir analist olmak için gereken bazı önemli özellikleri sıralamaya devam ediyoruz.

Çizgileri Belirlemek

Birçok projenin sınırları yazılı olarak belirlenmediği için neyin kapsam içinde, neyin dışında olduğu bilinemez ve bunun sıkıntıları zamanla ortaya çıkar. Yeni sistemin gereksinimlerini tanımlamaya öncelikle sistemin veya ürünün vizyonunu ve ne olup neler yapması gerektiğini ortaya koymakla başlanmalıdır. Sistemin iş gereksinimlerini tanımlamak ve vizyonu ortaya çıkarmak  için projenin pazarlama sorumlusu ve/veya finansal destekçisiyle iletişim içinde olmak, gerekirse hazırlanmış uygun bir doküman sunmak gereklidir. Son ürünün vizyonu tanımlamak zor olduğundan başlangıçtan son ürüne kadar her bir sürüm ve aşamanın vizyonlarını tanımlamak gerekecektir.

Gereksinimleri ortaya çıkarma görüşmelerinde önemli olan kullanıcıların sistemle neleri başarmak istedikleridir. Görüşmeler daha çok fonksiyonellik, kalite kriterleri ve çözüm önerileri odağında geçer. Bu kriterlerdeki ufacık bir bilgi bile kullanıcıların kafasından geçenleri anlamak için gerekli ve önemlidir. Bununla birlikte kullanıcıların bu sistemi kullanma hedefleri, bu sürecin verimli olmasında ve fonksiyonel gereksinimlerden tasarım arayüzlerinin çıkarılmasında oldukça etkilidir.

Açığa Çıkaran Sorular Sormak

Analist olarak çalışırken, kullanıcılarla yapılan oturumları kolaylaştırmak ve basitleştirmek gerekir. Müşteri temsilcisinin  daha önce hiç bahsetmediği bir görev hakkında alternatif yolları deneyerek kullanıcılara sorular sormak ve diğer görevlerle olan ilişkileri ortaya çıkarmak gerekir. Kullanıcının sorulara verdiği cevaplar o senaryo için olmazsa olmaz ve yapılsa iyi olur gibi ifadeler içerir. Böylece kullanıcı senaryolarının da iş akışı ortaya konulmuş olur. Kullanıcılar, sistemin doğru ve beklenildiği gibi çalışmasına odaklanırlar. Analist bunun yanı sıra beklenilmeyen durumlar için de uygun senaryoları hazırlamalıdır.  Hata durumlarında uygulama geliştiricinin ele alması gereken kontrolleri, zaman zaman kullanıcılardan da yardım alarak tanımlamalı ve hata durumlarını yönetmelidir. Bu öncelikle sistemin güvenilirliği ve tutarlılığı açısından önemlidir.

Yaratıcı ve bilgili bir analist, kullanıcıların söylediklerini birebir kaydetmek yerine alternatif bakış açıları ve öneriler sunar. Kullanıcılar bazen uygulama geliştiricilerin yeteneklerinin farkında olmayabilirler. Önerilecek fikirler ile sistemin daha kullanışlı olması sağlanabilir. Zaman zaman da kullanıcıların iş yapışını izleyerek, otomatikleştirilebilecek olan süreçler hakkında bilgiler verilerek, kullanıcıların sistemin kullanılabilirliğine olan bakışı arttırılabilir. Önceki sistemlerde kullanılmış bir fonksiyonel yapının tekrar kullanımının sağlanması, kullanıcıların gereksinimlerini yeniden gözden geçirmesini ve düzenlemesini sağlayacak ve yeni yapılar üzerinden yeni gereksinimleri düşünecektir.

Etkili bir analist birçok düzeyde soyutlama yapabilmelidir. Kullanıcının bildirdiği belirgin özellikteki gereksinimlerin, diğer kullanıcıların gereksinimleri ile ilgili olup olmadığını ve aralarındaki ilişkileri sağlamalıdır.  Bir konudaki önemli noktaları ortaya çıkarmak, belirsizlikleri yok etmek, anlaşmazlıkları ortadan kaldırmak, öngörü ve varsayımları belirlemek, beklentileri karşılamak için soru sorma sanatına hakim ve yetenekli olmak gerekir ve bu da çoğunlukla tecrübeye dayanır.

Önceliklendirme

Gereksinim geliştirme süreci, bulanık, her bir aşama için belirsiz tanımlardan detaylı belirtimlere giden döngüsel-artımlı bir süreçtir. Her aşamada doğru soyutlama düzeyine odaklanmak gerekir. Birden tasarıma dalmak veya detaylara girmek, sistemin ve sürecin hataya düşmesine neden olabilecektir. Kullanıcı arayüz ekranlarından veya prototiplerden gereksinimleri ortaya çıkarmak ve her aşamada gerektiği kadar detaya girmek sistemi doğru anlamak açısından önemlidir. Temel yapılması gereken şeylerin yapılmamış ve daha az önemi olan özelliklerin yapılmış olması, yazılım takımının cesareti kırıp, müşteriye ümitsizliğe yöneltir. Bu sebepten analist elde ettiği gereksinimleri önceliklendirmelidir. Herkes kendi işini çok önemli ve öncelikli görür. Analist bu noktada tüm kullanıcı sınıfları ve geliştiriciler arasında gerekli iletişim ve işbirliğini sağlayarak hassas öncelikli kararları almalıdır.

Gereksinim geliştirmede öncelikle katkıda bulunabilecek kullanıcı sınıfları oluşturulmalıdır. Bunu yaparken beğenilen, gözde ve beğenilmeyen gruplarla gereksinim geliştirmeye katkıda bulunmayacak grupları ayırt etmek gerekecektir. Tabii olarak beğenilen ve gözde sınıfın gereksinimleri de varolan çatışmalardan arındırıldıktan sonra öncelikli olacaktır.

Devam edecek.

Etkili Analistlerin Davranışları - 1

Not: 2002 yılında yazdığım ve yayımlanan bir makalemi paylaşmak istedim.

Etkili Analistlerin Davranışları - 1

Yazılım projelerinin belli başlı süreçlerinden birisi de gereksinimleri elde etmek ve bunları belli kategoriler ışığında organize edip tasarıma girdi olarak hazırlamaktır. İş geliştirme aşamasından ve proje planının  belli olmasından sonra yazılımın ve sistemin gereksinimleri ortaya çıkarılmaya başlanır. Bu görevde sorumluluk gereksinim analistlerine düşer. Böyle olunca da müşteri ortamında sürekli bulunup geri beslemeler yapan ve bu gereksinimleri organize eden analistlere ihtiyaç doğar. Yazılım yöneticileri zaman zaman, bu konuda hiç bir eğitim almamış ama  müşterilerle iyi ilişki kuran  bir programcının, müşteri gereksinimlerini belirleyip bunları yazabileceği kanısına kapılırlar. 

Proje yönetimi, ön kestirim   yapabilme gibi özel yetenek gerektiren işlemlerin nasıl kendine özgü eğitimleri ve yetenekleri olması gerekliyse, gereksinim belirleme işlemi de özel yeteneklere ihtiyaç duyar. Kendi kendine çalışarak veya iş tecrübesiyle gereksinim mühendisliği tek başına başarılamaz. Bir çok yazılım mühendisliği eğitimi veren bölümlerin vurgulamasına rağmen,  programcılık alanında yeterlilik, projelerin tüm aşamalarının üstesinden gelmeyi sağlamaz.  
 

Gereksinim analistlerinin projedeki rolü, proje yöneticileri veya uygulama geliştiriciler tarafından yerine getirilemeyecek kadar önemli ve can alıcı bir niteliğe sahiptir, sahip olmalıdır. Kullanıcı1ık geçmişi olan bir analist teknik konularda yetersiz kalabildiği gibi, programcılıktan analistliğe geçen bir kişi ise iş süreçleri konusunda yetersiz kalabilmektedir. İşte bu aşama her yazılım geliştirme organizasyonu, yazılım geliştirme süreçlerinin diğerlerinde tüm zamanını harcamayacak olsa bile, mutlaka konusunda bilgili gereksinim analistlerini, uygun formasyon ve eğitim ile yetiştirmek zorundadır. Başarılı bir analist olmak için gereken bazı önemli özellikler şu şekilde sıralanabilir.

 İletişim Köprüsü kurmak

Analistler, müşterinin belirsiz ve karmakarışık düşünce ve gereksinimleri ile geliştiricilerin istediği açık ve iyi tanımlanmış belirtimler arasında yer alan boşluğu ortadan kaldıran bir köprü görevini üstlenirler. Her iki tarafa eşit mesafede ama her iki tarafın isteklerini karşılayan bir orta-adam rolünü oynamalıdırlar. Bir analist önce kullanıcı ihtiyaçlarını belirleyip, bunlardan fonksiyonel gereksinimleri ve kalite hedeflerini tanımlamalıdır. Fonksiyonel yaklaşımlar da kalite için her zaman bir anahtardır.

İyi bir analist olmak için, okuma, yazma ve dinleme olmak üzere iletişimin tüm yöntemlerine hakim olmak gerekir. Örneğin pazarlama veya sunum yapan bir proje yetkilisi ile olan iletişim halinde olan bir analist, o kişilerin iş süreçlerine ve uygulamalarına odaklanabilmelidir.  Özellikle bir analistin, müşterinin işine özgü kelime ve terimlere hakim olması, gereksinimleri elde etmek amacıyla kurduğu iletişimdeki anlaşmazlıkları ve hataları ortadan kaldıracaktır. Hatta bunun yanı sıra  gereksinim dokümanına ek olarak bu terimleri içeren bir sözlük de eklenmelidir ve gereksinim dokümanları mümkün derece müşterinin kullandığı terimleri içermelidir. Analistin bu terimlere katacağı farklı anlamlar, müşterinin anlamayabileceği bir doküman üretilmesine yol açacaktır. Uç kullanıcılarla yapılan toplantılarda analist, kullanıcının sistem içindeki görev ve rollerine odaklanmalıdır. Görevleri hakkında kullanıcıdan örnekler istemeli ve anlaşılmayan tüm noktalarda soru sormaktan çekinmemelidir. Kullanıcılar karşılarında sistemi çok iyi bilen bir kişi olmasını beklememektedirler. Hatta bu iş konusunda fazla bilgisinin olmadığını açık biçimde söyleyebilmelidir. Belki böylece kullanıcılar da daha yardımsever davranabilirler. Sonuçta  analist kendini “doğru” soru sormak zorunluluğunda hissetmeden davranmalıdır.

Analistler, müşteri ile iletişimde kendi bilgi ve tecrübelerinin sınırlarından çıkarak müşterinin neler istediğini ve hangi noktalara önem verdiğini anlamaya çalışmalıdır. Kendi düşüncelerini empoze etmeye çalışmak veya kendince filtrelemeler yapmak, bazı önemli noktaların kaçırılmasına neden olabilir. Şunu unutmamak gerekir ki; müşteri her zaman haklı olmayabilir ama müşterinin belli başlı önem verdiği yerler ve noktalar vardır ve analist özellikle sistem içinde bu noktaları doğru adresleyebilmelidir. Müşterinin fonksiyonel ihtiyaçlarını elde etmek ürünün tam olarak gerçekleştirildiği anlamına gelmeyebilir. Analist, sistemin fonksiyonel olmayan, performans, kullanılabilirlik, verimlilik ve güvenilirlik gibi gereksinimlerini de elde etmeye çalışmalıdır.  Böylece ürün gerçek anlamda tamamlanmış sayılabilir. Fonksi-yonel olmayan gereksinimleri elde ederken subjektif  olmamalı, gereksinimlerin  ölçümlenebilir veya açıklıkla tanımlanabilir olmasına dikkat etmelidir. “Sistemin ekranları kullanıcı-dostu (user-friendly) olsun” şeklindeki bir gereksinim ortam, kişi ve koşullara göre değişebilen bir gereksinimdir. Analist bu tip gereksinimleri belli sınırlama ve sınıflamaya sokmak zorundadır.

Gereksinimleri elde ederken proje kapsamında birçok paydaşla, elde edilen müşteri ihtiyaçlarını paylaşmak gerekebilir. Analist, elde edilen tüm gereksinimleri iyi bir şekilde yazmalı, hazırlamalı ve organize etmelidir. Bunu yaparken müşteri temsilcisinin anlayabileceği açıklıkta, muğlak ifadeler bulundurmayan, fonksiyonel ve fonksiyonel olmayan gereksinimleri içeren bir doküman hazırlamaya çalışmalıdır. Hatta bu bazen bir doküman ile de sağlanamayabilir. Kullanıcı senaryoları tanımları, kullanıcının sisteme olan bakış açısını ve sistemden anladıklarını göstermesi sebebiyle kullanıcı ile analist arasında güzel bir iletişim ortamı sunar.  Fakat bu tanımlar, uygulama geliştiriciler için yüzeysel kalabilmektedir. Analistler kullanıcı senaryolarından, daha ayrıntıya girerek sistem gereksinim belirtimlerini içeren bir dokümanı hazırlayıp, uygulama geliştiricilere sunmalıdır.

Sonuçta analistler, uygulama geliştiriciler ve kullanıcılar olmak üzere her iki tarafa bakan, bunların arasında verimli bir iletişimi kuran kişilerdir. Bu sebepten dolayı analistlerin hazırladığı gereksinim dokümanının anlaşılırlığını anlamak için müşteri temsilcisi, uygulama geliştirici ve test sorumlularının bu dokümanı gözden geçirip onaylaması gerekir.

Devam edecek.