Gitti Gidiyor Yorum Sorgulama Uygulaması

Gitti Gidiyor Yorum Sorgulama Uygulaması 

ve 

Test Otomasyon

Merhabalar, 

Bugün "test otomasyon aracı kullanarak neler yapabiliriz" 'i Test otomasyon araçları sadece test için mi kullanılır? Sorusuyla ele alacağız.

Esas amaç olarak tabi ki budur ama bunun yanında işlerimizi de kolaylaştırabilir. 

Dilerseniz konuyu fazla dolandırmadan bir örnekle hareket edelim.

Buyurun size bir yorum sorgulama uygulaması...

Sizin de bildiğiniz gibi Gitti Gidiyor üzerinde sadece tek bir ürüne ait yorum sorgulama yapamıyoruz. 

Sistem, satıcının sattığı tüm ürünlere ait yorumları getiriyor. Dolayısıyla eğer ilgili satıcıdan sadece kalem alacak ve bu kaleme ait yorumları görmek istiyorsak, satıcının satıp yorum aldığı tüm ürünlerin içerisinde kendi ürünümüze ait yorumları aramak zorunda kalıyoruz ki bazı satıcıların aldığı toplam yorum, bin sayfa ve üzerini bulabiliyor. Her bir sayfada 20 adet yorum olduğunu düşünürsek, bir kullanıcı olarak kendi ürünümüze ait yorumları bulabilmek imkansız hale gelebiliyor. 

Tabi bir başka yazıda buradaki "Kullanılabilirlik" eksikliğini de konuşmak lazım ama şimdilik buna değinmeyeceğim.

Peki uygulamamız ne yapıyor;

Uygulamamız, Selenium WebDriver kullanarak, Gitti Gidiyor üzerinde gelen tüm yorumlar içerisinden sadece bizim istediğimiz ürüne ait yorumları filtreleyerek, istediğimiz takdirde bu yorumları Excel'e atıyor.

Normalde bizim reel kullanıcı olarak belki bir kaç saatte yapacağımız işlemi bir kaç dakikada bitiriyor.

Çalışma Prensibi

Kullanıcı tarafından verilen Ürün ID ile Chrome, I Explorer ve FireFox seçeneklerinden biri kullanılarak arama yapılır ve sadece istenen ürüne ait yorumlar listelenir. 

Eğer istenilirse tüm yorumlar Excel'e aktarılabilir.

Uygulamaya Github üzerinden aşağıdaki link aracılığı ile ulaşabilirsiniz.

Gitti Gidiyor Yorum Sorgulama Uygulaması 

Bu ve bunun gibi benim aklıma gelmemiş olan bir çok geliştirme yapılabilir. Bu şekilde ilerlemek hem sizlere yeni bir şey yaptırmış olacak hem de konuyu daha iyi anlamanızı sağlayacaktır.

Yeni bir şey öğrenmenin en güzel yolu onu zevkli hale getirmektir.

                                                                                          Ozan TÜRK

                                                                          İş Analisti 

                                 

Devamını Oku

VOICE of CUSTOMER (VoC) & VOICE of BUSINESS (VoB)

Voice of Customer & Voice of Business

Bu yazı içerisinde VoC (Voice of Customer) ve VoB (Voice of Business) kavramlarını bu iki kavramı nasıl bir arada tutmamız gerektiğini ele alacağız. 

Voice of Customer

Adından da anlaşılacağı gibi ana hatlarıyla, müşterinin kendisi için geliştirilecek/güncellenecek olan ürün ile ilgili beklentilerinin elde edilmesinin amaçlandığı tanımlamadır diyebiliriz. Tabi müşteriden bilgi toplama aşamasının birden fazla yolu olduğu gibi toplanmış bu bilgilerin nasıl elde tutulacağı, nasıl derleneceği ve hangi bilgilerin ne derece önem arz ettiğinin analiz edilmesi, müşteri memnuniyeti gibi birçok farklı kavramı da içerisinde barındırır. Sadece ürün geliştirme aşamasında ya da öncesinde ele alınan bir kavram olmayan Voice of Customer (VOC), müşterilerinizin onlara sunmuş olduğunuz ürün ile ilgili edinmiş oldukları deneyim sonrası geri dönüşlerini de kapsamaktadır. Dolayısıyla aynı zamanda bir “geri besleme” noktasıdır.

Dilerseniz şimdi müşteri isteklerini toplama aşamasına değinelim.

Müşteri İsteklerini Toplama

Hedef market ve müşterilerin tanımlandığı ürün planı yayınlandıktan sonraki adım, tanımlanmış olan müşterilerin her bir yazılım projesi için ihtiyaçlarını elde etmektir. Buradaki ilerleyiş şu şekilde olacaktır; hedef müşterilerin belirlenmesi, ihtiyaçların toplanmasında hangi müşteri ile iletişimde olunacağı, bu ihtiyaçların toplanmasında hangi mekanizmaların devreye alınacağı, proje planı ve ürün tanımlama.

Tabi tüm bu ihtiyaç toplama süreci, müşterilerle olan iletişim şekillerine göre farklılık gösterir.

Bu iletişim şekillerini şu şekilde ikiye ayırabiliriz;

• Direkt İletişim
• Dolaylı İletişim

Bu iki iletişim şeklinde kullanılacak yöntemler farklılık gösterecektir. İletişim şekillerine göre kullanılacak yol ve yöntemleri hizalayacak olursak;

• Direkt İletişim
• Daha sayılı ve belirli müşteri ile iletişime geçilir.
• Direkt iş ilişkileri kullanılır.
• Gereksinimlerin elde edilmesinde kullanılacak olan yöntemler
• Gereksinim dokümanı hazırlamak
• Müşteri toplantıları organize etmek
• Veri güvenliği ve bakımı sağlamak
• Müşteri temsilcilerini etkin olarak kullanmak
• Dolaylı İletişim
• Daha çok müşteri ile iletişime geçilir.
• Distribütörler ile iletişimde olunur.
• Gereksinimlerin elde edilmesinde kullanılacak olan yöntemler
• Anketler yapmak
• Odak grup çalışmaları gerçekleştirmek
• Pazar araştırmaları yapmak
• Görüşme ve röportajlar gerçekleştirmek
• Müşteriden gelen geri bildirimleri edinmek 

