Wsłuchaj się w rzeczowniki

🌐 Dostępne także w 28 językach

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

Obraz wygenerowany przez AI

Przetłumaczone przez AI. Jeszcze niesprawdzone przez społeczność. Czytaj po angielsku

Moduł 1 z 6 w rozdziale Modelowanie danych, które coś znaczą, rozdziale 2 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: przegląd rozdziału · Dalej: Narysuj relacje

Pytanie, na które odpowiada ten moduł: jak znaleźć zaczątki modelu danych w rozmowie z biznesem?

Jedna z rzeczy, które robię podczas pierwszej rozmowy z klientem, to wsłuchiwanie się w rzeczowniki.

Nie mówię o pierwszej sesji projektowej. Mówię o tej wstępnej rozmowie, w której wciąż próbuję zrozumieć biznes i to, co chce osiągnąć.

Oni mówią. Ja słucham.

I nasłuchuję słów takich jak:

Partner detaliczny. Odbiorca. Centrum dystrybucyjne. Manifest. Dostawa. Trasa. Ekipa. Ciężarówka.

Te rzeczowniki od razu przyciągają moją uwagę, bo gdzieś w tej rozmowie są zaczątki mojego modelu danych.

Nie czekam, aż uznam, że w pełni rozumiem problem. Zaczynam widzieć dane, jeszcze słuchając: słyszę rzeczowniki, zaczynam szkicować, jak się ze sobą wiążą, a ten szkic pomaga mi ułożyć następną rozmowę. Czasem pod koniec pierwszego spotkania z klientem mam już narysowany własny, prywatny model danych.

U mnie zaczyna się to od rzeczowników.

Zapomnij na chwilę o Salesforce

Tu chcę, żeby udało ci się powstrzymać odruch, który jest szczególnie silny u osób od dłuższego czasu pracujących jako administratorzy Salesforce.

Klient mówi klient, a ty myślisz:

Konto.

Mówi osoba, a ty myślisz:

Kontakt.

Mówi centrum dystrybucyjne, a ty już się zastanawiasz, czy potrzebny będzie obiekt niestandardowy.

Jeszcze tego nie rób.

Na tym etapie nie obchodzi mnie, czy klient w końcu stanie się kontem, kontem osoby, obiektem niestandardowym czy czymś jeszcze innym. Najpierw chcę zrozumieć biznes.

Na tym polega różnica między modelowaniem biznesu a konfigurowaniem Salesforce. Jeśli zacznę od obiektów Salesforce, już ograniczyłem swoje myślenie do jednej implementacji. Może skończę dokładnie tam, gdzie się spodziewałem, ale chcę tam dojść dlatego, że zaprowadził mnie tam biznes, a nie dlatego, że konto i kontakt to były pierwsze dwa obiekty, jakie znałem.

Na kilka minut zapomnij więc o Salesforce. Posłuchaj, jak swój świat opisują ludzie, którzy naprawdę prowadzą ten biznes.

Siad, zostań, modeluj

Zanim posłuchamy biznesu, posłuchajmy czegoś, co wszyscy już rozumieją. Kiedy uczę tego na żywo, zaczynam od psów.

Oto pies: Marcus jest właścicielem Belli. Wyhodowała ją hodowla Maple Ridge Kennels. To labrador i zna komendy Siad, Zostań i Daj łapę.

Wsłuchaj się w rzeczowniki: Marcus, Bella, Maple Ridge Kennels, labrador, Siad. To jednak nazwy, czyli konkretne rzeczy. Mnie interesuje rodzaj rzeczy, do którego należy każda nazwa. Bella to Pies. Marcus to Właściciel. Maple Ridge Kennels to Hodowca. Labrador to Rasa. Siad to Sztuczka. Pięć rzeczowników, pięć kandydujących prostokątów.

Click to enlarge

Potem pytanie, które zadaję każdemu rzeczownikowi: czy to osoba wykonująca pracę, czy fragment danych? Marcus to osoba. Ale bycie właścicielem Belli to nie praca; to fakt o Belli, a prędzej czy później ktoś zapyta: „Kto jest właścicielem tego psa?”. Więc Właściciel należy do modelu. Trener, który nauczył Bellę dawać łapę, to osoba wykonująca pracę i może nigdy nie potrzebować prostokąta, chyba że biznes zacznie pytać, kto nauczył której sztuczki.

I zwróć uwagę na słowo kandydujący. Czy Rasa to naprawdę osobny prostokąt, czy tylko słowo zapisane przy psie? Zapamiętaj to pytanie; odpowiemy na nie, kiedy będziemy normalizować w module 4.

To cała technika, na czymś małym. Teraz posłuchajmy prawdziwego biznesu.

Rzeczowniki dają ci encje kandydujące

Posłuchajmy Steve Trucking, rodzinnej firmy, której będziemy używać przez cały kurs. Dowozi duże rzeczy (lodówki, pralki, telewizory) z centrów dystrybucyjnych wielkich sieci handlowych do domów klientów i część z nich instaluje.

