İsimlere Kulak Verin

🌐 28 dilde daha mevcut

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku

Data Architect kursunun 2. bölümü olan Veriyi Anlam İçin Modellemek bölümündeki 6 modülden 1.‘si. Her modül kendi başına okunabilir. Önceki: bölüme genel bakış · Sonraki: İlişkileri Çizin

Bu modülün yanıtladığı soru: Bir iş konuşmasında bir veri modelinin başlangıçlarını nasıl bulurum?

Bir müşteriyle ilk görüşmede yaptığım şeylerden biri isimlere kulak vermektir.

İlk tasarım oturumundan bahsetmiyorum. Hâlâ işi ve neyi başarmaya çalıştıklarını anlamaya çalıştığım o ilk konuşmadan bahsediyorum.

Onlar konuşuyor. Ben dinliyorum.

Ve şu tür sözcüklere kulak veriyorum:

Perakende Ortağı. Alıcı. Dağıtım Merkezi. Yük Listesi. Teslimat. Rota. Ekip. Kamyon.

Bu isimler hemen dikkatimi çeker, çünkü o konuşmanın bir yerinde veri modelimin başlangıçları vardır.

Sorunu tamamen anladığımı düşünene kadar beklemem. Hâlâ dinlerken veriyi görmeye başlarım: isimleri duyarım, birbirleriyle nasıl ilişkili olduklarını çizmeye başlarım ve o taslak bir sonraki konuşmayı çerçevelememe yardım eder. Bazen bir müşteriyle ilk toplantının sonunda kendime ait, kimseye göstermediğim bir veri modelini çoktan çizmiş olurum.

Benim için bu, isimlerle başlar.

Bir Dakikalığına Salesforce’u Unutun

Burada, özellikle bir süredir Salesforce yöneticisiyseniz çok güçlü olan bir içgüdüye direnmenizi istiyorum.

Müşteri müşteri diyor ve siz şunu düşünüyorsunuz:

Hesap.

Kişi diyorlar ve siz şunu düşünüyorsunuz:

Kişi (Contact).

Dağıtım merkezi diyorlar ve siz şimdiden özel bir nesneye ihtiyacınız olup olmadığını merak ediyorsunuz.

Bunu henüz yapmayın.

Bu noktada bir müşterinin sonunda bir Hesap mı, bir Kişi Hesabı mı, özel bir nesne mi yoksa başka bir şey mi olacağı umurumda değil. Önce işi anlamak istiyorum.

İşi modellemek ile Salesforce’u yapılandırmak arasındaki fark budur. Salesforce nesneleriyle başlarsam düşüncemi daha baştan tek bir uygulamayla sınırlamış olurum. Tam da beklediğim yere varabilirim, ama oraya işin beni götürdüğü için varmak isterim; Hesap ve Kişi bildiğim ilk iki nesne olduğu için değil.

Yani birkaç dakikalığına Salesforce’u unutun. İşi gerçekten yürüten insanların kendi dünyalarını nasıl anlattığını dinleyin.

Otur, Bekle, Modelle

Bir işletmeyi dinlemeden önce, herkesin zaten anladığı bir şeyi dinleyelim. Bunu canlı olarak öğretirken köpeklerle başlarım.

İşte bir köpek: Marcus, Bella’nın sahibi. Onu Maple Ridge Kennels yetiştirdi. Bir Labrador ve Otur, Bekle ve Pati Ver’i biliyor.

İsimlere kulak verin: Marcus, Bella, Maple Ridge Kennels, Labrador, Otur. Ama bunlar özel adlar: belirli şeyler. Benim istediğim, her adın ait olduğu şeyin türü. Bella bir Köpek. Marcus bir Sahip. Maple Ridge Kennels bir Yetiştirici. Labrador bir Irk. Otur bir Numara. Beş isim, beş aday kutu.

Click to enlarge

