聆聽名詞
另有 28 種語言版本
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)
第 1 個模組，共 6 個，屬於 Data Architect 課程第 2 章為含義建模資料。每個模組都可以單獨閱讀。 上一篇：本章概覽 · 下一篇：畫出關係
**本模組回答的問題：**如何在一次業務對話中找到資料模型的雛形？
和客戶第一次通話時，我會做的一件事就是聆聽名詞。
我說的不是第一次設計會議，而是最初的那次對話，那時我還在努力理解這個業務以及他們想要達成什麼。
他們在說，我在聽。
我在留意這樣的詞：
零售合作夥伴。收貨人。配送中心。裝貨清單。配送。路線。配送小組。卡車。
這些名詞會立刻引起我的注意，因為在這段對話的某處，藏著我的資料模型的雛形。
我不會等到自認為完全理解了問題才開始。我在聆聽的同時就開始看到資料：我聽到名詞，開始勾勒它們之間的關係，而這張草圖又幫我構思下一次對話。有時，和客戶的第一次會議結束時，我已經畫好了一份只屬於自己的資料模型。
對我來說，這一切從名詞開始。
暫時忘掉 Salesforce
Section titled “暫時忘掉 Salesforce ”在這裡，我希望你抵制一種本能，如果你做 Salesforce 管理員已經有一段時間，這種本能會特別強烈。
客戶說客戶，你想到的是：
客戶（Account）。
他們說人，你想到的是：
連絡人（Contact）。
他們說配送中心，你已經在琢磨是否需要一個自訂物件了。
先別這樣做。
此時此刻，我不在乎一個客戶最終會成為客戶（Account）、個人帳戶、自訂物件還是別的什麼。首先，我想理解業務。
這就是為業務建模和配置 Salesforce 的區別。如果我從 Salesforce 物件開始，我的思路就已經被限制在一種實現上了。我也許最後會落到預想的地方，但我希望是業務把我帶到那裡，而不是因為客戶和連絡人恰好是我最先認識的兩個物件。
所以，在幾分鐘內，忘掉 Salesforce。去聽真正經營這個業務的人如何描述他們的世界。
坐下、別動、建模
Section titled “坐下、別動、建模 ”在聆聽一個業務之前，我們先來聽聽大家都已經懂的東西。我在現場授課時，會從狗講起。
這是一隻狗：Marcus 是 Bella 的主人。Bella 由 Maple Ridge Kennels 繁育。她是一隻拉布拉多，會坐下、別動和握手。
聆聽名詞：Marcus、Bella、Maple Ridge Kennels、拉布拉多、坐下。不過這些都是名字，是具體的事物。我想要的是每個名字所屬的那一類事物。Bella 是一隻狗（Dog）。Marcus 是主人（Owner）。Maple Ridge Kennels 是繁育者（Breeder）。拉布拉多是一個品種（Breed）。坐下是一項技能（Trick）。五個名詞，五個候選方框。
然後，我對每個名詞都會問：**它是一個在做某項工作的人，還是一份資料？**Marcus 是一個人。但擁有 Bella 並不是一項工作；它是關於 Bella 的一個事實，而且遲早會有人問：「這隻狗的主人是誰？」所以主人屬於模型。教會 Bella 握手的訓練師是一個在做某項工作的人，可能永遠不需要一個方框，除非業務開始問是誰教會了哪項技能。
再注意候選這個詞。品種真的是一個獨立的方框，還是隻是寫在狗身上的一個詞？先記住這個問題；我們會在模組 4做規範化時回答它。
這就是整個技巧，用在一個小東西上。現在我們來聆聽一個真實的業務。
名詞給你候選實體
Section titled “名詞給你候選實體 ”我們來聽聽 Steve Trucking，這家家族企業我們會在整門課中使用。它把大件商品（冰箱、洗衣機、電視）從大型零售商的配送中心送到人們家裡，其中一部分還負責安裝。
在第一次對話中，我們聽到：
- 零售合作夥伴（Retail Partner）
- 收貨人（Recipient）
- 配送中心（Distribution Center）
- 裝貨清單（Manifest）
- 配送（Delivery）
- 路線（Route）
- 配送小組（Crew）
- 卡車（Truck）
這已經很有用了。我可以開始在白板上畫方框了。
所以把名詞放進矩形裡。此時它們就只是這樣：方框。沒有連線，沒有顏色，沒有任何表示 Salesforce 的東西。課程後面，形狀和顏色會開始有含義。現在，一個矩形只是業務談論的一樣東西。
然後開始給它們定位。放置每個方框時，你要想兩件事：它們彼此如何關聯，以及它們是哪類資料。有些是客戶資料：我們打交道的企業和人。有些是交易資料，比如訂單和訂單項目：一再發生的事情。還有些是參考資料，比如一個企業提供的產品或服務：工作所依賴的東西。
在 Steve Trucking，零售合作夥伴和收貨人是客戶資料。裝貨清單、配送和路線是交易。配送中心、配送小組和卡車是工作所依賴的東西。
但這裡有一個重要的詞：候選。
名詞是線索。它不會自動成為一個實體，更不會自動成為一個 Salesforce 物件。
在需求調研會上，我會把每個名詞都記下來。他們說出的每個名詞，我都會問自己一個問題：**這是一個在做某項工作的人，還是一份資料？**業務拓展經理是一個在做某項工作的人。那是一個使用者、一個角色，也許是一個權限集。訂單、發票、明細項目：這些是資料。兩者都重要，但它們在設計中會落到截然不同的地方，儘早把它們分開，可以讓我免於給組織架構圖上的每個職位都畫一個方框。
那麼，這些名詞中有一些會是人。在 Steve Trucking，那就是等著冰箱的收貨人、零售合作夥伴那邊傳送裝貨清單的人，以及配送小組：卡車上的司機和助手。這些是角色，而角色看起來也許不像資料。但當人對資料採取行動，或者與資料相關時，他們本身就需要在資料中得到體現。這是誰送的？誰簽收的？誰發的裝貨清單？所以很多角色，有時是全部角色，最終也會進入模型。
聽聽 Steve Trucking 怎麼說話，你會注意到一件事。他們從不只說「客戶」。客戶有兩種。零售合作夥伴是 Steve Trucking 為之配送的大型零售商：它傳送裝貨清單，並按每次配送付費。收貨人是冰箱送達的那個人。收貨人是從商店買的冰箱，可能從沒聽說過 Steve Trucking。
如果我只畫了一個叫「客戶」的方框，我就把兩樣完全不同的東西混在一起了。
也許配送中心足夠重要，需要有自己的記錄、歷史、關係和屬性。
也許另一個名詞最後只不過是別的東西的一個屬性。
這正是我們要去發現的。我們還沒有在建立物件，我們在建立對業務的理解。
現在聆聽關係
Section titled “現在聆聽關係 ”名詞給了我一個起點。然後我去聽業務如何把它們聯絡起來。
一個零售合作夥伴運營著若干配送中心。
一個零售合作夥伴為每個配送中心的每個配送日傳送一份裝貨清單。
一份裝貨清單列出若干配送。
一次配送送達一位收貨人。
一條路線是一天的行程，包含大約十個停靠點。
一個兩人配送小組駕駛一輛卡車。
現在，有些東西正在發生。我看到的不再是一串名詞，而是開始看到一個模型。
問題也在這裡開始出現。
一個零售合作夥伴可以有多個配送中心嗎？
一次配送和一個停靠點是同一回事嗎？
一個停靠點可以給兩位收貨人送貨嗎？
一個配送小組總是同樣的兩個人嗎？
我們在意上個月哪個配送小組開的是哪輛卡車，還是隻在意他們今天開的是哪輛？
注意我們在做什麼。我們還沒有在問 Salesforce 的問題，我們在問業務問題。而這些答案最終會驅動 Salesforce 的設計。
你的第一個模型不必完美
Section titled “你的第一個模型不必完美 ”我不指望自己最先畫的方框能原封不動地保留下來。事實上，如果它們真的原封不動，我反而會起疑。
第一個模型的意義不在於正確，而在於給我們一個足夠具體的東西，讓我們發現自己哪裡錯了。
把配送、路線、配送小組和卡車放到白板上，大家就可以對它們作出反應。
「其實，一次配送不總是一件商品。它可能是一臺洗衣機、一臺烘乾機，外加把舊的拉走。」
很好。再多說一點。
「我們不是把配送小組分配給一次配送，而是把配送小組分配給一條路線。」
太好了。路線上有什麼？
「而且如果有安裝，配送小組要等檢查清單和照片都完成後才能關閉這個停靠點。」
現在我們學到了重要的東西。
一張圖把一次模糊的對話變成了可以質疑的東西。這正是我喜歡儘早建模的原因之一。我不是要用一張漂亮的圖讓滿屋子的人刮目相看，而是要學得更快。
模型是對話的一部分。
這就是你的概念模型
Section titled “這就是你的概念模型 ”我們開始構建的東西有一個正式的名字：概念資料模型。
在這個層次上，我感興趣的是業務在意的重要事物，以及它們之間的關係。我還不擔心標準物件和自訂物件、欄位 API 名稱、查閱關係和主要-詳細資料關係、必填欄位、索引、自動化、Apex 或 Flow。這些都很重要，我們會講到。但如果在理解我們要建模的東西之前就決定它們，我們就是先去解決了錯誤的問題。
概念模型應該讓會議室裡不懂 Salesforce 的人也看得明白。這是一個有用的檢驗。如果在運營經理能看懂我的圖之前，我得先解釋 Delivery__c 是什麼意思，那我就過早地進入實現了。
我希望他們看著模型說：
「對，我們的業務就是這樣運作的。」
或者，更好的是：
「不對，不是這樣運作的。」
因為這樣我就有東西可以修正了。
沒人說話時，同樣的技巧也管用
Section titled “沒人說話時，同樣的技巧也管用 ”這不只是我在客戶需求調研中使用的技巧。當「客戶」是一份文件時，它同樣管用。
當我研讀一份需求文件時，我做的事情也大致相同。重要的業務概念是什麼？描述了哪些關係？什麼反覆出現？什麼有自己的生命週期、需要被單獨識別，或者需要歷史記錄？什麼在被建立、修改、分配、轉移、排期或退役？
這些和我在第一次會議上留意的東西是一樣的。在紙面上，這些線索把一段段需求變成一個我可以推理的模型，也變成下一次對話中更好的問題。
模型不只是你解決問題之後產出的東西。它是你用來解決問題的工具之一。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”第一輪結束時，我要決定的是：
- 哪些名詞代表有意義的候選實體。
- 哪些不同的詞代表同一個業務概念，又有哪一個詞背後藏著兩個概念（比如「客戶」）。
- 哪些概念需要有自己的記錄和生命週期。
- 主要概念之間如何相互關聯。
- 在我能有把握地為它們建模之前，業務方需要回答哪些問題。
我現在還不決定 Salesforce 的實現。首先，我們需要把業務理解到足以把它畫出來的程度。而一旦名詞都上了白板，我接下來想理解的就是它們之間的連線。
考試之外：AI 改變了什麼。把一份需求文件交給 AI 工具，它會在幾秒內找出名詞、提出實體、勾勒關係。用它來加速需求調研，但不要把理解外包出去：除非業務方告訴你，它無法知道「客戶」在 Steve Trucking 意味著兩種不同的東西。把它給出的第一個模型擺到經營這個業務的人面前，問一問：「你們的業務真的是這樣運作的嗎？」