Naslouchejte podstatným jménům

🌐 K dispozici také v 29 jazycích

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

Obrázek vytvořený pomocí AI

Přeloženo pomocí AI. Komunita překlad zatím nezkontrolovala. Číst anglicky

Modul 1 z 6 kapitoly Modelování dat podle významu, kapitoly 2 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: přehled kapitoly · Další: Nakreslete vztahy

Otázka, na kterou tento modul odpovídá: Jak v obchodním rozhovoru najdu začátky datového modelu?

Jedna z věcí, které dělám na prvním hovoru s klientem, je, že naslouchám podstatným jménům.

Nemluvím o prvním návrhovém sezení. Mluvím o tom úvodním rozhovoru, kdy se pořád snažím pochopit byznys a to, čeho chtějí dosáhnout.

Oni mluví. Já poslouchám.

A poslouchám slova jako:

Maloobchodní partner. Příjemce. Distribuční centrum. Manifest. Doručení. Trasa. Posádka. Kamion.

Tato podstatná jména okamžitě upoutají mou pozornost, protože někde v tom rozhovoru jsou začátky mého datového modelu.

Nečekám, až si budu myslet, že problému úplně rozumím. Data začínám vidět, už když poslouchám: slyším podstatná jména, začnu si načrtávat, jak spolu souvisejí, a ten náčrt mi pomáhá připravit další rozhovor. Někdy už na konci první schůzky s klientem mám nakreslený svůj vlastní soukromý datový model.

U mě to začíná podstatnými jmény.

Na chvíli zapomeňte na Salesforce

Tady chci, abyste odolali instinktu, který je obzvlášť silný, pokud jste nějakou dobu administrátorem Salesforce.

Klient řekne zákazník a vy si pomyslíte:

Účet (Account).

Řekne osoba a vy si pomyslíte:

Kontakt.

Řekne distribuční centrum a vy už přemýšlíte, jestli potřebujete vlastní objekt.

To zatím nedělejte.

V tuto chvíli je mi jedno, jestli se ze zákazníka nakonec stane účet, osobní účet (Person Account), vlastní objekt nebo něco jiného. Nejdřív chci porozumět byznysu.

To je rozdíl mezi modelováním byznysu a konfigurací Salesforce. Když začnu objekty Salesforce, už jsem své myšlení omezil na jednu implementaci. Možná skončím přesně tam, kde jsem čekal, ale chci se tam dostat proto, že mě tam dovedl byznys, ne proto, že účet a kontakt byly první dva objekty, které jsem znal.

Takže na pár minut zapomeňte na Salesforce. Poslouchejte, jak svůj svět popisují lidé, kteří byznys skutečně řídí.

Sedni, zůstaň, modeluj

Než začneme poslouchat byznys, poslechněme si něco, čemu už rozumí každý. Když tohle učím naživo, začínám psy.

Tady je pes: Marcus je majitelem Belly. Vyšlechtila ji chovatelská stanice Maple Ridge Kennels. Je to labrador a umí povely Sedni, Zůstaň a Podej pac.

Poslouchejte podstatná jména: Marcus, Bella, Maple Ridge Kennels, labrador, Sedni. To jsou ale jména: konkrétní věci. Já chci druh věci, ke kterému každé jméno patří. Bella je Pes. Marcus je Majitel. Maple Ridge Kennels je Chovatel. Labrador je Plemeno. Sedni je Trik. Pět podstatných jmen, pět kandidátních krabic.

Kliknutím zvětšíte

Pak otázka, kterou kladu u každého podstatného jména: je to člověk, který dělá nějakou práci, nebo kus dat? Marcus je člověk. Vlastnit Bellu ale není práce; je to fakt o Belle a dřív nebo později se někdo zeptá: „Kdo je majitelem tohoto psa?“ Majitel tedy do modelu patří. Trenér, který Bellu naučil podat pac, je člověk, který dělá práci, a krabici možná nikdy potřebovat nebude, pokud se byznys nezačne ptát, kdo naučil který trik.

A všimněte si slova kandidátní. Je Plemeno opravdu samostatná krabice, nebo jen slovo napsané u psa? Tuto otázku si podržte; odpovíme na ni, až budeme normalizovat v modulu 4.

To je celá technika, na něčem malém. Teď si poslechněme skutečný byznys.

Podstatná jména vám dávají kandidátní entity

Poslechněme si Steve Trucking, rodinnou firmu, kterou budeme používat v celém kurzu. Doručuje velké zboží (ledničky, pračky, televize) z distribučních center velkých obchodních řetězců lidem domů a některé z nich i instaluje.