Şeklinde hizalayabiliriz. Direkt ya da dolaylı iletişimde olduğumuz kişilerden ihtiyaçları toplanırken, geliştirilecek olan iş aynı şirketin çok küçük bir modülü bile olsa muhakkak birden çok müşterinin kendisinden ihtiyaçlarını dinlemek ve analiz etmek gerekmektedir. Farklı müşterilerden toplanan tüm bu bilgiler özümsenip geliştirilecek olan projenin başarı kriteri dengelerine aynı paralelde olacak şekilde değerlendirilmelidir ki yüksek oranda ihtiyaçlar toplanabilsin ve gözden kaçabilecek olan maddeler en aza indirilebilsin. Etkili bir VoC programı yaratmanın anahtarı, müşteriden gelecek bilgileri toplama ve bu toplanmış bilgileri ürün geliştirme aşaması içerisinde tam zamanında kullanmaktır.

VoC Sürecinde Pazarlamanın Önemi:

Pazarlama çalışmalarının müşteri ihtiyaçlarını ve ürün gereksinimlerini belirleme sorumluluğu mevcuttur. Bu sorumluluğun pazarlamada olması, işi geliştirecek olan geliştiricileri, müşteriden ve dolayısıyla kendilerini müşteri ihtiyacını ilk olarak elde eden kişi olmaktan kurtaracaktır. Bu gibi yüklerden izole olarak çok daha verimli çalışmaları sağlanacaktır.

VoC Ürün Geliştirme Ekibi:

Ürün geliştirme ekibi direkt olarak müşteri ihtiyaçlarını anlamaya ve çözümlemeye odaklanmalıdır. İhtiyaçları anlamak ve çözümlemek için birçok farklı yol, birlikte ya da ayrı ayrı denenebilir. Bu yolları şu şekilde listeleyebiliriz;

• Müşteriler ile düzenlenecek toplantılar
• Ürünü kullanan ya da bakımını gerçekleştiren kullanıcıları gözlemleme
• Odak gruplarına katılmak
• Geliştirici ekibinin, pazarlama, satış ya da müşteri destek elemanlarıyla belirli süre birlikte çalışması

Bu ve bunun gibi direkt dâhil olma durumları müşteri ihtiyacını anlamada çok önemli bir yarar sağlayacaktır. Müşteri ortamında olmak, ürünü kullanmak müthiş bir empati sağlayacak, ürünle ilgili bilinmeyen noktaları en aza indirecek, gelecekte ve bu gün için alınacak kararları daha sağlıklı hale getirecektir. Ayrıca bu ve bunun gibi hamleler, ileri teknoloji ürünleri mühendisliğinin temellerini daha sağlam hale getirdiği için, geliştirilecek olan bu yeni ürünün kullanım süresi eski teknolojiye göre çok daha uzun kalacak, devamlılığını çok daha uzun süre korunmuş olacaktır.

Müşterilerin çok küçük bir kısmıyla direkt ilişkiler içinde olan şirketler için, ürün geliştirme takımı içerisinde müşteri temsilcilerinin de yer alması istenir. Daha geniş müşteri kitlesi ile yürütülen ilişkilerde ise daha çok “odak grup” çalışmaları gibi alternatif yollara gidilerek müşteriden gelen geri beslemeleri edinmek gerekmektedir. Müşteri ilişkilerinin bu şekilde düzenlenmesi, gereksinimlerin, soru / cevapların ve geliştirme sırasında alınması gereken girdilerin rahatça elde edilmesini ve tasarım aşamasının kritik edilmesini kolaylaştıracaktır.

Kaç müşteriyle irtibatta olunacağı konusu ise projenin karmaşıklık ölçeğine bağlı olarak değişir. Burada esas amaç; proje ile ilgili gereksinimlerin ve tüm isteklerin en az %90-95 oranında edinilmesini sağlamaktır. 

Hangi Müşterilerle İletişime Geçilmeli:

Peki, hangi müşterilerle iletişime geçmeliyiz? Eğer yapılacak ürün hali hazırda pazarda yeri olan bir ürünse, mevcutta bilinen müşteriler bilgi için ilk kaynak olacaklardır. Ek olarak, potansiyel müşterilerle de konuşmak alınacak bilgiyi sağlamlaştırıcı olur. Keza eğer geliştirilecek olan ürün, pazarda yeni yer alacak olan bir ürünse zaten direkt olarak potansiyel müşteriler bilginin ilk ve en önemli kaynakları halini alacaklardır. Bunların dışında ise çok büyük önem arz eden iki müşteri tipi vardır. Bunlar;

• Rakiplerin Müşterileri
• Lider Müşteriler

Rakiplerin Müşterileri: Rakiplerin müşterilerinden toplanacak bilgiler bize; rakibin ve/veya rakip ürünün hangi yönlerinin çok güçlü olduğunu ve müşterilerin neden bizi tercih etmediklerini ortaya koyacak olan çok önemli bilgilerdir.

Lider Müşteriler: Lider müşteriler, ürünü en iyi kullanan, ürünün limitlerini sonuna kadar kullanan ve bu kullanım sonrasında yeni gereksinimlerin olduğunu öne süren kullanıcılar ya da müşterilerdir. Onların ürün ile olan deneyimleri ışığında ürün içerisindeki eksiklikler fark edilir ve gerek güncellemelerle gerekse ürünün yeni sürümümde bu müşterilerden gelen geri beslemeler kullanılır. Lider müşteriler yeni ürün için en önemli kullanıcı sezgilerini sağlamamıza yarayan özel müşteriler bütünüdür.

Tüm gereksinimler toplandıktan sonra ise yapılacak olan iş bu toplanmış olan ihtiyaçları yönetme ve derleme işidir. 

Müşteri İhtiyaçlarını Yönetme

