Requirement Elicitation: Görüşme, Gözlem, Workshop ve Prototiple Gerçek İhtiyacı Çıkarmak

Sürüm notu: Bu yazı kavramsaldır; elicitation'ın hazırlık, yürütme ve teyit adımları için IIBA'nın (International Institute of Business Analysis) BABOK (Business Analysis Body of Knowledge) Guide v3'ündeki Elicitation and Collaboration bilgi alanı, terimler için ISO (International Organization for Standardization), IEC (elektroteknik standartları yayımlayan uluslararası kuruluş) ve IEEE'nin (Institute of Electrical and Electronics Engineers) ortak standardı ISO/IEC/IEEE 29148:2018 esas alınmıştır.

Önce Tahmin Et

Önceki yazıda Bookstore ekibi, Hakan'ın "Excel'den yükleme ekranı" talebinin arkasındaki problemi ilk kez yazdı: kurumların kitap listeleri farklı biçimlerde geliyor, müşteri hizmetleri bunları elle giriyor, eylülde siparişler birikiyor ve yanlış kitaplar gidiyor. Product Owner Selin'in toplu sipariş özelliği için ilk sprint planning'e kadar iki haftası var.

Üç kişi konuşmaya hazır. Kurumsal satış müdürü Hakan, on iki yıldır okullarla çalışıyor ve ne istendiğini bildiğinden emin. Özel bir okulun müdür yardımcısı, siparişleri imzalayan kişi. Aynı okulun satın alma sorumlusu Nevin Hanım ise listeleri öğretmenlerden toplayıp hazırlayan kişi. Selin'in yalnız bir günü varsa önce kiminle konuşmalı?

İkinci soru: görüşmeye şu iki sorudan hangisiyle başlamalı? "Toplu sipariş ekranında neler olmasını istersiniz?" mi, yoksa "Geçen eylül siparişi nasıl hazırladınız, baştan anlatır mısınız?" mı?

Elicitation: Toplamak Değil, Ortaya Çıkarmak

Türkçede bu iş çoğu zaman "requirement toplamak" diye anılır ve bu ifade yanıltıcıdır. Toplamak, requirement'ların bir yerde hazır durduğunu, birinin gidip onları sepete koyacağını ima eder. Gerçekte requirement'ların çoğu kimsenin aklında cümle olarak durmaz; stakeholder'ın işini anlatırken, bir dokümanın kenarındaki notta ya da bir prototipe tıklarken ortaya çıkar. ISO/IEC/IEEE 29148 de elicitation'ı pasif bir derleme olarak değil, prototip ve yapılandırılmış anket gibi sistematik tekniklerle ihtiyaçları proaktif biçimde belirleme işi olarak tanımlar.

BABOK bu işi üç adıma ayırır ve bu ayrım bir geliştirici için bile çok pratiktir. Hazırlık: kapsamı, kiminle konuşulacağını ve hangi tekniğin kullanılacağını seçmek. Yürütme: görüşmeyi, gözlemi, workshop'u yapmak; buradan çıkan şey BABOK'un deyişiyle henüz teyit edilmemiş bilgidir. Teyit: anlaşılanı stakeholder'a geri götürüp "doğru mu anladık?" diye sormak ve kaynaklar arasındaki çelişkileri ayıklamak. Ekiplerin çoğu ikinci adımı yapar, üçüncüsünü atlar ve not defterindeki cümleleri requirement diye backlog'a taşır.

BABOK teknikleri de üç gruba ayırır: stakeholder'la doğrudan etkileşim (görüşme, workshop), mevcut veri ve dokümandan araştırma (doküman analizi) ve kontrollü denemeler (prototip). Bu yazıda her gruptan en az bir tekniği toplu sipariş üzerinde kullanacağız.

Bir sınırı da baştan çizelim. Hangi problemin çözülmeye değer olduğunu bulmak, yani product discovery, Product Management'a Giriş serisinin "Product Discovery" yazısının konusuydu; o yazıdaki müşteri görüşmesi ilkeleri burada da geçerli. Elicitation ise genellikle çözülecek problem seçildikten sonra başlar ve şunu sorar: bu problemi çözecek sistem tam olarak hangi kurallara, hangi istisnalara, hangi kısıtlara uymalı?

Stakeholder Haritası