V prvním rozhovoru slyšíme:

• Maloobchodní partner (Retail Partner)
• Příjemce (Recipient)
• Distribuční centrum (Distribution Center)
• Manifest
• Doručení (Delivery)
• Trasa (Route)
• Posádka (Crew)
• Kamion (Truck)

To už je užitečné. Můžu začít kreslit krabice na tabuli.

Dejte tedy podstatná jména do obdélníků. Nic víc v tuto chvíli nejsou: krabice. Žádné čáry, žádné barvy, nic, co by říkalo Salesforce. Později v kurzu začnou tvary a barvy něco znamenat. Zatím je obdélník jen věc, o které byznys mluví.

Pak je začněte uspořádávat. Když každou krabici umisťujete, chcete myslet na dvě věci: jak spolu souvisejí a o jaký druh dat jde. Část jsou zákaznická data: firmy a lidé, se kterými pracujeme. Část jsou transakční data, jako objednávky a jejich položky: věci, které se dějí znovu a znovu. A část jsou referenční data, jako produkty nebo služby, které firma nabízí: věci, na kterých práce závisí.

Ve Steve Trucking jsou maloobchodní partner a příjemce zákaznická data. Manifest, doručení a trasa jsou transakce. Distribuční centrum, posádka a kamion jsou to, na čem práce závisí.

Kliknutím zvětšíte

Je tu ale jedno důležité slovo: kandidátní.

Podstatné jméno je vodítko. Není automaticky entitou a rozhodně není automaticky objektem Salesforce.

Když jsem na discovery sezení, zapisuji si každé podstatné jméno. U každého, které řeknou, si položím jednu otázku: je to člověk, který dělá nějakou práci, nebo kus dat? Manažer rozvoje obchodu je člověk, který dělá práci. To je uživatel, role, možná sada oprávnění. Objednávky, faktury, řádkové položky: to jsou kusy dat. Na obojím záleží, ale v návrhu skončí na velmi různých místech, a když je roztřídím brzy, nemusím kreslit krabici pro každou pracovní pozici z organizačního schématu.

Některá z těch podstatných jmen budou lidé. Ve Steve Trucking je to příjemce, který čeká na ledničku, lidé u maloobchodního partnera, kteří posílají manifest, a posádka: řidiči a pomocníci na kamionu. To jsou role a role se nemusí zdát jako data. Když ale lidé s daty pracují nebo s nimi souvisejí, musí být v datech reprezentováni i oni sami. Kdo to doručil? Kdo převzetí podepsal? Kdo poslal manifest? Mnoho rolí, někdy všechny, tak skončí v modelu také.

Poslouchejte, jak Steve Trucking mluví, a něčeho si všimnete. Nikdy neříkají jen „zákazník“. Existují dva druhy zákazníků. Maloobchodní partner je velký obchodní řetězec, pro který Steve Trucking doručuje: posílá manifest a platí za každé doručení. Příjemce je člověk, kterému se lednička doručuje. Příjemce ji koupil v obchodě a o Steve Trucking možná nikdy neslyšel.

Kdybych napsal jednu krabici jménem Zákazník, smíchal bych dvě úplně odlišné věci.

Možná je distribuční centrum dost důležité na to, aby mělo vlastní záznam, historii, vztahy a atributy.

Možná se ukáže, že jiné podstatné jméno není nic víc než atribut něčeho jiného.

Právě to se snažíme zjistit. Ještě nevytváříme objekty. Budujeme své porozumění byznysu.

Teď naslouchejte vztahům

Podstatná jména mi dávají místo, kde začít. Pak poslouchám, jak je byznys propojuje.

Maloobchodní partner provozuje distribuční centra.

Maloobchodní partner posílá manifest za každé DC a den doručení.

Manifest obsahuje seznam doručení.

Doručení jde k příjemci.

Trasa je denní jízda s asi deseti zastávkami.

Dvoučlenná posádka jezdí s kamionem.

Teď se něco děje. Už se nedívám na seznam podstatných jmen. Začínám vidět model.

Kliknutím zvětšíte

Tady se také začnou objevovat otázky.

Může mít maloobchodní partner víc než jedno distribuční centrum?

Je doručení totéž co zastávka?

Může jedna zastávka doručovat dvěma příjemcům?

Je posádka vždycky stejná dvojice lidí?

Zajímá nás, která posádka měla který kamion minulý měsíc, nebo jen to, s kterým kamionem jezdí dnes?