Sonra her isme sorduğum soru: bu, bir iş yapan bir kişi mi, yoksa bir veri parçası mı? Marcus bir kişi. Ama Bella’nın sahibi olmak bir iş değildir; Bella hakkında bir olgudur ve er ya da geç biri “Bu köpeğin sahibi kim?” diye sorar. Bu yüzden Sahip modelde yer alır. Bella’ya pati vermeyi öğreten eğitmen ise bir iş yapan bir kişidir ve belki hiç kutuya ihtiyaç duymaz; tabii işletme hangi numarayı kimin öğrettiğini sormaya başlamadıkça.

Ve aday sözcüğüne dikkat edin. Irk gerçekten kendi başına bir kutu mu, yoksa sadece köpeğin üzerine yazılmış bir sözcük mü? Bu soruyu aklınızda tutun; 4. modülde normalleştirme yaparken cevaplayacağız.

Tekniğin tamamı bu, küçük bir şey üzerinde. Şimdi gerçek bir işletmeyi dinleyelim.

İsimler Size Aday Varlıklar Verir

Bu kurs boyunca kullanacağımız aile şirketi Steve Trucking’i dinleyelim. Büyük perakendecilerin dağıtım merkezlerinden insanların evlerine büyük ürünler (buzdolapları, çamaşır makineleri, televizyonlar) teslim ediyor ve bazılarının kurulumunu yapıyor.

İlk konuşmada şunları duyuyoruz:

• Perakende Ortağı (Retail Partner)
• Alıcı (Recipient)
• Dağıtım Merkezi (Distribution Center)
• Yük Listesi (Manifest)
• Teslimat (Delivery)
• Rota (Route)
• Ekip (Crew)
• Kamyon (Truck)

Bu bile işe yarar. Bir beyaz tahtaya kutular koymaya başlayabilirim.

Öyleyse isimleri dikdörtgenlerin içine koyun. Bu noktada olabilecekleri tek şey bu: kutular. Çizgi yok, renk yok, Salesforce diyen hiçbir şey yok. Kursun ilerleyen kısımlarında şekiller ve renkler bir anlam taşımaya başlayacak. Şimdilik bir dikdörtgen yalnızca işin bahsettiği bir şeydir.

Sonra onları yerleştirmeye başlayın. Her kutuyu koyarken iki şeyi düşünmelisiniz: birbirleriyle nasıl ilişkili oldukları ve ne tür veri oldukları. Bir kısmı müşteri verisidir: birlikte çalıştığımız işletmeler ve insanlar. Bir kısmı siparişler ve sipariş kalemleri gibi işlem verisidir: tekrar tekrar olan şeyler. Bir kısmı da bir işletmenin sunduğu ürünler ya da hizmetler gibi referans verisidir: işin dayandığı şeyler.

Steve Trucking’de Perakende Ortağı ve Alıcı müşteri verisidir. Yük Listesi, Teslimat ve Rota işlemlerdir. Dağıtım Merkezi, Ekip ve Kamyon işin dayandığı şeylerdir.

Click to enlarge

Ama burada önemli bir sözcük var: aday.

Bir isim bir ipucudur. Otomatik olarak bir varlık değildir ve kesinlikle otomatik olarak bir Salesforce nesnesi değildir.

Bir keşif oturumundayken her ismi not ederim. Söyledikleri her isim için kendime tek bir soru sorarım: bu bir iş yapan bir kişi mi, yoksa bir veri parçası mı? Bir iş geliştirme yöneticisi bir iş yapan bir kişidir. Bu bir kullanıcıdır, bir roldür, belki bir izin kümesidir. Siparişler, faturalar, satır kalemleri: bunlar veri parçalarıdır. İkisi de önemlidir, ama tasarımda çok farklı yerlere düşerler ve onları erkenden ayırmak, organizasyon şemasındaki her unvan için bir kutu çizmekten beni kurtarır.