Elicitation'ın ilk adımı, kimin bu özellikten etkilendiğini ve kimin bir şey bildiğini çıkarmaktır. Selin ile geliştiriciler Emre ve Ayşe yarım saatte şu listeyi çıkarıyor:

Tablonun en değerli satırı, ilk akla gelmeyenlerdir. Öğretmenler sistemi hiç kullanmayacak, ama listenin şube şube ve kitap adıyla gelmesinin sebebi onlar. Vakıf muhasebesi de sisteme girmeyecek, ama "fatura kime kesilir?" sorusunun tek gerçek cevabını o verir. Haritayı çıkarırken her satır için iki şeye ayrı ayrı bak: bu kişinin kararlar üzerindeki etkisi ve bu kişinin iş hakkında bildikleri. Hakan'ın etkisi büyük; Gül'ün bilgisi. Elicitation'da ikisine de ihtiyacın var, ama ikisinden aynı şeyi bekleme.

Görüşme: "Bana Son Seferi Anlatın"

Önce Tahmin Et'teki iki sorudan ikincisi doğru başlangıç. "Neler olmasını istersiniz?" sorusu, karşındakini ürün tasarımcısı rolüne iter; cevap genellikle başka bir sitede gördüğü bir özelliktir. "Geçen sefer nasıl yaptınız?" sorusu ise gerçekte olmuş bir olayı anlattırır ve olaylar istisnalarla doludur.

Selin ile Emre, Nevin Hanım'la kırk beş dakikalık görüşmeye bir soru listesiyle gidiyor ama listeye sıkı sıkıya bağlı kalmıyor. Görüşmenin bir kesiti:

"Geçen eylülün siparişini düşünün. İlk adım neydi?" Nevin Hanım anlatıyor: haziranda on dört zümre başkanına boş bir tablo gönderiyor; tablolar ağustosun ortasına kadar dönüyor, bir kısmı kitap adıyla, bir kısmı ISBN ile. "Sonra?" Tabloları tek dosyada birleştiriyor, aynı kitabı isteyen şubeleri topluyor, vakfın muhasebesine toplam tutarla onaya gönderiyor. "Onay ne kadar sürüyor?" Bir hafta; vakfın bütçe onayı 15 Ağustos'tan sonra çıkmazsa sipariş eylülün ikinci haftasına kalıyor. "Sipariş gittikten sonra neler oldu?" Okulun açıldığı ilk hafta üç öğretmen listesini değiştirmiş, Nevin Hanım düzeltme listelerini ayrı e-postalarla göndermiş. "Kitaplar nereye geldi?" Okulun üç kampüsü var; her kampüse ayrı koli gelmesi gerekiyor ama geçen yıl hepsi merkez kampüse gelmiş ve okul servisiyle dağıtılmış.

Bu kırk beş dakikadan çıkan bilgilerin hiçbiri Hakan'ın e-postasında yoktu: bütçe onayı bir tarihe bağlı, listeler sipariş verildikten sonra da değişiyor, teslimat noktası birden fazla, fatura okula değil vakfa kesiliyor. Hiçbirini Nevin Hanım'a doğrudan sormadık; olayı anlatırken kendiliğinden söyledi.

İyi bir görüşmenin birkaç alışkanlığı var. Somut bir olayı sor ve olayın sırasını takip et. Cevabı bir sonraki "sonra?" ile genişlet, yorumunla kapatma. Bir istisna duyduğunda orada dur: "Bu kaç kez oldu? En son ne zaman?" Kendi çözüm fikrini görüşmede söyleme; karşındaki seni memnun etmek için ona katılır. Ve görüşmenin sonunda mutlaka sor: "Size sormadığım ama sormam gereken bir şey var mı?"

Kütüphane müdürüyle yapılan görüşme bambaşka bir akış ortaya çıkarıyor: belediye önce yazılı bir fiyat teklifi istiyor, teklif kendi içinde onaylanmadan sipariş verilemiyor ve ödeme teslimattan sonra faturayla yapılıyor. Aynı "toplu sipariş" kelimesinin arkasında iki farklı süreç var.

Gözlem ve Doküman Analizi

İnsanlar işlerini anlatırken alışkanlık hâline gelmiş adımları atlar. Bu yüzden Emre bir sabahı müşteri hizmetlerinde, Gül'ün yanında geçiriyor ve yaz okulu için gelen iki küçük kurumsal siparişi işlerken onu izliyor. Soru sormadan önce izliyor, sonra gördüklerini soruyor.