Všimněte si, co děláme. Zatím se neptáme na Salesforce. Klademe obchodní otázky. A odpovědi na ně nakonec budou řídit návrh v Salesforce.

Váš první model nemusí být dokonalý

Nečekám, že první krabice, které nakreslím, přežijí beze změny. Vlastně bych byl podezíravý, kdyby přežily.

Smyslem prvního modelu není mít pravdu. Smyslem je dát nám něco dost konkrétního na to, abychom zjistili, kde se mýlíme.

Dejte na tabuli doručení, trasu, posádku a kamion a lidé na ně mohou reagovat.

„Vlastně doručení není vždycky jedna položka. Může to být pračka, sušička a odvoz těch starých.“

Dobře. Povězte mi víc.

„Posádku nepřiřazujeme k doručení. Posádku přiřazujeme k trase.“

Skvělé. Co je na trase?

„A když jde o instalaci, posádka nemůže zastávku uzavřít, dokud nejsou hotové kontrolní seznam a fotky.“

Teď se dozvídáme něco důležitého.

Diagram proměnil vágní rozhovor v něco, co můžeme zpochybnit. To je jeden z důvodů, proč rád modeluji brzy. Nesnažím se ohromit místnost krásným diagramem. Snažím se rychleji učit.

Model je součástí rozhovoru.

Tohle je váš konceptuální model

To, co jsme začali stavět, má formální název: konceptuální datový model.

Na této úrovni mě zajímají důležité věci, na kterých byznysu záleží, a jak spolu souvisejí. Zatím se nestarám o standardní versus vlastní objekty, názvy API polí, lookup versus master-detail, povinná pole, indexy, automatizaci, Apex ani Flow. Na těch věcech záleží a dostaneme se k nim. Pokud o nich ale rozhodneme dřív, než pochopíme, co modelujeme, řešíme jako první špatný problém.

Konceptuální model by měl dávat smysl lidem v místnosti, kteří Salesforce neznají. To je užitečný test. Pokud musím vysvětlovat, co znamená Delivery__c, než provozní manažer dokáže můj diagram přečíst, přešel jsem do implementace příliš brzy.

Chci, aby se na model podívali a řekli:

„Ano, takhle náš byznys funguje.“

Nebo ještě lépe:

„Ne, takhle to nefunguje.“

Protože teď mám co opravit.

Stejná technika funguje, i když nikdo nemluví

Tohle nepoužívám jen při discovery s klientem. Funguje to i tehdy, když je „klientem“ dokument.

Když procházím dokument s požadavky, dělám v podstatě totéž. Jaké jsou důležité obchodní pojmy? Jaké vztahy se popisují? Co se opakuje? Co má vlastní životní cyklus, musí být samostatně identifikovatelné nebo potřebuje historii? Co se vytváří, mění, přiřazuje, převádí, plánuje nebo vyřazuje?

To jsou stejné věci, kterým naslouchám na té první schůzce. Na papíře tyto stopy promění odstavce požadavků v model, o kterém můžu uvažovat, a v lepší otázky pro další rozhovor.

Model není jen něco, co vytvoříte, až problém vyřešíte. Je to jeden z nástrojů, kterými problém řešíte.

Co tady rozhoduje architekt

Na konci tohoto prvního průchodu se snažím rozhodnout:

• Která podstatná jména představují smysluplné kandidátní entity.
• Která různá slova představují stejný obchodní pojem a které jedno slovo skrývá dva (jako „zákazník“).
• Které pojmy potřebují vlastní záznam a vlastní životní cyklus.
• Jak spolu hlavní pojmy souvisejí.
• Na jaké otázky musí byznys odpovědět, než je budu moct s jistotou namodelovat.

Implementaci v Salesforce zatím nerozhoduji. Nejdřív potřebujeme byznysu rozumět natolik, abychom ho dokázali nakreslit. A jakmile máme podstatná jména na tabuli, další věc, které chci porozumět, jsou čáry mezi nimi.

Nad rámec zkoušky: co mění AI. Dejte nástroji AI dokument s požadavky a během pár sekund najde podstatná jména, navrhne entity a načrtne vztahy. Použijte ho k urychlení discovery, ale porozumění mu nesvěřujte: nemůže vědět, že „zákazník“ ve Steve Trucking znamená dvě různé věci, pokud vám to byznys neřekne. Dejte jeho první model před lidi, kteří byznys řídí, a zeptejte se: „Opravdu takhle váš byznys funguje?“