在第一篇指南中，我們介紹了產品需求文檔的核心思路。這篇文章，我們來看看其整體設計部分，需要關注那些問題。

在《產品需求文檔完整指南（一）：核心思路》介紹了整體設計的目的：

• 讓文檔閱讀者有整體的概念，能夠讓他站在更加宏觀的視角理解方案。
• 為后續理解具體的功能用例提供鋪墊。

本篇將主要講述整體設計的寫作思路和技巧，技巧部分會偏重于介紹圖形的作用，但由于篇幅所限不會詳細闡述畫圖的技巧，若讀者認為某些部分需要詳細，我會考慮出單獨的文章幫助大家建立畫圖技巧。

什么時候應該寫整體設計？

雖然不是所有的需求都必須要寫整體設計，但我仍建議新手同學在每個需求都嘗試著寫，同時如果你的需求只要滿足了以下其中一個條件，我會強烈建議一定要寫。

• 涉及多個業務角色
• 橫跨多個系統領域
• 涉及到了新的單據流

一、方案涉及到多個用戶角色

1.1 條件

方案涉及到多個使用角色：例如一個流程中涉及了用戶A和用戶B

一個角色（從權限管理角度是代表某一類具有相同職能的統稱）能夠被涉及到某個功能/流程，說明這個角色在流程中需要進行操作/決策，因此在跨角色的項目中，需要讓不同角色明確自己在功能中的位置，前后的流程，以及自己到底要在這個流程中做什么，同時也讓產研側明確業務場景。

1.2 推薦的表達方式

泳道流程圖：一種展示業務流程或工作流程的圖表，表示不同的業務部門或參與者（不同系統等），以及它們之間的交互和流程。會涉及到縱向和橫向兩個維度，兩個維度分別表示的是角色和流程階段，至于是縱向表示角色還是橫向表示角色依據個人喜好即可，與時序圖相比，強調角色執行的動作/邏輯判斷，弱化時間順序/系統間交互。

1.3 泳道圖實例

申請報銷流程

二、橫跨多個系統/領域

2.1 條件

• 單個系統的多個模塊（例如訂單履約系統中訂單、庫存、商品等）
• 多個系統（例如訂單履約系統和倉庫管理系統）

2.2 推薦的表達方式

無論是什么樣的表達方式，盡量使用圖+文字說明的方式，讓閱讀者更容易理解。

2.2.1 實體關系圖

表明不同領域之間的關系，是1:1還是1：N還是N：1，能清晰畫出模塊間關系需要一定的垂直業務沉淀和領域抽象能力。

（產品畫到示例這個程度即可，更詳細可以了解ERD圖）

垂直業務沉淀：這屬于知識層面的經驗能力，只要去學就能學得到。例如我們要打造賬號體系中的母子賬號，母賬號有超級管理權限，子賬號可以被母賬號分配權限，一個母賬號可以關聯多個子賬號。那么母賬號和子賬號的關系就是1:N。同時還要考慮，1個子賬號是否能對應多個母賬號，業務層面有沒有這樣的需求，如果有就是N:N。

領域抽象能力：抽象能力不屬于知識，是一種技能，要靠悟性和大量訓練。最核心的是要有給領域下定義的能力。例如我們在做會員管理的時候，需要拆分賬號和商家兩個細分領域，就要給賬號和商家下定義。

• 定義賬號：賬號是主要管授權登錄用的，能不能被登錄驗證通過，就是賬號領域的事情；包括如果想做第三方登錄（如微信登錄），這個只和賬號體系打通就可以，跟商家領域就沒有關系。
• 定義商家：商家則關系到很多業務能力，例如結算方式是先款后貨，還是賬期。

與此同時，賬號和商家又要有綁定關系，商家和賬號（母子賬號）的關系是1：N。

再舉一個例子，說明一下抽象定義的重要性：我們先看四個詞，黑馬、白馬、河馬、盒馬，針對這個四個詞我們應該怎么分類呢？

若定義一個類為：名字中帶馬的詞，那他們都可以歸為一類；若定義一個類為：按動物科屬劃分，白馬黑馬屬于馬科，河馬屬于河馬科，盒馬是超市不是動物。

不同的關系在產品設計上意味著什么?

• 領域A與領域B的關系為1:1，這是關系中最簡單的，無論從A到B還是從B到A都能找到唯一值。
• 領域A與領域B的關系為1:N，從領域A觸發的時候要有決策的邏輯找到領域B中的某個值。
• 領域A與領域B的關系為N:1，從領域A觸發任一值都能找到唯一，反之則不是。
• 領域A與領域B的關系為N:N，不管從A到B還是從B到A都需要有決策的邏輯，這是關系中最復雜的，若能避免一定要盡量避免，避免不了一定要做好決策邏輯。

梳理清楚關系為什么那么重要？

• 能加強/外顯對業務的理解： 領域的關系圖能確保軟件系統能夠準確地反映業務邏輯，當你能夠精準的畫出領域關系說明這個整體是真的搞懂了，基本上這個關系上在了解清楚業務需求后瞬間形成的，如果你需要冥思苦想，說明功夫還不到家。
• 系統的可維護性： 更容易維護和更新，因為變更可以更精準地在領域模型中進行反映，能夠有效的避免不同系統和模塊間的撕逼，幫助劃清產品邊界。
• 模塊化和擴展性： 不同領域之間清晰的邊界和關系使得系統更容易進行模塊化設計，同時也更容易擴展。這是高階產品經理的必備能力，當你重構過幾個系統以后才知道模塊化和拓展性到底有多重要。
• 有助于團隊協作： 幫助不同團隊成員更好地理解系統的整體結構和各個部分之間的協作方式。如果你是系統負責人或某個項目的主產品，這個圖能夠很好的幫助各個領域的產品理解自己的邏輯，同時也能有效的幫助研發、測試無歧義的理解需求。

