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

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

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

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

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

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

• 涉及多個業(yè)務角色
• 橫跨多個系統(tǒng)領(lǐng)域
• 涉及到了新的單據(jù)流

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

1.1 條件

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

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

1.2 推薦的表達方式

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

1.3 泳道圖實例

申請報銷流程

二、橫跨多個系統(tǒng)/領(lǐng)域

2.1 條件

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

2.2 推薦的表達方式

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

2.2.1 實體關(guān)系圖

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

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

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

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

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

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

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

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

不同的關(guān)系在產(chǎn)品設計上意味著什么?

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

梳理清楚關(guān)系為什么那么重要？

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

2.2.2 時序圖

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

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

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

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

在復雜的B端系統(tǒng)中，產(chǎn)品經(jīng)理一定要清楚以下情況，這些情況可能會限制功能設計。

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

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

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

因此第三方系統(tǒng)會在一段時間之后通過Webhook等方式回調(diào)給我方，告訴我們實際的結(jié)果。

• 成功：返回運單號
• 失敗：返回報錯信息

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

三、方案涉及到了狀態(tài)機

3.1 條件

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

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

當然狀態(tài)機其實也廣泛用于各種領(lǐng)域，軟硬件結(jié)合的比如自動零食售賣機，純軟件的比如網(wǎng)路游戲中。

3.2 推薦的表達方式

我們常用的狀態(tài)機叫做有限狀態(tài)機。

有限狀態(tài)機（Finite State Machine，簡稱FSM）是一種數(shù)學模型和計算機科學中的概念，用于描述系統(tǒng)的行為。它由一組狀態(tài)、一組轉(zhuǎn)移規(guī)則和一個初始狀態(tài)組成。有限狀態(tài)機可以處于這些狀態(tài)之一，并根據(jù)輸入執(zhí)行狀態(tài)轉(zhuǎn)移。

狀態(tài)機描述的是活動中狀態(tài)的變化，突出的是「動作」引發(fā)「狀態(tài)」變更，這對產(chǎn)品經(jīng)理能力有3個要求：

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

（產(chǎn)品經(jīng)理掌握確定性的「有限狀態(tài)機」即可，此類的狀態(tài)個數(shù)是可窮舉的，且動作引發(fā)的條件是可枚舉的。）

（簡單的狀態(tài)機）

3.3 有限狀態(tài)機實例

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

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

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

四、復雜功能的本質(zhì)說明：

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

五、多個方案的選用記錄

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

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

例如我做訂單拆單時：

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

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

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

6.1 腦圖

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

6.2 用例圖

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

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

如果你有疑問請直接打在評論區(qū)，別忘了收藏加關(guān)注！