Müşterileriniz sizinle ve organizasyonunuzla düşüncelerini ve fikirlerini paylaştıklarında, dinleyeceğinizi ve dikkate alacağınızı umarak bir şeyler anlatırlar. Dolayısıyla bu anlatılar sonrasında ise bir çıktı beklerler. İlk bekledikleri ise konuşulanlarla ve yapılanlarla ilgili bilgilendirici raporlardır.

Toplanmış olan gereksinimlerin yönetilmesi şarttır. Toplanmış olan tüm görüşme notlarının, gereksinim dokümanlarının, pazar araştırmalarının ve müşteri verilerinin anahtar müşteri ihtiyacını belirtmesi için elden geçirilmesi ve düzenli hale getirilmesi gerekmektedir.

Bu iş için ise en iyi yardımcı teknik, yakınlık diyagramlarıdır. Toplantılarda müşterilerin belirtmiş oldukları hususlar, anahtar gereksinimleri ortaya koymak için en iyi verileri barındırır. Ürün ile ilgili yapılmış herhangi bir açıklamayı atlamamak üzere “veri sözlüğü” hazırlanması önem taşır.

Ayrıca müşteri ihtiyaçlarını tam olarak anlamak için müşterinin perspektifinden bakılarak yaratılmış prototipler ile müşterinin görmek istediği ürün ortaya koyulmaya çalışılır.

Bu ve bunlar gibi amaca hizmet edecek olan kayıtlar, müşteri ihtiyacını ortaya çıkaracak olan bütünü masaya yatırma işini kolaylaştırıcı ve işin daha düzgün, anlaşılır yapılmasını sağlayacak işlemlerdir.

Bu gün tüm bu işlemlerin daha düzgün olarak toplanması ve derlenmesi işleminin dokümana aktarılmış haline iş analizi dokümanı diyoruz. 

Voice of Business

İşin sesi dediğimiz şey kısaca, işi yürüten insanların konuşulan ve konuşulmamış olan ihtiyaçlarının, isteklerinin, beklentilerinin ve tercihlerinin bütününü temsil eder.

Kazanç, büyüme ve pazarda lider olmak gibi olgular iş ihtiyacını temsil eden maddelere örnek olarak verilebilir.

VoB verileri, finansal/pazar analizlerinden, rakip analizlerinden, çalışan anketlerinden elde edilebilir verilerdir. Bu toplanan veriler aynı VoC verileri gibi işin daha sağlıklı yürümesi için kullanılacak olan verilerdir.

Bir başka önemli nokta ise içte yapılan işlem süreçlerinin, bilgi teknolojileri, basitleştirme ve lojistik gibi müşteriler için değer sağlayacak süreçlere destek vermesi gerektiğidir.

VoB, içerisinde ihtiyaçları ve ölçütleri barındırır. Burada ihtiyaçlar: Sıfır hata/kusur, Sıfır israf, Çalışan motivasyonu……..şeklinde sıralanacaktır. Ölçütler ise: Çalışan memnuniyeti, Çalışan cirosu ve iş hacmi, Hata/Kusur sayısı……..şeklindedir.  

VoC & VoB

Sonuç olarak elimizde iki durum var, şirketler işi ayakta tutabilmek, amaca ulaşabilmek için kâr etmek durumundadırlar ve bunun için çalışırlar. Ama bu durum tabi ki müşteriye pahalılık olarak yansıyacaktır. Müşteriler ise doğal olarak en iyi ürünleri en uygun fiyata edinmek isterler. Peki, organizasyonlar iflas etmeden bu hizmeti nasıl sunabilir?

Bu iki farklı açı sebebiyle bir projeye başlandığında VoC ve VoB birlikte düşünülerek değerlendirilmelidir. Proje başladığı andan itibaren, VoC ve VoB arasındaki sinerjiyi yakalamak için en uygun eşleşmeyi bulmak, organizasyon için en büyük hedef olarak ortaya çıkmalıdır. Bu yaklaşımı tüm projelerde uygulamak ise şirket stratejisi halini alacaktır ve bu açıdan çok büyük önem taşır.

Şirket niçin var? Müşteriler kimler? Müşterilerimiz bizden neler istemekteler? Müşterilerimiz ne zaman memnun olurlar?

Bu soruların cevaplarını bulduğumuzda, müşterilerimize onlar için değerli bir işlem süreci haritasını çıkarmaya başlayabiliriz. Bu yol haritasına bir kez sahip olduğumuzda ise, yaratmış olduğumuz bu işlem sürecini destekleyecek iç süreçlerin yol haritasını yaratmaya başlayabiliriz.

Teşekkürler.

Kaynakça

        VOICE OF THE CUSTOMER 

        Written by  Kenneth Crow DRM Associates

Ozan TÜRK

İş Analisti 

Devamını Oku

UXD TEMEL BİLEŞENLER - MENTAL MODEL ve YAKINLIK DİYAGRAMI

Mental Model Nedir?

"Bir kişiyi anlamanın en iyi yolu, dışarıdan görünenin nasıl olduğu ve gören kişiye nasıl hissettirdiği kavramları ile donanmış empatidir."

Odağında kullanıcı olan yani kendi kendine çalışan değil; kullanıcıların çalıştıracağı, işlem yapacağı bir uygulama geliştiriyorsanız kullanıcıları tamamıyla anlamanız gerekir. Kullanıcıların bakış açısıyla uygulamaya bakmalı, onların beklediklerini beklemeli ve onların istediklerini istemelisiniz. 

“Bu ve bunun gibi düşüncelerin çok büyük önem arz ettiği durumlarda kesin birileri bunu düşünmüş ve bir yolunu bulup modelini, diyagramını çıkarmıştır” diye düşünüyorsanız haklısınız. 

İşte bu bahsi geçen empati odaklı modelin adı Mental Model’dir.

İlk olarak Kenneth Craik (1914–1945) tarafından 1943 yılında yayınlanan The Nature of Explanation adlı kitapta ele alınmış olan Mental Model, yurt dışında uzun zamandır kullanılmaktadır. Ülkemizde ise son dönemde dikkatleri üstüne çekmiştir ve artık neredeyse “olmazsa olmaz” denecek düzeyde ele alınan “Kullanıcı Deneyimi Tasarımı” yapı taşlarından biridir. 