W pierwszej rozmowie słyszymy:

• Partner detaliczny (Retail Partner)
• Odbiorca (Recipient)
• Centrum dystrybucyjne (Distribution Center)
• Manifest (Manifest)
• Dostawa (Delivery)
• Trasa (Route)
• Ekipa (Crew)
• Ciężarówka (Truck)

To już się przydaje. Mogę zacząć rysować prostokąty na tablicy.

Umieść więc rzeczowniki w prostokątach. Na tym etapie tym właśnie są: prostokątami. Żadnych linii, żadnych kolorów, niczego, co mówi „Salesforce”. Później w kursie kształty i kolory zaczną coś znaczyć. Na razie prostokąt to po prostu rzecz, o której mówi biznes.

Potem zacznij je układać. Umieszczając każdy prostokąt, myśl o dwóch rzeczach: jak się ze sobą wiążą i jakim rodzajem danych są. Część to dane klientów: firmy i ludzie, z którymi pracujemy. Część to dane transakcyjne, jak zamówienia i pozycje zamówień: rzeczy, które dzieją się raz za razem. A część to dane referencyjne, jak produkty czy usługi, które oferuje firma: rzeczy, od których zależy praca.

W Steve Trucking partner detaliczny i odbiorca to dane klientów. Manifest, dostawa i trasa to transakcje. Centrum dystrybucyjne, ekipa i ciężarówka to to, od czego zależy praca.

Click to enlarge

Ale jest tu ważne słowo: kandydująca.

Rzeczownik to wskazówka. Nie jest automatycznie encją, a już na pewno nie jest automatycznie obiektem Salesforce.

Podczas sesji discovery zapisuję każdy rzeczownik. Przy każdym rzeczowniku zadaję sobie jedno pytanie: czy to osoba wykonująca pracę, czy to element danych? Kierownik ds. rozwoju biznesu to osoba wykonująca pracę. To użytkownik, rola, może zestaw uprawnień. Zamówienia, faktury, pozycje: to elementy danych. Jedno i drugie ma znaczenie, ale trafia w zupełnie różne miejsca projektu, a wczesne posortowanie ich oszczędza mi rysowania prostokąta dla każdego stanowiska ze schematu organizacyjnego.

Część tych rzeczowników będzie oznaczać ludzi. W Steve Trucking to odbiorca czekający na lodówkę, ludzie u partnera detalicznego, którzy wysyłają manifest, i ekipa: kierowcy i pomocnicy na ciężarówce. To role, a rola może nie wyglądać na dane. Ale kiedy ludzie działają na danych albo są z nimi powiązani, sami muszą być odwzorowani w danych. Kto to dostarczył? Kto pokwitował odbiór? Kto wysłał manifest? Dlatego wiele ról, czasem wszystkie, też trafia do modelu.

Posłuchaj, jak mówi Steve Trucking, a coś zauważysz. Nigdy nie mówią po prostu „klient”. Są dwa rodzaje klientów. Partner detaliczny to wielka sieć handlowa, dla której Steve Trucking dostarcza: wysyła manifest i płaci za każdą dostawę. Odbiorca to osoba, do której dostarczana jest lodówka. Odbiorca kupił ją w sklepie i mógł nigdy nie słyszeć o Steve Trucking.

Gdybym narysował jeden prostokąt o nazwie Klient, zmieszałbym dwie zupełnie różne rzeczy.

Może centrum dystrybucyjne jest na tyle ważne, że zasługuje na własny rekord, historię, relacje i atrybuty.

Może inny rzeczownik okaże się niczym więcej niż atrybutem czegoś innego.

To właśnie próbujemy odkryć. Jeszcze nie tworzymy obiektów. Budujemy nasze zrozumienie biznesu.

Teraz wsłuchaj się w relacje

Rzeczowniki dają mi punkt wyjścia. Potem słucham, jak biznes je ze sobą łączy.

Partner detaliczny prowadzi centra dystrybucyjne.

Partner detaliczny wysyła manifest dla każdego CD i dnia dostaw.

Manifest wymienia dostawy.

Dostawa trafia do odbiorcy.

Trasa to dzienny kurs z mniej więcej dziesięcioma przystankami (Stops).

Dwuosobowa ekipa obsługuje ciężarówkę.

Teraz coś się dzieje. Nie patrzę już na listę rzeczowników. Zaczynam widzieć model.

Click to enlarge

W tym miejscu zaczynają się też pojawiać pytania.

Czy partner detaliczny może mieć więcej niż jedno centrum dystrybucyjne?

Czy dostawa to to samo co przystanek?

Czy na jednym przystanku można dostarczyć do dwóch odbiorców?

Czy ekipa to zawsze te same dwie osoby?

Czy obchodzi nas, która ekipa miała którą ciężarówkę w zeszłym miesiącu, czy tylko to, którą jeździ dziś?

