Daha önce bu konuya bu yazıyla giriş yapmış ve ihtiyaç ile istek arasındaki ilişkiden bahsetmiştik. Bu yazıda bu konuyu sonlandıralım.

Karl Wiegers, “More About Software Requirements” isimli kitabının ikinci bölümünde, kozmik doğrulardan bahsederken “The customer is not always right, but the customer always has a point.” der. Yani “müşteri her zaman haklı değildir fakat müşteri her zaman bir noktaya işaret ediyordur.” Bu sözü, bir önceki yazının ışığında ele alırsak demek istenen şey, müşterinin ihtiyacı olarak size aksettirdiği sey her zaman bir ihtiyaç olmayabilir, bir istektir örneğin, ama bu isteğin ardında müşteriyi bunu ifade etmeye iten bir sebep muhakkak vardır.

“Müşteri her zaman haklı değildir fakat müşteri her zaman bir noktaya işaret ediyordur.” sözünün en doğru olduğu zaman, müşterinin ihtiyacını değil de ihtiyacına çözüm olduğunu düşündüğü şeyi ifade ettiği zamandır. Sıklıkla karşılaşırız, analiz toplantısında müşteri açmıştır kullandığı yazılımın bir tarafını ve ilgili kullanıcı ekranları üzerinden, “şuraya bir kombo istiyorum”, “şurada şöyle bir liste olsun” vb. bir dille konuşmaya başlamıştır. Bu durumda, müşterinin, ihtiyacından değil, isteğinden de değil ama çözümden bahsettiği aşikardır. Tecrübeli analistler, müşteriyi bu durumda, “siz ihtiyacınızdan değil de çözümden bahsediyorsunuz” diye hemen kesmezler, müşteriyi dinlerler, çünkü müşterinin bir sıkıntısı vardır ama bu sıkıntıyı, onu halledeceğini düşündüğü çözüm olarak anlatıyordur.

Zaten iş süreçlerini soyut bir şekilde anlamak ve anlatmak müşterinin çok nadiren yapabildiği bir şeydir. Müşteri çoğu zaman, ihtiyacını değil, nasıl bir çözümün onu tatmin edeceğini ifade etme eğilimindedir ve bunu da çoğu zaman kullanıcı arayüzleri üzerinden yapmayı kolay bulur. Bu durumda müşterinin bahsettiği bu çözümü doğuran esas ihtiyaca, hatta ihtiyaçtan da bu ihtiyacın arkasındaki kök probleme (root cause) gitmeliyiz. Tecrübesiz analistler, müşterinin çizdiği çözümü aynen aktarırlar, Analistlerin olmayıp, kullanıcıların doğrudan programcılarla iletişimde oldukları durumlarda, pek çok programcı, kullanıcının istediği çözümü aynen geliştirme yönünde davranır. Bu durum ise nihayetinde tuttarsız, aynı şeyin bir kaç yerde yapıldığı, sürecin ıskalanıp yerine bir sürü “ekran”ın yanyana yığıldığı yazılımlara sebebiyet verir.

Müşteri ne kadar süreç odaklı düşünebiliyorsa ihtiyacını da o kadar soyut ve süreç cinsinden anlatır. Bu durumda gerçek sebebe, yani ihtiyacı doğuran gerçek probleme daha yakınız demektir. Fakat çoğu zaman kullanıcı ekranları seviyesinde konuşan bir kullanıcı ile karşı karşıya olabileceğimizi unutmayalım.

Bu durumlarda yapılacak şey bellidir, “neden/niçin” sorularını sormaya devam edip, katman katman giderek esas, kök probleme varmak. Karşı tarafı rahatsız etmeden, soracağınız 3-5 tane “neden” sorusuyla asıl ihtiyaca, oradan da ihtiyacı doğuran nedene ulaşabilirsiniz. Örneğin müşterinin “şuraya bir radyo buton koyalım ve kullanıcı, evet cevabı verise de şuraya koyacağımız listeden şunu şeçsin” şeklinde bir cümle sarfettiğini düşünelim. Burada yapılacak ilk şey, “neden bu iki arayüz elemanına ihtiyacınız var?” ya da daha açık olarak “buradan girilen bilgiyi ne yapacaksınız?” şeklinde sorular sormaktır. Muhtemelen kullanıcı şöyle cevap verecektir: “biz bu bilgileri şu raporda, şunu hesaplamada vs. kullanmak istiyoruz.” Bu durumda tecrübeli bir analist, o raporun ya da hesaplamanın ne iş yaptığını, kullanıcı için neden önemli olduğunu anlamalıdır. Çünkü belki o bilgi o raporda olmamalıdır, belki o bilgi farklı bir yerde farklı bir şekilde alınmalıdır, belki o bilgi zaten sistemin bir başka yerinde alınıyordur da o kullanıcının haberi yoktur, ya da o hesaplama aslında o bilgiye ihtiyaç duymuyordur, vs. vs. gibi pek çok durum söz konusu olabilir. Bu şekilde dibe doğru inen sorulardan sonra örneğin bu bilgilerin alınmasının devlet tarafından istenen bir durum olduğu ya da pazarlama biriminin yapacağı promosyonları yönlendirmek üzere kullanılacağı gibi sonuçlara varılabilir. İşte bu sonuçlar, gerçek problemi ortaya koyar.

Kullanıcı, işinin başı ile sonunu bir anda görme yetisine her zaman sahip değildir. O çoğu zaman, “şuraya koyalım şunları, sonra kullanırız” gibi de düşünüyor olabilir. Kullanıcın kafasındaki gerçek nedene ulaşamazsanız, cicili-bicili arayüzleriniz olur ama hala müşteri memnun değildir. Çünkü siz, müşterinin problemini çözmemiş, onun çözüm olduğunu düşündüğü şeyi yapmışsınızdır. Bu durumda analist “analitik olmak” yerine postacı olmayı seçmiş demektir. Analistlerin postacılık yapıp, herhangi bir analitik süreç işletmemeleri ise kullanılması zor, işe yaramayan bir sürü kullanıcı ekranına sahip, tutarlılığı düşük yazılımlar demektir. Bu yüzden müşteri her zaman haklı değildir ama onu bu şekilde konuşmaya ve davranmaya iten sebepler vardır.

Tecrübeli ve iyi niyet ve sistematik yaklaşıma sahip analistler, belli bir müddet çalıştıkları kullanıcıları eğitirler. Bu tür kullanıcılar bir süre sonra zaten kulanıcı arayüzleri yerine ihtiyaçlarına, hatta onları doğuran gerçek problemlere inmeyi, toplantılarda bunlar üzerinden konuşmayı öğrenirler. Bu durum ise analistin ve nihayetinde tüm takımın işini kolaylaştırdığı gibi, tekrarların önüne geçer, daha doğru ve kullanılabilen sistemler tasarlanmasını sağlar.

Analitik analistler ve sistematik kullanıcılarla yazılım projesinde bulunmak büyük bir keyiftir. 

Toplam görüntülenme sayısı: 1207