Mental Model, insan odaklı bir modellemedir ve bu modelleme insanı sadece “user/kullanıcı” olarak görmekten kaçınır. Bireyin duygusal ve psikolojik özelliklerini ele alır. Geliştirilecek olan bir uygulamada duygusal ve psikolojik etkenlerin kesinlikle göze alınması gerekir. Unutmayalım ki “Eğlence ve Oyunlaştırma” Ux’in de en önemli parçaları arasında yer alır, kullanıcı odaklı tasarımda kullanıcıyı sisteme bağlamak ya da akılda kalıcılık çok önemli bir unsurdur. En sevdiğiniz uygulamaların arayüzlerinde yer alan renkleri düşünün. Psikolojik yapınız dikkate alınarak bu renklere karar verilmiş olabilir mi? 

• Birkaç yıl önce Gmail’in Login ekranında bulunan arka plan rengi için Google’ın mavi rengin tam 41 ayrı versiyonunu analiz etmiş olduğunu unutmayalım. Buradaki hassasiyeti kazandıran şey, renklerin insanlar üzerinde bıraktıkları psikolojik ve duygusal etkilerdir. 

Biraz da Mental Model’in teknik özelliklerine değinelim:

• Mental Model, her bir bölüm içerisinde oluşturulmuş grupları bünyesinde barındırır.
• Katılımcıları temsil eden toplanmış verilerden meydana gelen basit yakınlık diyagramlarıdır.

Günlük yaşamımızdan yola çıkarsak:

Klasik bir sabahımızı ele alalım. Giyinmek, kahvaltı yapmak ve işe gitmek için araca binmek alanlarını sabah diyagramınızın "mental alanları" olarak düşünelim. Tatil günlerine "işe gitmek için araca binmek" alanının yerine "aile ile uzun ve büyük bir kahvaltı" alanını yerleştirebiliriz. Yahut sabahları yorgun/uykusuz kalktığımızda sabah diyagramımızın mental alanına "uyanık kal" alanını ekler ve bu alan içerisinde kahve/çay içer, biraz egzersiz yaparız.

Yani özetle yaratacağımız alanlar ve alanları besleyen destekleyici maddeler olacaktır. Bu maddeler, mevcut durumdaki değişikliklere göre yakınlık diyagramı içerisinde değiştirilebilir ya da yenilenebilir olacaklardır.

Indı Young’ın Mental Models-Aligning Design Strategy with Human Behavior adlı kitabından alınmış olan bu örneğin, modellemesine de bakmak güzel olacaktır.

Tabi bu modelleme gerçek hayatın bir kesiminin modelleme örneğidir. İş hayatında ise artık Mental Model Diyagramları bir işin nasıl yapılacağını gösterme amaçlı olarak kullanılmaktadır. Öyle ki tüm esaslar ve işler ele alınarak oluşturulmuş bir modelleme; hangi iş için oluşturulmuşsa o iş için neredeyse on yıl boyunca kullanılabilir, uzun ömürlü bir iş süreci anlatımı anlamına gelir.

Yani gerek kullanıcıları anlamada gerekse iş sürecimizi modellemede kullanabileceğimiz bir modellemeden bahsediyoruz. 

Kullanıcı Deneyimi konusunda ülkemizde iyi işlere imza atan User Spots der ki: “Mental Model, senaryonun görsel bir tasviridir. Kullanıcının hayatındaki olayları tarif etmek için bir zaman çizgisinden yararlanılır. Düşünce halindeki ürünlerin gerçek hayatta nasıl çalışacağını anlatan bir metottur. Bunun için örnek olarak akış diyagramları da kullanılabilir. Problem çözümlerinde davranışları şekillendirmeye yardımcı olur.”

Bu ifade Mental Model’in tüm özelliklerini açıklar niteliktedir.

Yakınlık (Affinity) Diyagramı Nedir?

Yakınlık diyagramı en basit yorumuyla, birbiriyle ilişkisi olan grupları gösterir.

Direkt örnekle ele alalım: Sabah için krep, akşam için ise soslu makarna yapmayı planlıyor olalım. Yakınlık Diyagramımızı bir market listesi gibi düşünürsek alacaklarımız arasında yer alan yumurta, un ve süt, bir grupta yer alacaktır. Makarna sosu ve makarna ise bir başka grupta yer alacaktır. Çünkü krep için yumurta, süt ve un arasında bir yakınlık; soslu makarna için ise makarna sosu ve makarna arasında bir yakınlık mevcuttur. 

Diyagram içerisinde birden fazla grubun set olarak sunulan ilişkisel davranışları, bize daha yüksek seviyedeki davranışsal grupları sunar: 

• Akşam yemeğinde köfte ve makarna yapmaya karar verdik. Ekmek içi, baharatlar ve kıyma; köfte ile yakınlık içindedir. Makarna ve sosu ise makarna ile yakınlık içindedir. Ancak her ikisi de akşam yemeğini oluşturduğu için set olarak karşımıza çıkarak Yüksek Seviyedeki Akşam Yemeği grubunu oluştururlar.

Şimdi de dilerseniz iş yaşamında kullanılışını örnekleme adına bir Ux iş sürecini kesin olmamakla birlikte modelleyelim;

Örnek olarak düşünülmüştür. Kesinlik içermemektedir, değişkenlik gösterebilir. 

Modelleme içerisinde yer alan alanlara daha yakından bakalım:

Bu bölümde Mental Model kavramının ne olduğunu farklı açılardan ele aldık. Bir sonraki bölümde görüşmek üzere.

Teşekkürler.

Kaynakça

        

        Mental Models: Aligning Design Strategy with Human Behavior

        Written by  Indi Young

http://www.amazon.com/Mental-Models-Aligning-Strategy-Behavior/dp/1933820063

        UserSpots

http://www.userspots.com

        Mental Modeling For Content Work: Creation

        Written by  Daniel Eizans

http://danieleizans.com/2012/03/mental-modeling-for-content-work-creation/

Ozan TÜRK

İş Analisti

