編輯導語：利用類圖這一方式，産品經理可以更清晰地梳理設計思路，進而推動後續方案的疊代優化，同時結合類圖梳理，團隊内也能降低溝通成本。具體應該如何拆解？本篇文章裡，作者結合餐飲系統，對類圖拆解和梳理做了案例上的總結，一起來看一下。

學了UML的知識後，還要多看案例。下面我們就來拆解餐飲系統，該系統是餐廳用的點餐、預定和外賣等業務的系統，我會分成幾篇逐一拆解。

該系統大緻可分為：

1. 面向企業的：财務管理、物資管理、員工管理。
2. 面向用戶的：用戶管理、交易管理（含點餐、預定、排隊）、營銷管理。
3. 面向數據的，即通過數據幫助企業決策。

本次，我們梳理的是員工結構與工作職責。而你需要有《圖解産品》一書的知識背景。

一、梳理人員結構與工作職責

要設計餐廳系統，就要考慮清楚該餐廳的涉衆（利益相關者）有誰，以及涉衆中的參與人（使用系統的人）有誰，并梳理清楚參與人的工作職責。如何梳理？

這些内容在《圖解産品》一書中都有。大緻方法是你需要用三個角度找全涉衆，再從其中明确參與者，這些參與者就是用系統的人，這之後再通過四個調研方法找全工作職責。

下圖就是我用該書方法，梳理出來的内容：

該圖就是一個類圖，表達了服務員、廚師、店經理人等之間的關系，以及他們的工作職責。如表達了服務員、廚師都是員工，并且都有姓名、地址等内容，但各自的工作又不一樣，如廚師負責做菜，服務員負責送菜。

二、為什麼這麼梳理？

1. 指導後台的原型

後台要創建員工，那麼每個員工既要有一些公用字段，更有一些特有字段。如每個員工都有年齡、性别等，但是廚師長還要有健康證、廚師等級等内容。通過該類圖，就可明确後台新建員工時要填寫的字段。

2. 明确要實現的業務

産品經理隻有知道了每個員工的工作職責後，才能再說如何設計業務。通過這個類圖，就可知道各自工作，從而再将部分工作在線上完成。

3. 方便研發的實現

類圖是嚴謹的、無歧義的。研發也非常清楚什麼是類，以及這些符号的意思，這樣就便于研發構建數據庫。其實這個圖即使你不畫，研發也會從你的原型圖中抽象出來，但這樣做就增加了溝通成本。

三、是否都要畫？如何梳理？

1. 是否都要畫？畫到多詳細？

這要基于目的、受衆、階段、業務複雜度等方面考慮。而本圖是一個中型系統常見的内容。

該圖和實戰中不同的是，梳理的角色略少，沒有老闆、财務等角色；列出的員工信息也略少，沒有列出每個員工的特殊字段。

2. 如何梳理？

梳理清楚類（廚師、服務員等）是産品經理功底的表現，這些類大緻等同于職位名稱，但并不總是如此。更準确地說應梳理工作職能塊，而不是職位名稱。

這其實是領域建模的範疇，而設計複雜中台和SaaS的核心知識就是領域建模，但限于篇幅這裡不做展開。

四、符号的含義是什麼？

在《圖解産品》一書中用了30多頁講了類的知識（信息結構一章），你要看書才能理解為什麼叫類，以及符号的含義和梳理類的方法。本文僅就書中未講到之處做補充。

1. 繼承關系

繼承關系是指一個類（服務員）會繼承另一個類（員工）的屬性和行為。表達方式如下圖。

在該關系中，服務員也被稱為子類，員工被稱為父類（超類）。子類擁有父類的所有屬性與行為，但子類卻有父類沒有的特殊内容。

如服務員繼承了員工這個類的“姓名”等内容，但服務員還有上菜這個工作（稱其為操作或行為），但一般員工卻沒有該工作。

通過繼承關系的梳理，可明确後台每類員工的公共和特殊屬性有什麼。

繼承的另一個說法是泛化，也就是說服務員泛泛而談就是一個員工。

2. 類的操作

類的操作就是類自己能做的事情，或者是你或他人能對類做的事情。

在本案例中，服務員能端茶送水，但卻不能做菜，這就是在表明服務員這個類能做什麼，不能做什麼。再如，一個洗衣機你可以對他加衣服、加洗衣粉，打開開關和關閉開關等操作。

操作的畫法很簡單，就是在類的所有屬性（姓名等就是屬性）下面再加一條橫線，再寫上具體的操作，如寫上“上菜”等。

但要注意，按照UML的标準應寫作“上菜”而不是“上菜”。括号内可加上該操作的默認值和類型（如可默認上XX菜），如不想加任何值也要用“”來表示。

但為了便于産品經理理解，本文沒有加括号。而研發則可能在括号裡再加内容，産品經理通常不需要做。

五、如何做好翻譯官

産品經理是個翻譯官，要見人說人話，見鬼說鬼話。

上面話就是說給研發聽的。當你這樣說了以後，研發容易理解，也沒有歧義，并可輕松轉化成代碼。

也許研發還會誇你一句“小子，可以啊，類圖都懂”。但這樣的内容如說給業務人員聽，就可能被罵，說你“不畫人圖，不說人話”。

那你就要用一些不嚴謹的說法，從而保護好自己。你可以說員工“包含”服務員、店經理、廚師等，他們都有性别，姓名等信息。而他們各自的工作是XXX，其中餐廳服務員可以要求酒保遞送菜單等。

其實這個說法還是上圖内容，隻是換了個說法。而你還可将上圖用腦圖表達出來，這樣畫的又快，又便于業務人員理解。

但注意該說法中的“包含”一詞并不嚴謹，“包含”在研發體系中有特定的含義。

好了，以上這就是用類圖表達員工信息與工作。而一個類圖其實是就是一種梳理業務的方法，也是一種無歧義的表達方法，這可幫助你理順思路。而産品經理也應做好翻譯官，這樣才能擁有更強的話語權，并獲得對方的認同。

希望本文能幫到你，我們下期見！

作者：擎蒼，《“圖解”産品：産品經理業務設計與UML建模》作者，公衆号：圖解産品設計

本文由 @圖解産品設計 原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部