Bu isimlerin bazıları insan olacak. Steve Trucking’de bunlar buzdolabını bekleyen Alıcı, yük listesini gönderen Perakende Ortağı çalışanları ve Ekip’tir: kamyondaki sürücüler ve yardımcılar. Bunlar rollerdir ve bir rol veri gibi görünmeyebilir. Ama insanlar veri üzerinde işlem yaptığında ya da veriyle ilişkili olduğunda, kendilerinin de veride temsil edilmesi gerekir. Bunu kim teslim etti? Kim imzaladı? Yük listesini kim gönderdi? Bu yüzden pek çok rol, bazen hepsi, modelde de yer alır.

Steve Trucking’in nasıl konuştuğunu dinleyin, bir şey fark edeceksiniz. Hiçbir zaman yalnızca “müşteri” demiyorlar. İki tür müşteri var. Perakende Ortağı, Steve Trucking’in adına teslimat yaptığı büyük perakendecidir: yük listesini gönderir ve teslimat başına ödeme yapar. Alıcı ise buzdolabının teslim edildiği kişidir. Alıcı onu mağazadan satın almıştır ve Steve Trucking’i hiç duymamış olabilir.

Müşteri adında tek bir kutu çizseydim, tamamen farklı iki şeyi birbirine karıştırmış olurdum.

Belki Dağıtım Merkezi kendi kaydına, geçmişine, ilişkilerine ve özniteliklerine sahip olacak kadar önemlidir.

Belki başka bir isim, başka bir şeyin özniteliğinden başka bir şey olmadığı ortaya çıkar.

Keşfetmeye çalıştığımız şey bu. Henüz nesne oluşturmuyoruz. İşe dair anlayışımızı inşa ediyoruz.

Şimdi İlişkilere Kulak Verin

İsimler bana başlayacak bir yer verir. Sonra işin onları nasıl bağladığını dinlerim.

Bir Perakende Ortağı Dağıtım Merkezleri işletir.

Bir Perakende Ortağı, her DC ve teslimat günü için bir Yük Listesi gönderir.

Bir Yük Listesi Teslimatları listeler.

Bir Teslimat bir Alıcıya gider.

Bir Rota, yaklaşık on Duraktan oluşan bir günlük turdur.

İki kişilik bir Ekip bir Kamyonu kullanır.

Şimdi bir şeyler oluyor. Artık bir isim listesine bakmıyorum. Bir model görmeye başlıyorum.

Click to enlarge

Soruların ortaya çıkmaya başladığı yer de burasıdır.

Bir Perakende Ortağının birden fazla dağıtım merkezi olabilir mi?

Bir teslimat bir durakla aynı şey mi?

Bir durak iki Alıcıya teslimat yapabilir mi?

Bir ekip her zaman aynı iki kişiden mi oluşur?

Geçen ay hangi ekibin hangi kamyonu kullandığını önemsiyor muyuz, yoksa yalnızca bugün hangi kamyonu sürdüklerini mi?

Ne yaptığımıza dikkat edin. Henüz Salesforce soruları sormuyoruz. İş soruları soruyoruz. Ve bu yanıtlar sonunda Salesforce tasarımını yönlendirecek.

İlk Modelinizin Mükemmel Olması Gerekmez

Çizdiğim ilk kutuların değişmeden kalmasını beklemem. Aslında kalsalar şüphelenirdim.

İlk modelin amacı doğru olmak değildir. Amaç, nerede yanıldığımızı keşfetmemize yetecek kadar somut bir şey ortaya koymaktır.

Tahtaya Teslimat, Rota, Ekip ve Kamyon koyun; insanlar bunlara tepki verebilir.

“Aslında bir teslimat her zaman tek bir ürün değildir. Bir çamaşır makinesi, bir kurutma makinesi ve eskilerinin götürülmesi olabilir.”

Güzel. Biraz daha anlatın.

“Bir teslimata ekip atamıyoruz. Ekibi bir rotaya atıyoruz.”

Harika. Rotada neler var?

“Ve bir kurulum varsa, kontrol listesi ve fotoğraflar tamamlanmadan ekip durağı kapatamaz.”

Şimdi önemli bir şey öğreniyoruz.