Devamını Oku

JAD (Joint Application Design) 2.BÖLÜM

Workshop Süreci (JAD Yaşam Döngüsü)

Workshop Öncesi

JAD sürecinde başarının anahtarı iyi bir hazırlık yapmış olmaktır. Bu hazırlık süreci 1 hafta ila 3 hafta arasında değişir. Hazırlık süreci; proje hedeflerini ve kısıtlarını belirleme, kritik başarı faktörlerini belirleme, proje çıktılarını belirleme, Workshop aktivitelerinin gerçekleşme planını yapılandırma, katılımcıları belirleme, Workshop materyallerini hazırlama, Workshop aktivitelerini ve egzersizlerini hazırlama, Workshop katılımcılarını eğitme, bilgilendirme ve hazırlama, Workshop donanımlarını hazırlama ve koordine etme aşamalarından oluşur.

Şimdi bu hazırlık aşamalarına teker teker değinelim.

Proje Hedeflerini ve Kısıtlarını Belirleme Aşaması

         Tüm proje ve projenin gerçekleştirileceği Workshopların amacının en baştan net olarak ortaya konması hayati önem taşır. Bu aşamada; planlama ve kapsam belirleme, Workshop sponsorunun ve diğer katılımcıların beklentilerinin belirlenmesi ve ortaya konması işlemleri gerçekleştirilir. Ayrıca proje tasarımının ve gerçekleştirilmesinin karmaşıklık oranı da yine bu bölümde ele alınan işlemler arasındadır.

Proje daha önceden geliştirilmek istendi mi? İstendiyse kaç kez başarısız bir başlangıç süreci yaşandı? Implementasyon aşamasında kaç kez başarısız olundu? Gibi soruların cevapları ile Projenin politik hassasiyetinin de belirlenmesi gerekmektedir.

Kritik Başarı Faktörlerini Belirleme Aşaması

Çalışılmış iş fonksiyonları ve projenin geliştirilmesi için kritik başarı faktörlerinin baştan belirlenmesi çok büyük önem arz eder ve bize şu soruların cevabını verir.

Planlanan değişikliklerin ne kadar efektif olduğunu nasıl bilebiliriz?

Başarı ölçütleri nelerdir?

Proje Çıktılarını Belirleme Aşaması

Genellikle sürecin doğuracağı çıktılar dokümantasyon ve tasarımdır. JAD süreci çalışmalarının dokümantasyon detaylarının derecesini ve formunu belirlemede çok büyük önem taşır. Süreç içerisinde hangi tip diyagram çıktıları elde edilecektir? Hangi tip ya da formda anlatılar elde edilecektir? Sorularının cevaplarının alınacağı aşamadır. Başlarda diyagram çizmeye destek olarak Case araçlarının kullanılması iyi bir yaklaşım olabilir. Çoğu Case aracının diyagram desteği çok iyi olmasına rağmen anlatı kısmı bir o kadar zayıftır. Bu sebeple bu araçlar anlatı kısmı için yeterli olmayacaktır. Dolayısıyla anlatı bölümünü yine kendinizin oluşturması en güvenilir olan yol olacaktır.

Workshop Aktivitelerinin Gerçekleşme Planını Yapılandırma Aşaması

            Workshoplar 1 ila 5 gün arasında değişiklik gösterirler. Gerçekleşecek olan ilk Sprint 3 günden az olmamalıdır.

İlk gün genellikle katılımcıların kendi rollerini benimseme ve rollerine alışma, birbirlerini tanıma ve ortamı tanıma ya da ortama alışma süreci ile geçer. İkinci gün; birbirlerini anlama ve proje ile ilgili endişe ya da sorunları ortak dilde belirleme çabası ile geçecektir. Üçüncü gün ise; artık katılımcılar birlikte aynı problem üzerinde çalışmaya başlayacakları ve üretkenliğin/verimliliğin ortaya çıkacağı gündür.                          

                İlk Sprint’in sonunda takım yapısı oluşturulmuş olacaktır. Kısa Workshoplar projenin alt fazları için örneğin Prototip doğrulaması için planlanabilirler. Bununla birlikte bu kısa Workshop planlamaları katılımcıların en az 1 ila 3 saatini ilk Workshop’taki takım psikolojisini yeniden kurmak için harcamaları anlamına gelmektedir. 

Katılımcıları Belirleme Aşaması

Katılımcılar başlığı altında ele almış olduğumuz katılımcıların en iyi JAD sürecine ulaşmak amacıyla özenle belirlenmesi aşamasıdır.

Workshop Materyallerini Hazırlama Aşaması

Workshop’a başlamadan önce Proje Yöneticisi (eğer projeye atanmış bir PM varsa) ve Facilitator rolündeki kişiler, diğer katılımcıların yapılacak olan çalışmaya odaklanmaları için ön analiz yapmalı ve ilk tasarımın temellerini atmalıdırlar.

Workshop materyalleri; dokümantasyon, diyagramlar, çalışma sayfaları ve hatta katılımcıların incelemekte olacakları iş fonksiyonlarını daha iyi anlamalarını sağlayacak her şeyi kapsar.

Workshop Aktivitelerini Ve Egzersizlerini Hazırlama Aşaması

Facilitator (workshop yöneticisi), workshop sonucunda ortaya çıkarılacak olan teslim edilebilir geçici çıktıları elde edebilmek için belli aktiviteler ve Workshop egzersizleri organize etmelidir.

Workshop öncesi aktiviteleri bu egzersizleri organize etmeye yardımcı olacaktır.

Örneğin İş alanı analizini ele alalım. Neleri kapsamaktadır? Ayrıştırıcı bir diyagram mıdır? Yüksek dereceli ER (Entitiy Relationship)diyagramı mıdır? Standartlaştırılmış bir veri modeli midir? Bir State Transition Diyagamı mıdır? Bir bağımlılık diyagramı mıdır? Yoksa bunların hepsini içerisinde barındırır mı? Belki de hiç birini?