Gördükleri: Gül'ün masaüstünde "ISBN düzeltmeleri" adlı kişisel bir Excel dosyası var; baskısı tükenmiş kitapların eski ISBN'leriyle yeni baskılarının ISBN'leri yan yana. Bir satırda katalogda olmayan bir kitap çıktığında okulu arayıp alternatif öneriyor. Kısmi gönderilen siparişleri ise bir defterde takip ediyor. Bu üç alışkanlığın hiçbiri herhangi bir dokümanda yazmıyor; Gül'e sorulduğunda "bunlar işin doğası" diyor. Tam olarak bu nedenle bunlar requirement adayı: yeni sistem bu işleri yapmazsa Gül defterini ve kişisel Excel'ini kullanmaya devam edecek.

Doküman analizi aynı soruya geçmişin verisiyle bakar. Selin, geçen eylül gelen 46 kurumsal siparişin e-postalarını ve eklerini inceliyor. Sonuç: dokuz farklı dosya düzeni; 31 dosyada ISBN var, 15'inde yalnızca kitap adı; 6 dosyada aynı kitap şube başına ayrı satırda; 12 e-postada fatura bilgisi dosyada değil e-postanın gövdesinde; 4 siparişin arkasından düzeltme listesi gelmiş. En büyük liste 870 satır. Bu sayılar, önceki yazıda "1.000 satıra kadar" diye yazdığımız requirement'ın nereden geldiğini gösteriyor ve tartışmayı görüşlerden verilere taşıyor.

Workshop: Herkes Aynı Duvarın Önünde

Görüşmeler ve gözlem farklı kişilerden parça parça bilgi getirir; parçaların birbiriyle çeliştiğini ancak hepsini yan yana koyunca görürsün. Selin bu yüzden doksan dakikalık bir workshop düzenliyor: Hakan, Gül, depo sorumlusu, Bookstore muhasebesinden bir kişi, çevrim içi bağlanan Nevin Hanım, Emre ve Ayşe.

Gündem tek bir şey: geçen eylülün gerçek bir siparişini, listenin hazırlanmasından faturanın ödenmesine kadar duvara yapışkan notlarla dizmek. Her katılımcı kendi adımlarını kendi renginde yazıyor; sonra herkes sorun yaşadığı adımın yanına kırmızı bir nokta koyuyor.

Duvar iki çelişkiyi hemen görünür kılıyor. Depo sorumlusu "bir sipariş, bir sevkiyat" kuralının kendi planlaması için şart olduğunu söylüyor; Nevin Hanım ise üç kampüse ayrı teslimat istiyor. Bookstore muhasebesi ERP'ye sipariş başına tek fatura aktarabildiğini söylüyor; vakfın ise kampüs başına ayrı fatura isteyip istemediği belli değil. Workshop bu çelişkilerin ikisini de çözmüyor, çözmesi de gerekmiyor; ama ikisi de artık birinin sorumluluğunda, tarihli birer açık soru.

Workshop'ta Selin'in en önemli işi kolaylaştırıcılık: en yüksek sesin tartışmayı ele geçirmesini engellemek. Hakan'ın her cümlesinden sonra Gül'e ve Nevin Hanım'a "sizde de böyle mi oluyor?" diye sormak, bütün workshop'un değerini değiştiriyor.

Prototiple Varsayımı Erken Test Etmek

Görüşmelerden çıkan bir varsayım var: satın alma sorumluları listeyi dosya olarak yüklemek isteyecek. Bunu bir sprint harcayıp öğrenmek yerine Ayşe bir günde Angular'da tıklanabilir bir iskelet hazırlıyor: backend yok, veriler sabit; ekranda bir yapıştırma alanı, bir "kontrol et" düğmesi ve doğrulama sonucunu gösteren bir tablo var. Kâğıt üzerinde çizilmiş bir taslak da aynı işi görebilirdi; önemli olan, kimsenin bu prototipi production koduna dönüştürmeye çalışmaması.