Bir diyagram belirsiz bir konuşmayı itiraz edebileceğimiz bir şeye dönüştürdü. Erken modellemeyi sevmemin nedenlerinden biri bu. Odayı güzel bir diyagramla etkilemeye çalışmıyorum. Daha hızlı öğrenmeye çalışıyorum.

Model konuşmanın bir parçasıdır.

Bu Sizin Kavramsal Modelinizdir

İnşa etmeye başladığımız şeyin resmî bir adı var: kavramsal veri modeli.

Bu düzeyde işin önemsediği önemli şeylerle ve bunların nasıl ilişkili olduğuyla ilgileniyorum. Standart ya da özel nesneler, alan API adları, arama ilişkisi ya da ana-ayrıntı ilişkisi, zorunlu alanlar, dizinler, otomasyon, Apex ya da Flow’lar henüz beni endişelendirmiyor. Bunlar önemlidir ve oraya geleceğiz. Ama neyi modellediğimizi anlamadan önce bunlara karar verirsek, önce yanlış sorunu çözüyoruz demektir.

Kavramsal model, odada Salesforce bilmeyen insanlar için de anlamlı olmalıdır. Bu yararlı bir testtir. Operasyon müdürü diyagramımı okuyabilsin diye önce Delivery__c’nin ne anlama geldiğini açıklamam gerekiyorsa, uygulamaya çok erken geçmişim demektir.

Modele bakıp şunu söylemelerini isterim:

“Evet, işimiz böyle işliyor.”

Ya da daha iyisi:

“Hayır, öyle işlemiyor.”

Çünkü artık düzeltecek bir şeyim var.

Aynı Teknik Kimse Konuşmadığında da İşe Yarar

Bu yalnızca müşteri keşfinde kullandığım bir şey değil. “Müşteri” bir belge olduğunda da işe yarar.

Bir gereksinim belgesi üzerinde çalışırken de hemen hemen aynı şeyi yapıyorum. Önemli iş kavramları neler? Hangi ilişkiler tanımlanıyor? Tekrar tekrar ne geçiyor? Neyin kendi yaşam döngüsü var, neyin kendi başına tanımlanması ya da geçmişinin tutulması gerekiyor? Ne oluşturuluyor, değiştiriliyor, atanıyor, aktarılıyor, planlanıyor ya da kullanımdan kaldırılıyor?

Bunlar o ilk toplantıda kulak verdiğim şeylerin aynısıdır. Bir sayfada bu ipuçları, paragraflarca gereksinimi üzerinde akıl yürütebileceğim bir modele ve bir sonraki konuşma için daha iyi sorulara dönüştürür.

Bir model, sorunu çözdükten sonra ürettiğiniz bir şey değildir yalnızca. Sorunu çözmek için kullandığınız araçlardan biridir.

Mimarın Burada Karar Verdikleri

Bu ilk turun sonunda karar vermeye çalıştığım şeyler:

• Hangi isimlerin anlamlı aday varlıkları temsil ettiği.
• Hangi farklı sözcüklerin aynı iş kavramını temsil ettiği ve hangi tek sözcüğün iki kavramı gizlediği (“müşteri” gibi).
• Hangi kavramların kendi kaydına ve yaşam döngüsüne ihtiyaç duyduğu.
• Ana kavramların birbirleriyle nasıl ilişkili olduğu.
• Onları güvenle modelleyebilmem için işin hangi soruları yanıtlaması gerektiği.

Salesforce uygulamasına henüz karar vermiyorum. Önce işi çizebilecek kadar iyi anlamamız gerekiyor. Ve isimler tahtaya geldiğinde anlamak istediğim bir sonraki şey aralarındaki çizgilerdir.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Bir yapay zekâ aracına bir gereksinim belgesi verin; saniyeler içinde isimleri bulur, varlıklar önerir ve ilişkileri çizer. Keşfi hızlandırmak için kullanın, ama anlamayı dışarıya devretmeyin: iş size söylemedikçe Steve Trucking’de “müşteri”nin iki farklı anlama geldiğini bilemez. İlk modelini işi yürüten insanların önüne koyun ve sorun: “İşiniz gerçekten böyle mi işliyor?”