Ortama en uygun teknik diyagram seviyesinin ne olacağını belirlemek büyük önem taşır. Diyagramlarla ilgili en önemli durum, kullanıcılar tarafından anlaşılır olmak zorunda olmasıdır. Bir diyagram belirlenmiş ve ortam için en uygunu budur denmişse, Facilitator statüsündeki kişinin Workshop katılımcılarının bu diyagramlar üzerinde geliştirme yapabilmeleri için çeşitli egzersizler hazırlaması gerekmektedir. Hazırlanacak olan bu egzersizlerin farklı alanlarda aynı projenin belli parçaları üzerinde çalışan her bir takım üyeleri düşünülerek, birbiri ardına seri egzersizler olacak şekilde ve paralel olarak ayarlanması gerekmektedir.

                Yüksek yoğunluktaki egzersiz süreçleri Facilitator öncülüğünde gerçekleştirilir. Facilitator grup üyelerine vereceği yüksek motivasyonla grubu spesifik amaca doğru yönlendirecektir.

                Düşük yoğunluktaki egzersiz süreçleri ise alınacak kararlardan önce detaylı tartışmaya önem verir burada amaçlanan budur. Bu tartışmalar, tüm grup ya da takım üyelerinin mevcut sorunlarla ilgili önerilerini almayı da kapsayarak herkesin birlikte bir karar almasını hedefler.

                Bu egzersizlerde Facilitator, farklı departmanlardaki insanları aynı uzmanlık alanında bir araya getirebilir. Bu sayede farklı departmanlardan gelmiş olan kişiler, birbirlerinin farklı uzmanlıklarından yararlanıp hem birbirlerinden farklı şeyler öğrenecekler hem de bağlı oldukları organizasyonun gerek kültürel gerekse politik amaçlarını daha iyi anlayacaklardır.

                Facilitator’ün yani Workshop yöneticisinin işi, JAD sürecinde rastlanabilecek sorunları, ortak fikir ve iletişim ile önceden çözmektir.

Workshop Katılımcılarını Eğitme, Bilgilendirme Ve Hazırlama Aşaması

Tüm katılımcıların Workshop’lardan önce proje amaçlarından, kısıtlarından ve Workshop sonucu beklenen çıktılardan haberdar olması gerekmektedir. Katılımcıları ön bilgilendirme süreci 1 ile 5 günlük bilgilendirme toplantılarıyla sağlanır. Eğer katılımcılar farklı lokasyonlara dağılmışlar ise bu bilgilendirme toplantıları telekonferans yoluyla da gerçekleştirilebilir.

                Bilgilendirme toplantıları dokümanı genellikle “Tanıtım Rehberi” olarak adlandırılır ama “Proje Kapsam Tanımlaması” ya da “Yönetim Tanım Rehberi” olarak da çağrılabilir.

Workshop Donanımlarını Hazırlama Ve Koordine Etme Aşaması

Workshop öncesinde mutlaka toplantıda kullanılacak olan; projektörler, ekranlar, bilgisayarlar, tabletler, işaretleyiciler, kayıt cihazları gibi parçaların kullanıma hazır halde Workshop yapılacak olan yere yerleştirilmiş olması gerekmektedir.

Workshop Sonrası

Bu bölümde tabi ki en büyük amaç Workshop’lar süresince takım tarafından ortaya çıkarılmış açık sorunların çözülmüş olmasıdır.

                Tipik 3 günlük bir Workshop’da ortalama 20’ye yakın Business sorunu açığa çıkarılır. Takım için en önemli unsur; ortaya çıkarılmış olan bu hataların, geliştirme (kodlama) aşamasına geçilmeden önce çözülmüş olmasıdır.

                Workshop’lar sonrasında Facilitator ve yazıcı, birlikte çalışarak Workshop dokümanını oluştururlar. Bu ve bunun gibi çıktılar proje yöneticisine ulaştırılacak olan dokümanlardır. Hazırlanacak olan bu doküman, daha sonraki geliştirme süreçlerinde destek ya da onay ihtiyacı duyulduğunda bakılacak olan doküman özelliğini taşımalıdır.

                Tasarım aşaması, yazılım uygulaması edinimleri sonucunda çıkan önerileri, ortaya çıkan ekran yerleşimi ve menüleri de içinde barındıran prototipleri ya da kod geliştirme sürecini kapsar. Eğer tasarım prototipleme yoluyla yapılacaksa, yarım günlük ya da bir günlük Workshop içerisinde değerlendirilir ve geçerli hale getirilir.

 JAD Süreci Yararları

·         Tasarım sürecini hızlandırır.

·         Tasarım kalitesini yükseltir.

·         Proje takımı yapılan işe odaklanır ve odaklanmış olarak devam eder.

·         Müşteri tarafı ile birlikte yapılacak olan takım çalışmasını destekler.

·         Müşterinin perspektifinden bakılarak tasarım yapılmasına olanak sağlar.

·         Geliştirme ve bakım maliyetlerini düşürür.

o   1989 yılında Bilgisayar Endüstrisi Üretkenlik Eksperi Capers Jones 60 ayrı projeyi baz alarak bir araştırma yaptı ve şu sonuca ulaştı

JAD olmadan geliştirilen bir projede %35 fonksiyonel eksiklik görüldü ve bu %35’ilik eksikliğin kod tarafına en az %50 etkisi olduğu görüldü.

JAD ile geliştirilen bir projede ise fonksiyonel eksiklik toplamda %10 civarlarında olarak görüldü ve bunların kod tarafına etkilerinin minimum ölçülerde olduğu görüldü.

·         Modern geliştirme araçları ile çalışılır böylece gereksinimlerin yüksek kalitede ve hızda girilmesini sağlar.

Sonuç

Bana birçok yönü ile 1990’ların başında geliştirilen Scrum metodolojisini hatırlatan proje geliştirme süreci olan JAD, proje geliştirme aşamasından çok daha önce başlayan, iş/sistem gereksinimlerini alma ve geliştirme aşamalarını müşteri ile birlikte yürüterek işe müşterinin perspektifinden bakabilen, takım çalışması temelinde ilerleyen ve farklı bakış açılarıyla iş körlüğünü ortadan kaldırıp daha kaliteli ve sorgulayıcı bir çalışma anlayışını benimsemiş, modern geliştirime araçlarını aktif olarak kullanan ve tüm bu süreçler sonucunda ortaya net bir kâr koyan proje tasarım ve geliştirme sürecidir.