Prototip üç satın alma sorumlusuyla, her biri yirmi dakika, deneniyor. Her birine yalnızca bir görev veriliyor: "Geçen yılki listenizi sipariş etmeye hazırlayın." Gözlenenler: iki kişi dosya aramadan Excel'deki ISBN ve adet sütunlarını kopyalayıp yapıştırıyor. Üçüncüsünün listesinde ISBN yok; yapıştırma alanı onun için işe yaramıyor ve kitap adıyla arama ihtiyacı ortaya çıkıyor. Üçü de aynı soruyu soruyor: "Bunu taslak olarak kaydedip müdüre onaya gönderebilir miyim?"

Son soru, hiçbir görüşmede çıkmamış bir requirement: okul içinde bir onay adımı. Prototipin değeri tam olarak bu; insanlar bir şeye tıklarken, ona dair konuşurken hiç söylemedikleri ihtiyaçları dile getirir. Bir uyarı: "Çok güzel olmuş" bir prototip testi sonucu değildir. Sonuç, kullanıcının görevi tamamlayıp tamamlamadığı ve nerede takıldığıdır.

Notlardan Glossary'ye ve Açık Soru Listesine

İki haftanın sonunda Selin'in elinde görüşme notları, bir duvar fotoğrafı, doküman analizi sayıları ve prototip gözlemleri var. Bunlar henüz requirement değil; elicitation'ın iki somut çıktısı olmaları gerekiyor: bir glossary ve bir açık soru listesi.

Glossary, ekip ile stakeholder'ların aynı kelimeyi aynı anlamda kullanmasını sağlar. Domain-Driven Design serisinin "Ubiquitous Language" yazısında, bu dilin kodda nasıl korunduğunu görmüştük; burada dilin doğduğu yere bakıyoruz. Bookstore ekibinin ilk glossary satırları şöyle: "Kurum" (kodda Institution) Bookstore'la sözleşmesi olan okul ya da kütüphanedir, faturanın muhatabı olan vakıf ya da belediye ayrı bir kavramdır ve "Fatura muhatabı" (BillingParty) diye geçer. "Teslimat noktası" (DeliveryPoint) bir kurumun kitapların teslim edileceği her adresidir; bir okulun birden fazla teslimat noktası olabilir. "Satın alma emri numarası" (PurchaseOrderNumber) kurumun kendi muhasebesinde verdiği numaradır ve faturada görünmek zorundadır. "Onay limiti" (ApprovalLimit) kurumun, üzerindeki siparişler için iç onay istediği tutardır.

Glossary'yi yazarken bir kelimenin iki anlamı olduğunu fark edersen, bu bir hata değil, bir bulgudur. "Toplu sipariş" kelimesi Hakan için bir kurumun siparişi, depo için çok adetli bir sevkiyattı; ekip glossary'de "kurumsal sipariş" terimini seçip "toplu"yu yalnız adet bağlamında kullanmaya karar veriyor.

Açık soru listesindeki her satırın üç parçası var: soru, cevabı kimin vereceği ve hangi tarihe kadar. Bookstore'un listesinin ilk maddeleri:

• "Minimum 20 adet" kuralı siparişin toplamı için mi, her kitap için mi? Kurumsal satış (Hakan), 15 Temmuz.
• Stok yetersizse kurum kısmi sevkiyatı kabul ediyor mu, yoksa bekletmeyi mi tercih ediyor? İki okul ve kütüphane, 18 Temmuz.
• Vakıf kampüs başına ayrı fatura istiyor mu? Vakıf muhasebesi, 18 Temmuz.
• Okul içi onay adımı ilk sürümde gerekli mi, yoksa sipariş e-postayla onaylatılıp sonra mı giriliyor? Nevin Hanım, 20 Temmuz.

Bu listedeki kural sorularının bir kısmını 05. yazıda Example Mapping oturumunda örneklerle netleştireceğiz. Listede olmayan ama elicitation'ın en değerli çıktısı olan şey ise söylenmeyen kurallar (tacit knowledge): bütçe onayının 15 Ağustos'a bağlı olması, faturanın vakfa kesilmesi, öğretmenlerin listeyi okul açıldıktan sonra değiştirmesi. Bunları ayrı bir başlık altında, kaynağıyla birlikte yaz; ilk okumada fark edilmeyecek kadar "doğal" oldukları için en kolay kaybolan bilgiler bunlardır.

Üretimde Dikkat

