在學生時期，我第一次聽到「實體關係圖」這個名詞，是在上資料庫的課。
老師在黑板上畫了一堆長方形、菱形、線條，寫上「學生」「老師」「課程」，再用一條線連起來，說這個叫 ER-Model，可以幫助我們規劃資料表。
那時候的我，老實說只想趕快考試及格。
出社會之後，實際在專案裡做事，很少真的有人把「實體關係圖」拿出來用。
更多的狀況是這樣：
開完需求會，RD 回座位，直接開資料庫。
「這裡應該要一個訂單表。」
「這邊加一個優惠券表。」
「這個狀態不好放，乾脆再開一張表。」
欄位就這樣一個一個長出來，
表就這樣一張一張疊上去。
等到系統做了一段時間之後，你會發現一個熟悉的畫面。
查資料時，要 join 五六張表，
每個欄位名稱都很像，
改需求時，誰也說不清楚這個欄位當初為什麼這樣設計。
那種感覺很像走進一片很茂密的森林，
每棵樹都長得很用力，
卻沒有人知道自己身在第幾座山。
你只看得到一棵棵樹，
看不到整片林。
很多系統會變成這樣，
不只是因為 RD 忙，
更是因為一開始在設計時，
沒有先停下來問一個最基本的問題：
這個系統裡，到底有哪些「實體」存在。
◆ 「實體」這兩個字，為什麼總是聽起來很抽象
如果你是 PM，第一次聽到「實體」這個詞，很可能會有點不知所措。
明明只是想做好一個系統，
突然有人跟你說要先想實體是什麼，
你腦中浮現的可能是：
「是指資料表嗎？」
「還是指使用者？」
「還是指畫面上的那些東西？」
當初我在學時也是這樣。
老師講得很認真，我聽得很用力，
可是一離開教室，那些方框和線就全部散掉。
直到進了職場，
在一個一個專案裡被打過之後，
我才慢慢抓到一個比較好懂的說法。
可以先這樣理解「實體」：
在這個系統裡，
有沒有一些是「看得到、說得出名字、可以被點名」的重要東西。
比方說：
- 會登入這個系統的人
- 匯入進來的文件
- 系統產出的報表
- 每一張訂單
- 每一筆申請
- 每一個案件
這些，不是單純的「資料」，
而是這個系統裡「某種角色」或「某種東西」。
你可以指著它說：「這是一個什麼」。
它不是一個欄位的一部分，
它本身就是一個完整的東西。
在 ER-Model 裡，
這些就是「實體」。
◆ 為什麼先找到實體，才談得上系統思考
對 PM 來說，「實體」這件事最直接的價值在這裡。
當你把「這個系統裡有哪些實體」列清楚時，其實等於是在做幾件事。
第一，你在整理「系統的角色」。
不只是 User 而已，
而是：
- 誰會進來操作
- 誰會提供東西給系統
- 誰會從系統拿走東西
你可以粗略地把它們拆成三種：
- 使用者（User）
- 輸入的東西（Input）
- 輸出的東西（Output）
這三種角色的組合，
就是你之後在設計資料流程時的基礎。
第二，你在確認「系統到底要管到哪裡」。
有一些東西，看起來跟系統有關，
但其實只存在人腦裡，
或者只存在外部工具裡。
如果你硬要把它拉進來當實體，
你就會把系統的邊界畫得很混亂。
反過來說，如果有一些明明跟系統高度相關的東西，
你卻從來沒有把它當成實體看待，
那最後就會變成：
有些流程只能靠大家「心照不宣」地處理，
資料也只能靠人工對來對去。
簡單講一句，如果連「有哪些實體」都沒想清楚，
你畫流程、開資料表、設計 API，
都只是在局部救火，
沒有一次把整體看清楚。
◆ 「實體跟系統有沒有關係」這件事，值得先講清楚
找出實體，只是第一步。
下一步比較關鍵的，是問自己：
這個實體和系統之間，
到底有什麼樣的關聯。
一個簡單的檢查方式是這樣。
問自己：
這個實體，會不會和系統「互動」。
比方說：
- 系統會不會存它
- 會不會修改它
- 會不會根據它做判斷
- 會不會用它來產出別的東西
如果都不會，
那代表這個東西，
其實不在系統的管理範圍裡。
只是大家聊天時順口提到，
或是存在某個外部流程裡。
那它就不應該出現在 ER-Model 裡。
但是，如果一個東西
會被建立、
會被查詢、
會被修改、
會被刪除、
還會牽動別的東西，
那它很有可能就是一個「關鍵實體」。
系統在做的事情，
往往就是在幫這些實體「執行某種功能」。
例如：
- 幫訂單做審核
- 幫申請單做簽核
- 幫文件做版本管理
- 幫會員帳號做權限調整
如果你沒有先釐清實體和系統之間的關係，
你在後面設計功能時，
就會常常出現這種情況：
功能做了一堆，
每一頁看起來都有用途，
可是整體看起來很鬆散，
不知道自己到底在維護哪些核心東西。
◆ 把 ER-Model 想成「系統版的人物關係圖」
如果你喜歡看影集或日劇，
應該對「人物關係圖」不陌生。
一部劇裡，角色很多，
家人、同事、朋友、前任、仇人，
每個人都有關係。
你要讓一個沒有看過這部劇的人，
在短時間內抓到這些關係，
最直覺的做法就是畫一張人物關係圖。
誰跟誰是同事，
誰是誰的上司，
誰暗戀誰，
誰和誰是對立。
看完之後，
就算你還沒看劇，
大概也能想像這部作品在演什麼。
ER-Model，其實就是系統世界的人物關係圖。
只是這裡的「人物」，
不一定是人，
而是實體。
例如在一個電商系統裡，你可能會有：
- 會員
- 商品
- 訂單
- 優惠券
- 付款紀錄
- 出貨單
這每一個都是實體，
而實體之間會有各種關係：
- 會員可以有很多張訂單
- 一張訂單可以包含多個商品
- 一張訂單可以對應一次或多次付款紀錄
- 一個優惠券可以被很多會員使用，
但一張訂單可能只能用一張
當你把這些實體拉出來，
再把關係標上去，
你手上拿到的，就不只是資料庫設計，
而是這個系統的「世界觀」。
◆ 對團隊來說，一張好的實體關係圖，勝過一百頁規格書
很多 PM 覺得自己的規格書沒有人想看，
其實不完全是工程師不願意看文件，
更多時候是因為：
他們沒有一張「可以先把全貌看完」的東西。
直接被丟進一份一百頁的規格書裡，
裡面充滿各種畫面描述、欄位說明、流程步驟，
RD 看得很辛苦，
也很難在短時間內理解
「這個系統真正重要的東西是什麼」。
如果在那份規格之前，
你先放了一張實體關係圖，
效果會很不一樣。
工程師可以先從這張圖上，
理解這個系統到底在管理哪些實體，
關係大概怎麼連，
哪些地方看起來比較複雜，
哪些地方是關鍵節點。
設計師也可以從這張圖上，
大概知道介面會服務哪些實體，
哪些是主要操作對象，
哪些只是附屬資訊。
連業務或營運進來看，
也比較容易對號入座：
自己日常在談的那些「案件」「訂單」「活動」，
在系統裡分別對映到哪幾個實體。
這張圖不會取代所有文件，
但會讓後面的溝通，
有一個共同的起點。
◆ 如果你是 PM，從下一個專案開始，可以這樣練習
如果你覺得 ER-Model 聽起來還是有點抽象，
可以試著在下一個專案裡，
做一個很簡單的練習。
在你開始畫流程圖之前，
先拿一張紙，問自己幾個問題：
一、這個系統裡，最重要的幾個「東西」是什麼
例如：案件、申請、工單、訂單、報表、帳號、合約
二、這些東西，哪些會被系統記錄、修改、查詢
如果只是短暫存在畫面上，
沒有任何後續的操作，
它可能不是核心實體
三、這些實體之間，有沒有明顯的關係
一對多、多對多、誰屬於誰、誰底下可以生出什麼
四、如果這些實體畫成方框，
要用幾條線才能把它們合理連起來
你不需要一開始就畫得像教科書那麼標準，
也不一定要用到很嚴謹的符號。
一開始只要做到一件事就好：
在你開始談流程、談畫面、談 API 之前，
先讓自己看清楚，
「這個系統到底是由哪些實體組成的」。
當你開始習慣這樣做，
你會發現一件有趣的事。
也許手上那張的實體關係圖還很粗糙，
原本那些很容易迷路的討論，
會慢慢有一個可以對焦的中心。
RD看待你的眼神也會越來越不一樣，
不再把你當成只會畫框線圖的美工，
而是把你當成一個懂系統架構的夥伴。
你不會再只是在每棵樹旁邊打轉，
而是慢慢看出來，
這整片森林，
到底在長成什麼形狀。
而那，才是系統思考的第一課。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
留言