Teşekkürler.

JAD (Joint Application Design) 1.BÖLÜM için tıklayınız.

Kaynakça

        Joint Application Design 

        Business Requirements Analysis for Successful Re-engineering 

        Written by  Bill Jennerich

http://www.bee.net/bluebird/jaddoc.htm

Joint Application Development (JAD)

        Dave Rottmann

http://www.umsl.edu/~sauterv/analysis/488_f01_papers/rottman.htm#Generic JAD Life

Using JAD for an Iterative Approach to Requirements Management

        Written by  Joy Matthews

http://www.batimes.com/articles/using-jad-for-an-iterative-approach-to-requirements-management.html

Ozan TÜRK

İş Analisti

Devamını Oku

JAD (Joint Application Design) 1.BÖLÜM

JAD (Joint Application Design) 

JAD, yeni bilgi sistemlerinin geliştirilmesi sırasında gereksinimlerin toplanması için uygulanan ve iteratif geliştirme yaklaşımının önemli parçalarından biri olan hızlandırıcı çözüm tekniğidir.

Amacı; fikir birliği ile kabul edilmiş sistem gereksinimlerini ortaya çıkarmak maksadıyla yapılandırılmış Workshop’lar ile geliştirme aşamasında yer alacak olan IT ve Business tarafını bir arada tutmak olan JAD,  Tony Crawford ve Chuck Morris (IBM) tarafından 1977’de dağınık sistemlere ait gereksinimleri elde etme metodu olarak tasarlanmıştır. 1980 yılında IBM Canada JAD yaklaşımını kabul etmiş ve işlemiştir.

1984 yılında IBM, JAD yaklaşımını biçimlendirmiş ve JAD tanıtım broşürünü yayınlamıştır. 1980’lerin sonuna doğru birçok şirket analiz ve tasarım aşamaları için JAD Workshop’larını uygulamaya almıştır. Daha sonraları Tony Crawford tarafından JAD-Plan geliştirilmiş ve JAR yani Joint Apllication Requirements ortaya çıkmıştır. JAD ve JAR bir arada işlemeye devam etmiştir.

JAD metodunun yıllar içerisinde prototipleme elementlerini, Case kavramını içinde barındırmak üzere evrimleşmeye devam etmesi üzerine bazı insanlar artık Jad’ın sadece bir yaklaşım değil bütün bir geliştirme süreci olduğunu düşünmeye başlamış ve “Joint Application Development” olarak adlandırmaya başlamışlardır. Fakat ne yazık ki JAD, tanımlama, analiz ve tasarım alanlarında biçimlendirilmiştir.  

Ne Zaman Daha Etkin Kullanılır?

·         Yeni Sistemlerde

·         Mevcut Sistemin İyileştirmesi Sürecinde

·         Sistem Değişim Süreçlerinde

·         Sistem Alım Süreçlerinde

Katılımcılar

Scrum’da olduğu gibi JAD metodunda da katılımcılar mevcut. Katılımcı rolleri şu şekildedir;

·         Executive Sponsor – Proje Yürütme Sponsoru

·         JAD Facilitator – Workshop Yöneticisi

·         Documentor – Yazıcı (Scribe)

·         Business Users – Business Tarafı Kullanıcısı / Experti (Bilir Kişisi)

·         Technical Support ya da System Expert – Sistem Bilir Kişisi

o   (İstenildiği takdirde) Outside Experts – Eğer istenilirse dışarıdan çağırılan danışman/bilir kişi

·         Observers – Gözlemciler

Dilerseniz şimdi bu her bir rolün ne amaçla JAD Workshop süreci içerisinde yer aldıklarına kısaca değinelim.

Executive Sponsor – Proje Yürütme Sponsoru

Proje yürütme sponsoru, işi yaptıracak organizasyondan gelen proje ile ilgili karar almada en yüksek yetkiye sahip kişidir. Bu kişi, işi yaptıracak organizasyonun proje lideri, CIO’su ve bazı maddeler ya da durumlar için kısıtlı yetkili CEO’su olabilir.

Proje yürütme sponsoru, Workshop yöneticisi (Teh Facilitator) ile birlikte projeye start vermek üzere çalışabilir ama ikisinin arasındaki fark, startı verecek olan kişinin Proje yürütme sorumlusu olmasıdır.

Executive Sponsor Sorumlulukları:

• Sistem tarafından adres gösterilmiş olan alanda en yüksek yetkiyi ve sorumluluğu kabul etmelidir.
• Proje için vizyon belirlemelidir.
• En yüksek karar alıcı kişi olarak iş politikalarındaki çatışmaları çözmelidir.
• JAD işleminin sonuçlarıyla onur duyabilecek kadar iyi bir iş çıkartabilmelidir.
• Proje takımının, doğru Business tarafı kullanıcılarıyla çalıştıklarına emin olmalıdır.
• Müşteri destek ekipleriyle iletişime geçen kişi olmalıdır.

Executive Sponsor, müşterinin gözüyle JAD işleminin kredibilitesini veren kişidir. JAD işlemi süresinde Workshop yöneticisine (Facilitator) güven vermelidir. JAD işlemi süresine katılmayabilir olan tek katılımcıdır.

JAD Facilitator – Workshop Yöneticisi

JAD sürecinin başarısı ya da başarısızlığı Facilitator’ün süreci ne kadar iyi ya da kötü yönettiği ile yakından alakalıdır. Workshop yöneticisi rolünü üstlenecek olan kişinin, öncelikle mutlaka bu konu ile ilgili eğitim almış olması gerekmektedir. Bunun yanı sıra yine kişinin, JAD sürecinde kullanılacak olan araçlarla ve teknolojiler ile ilgili yüksek derecede bilgiye sahip olması gerekmektedir. Workshop yöneticisi ayrıca JAD takımı içerisinde yer alan birçok farklı tipte kişilik ile son derece efektif bir diyalog kurması gerekmektedir.