Teyit adımını atlama. Her görüşmeden sonra kısa bir özet yazıp konuştuğun kişiye gönder: "Şunları anladık, yanlış ya da eksik olan var mı?" Nevin Hanım'a giden özete gelen cevap, bir ayrıntıyı düzeltti: kampüs teslimatı yalnız ders kitapları için gerekiyormuş, kütüphane kitapları merkeze gelebilirmiş. Teyit edilmemiş not, ekip içinde dolaştıkça kesinleşmiş bilgiye dönüşür.

Her bilginin kaynağını sakla. "Fatura vakfa kesilir" cümlesinin yanında kimin söylediği ve hangi tarihte söylediği yazmalı. Altı ay sonra kural değiştiğinde kime soracağını bu not söyler.

Görüşmeyi kaydetmek istiyorsan önce açıkça izin al. Ses kaydı kişisel veridir; KVKK (Kişisel Verilerin Korunması Kanunu) kapsamında ne yapman gerektiğini şirketinin hukuk ya da veri koruma sorumlusuna sor ve kayıtları gerekenden uzun tutma.

Görüşmede söz verme. "Bunu da ekleriz" cümlesi, stakeholder'ın aklında bir taahhüde dönüşür; öncelik kararı Product Owner'ındır ve görüşmede değil, backlog'da verilir.

Sık Düşülen Tuzaklar

İlk tuzak yalnız en yüksek sesli stakeholder'ı dinlemek. Hakan'ın deneyimi değerli, ama Hakan kendi işini anlatıyor; Gül'ün defterini, Nevin Hanım'ın bütçe tarihini ve vakfın faturasını bilmiyor. Workshop'ta sessiz kalanlara doğrudan sor; görüşme listesine etkisi az ama bilgisi çok olan kişileri bilerek koy.

İkinci tuzak kullanıcı yerine yöneticisiyle konuşmak. Müdür yardımcısı siparişi imzalıyor ama hazırlamıyor; onunla yapılan bir görüşme süreci olması gerektiği gibi anlatır, olduğu gibi değil. Asıl işi yapan kişiye ulaşmak için yöneticiden izin istemek gerekebilir; bunu yapmaya değer.

Üçüncüsü yönlendirici soru sormak. "Excel'den yükleme işinizi kolaylaştırır, değil mi?" sorusunun tek kibar cevabı "evet"tir. Soruyu açık uçlu sor ve geçmişteki bir olaya bağla.

Dördüncüsü elicitation'ı projenin başında bir kez yapılan bir faz sanmak. Prototip testinde çıkan okul içi onay adımı, iki hafta önce yapılan görüşmelerin hiçbirinde yoktu. Her yeni story ve her demo, yeni bir elicitation fırsatıdır.

Beşincisi geliştiricileri elicitation'ın dışında tutmak. Emre'nin Gül'ün yanında geçirdiği sabah, ISBN düzeltme listesini ortaya çıkardı; bu bilgi bir toplantı özetinden okunsaydı muhtemelen önemsiz bir ayrıntı gibi görünürdü.

Küçük Bir Deneme

★☆☆ Üzerinde çalıştığın bir özellik için stakeholder haritası çıkar. Her satıra "etkisi" ve "bildikleri" diye iki ayrı not düş ve henüz hiç konuşmadığın, bilgisi yüksek bir kişiyi bul.

★★☆ Bir kullanıcıyla on beş dakikalık bir görüşme yap ve tek bir soruyla başla: "Bu işi en son ne zaman yaptınız, baştan anlatır mısınız?" Duyduğun her istisnayı yaz; sonra mevcut requirement metninde bu istisnaların kaçının geçtiğini say.

★★★ Ekibinin kullandığı terimlerden on tanesini al ve her biri için glossary satırı yaz: Türkçe terim, koddaki adı, tek cümlelik tanım. Aynı kelimeyi iki farklı anlamda kullandığınız en az bir yer bul ve hangi anlamın hangi kelimeyle anılacağına ekipçe karar verin.

Elicitation'dan bir glossary, bir açık soru listesi ve bir yığın teyit edilmiş bilgiyle çıktık. Bunları geliştirme ekibinin üzerinde çalışabileceği parçalara dönüştürmek gerekiyor. Bir sonraki yazıda toplu siparişi önce bir use case olarak yazıp sonra user story'lere böleceğiz: card, conversation ve confirmation üçlüsünü, INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) kontrolünü ve use case'in hâlâ daha iyi olduğu durumları göreceğiz.