2.2.2 時序圖

時序圖：描述不同領域/對象之間的交互與通信。

• 誰在什么時候請求了誰的接口，返回是什么？
• 一個動作中包含了哪些業務層面的不可缺少的服務調用，否則就從頭開始？
• 是同步返回還是異步返回等？

主體可以是不同系統，可以是同一個系統的不同模塊，也可以是同一個系統的前端、后端（針對前后端分離的系統）。

大多數情況下時序圖是研發側在做技術設計時才會用到的，產品所畫的時序圖其實是沒有辦法真實體現技術的實現細節，但我認為他有其他圖像不可比擬作用：與泳道流程圖相比弱化了邏輯判斷關系，但是強調了時間順序，尤其在多個接口調用的先后以及表達同步異步關系上。

在復雜的B端系統中，產品經理一定要清楚以下情況，這些情況可能會限制功能設計。

• 不同接口的作用
• 大流程上接口調用的順序
• 同步/異步的接口消息響應

舉一個物流行業對接第三方物流服務商時經常碰到的場景：我們系統給第三方物流下單（可以理解為申請運單號）時，第三方物流系統同步返回的只有接口響應的成功/失敗，這個成功/失敗結果只代表了對方接收到了你的信息，只是通過了接口層面的一些基礎校驗邏輯，實際的能否真正的通過校驗，拿到實際的運單號還未可知。

為什么會這樣？第三方的物流系統可能是因為內部系統過于復雜不能同步返回，也可以他們也依賴了別人的系統。

因此第三方系統會在一段時間之后通過Webhook等方式回調給我方，告訴我們實際的結果。

• 成功：返回運單號
• 失?。悍祷貓箦e信息

這樣一個比較簡單的系統交互，用時序圖+文字表示就再好不過：

三、方案涉及到了狀態機

3.1 條件

當一個方案需要新增/修改狀態機，一般來講改動都較大。

以我在電商供應鏈的工作經歷中，狀態機一般是和單據流同時出現的，之所以有單據流是因為要持續一段時間追蹤某一件事，這件事會不停的變更狀態來反映當前的事實。例如銷售訂單會記錄「新建」、「待支付」、「已支付」、「待發貨」、「已發貨」、「取消」等狀態。

當然狀態機其實也廣泛用于各種領域，軟硬件結合的比如自動零食售賣機，純軟件的比如網路游戲中。

3.2 推薦的表達方式

我們常用的狀態機叫做有限狀態機。

有限狀態機（Finite State Machine，簡稱FSM）是一種數學模型和計算機科學中的概念，用于描述系統的行為。它由一組狀態、一組轉移規則和一個初始狀態組成。有限狀態機可以處于這些狀態之一，并根據輸入執行狀態轉移。

狀態機描述的是活動中狀態的變化，突出的是「動作」引發「狀態」變更，這對產品經理能力有3個要求：

• 關于動作(action)：要明確知道誰在什么時候觸發的動作是什么
• 關于狀態(status)：要有明確的預期動作后的狀態結果是什么
• 關于整體：一個單據流的狀態掌握絕不僅僅是只針對自己修改的部分，關鍵狀態的變更有可能是牽一發而動全身，因此產品要掌握整體的狀態變化，才可以產出一個高質量的狀態機。

（產品經理掌握確定性的「有限狀態機」即可，此類的狀態個數是可窮舉的，且動作引發的條件是可枚舉的。）

（簡單的狀態機）

3.3 有限狀態機實例

以「電商的銷售訂單支付狀態」簡單展示下狀態機如何畫如何表述。

在這種流程中一般會建議加上開始和終止，尤其終止表示了某個狀態為終態，終態是不可以再變更的。

以上三種情況是我遇到的比較常見的需要寫整體設計的場景，還有三種看個人風格是否愿意寫出來：

四、復雜功能的本質說明：

為了進一步明確表達我需求的核心訴求，往往我會把最核心的東西寫出來，比如我在描述ERP系統庫存上報模式的時候會給一個核心定義，然后再解釋不同模式。

五、多個方案的選用記錄

有時候一個問題可以有種模式和方案構成，我習慣于將不同的方案全部羅列出來，甚至標記出優劣勢，最后再給出結論，這樣做的好處是：

• 強化自己的思考：真正想清楚到底應該用什么方案。
• 用來說服別人：當你的老板、業務方、研測試同事看到你的優劣勢對比時，他會能知道你是技能是專業的、態度是積極的從而更容易獲取信任。
• 告知以后讀文檔的人：為什么“不得不”做出的「最符合當時情況的決策」。

例如我做訂單拆單時：

六、功能地圖：腦圖/用例圖

腦圖和用例圖均是為了有層次的表述全盤的功能點。腦圖會更加站在全局的角度描述功能構成，而用例圖則是以某一個用戶的角度來描述此用戶需要使用的功能，同時由于用例圖不同線段也能代表不同關系，因此用例圖的表述會更加的豐富。

例如，我們的功能是一個后臺的訂單管理功能，用腦圖和用例圖分別表示如下。

6.1 腦圖

傾向于結構性的羅列出此次功能所包含的所有要點，閱讀的人一目了然的知道本次功能不同層級的功能是什么。

6.2 用例圖

傾向于從用戶的角度出發能夠執行的動作。當一個功能較大需要不同的角色介入時，從不同角色觸發的用例圖可以讓閱讀者知道這里包含了一定的「權限」范圍，以及不同的角色需要處理的事情具體是什么。

以上就說關于整體設計的部分，這個系列的第三篇文章將會為大家介紹關于《產品需求文檔：需求詳情》的寫作技巧。

如果你有疑問請直接打在評論區，別忘了收藏加關注！