Zwróć uwagę, co robimy. Jeszcze nie zadajemy pytań o Salesforce. Zadajemy pytania biznesowe. A odpowiedzi na nie w końcu pokierują projektem w Salesforce.

Twój pierwszy model nie musi być idealny

Nie oczekuję, że pierwsze narysowane przeze mnie prostokąty przetrwają bez zmian. Właściwie byłbym podejrzliwy, gdyby przetrwały.

Pierwszy model nie ma mieć racji. Ma dać nam coś na tyle konkretnego, żeby odkryć, gdzie się mylimy.

Umieść na tablicy dostawę, trasę, ekipę i ciężarówkę, a ludzie mogą na nie zareagować.

„Właściwie dostawa to nie zawsze jedna rzecz. Może to być pralka, suszarka i wywiezienie starych”.

Dobrze. Opowiedzcie więcej.

„Nie przypisujemy ekipy do dostawy. Przypisujemy ekipę do trasy”.

Świetnie. Co jest na trasie?

„A jeśli jest instalacja, ekipa nie może zamknąć przystanku, dopóki nie skończy listy kontrolnej i zdjęć”.

Teraz dowiadujemy się czegoś ważnego.

Diagram zamienił mglistą rozmowę w coś, co możemy podważyć. To jeden z powodów, dla których lubię modelować wcześnie. Nie próbuję zrobić wrażenia na sali pięknym diagramem. Próbuję szybciej się uczyć.

Model jest częścią rozmowy.

To jest twój model konceptualny

To, co zaczęliśmy budować, ma formalną nazwę: konceptualny model danych.

Na tym poziomie interesują mnie ważne rzeczy, na których zależy biznesowi, i to, jak się ze sobą wiążą. Jeszcze nie martwię się obiektami standardowymi a niestandardowymi, nazwami API pól, lookup a master-detail, polami wymaganymi, indeksami, automatyzacją, Apex czy Flow. Te rzeczy mają znaczenie i do nich dojdziemy. Ale jeśli zdecydujemy o nich, zanim zrozumiemy, co modelujemy, najpierw rozwiązujemy zły problem.

Model konceptualny powinien mieć sens dla osób na sali, które nie znają Salesforce. To przydatny test. Jeśli muszę wyjaśnić, co znaczy Delivery__c, zanim kierownik operacyjny zdoła przeczytać mój diagram, za wcześnie przeszedłem do implementacji.

Chcę, żeby patrzyli na model i mówili:

„Tak, tak działa nasz biznes”.

Albo, jeszcze lepiej:

„Nie, to tak nie działa”.

Bo wtedy mam co poprawić.

Ta sama technika działa, gdy nikt nie mówi

Nie używam tego tylko w rozmowach discovery z klientem. Działa to też wtedy, gdy „klientem” jest dokument.

Kiedy pracuję nad dokumentem wymagań, robię mniej więcej to samo. Jakie są ważne pojęcia biznesowe? Jakie relacje są opisane? Co powtarza się wielokrotnie? Co ma własny cykl życia, musi być identyfikowane samodzielnie albo potrzebuje historii? Co jest tworzone, zmieniane, przypisywane, przenoszone, planowane albo wycofywane?

To te same rzeczy, na które nasłuchuję na pierwszym spotkaniu. Na papierze te wskazówki zamieniają akapity wymagań w model, o którym mogę rozumować, i w lepsze pytania na następną rozmowę.

Model to nie tylko coś, co powstaje po rozwiązaniu problemu. To jedno z narzędzi, którymi problem się rozwiązuje.

Co tu decyduje architekt

Pod koniec tego pierwszego przejścia próbuję zdecydować:

• Które rzeczowniki oznaczają sensowne encje kandydujące.
• Które różne słowa oznaczają to samo pojęcie biznesowe, a które jedno słowo kryje dwa (jak „klient”).
• Które pojęcia potrzebują własnego rekordu i cyklu życia.
• Jak główne pojęcia wiążą się ze sobą.
• Na jakie pytania biznes musi odpowiedzieć, zanim będę mógł je pewnie zamodelować.

Nie decyduję jeszcze o implementacji w Salesforce. Najpierw musimy zrozumieć biznes na tyle dobrze, żeby go narysować. A gdy rzeczowniki są już na tablicy, następne, co chcę zrozumieć, to linie między nimi.

Poza egzaminem: co zmienia AI. Daj narzędziu AI dokument wymagań, a w kilka sekund znajdzie rzeczowniki, zaproponuje encje i naszkicuje relacje. Używaj go, żeby przyspieszyć discovery, ale nie zlecaj mu zrozumienia: nie może wiedzieć, że „klient” w Steve Trucking oznacza dwie różne rzeczy, dopóki biznes ci tego nie powie. Postaw jego pierwszy model przed ludźmi, którzy prowadzą biznes, i zapytaj: „Czy wasz biznes naprawdę tak działa?”