JAD Facilitator Sorumlulukları:

• JAD aktivitelerini organize etmeli ve planlamalıdır.
• JAD sürecinin rehberi olmalıdır.
• Anlaşmazlıkları çözmelidir.
• Takımın odak noktasından sapmamasını sağlamalıdır.
• Süreç içerisindeki görüşmelerden, tartışmalardan çıkan sonuçları analiz ederek, süreç içerisinde belli kararlar alabilmelidir.
• JAD sürecinden menfaat çıkarma çabasında olmamalıdır.

Bu rolü üstlenecek olan kişinin en kritik özelliği tarafsız olması olmalıdır. Facilitator’ün takım içerisindeki yansız ve güvenilir rehberliği ile JAD süreci katılımcılarının her biri kendi işlerini çok daha iyi açıklama / izah etme şansını elde edeceklerdir. Süreç içerisinde Facilitator, karar verme aşamasını katılımcılara sorular sorarak yönetir. Tüm katılımcılardan fikirlerini alır bu fikirlerin yürütülen proje amacına uygun ve odaklı olduklarını teyit eder. Süreç sonunda Facilitator’ün amacı; tüm katılımcıların kendi fikirlerinin alınmış olduğunu ve yapılan işin ortak müşterekte çıkmış olduğunu bilmeleridir.

Documentor - Yazıcı (Scribe)

JAD süreci içerisinde yazıcılar (bu şekilde adlandırılıyorlar),  JAD Facilitator’ün tarafsız asistanı görevini üstlenirler. Yazıcıların işi; tartışmalar/görüşmeler ve tasarım süreçleri esnasında konuşulanları ya da alınan kararları not almaktır. Alınan notlar sadece bunlardan ibaret olmalıdır.

Yazıcı not alabilmek için genellikle kişisel bilgisayar kullanır. Eğer, Development araçları kullanılıyor ise birden fazla yazıcı ele alınabilir. Bir tanesi notlar ve prototip güncellemelerini tutması için diğeri ise Development aracını kullanması için.

Business Users – Business Tarafı Kullanıcısı / Experti (Bilir Kişisi)

Tüm kullanıcılar kendi işlerini gruba layıkıyla anlatmak zorunluluğundadırlar. Projeye uygun Business kullanıcıları sistem tasarımını daha yüksek kalitede ortaya koyabilirler. JAD süreci içerisinde grupta bulunan kullanıcıların birbirleri arasında herhangi bir rütbe farkı yoktur.             

Business Kullanıcısı Sorumlulukları:

• JAD sürecinin esas odak noktasını belirlemelidirler.
• İş uzmanlıklarını sunarlar. (Business Expertise)
• İşin stratejik, taktiksel ya da operasyonel yönünü temsil etmelidirler.
• Projeden etkilenen tüm majör kullanıcı gruplarını temsil etmelidirler.
• Organizasyonun tek bir yönünü değil birçok yönünü temsil etmelidirler.

Technical Support ya da System Expert – Sistem veya Teknik Destek Bilir Kişisi

Grup içerisinde bu kişiler IT Temsilcisi olarak da bilinen kişilerdir. Bu temsilciler, gerek duyuldukları takdirde teknik öneri veren, mantıksal modellerin ve özelliklerinin geliştirilmesine yardım eden ve prototip üreten kişilerdir.

Tabi ki bu görevleri yerine getirebilmeleri için JAD süreci ile ilgili ve bu süreçte kullanılan araç ve metotları çok iyi bilmeleri gerekmektedir. IT temsilcileri sistemin kilit geliştiricileri arasındadırlar. JAD imkânlarını müşterilerin iş fonksiyonlarında uzmanlaşmak için kullanırlar. Ekspertiz olarak hangi seviyede olurlarsa olsunlar karar yetkisine sahip değillerdir. Sadece öneri ve yardım ve geliştirme eylemlerini gerçekleştirebilirler.

Sistem veya Teknik Destek Bilir Kişisi (IT Temsilcisi) Sorumlulukları:

• Müşterilerin düşüncelerini iş gereksinim modellerine dönüştürmeye yardım ederler.
• Tüm teknolojik kısıtların ortaya konulduğuna emin olmak zorundadırlar.
• İşin amacının, önceliklerin ve stratejisini anlamalı ve geliştirmelidirler.
• Veri yetkilendirme, iş analizi, programlama, prototipleme ve ürün yönetimi gibi iş fonksiyonlarını tamamıyla yansıtmalı, ifade etmelidirler.
• Geliştirilecek çözümün bütçeyi aşmadığına, ihtiyaç olduğunda yayına alınabilir olduğuna ve etkin olarak mevcut teknolojilerin avantajlarını taşıdığına emin olmalıdır.

Observers – Gözlemciler

Kısaca gözlemciler, rol isimlerinden de belli olduğu gibi gerçekten de workshop süreçlerini gözlemleyen ve müşteri ihtiyaçlarını, alınan kararları öğrenen gruptur. IT projesi takım üyeleri JAD eğitimine girmeden önce bir JAD sürecinde observer olarak görev alabilirler.

Sorumlulukları:

• İzlemek ve dinlemek.
• Kullanıcı ihtiyaçlarını ve workshop kararlarını öğrenmek.
• Katılımcılarla ve Facilitator ile sadece Workshop aralarında, öncesinde ya da sonrasında iletişime geçmek.

Bir sonraki bölümde ulaşmak için tıklayın.

Teşekkürler.

Kaynakça

        Joint Application Design 

        Business Requirements Analysis for Successful Re-engineering 

        Written by  Bill Jennerich

http://www.bee.net/bluebird/jaddoc.htm

Joint Application Development (JAD)

        Dave Rottmann

http://www.umsl.edu/~sauterv/analysis/488_f01_papers/rottman.htm#Generic JAD Life

Using JAD for an Iterative Approach to Requirements Management

        Written by  Joy Matthews

http://www.batimes.com/articles/using-jad-for-an-iterative-approach-to-requirements-management.html

Ozan TÜRK

İş Analisti

Devamını Oku