在職場上，如果有一些工具能讓我們順手使用，工作效率會高很多。本文作者匯總整理了一份B端產(chǎn)品的工具包，并以案例穿插其中，可以幫助大家更好掌握文中列舉的這些工具。

這篇推文僅包含前4、5節(jié)哦，由于單篇文章字?jǐn)?shù)不宜過長，分為上、中、下三篇更新后續(xù)章節(jié)，歡迎收藏、評論或轉(zhuǎn)發(fā)給有需求的小伙伴~

四、產(chǎn)品設(shè)計工具

4.1 建模方法：MBSE （Model-Based Systems Engineering）

為什么B端產(chǎn)品經(jīng)理要了解MBSE（Model-Based Systems Engineering）？

系統(tǒng)工程國際委員會（INCOSE）給MBSE的定義是：“從概念設(shè)計階段開始，并持續(xù)貫穿開發(fā)和后續(xù)生命周期階段，支持系統(tǒng)需求、設(shè)計、分析、驗證和確認(rèn)活動的（模型）正規(guī)化應(yīng)用”。簡單理解，就是用標(biāo)準(zhǔn)的模型語言替代自然語言，應(yīng)用特定的方法論和工具，實現(xiàn)系統(tǒng)工程。

在MBSE出現(xiàn)之前，廣泛應(yīng)用的是基于文檔的系統(tǒng)工程DBSE（Document-based Systems Engineering），即以諸多文檔貫穿需求到落地（如需求文檔、產(chǎn)品設(shè)計文檔等），其中雖然有少量插圖，但是主體還是文字，受制于文字的表達(dá)能力，不同工程師在理解同一段信息時，可能會產(chǎn)生不同的理解，從而無法保障需求收集、需求分析、產(chǎn)品設(shè)計、開發(fā)測試的一致性[3]。

對于產(chǎn)品經(jīng)理來說，MBSE能夠有效地幫助我們，改善不同利益相關(guān)者的溝通，確保溝通的標(biāo)準(zhǔn)統(tǒng)一和準(zhǔn)確，從源頭提升產(chǎn)品交付的質(zhì)量。

那么B端產(chǎn)品經(jīng)理怎么使用MBSE呢？

B端產(chǎn)品經(jīng)理，可以了解Harmony SE ( Harmony for Systems Engineer-ing)。

圖片 21 Harmony diagram of Rational integrated system development process

它是MBSE方法中的一種，可以分成需求分析、系統(tǒng)功能分析和設(shè)計綜合三個階段：

1. 需求分析：會將涉眾需求轉(zhuǎn)化為系統(tǒng)需求，包括功能性需求和非功能性需求。
2. 系統(tǒng)功能分析：在這個階段會把系統(tǒng)功能性需求，通過建模語言轉(zhuǎn)化為庫可執(zhí)行的模型，一般可以通過三種SysML圖來展現(xiàn)模型的內(nèi)容（活動圖、順序圖、狀態(tài)機(jī)圖）。
3. 設(shè)計綜合：在這個階段會通過架構(gòu)分析和架構(gòu)設(shè)計，確定系統(tǒng)的解決方案，并將系統(tǒng)的功能性需求和非功能性需求，分配到系統(tǒng)架構(gòu)中。

我們以倉儲物流環(huán)節(jié)的車輛到達(dá)-分配月臺-卸貨-駛離月臺業(yè)務(wù)流程為例，詳細(xì)講解MBSE如何應(yīng)用：

STEP1：需求分析

首先在進(jìn)行需求分析之前，首先要明確在這個場景中的利益相關(guān)者都有哪些：

在這個業(yè)務(wù)場景下，利益相關(guān)者有倉庫和司機(jī)，具體執(zhí)行人，倉庫下有門衛(wèi)和裝卸操作工。

接著，通過現(xiàn)場調(diào)研，收集利益相關(guān)者在這個業(yè)務(wù)場景下的所有需求。

在這個業(yè)務(wù)流程中，可以使用BPMN來串聯(lián)業(yè)務(wù)流程，避免業(yè)務(wù)需求遺漏，繪制細(xì)節(jié)詳見“4.4建模語言：BPMN”章節(jié)。

在司機(jī)到達(dá)倉庫后，需要先到門衛(wèi)簽到，接著門衛(wèi)會通過監(jiān)控查看月臺閑置情況，確定卸貨月臺之后通過手動寫紙條遞交給司機(jī)，司機(jī)開車到卸貨月臺，下車把裝貨清單給操作工，操作工開始卸貨清點，完成卸貨之后操作工在裝貨清單上簽字，復(fù)印裝貨清單，把復(fù)印件交給司機(jī)，司機(jī)拿到后，開車駛離月臺。

圖片 22人工月臺分配流程BPMN圖

通過上面的BPMN圖，我們就大致明晰在月臺分派環(huán)節(jié)，我們需要線上化的信息和流程有哪些了。

然后，梳理出系統(tǒng)需求概述：

• 司機(jī)提前通過電話完成預(yù)約，倉庫客服錄入倉庫管理系統(tǒng)。
• 司機(jī)到達(dá)倉庫后，根據(jù)提前預(yù)約信息，倉庫門禁可以自動抬桿。
• 系統(tǒng)根據(jù)當(dāng)前月臺閑置情況，根據(jù)卸貨月臺優(yōu)先級，進(jìn)行推薦，推薦結(jié)果展示在倉庫門口的大屏。
• 司機(jī)查看大屏，將車開到指定的月臺處，此要有RFID設(shè)備校驗是否開到指定位置，如果開到指定位置，則修改月臺占用狀態(tài)到已占用；如果開錯月臺，則再根據(jù)月臺類型判斷是否能夠繼續(xù)卸貨，如果可以，則修改月臺狀態(tài)到已占用，如果不行，則通過大屏提示司機(jī)挪車。
• 操作工根據(jù)庫內(nèi)大屏提示，到指定月臺開始卸貨，用WMS（倉儲管理系統(tǒng)）的PDA進(jìn)行卸貨掃描，卸貨完成后，由PDA觸發(fā)自動打印卸貨清單，操作工根據(jù)卸貨清單信息對比司機(jī)提供的裝車單，完成簽字。
• 操作工復(fù)印簽字后的裝車單，遞交給司機(jī)，并且通過PDA提交裝車單照片，完成歸檔。
• 司機(jī)駛離月臺，RFID設(shè)備識別車輛離場狀態(tài)，修改月臺狀態(tài)到空閑。

STEP2：系統(tǒng)功能分析

利用SysML圖來展現(xiàn)模型的內(nèi)容（活動圖、順序圖、狀態(tài)機(jī)圖）。

首先，我們來繪制活動圖中的頂級函數(shù)圖，在繪制之前，我們要了解基礎(chǔ)的圖例。

表格 16 SysML活動圖圖例分類

圖片 23 SysML活動圖圖例

->拆分系統(tǒng)需求中的最小動作，每個動作有輸入（輸入栓）和輸出（輸出栓）

->在活動圖里，通過控制流（ControlFlow）和對象流（ObjectFlow）將動作串聯(lián)起來；控制流可以簡單理解成“告訴讀者步驟如何執(zhí)行”，比如在倉儲物流作業(yè)里“檢查裝車清單”和“卸載貨物”，就需要用控制流串聯(lián)，因為它們有前后聯(lián)系。對象流可以簡單理解成“告訴讀者（數(shù)據(jù)或物品）是如何在過程中傳遞的”，比如在倉儲物流作業(yè)里，貨物從卡車卸下，搬運(yùn)到暫存區(qū)，就需要用對象流串聯(lián)。

->在控制流或?qū)ο罅髦袀鬟f的數(shù)據(jù)稱為“令牌”（token）

根據(jù)圖例及需求繪制出活動圖：

圖片 24 SysML活動圖

接著，我們繪制這個需求的狀態(tài)機(jī)圖：

圖片 25 SysML狀態(tài)機(jī)圖

然后，我們繪制這個需求的順序圖（序列圖）：

圖片 26 SysML順序圖（序列圖）

STEP3：設(shè)計綜合

在完成了系統(tǒng)功能分析之后，接著要進(jìn)行架構(gòu)分析和架構(gòu)設(shè)計。

圖片 27 WMS架構(gòu)圖舉例

以上，我們就在MBSE的指導(dǎo)下，完成了一個簡單的場景分析。

4.2 建模語言：UML（Unified Modeling Language）

SysML和UML圖有什么區(qū)別？

UML圖服務(wù)于軟件工程，SysML圖服務(wù)于系統(tǒng)工程，后者拓展了UML圖，可以支持軟件外的硬件、信息、人員、過程和設(shè)備的系統(tǒng)建模。

為什么B端產(chǎn)品經(jīng)理要了解UML？

UML是一種面向?qū)ο蟮乃伎挤绞?，是開發(fā)的通用設(shè)計語言，掌握了UML之后，產(chǎn)品經(jīng)理可以更好地梳理業(yè)務(wù)邏輯，并且更順暢的與開發(fā)溝通。

UML圖有哪些種類呢？

截至UML2.0，產(chǎn)品經(jīng)常用到的，一共有13種圖形，分為靜態(tài)圖和動態(tài)圖

• 靜態(tài)圖有7種：組件圖、用例圖、類圖、包圖、對象圖、部署圖、復(fù)核結(jié)構(gòu)圖。
• 動態(tài)圖有6種：順序圖、協(xié)作圖、狀態(tài)機(jī)圖、活動圖、定時圖、交互概觀圖。

下面我們依次分享產(chǎn)品經(jīng)常用到的圖：

靜態(tài)圖1：UML-組件圖：

STEP1：在進(jìn)行UML組件圖的繪制之前，先要了解它適用于什么場景。

組件圖展示了系統(tǒng)的物理架構(gòu)，包含組件及相互關(guān)系，可以用于系統(tǒng)分析、接口設(shè)計。

STEP2：以自動化倉庫的WMS為例，繪制UML組件圖。

首先我們要了解UML組件圖常見圖例：

圖片 28 UML組件圖圖例

• 組件：用來表示系統(tǒng)中的一個物理或邏輯單元。
• 組件包：用來組織和分組組件。
• 接口：表示組件提供或需要的接口。
• 組件間依賴關(guān)系：表示一個組件依賴于另一個組件提供接口。
• 節(jié)點：用來表示運(yùn)行組件的物理節(jié)點，如服務(wù)器或工作站。

接著我們來繪制自動化倉庫WMS的組件圖：

圖片 29自動化倉庫WMS的UML組件圖

靜態(tài)圖2：UML-用例圖：

STEP1：在進(jìn)行UML用例圖的繪制之前，先要了解它適用于什么場景。

用例圖是一種描述系統(tǒng)功能需求和系統(tǒng)交互的圖形化工具，適用于需求分析、功能分析和測試驗證階段。

STEP2：以WMS維護(hù)基礎(chǔ)數(shù)據(jù)場景為例，繪制UML用例圖。

首先我們要了解用例圖常見圖例：

圖片 30 UML用例圖圖例

• 角色：代表與系統(tǒng)交互的用戶、系統(tǒng)或其他實體。
• 用例：描述系統(tǒng)可以執(zhí)行的特定功能或與用戶或系統(tǒng)交互的場景。
• 關(guān)聯(lián)：表示一條簡單的實線，連接用例和角色，表示二者的交互關(guān)系。
• 容器：用于組織和分組相關(guān)用例和角色。

接著我們來繪制用例圖，這里以WMS維護(hù)基礎(chǔ)數(shù)據(jù)場景為例：

圖片 31 UML用例圖

靜態(tài)圖3：UML-類圖：

STEP1：在進(jìn)行UML類圖的繪制之前，先要了解它適用于什么場景。

類圖幫助定義了系統(tǒng)的結(jié)構(gòu)，包括類、接口、屬性、方法和他們的關(guān)系。適用于系統(tǒng)架構(gòu)規(guī)劃和需求分析場景。

STEP2：以上架后庫存變動業(yè)務(wù)場景為例，繪制UML類圖。

在我們進(jìn)行UML類圖的繪制前，首先要了解類圖常見圖例。

圖片 32 UML類圖圖例

• 類：普通類可以用一個矩形表示，垂直分為三個部分；頂部是類名，中間是屬性，底部是操作或方法，其他類都是在普通類基礎(chǔ)上拓展的。
• 接口：表示為一個帶有“<< 接口>>”標(biāo)記的矩形。
• 枚舉：是一種特殊的數(shù)據(jù)類型，它表示為一組固定的常量值。
• 約束：用來指定模型元素之間的關(guān)系或模型元素屬性的限制條件。
• 三元關(guān)聯(lián)：服務(wù)于三個類相互關(guān)聯(lián)的復(fù)雜場景。
• 端口：端口定義了組件與其他組件或系統(tǒng)環(huán)境之間的交互點。

接著我們來繪制UML類圖，這里以上架后的WMS庫存變動為例：

圖片 33 UML類圖

靜態(tài)圖4：UML-包圖：

STEP1：在進(jìn)行UML包圖的繪制之前，先要了解它適用于什么場景。

包圖可以幫助進(jìn)行系統(tǒng)的分析和設(shè)計?？梢栽谲浖軜?gòu)設(shè)計的高層次系統(tǒng)結(jié)構(gòu)分析時使用。

STEP2：以簡單的倉庫管理系統(tǒng)為例，繪制UML包圖。

在繪制包圖之前，我們需要了解包圖的常見圖例：

圖片 34 UML包圖圖例

• 包：用來組織和封裝類、接口、協(xié)作以及子包等元素。包的名稱通常寫在矩形的頂部，內(nèi)部可以包含其他包、類、接口。
• 類：普通類可以用一個矩形表示，垂直分為三個部分；頂部是類名，中間是屬性，底部是操作或方法，其他類都是在普通類基礎(chǔ)上拓展的。
• 接口：表示為一個帶有“<< 接口>>”標(biāo)記的矩形。
• 依賴關(guān)系：表示為一條帶箭頭的虛線，箭頭指向依賴的元素，表示一個元素依賴于另一個元素。
• 泛化關(guān)系：表示為一條帶空心箭頭的實線，箭頭指向父元素，表示繼承關(guān)系。
• 實現(xiàn)關(guān)系：表示為一條帶空心箭頭的虛線，箭頭指向接口，表示類實現(xiàn)了該接口。
• 關(guān)聯(lián)關(guān)系：表示為一條實線，連接兩個類，表示類之間的結(jié)構(gòu)性關(guān)系。
• 聚合關(guān)系：表示為一條帶有空心菱形的實線，菱形靠近聚合的一方，表示整體與部分的關(guān)系。
• 組合關(guān)系：表示為一條帶有實心菱形的實線，菱形靠近組合的一方，表示更強(qiáng)烈的整體與部分的關(guān)系，部分不能獨(dú)立于整體存在。
• 導(dǎo)入：一個包使用另一個包的元素。

接著，我們以簡單的倉庫管理系統(tǒng)為例，繪制包圖：

圖片 35 UML包圖

靜態(tài)圖5：UML-對象圖：

STEP1：在進(jìn)行UML對象圖的繪制之前，先要了解它適用于什么場景。

UML適用于分析復(fù)雜系統(tǒng)，可以幫助理解系統(tǒng)中各個對象如何相互作用，可以在數(shù)據(jù)庫設(shè)計時展示數(shù)據(jù)庫表之間的關(guān)系。

STEP2：以訂單為例，繪制UML對象圖。

首先要了解對象圖的常見圖例：

圖片 36 UML對象圖圖例

• 對象：表示為矩形，頂部寫對象名，底部寫對象的屬性值。
• 鏈接：表示對象之間的關(guān)系，通常用實線連接兩個對象。
• 消息：表示對象間的通信，用帶箭頭的直線表示，箭頭指向接收消息的對象。
• 依賴關(guān)系：表示為一條帶箭頭的虛線，箭頭指向依賴的元素，表示一個元素依賴于另一個元素。
• 泛化關(guān)系：表示為一條帶空心箭頭的實線，箭頭指向父元素，表示繼承關(guān)系。
• 實現(xiàn)關(guān)系：表示為一條帶空心箭頭的虛線，箭頭指向接口，表示類實現(xiàn)了該接口。
• 關(guān)聯(lián)關(guān)系：表示為一條實線，連接兩個類，表示類之間的結(jié)構(gòu)性關(guān)系。
• 聚合關(guān)系：表示為一條帶有空心菱形的實線，菱形靠近聚合的一方，表示整體與部分的關(guān)系。
• 組合關(guān)系：表示為一條帶有實心菱形的實線，菱形靠近組合的一方，表示更強(qiáng)烈的整體與部分的關(guān)系，部分不能獨(dú)立于整體存在。

接著我們以訂單為例，進(jìn)行對象圖的繪制舉例：

圖片 37 UML對象圖舉例

靜態(tài)圖6：UML-部署圖：

STEP1：在進(jìn)行UML部署圖的繪制之前，先要了解它適用于什么場景。

部署圖用于展示系統(tǒng)的物理架構(gòu)，包括硬件、節(jié)點以及他們之間的通信。適用于系統(tǒng)架構(gòu)設(shè)計。

STEP2：以倉儲管理系統(tǒng)為例，繪制UML部署圖。

首先我們要了解部署圖的常見圖例：

圖片 38 UML部署圖圖例

• 組件：表示系統(tǒng)中的一個邏輯單元，可以是一個類、服務(wù)、庫或者其他可替換的軟件單元。
• 節(jié)點：表示物理的或虛擬的計算資源，如服務(wù)器、手機(jī)等。
• 對象：實例化的組件或者節(jié)點，代表運(yùn)行時的一個具體實體。
• 約束：表示部署圖中元素的特定限制或規(guī)則，用于說明如何部署或配置系統(tǒng)。
• 部署規(guī)范：表示部署的具體說明或要求，可能涉及技術(shù)標(biāo)準(zhǔn)、配置參數(shù)或性能指標(biāo)。
• 部署關(guān)系：表示組件間的關(guān)系。
• 通信路徑：表示節(jié)點之間或節(jié)點與組件間的通信鏈接，可能是網(wǎng)絡(luò)連接、消息傳遞或其他通信機(jī)制。

我們以倉儲管理系統(tǒng)為例，進(jìn)行部署圖的繪制：

圖片 39 部署圖舉例

動態(tài)圖1：UML-順序圖：

STEP1：在進(jìn)行UML順序圖的繪制之前，先要了解它適用于什么場景。

順序圖用于描述系統(tǒng)中對象之間的交互過程，可以用于需求分析、系統(tǒng)設(shè)計階段。我們在MBSE章節(jié)提到過SYSML順序圖，SYSML順序圖是UML順序圖的拓展，會包含額外的元素，例如需求鏈接和參數(shù)，兩者在基礎(chǔ)理念上是相似的。

STEP2：我們?nèi)砸栽屡_管理業(yè)務(wù)場景為例，繪制UML順序圖。

首先我們要了解順序圖的常見圖例：

圖片 40 UML順序圖常見圖例

• 對象：在順序圖中，對象通常用矩形表示，內(nèi)部可能包含對象的名稱和類名。對象代表參與交互的實體。
• 生命線：從對象矩形向下延伸的虛線，表示對象在交互過程中的存在和活躍時間。
• 同步消息：用實線箭頭表示，表示發(fā)送者發(fā)送消息給接收者，并等待接收者處理完畢。消息的發(fā)送和接收是同步進(jìn)行的。
• 異步消息：用虛線箭頭表示，表示發(fā)送者發(fā)送消息后可以繼續(xù)執(zhí)行，不需要等待接收者處理完畢。消息的發(fā)送和接收是異步的。
• 返回消息：用虛線箭頭指向發(fā)送者，表示方法調(diào)用的返回，通常在同步消息之后出現(xiàn)。
• 激活條：在生命線上的矩形條，表示對象在執(zhí)行操作或等待消息時的激活狀態(tài)。激活條的存在表示對象在這段時間內(nèi)是忙碌的。
• 自消息：箭頭指向同一對象，表示對象調(diào)用自己的操作或方法。
• 銷毀消息：用一個帶有“X”標(biāo)記的生命線末端來表示，表示對象的生命周期結(jié)束，對象將被銷毀。
• 實體：在順序圖中，實體通常指的是具有持久狀態(tài)的對象，如數(shù)據(jù)庫中的記錄。它們可能用帶有下劃線的對象名稱來表示。
• 控制：控制對象在順序圖中可能指的是負(fù)責(zé)協(xié)調(diào)和控制流程的對象，如控制器或管理器。
• 綁定：在順序圖中，綁定可能指的是對象之間的關(guān)聯(lián)關(guān)系，通常用于表示對象如何相互引用或調(diào)用。
• 時間信號：時間信號在順序圖中用來表示在特定時間點發(fā)生的消息或事件，通常用帶有時間標(biāo)記的箭頭表示。
• 約束：約束在順序圖中用來表示對消息或?qū)ο笮袨榈南拗茥l件，通常用大括號括起來的文本表示。
• 刪除：表示對象的生命周期結(jié)束，對象將被銷毀。

我們以月臺管理業(yè)務(wù)為例，進(jìn)行順序圖的繪制：

圖片 41 UML順序圖舉例

動態(tài)圖2：UML-協(xié)作圖：

STEP1：在進(jìn)行UML協(xié)作圖的繪制之前，先要了解它適用于什么場景。

UML協(xié)作圖用于闡述不同對象之間的交互方式，可以用于系統(tǒng)設(shè)計、需求分析階段。

STEP2：以倉庫管理系統(tǒng)入庫業(yè)務(wù)場景為例，繪制UML協(xié)作圖。

首先我們要了解協(xié)作圖的圖例：

圖片 42 UML協(xié)作圖圖例

• 角色：角色通常用來表示系統(tǒng)的外部用戶或者外部系統(tǒng)，它們與系統(tǒng)交互但不擁有系統(tǒng)內(nèi)部的狀態(tài)。在UML協(xié)作圖中，角色通常用一個人形圖標(biāo)或者帶有下劃線的矩形框來表示。
• 對象：對象是系統(tǒng)中的具體實例，它們擁有自己的狀態(tài)和行為。在UML協(xié)作圖中，對象通常用一個矩形框來表示，框內(nèi)可以包含對象的名稱。
• 生命線：生命線表示對象在交互過程中的存在時間。它是從對象符號向下延伸的垂直虛線，用來表示對象在交互過程中的活動時間段。
• 同步消息：同步消息表示一個對象向另一個對象發(fā)送消息，并等待消息被處理完成。在UML協(xié)作圖中，同步消息用實線箭頭表示，箭頭指向接收消息的對象。
• 異步消息：異步消息表示一個對象向另一個對象發(fā)送消息，但不需要等待消息被處理完成。在UML協(xié)作圖中，異步消息用虛線箭頭表示，箭頭指向接收消息的對象。
• 自關(guān)聯(lián)：自關(guān)聯(lián)表示對象與自身交互，即對象內(nèi)部的一個部分向另一個部分發(fā)送消息。在UML協(xié)作圖中，自關(guān)聯(lián)用一個從對象指向自身的帶箭頭的線表示。
• 激活條：激活條表示對象在某個時間段內(nèi)執(zhí)行操作。它是附著在對象生命線上的一個窄條，用來表示對象在這段時間內(nèi)是活躍的。
• 組合：組合表示一種強(qiáng)擁有關(guān)系，即一個對象是另一個對象的一部分，而且部分對象不能獨(dú)立于整體對象存在。在UML協(xié)作圖中，組合用一條帶有實心菱形的直線表示。
• 聚合：聚合表示一種弱擁有關(guān)系，即一個對象是另一個對象的一部分，但部分對象可以獨(dú)立于整體對象存在。在UML協(xié)作圖中，聚合用一條帶有空心菱形的直線表示。

我們以倉庫管理系統(tǒng)的入庫場景為例，繪制UML協(xié)作圖：

圖片 42 UML協(xié)作圖

動態(tài)圖3：UML-狀態(tài)機(jī)圖：

STEP1：在進(jìn)行UML狀態(tài)機(jī)圖的繪制之前，先要了解它適用于什么場景。

狀態(tài)機(jī)圖描述了一個對象在其生命周期內(nèi)歷經(jīng)的所有狀態(tài)及轉(zhuǎn)換，可以用于需求分析與系統(tǒng)設(shè)計階段。

STEP2：以倉庫管理系統(tǒng)的入庫訂單為例，繪制UML狀態(tài)機(jī)圖。

首先，我們要了解協(xié)作圖的圖例：

圖片 43 UML狀態(tài)機(jī)圖

• 狀態(tài)：狀態(tài)是對象在某個時間點的特定情況或條件，在這段時間內(nèi)，對象滿足某些條件或執(zhí)行某些活動。狀態(tài)通常用圓角矩形表示。
• 初始狀態(tài)：初始狀態(tài)是對象開始時所處的狀態(tài)。在UML狀態(tài)機(jī)圖中，初始狀態(tài)用一個帶實心黑點的圓表示，這個圓與開始狀態(tài)的邊相連。
• 終止?fàn)顟B(tài)：終止?fàn)顟B(tài)是對象生命周期結(jié)束時的狀態(tài)。在UML狀態(tài)機(jī)圖中，終止?fàn)顟B(tài)用一個帶實心黑圓的圓表示。
• 轉(zhuǎn)換：轉(zhuǎn)換是從一個狀態(tài)到另一個狀態(tài)的變化。它由一條帶箭頭的線表示，箭頭從當(dāng)前狀態(tài)指向新狀態(tài)。轉(zhuǎn)換通常伴隨著一個觸發(fā)事件和（可選的）動作。
• 守衛(wèi)條件：守衛(wèi)條件是轉(zhuǎn)換發(fā)生前必須滿足的條件。它是一個布爾表達(dá)式，只有當(dāng)這個表達(dá)式為真時，轉(zhuǎn)換才會發(fā)生。守衛(wèi)條件通常寫在轉(zhuǎn)換旁邊，用方括號表示。
• 同步條：同步條也稱為復(fù)合轉(zhuǎn)換，用于表示多個狀態(tài)同時結(jié)束和開始。它用一條粗橫線表示，橫跨多個狀態(tài)，表示這些狀態(tài)將同時結(jié)束，并觸發(fā)新的轉(zhuǎn)換。

我們以倉庫管理系統(tǒng)的入庫訂單為例，繪制UML狀態(tài)機(jī)圖：

動態(tài)圖44：UML-狀態(tài)機(jī)圖：

STEP1：在進(jìn)行UML活動圖的繪制之前，先要了解它適用于什么場景。

UML活動圖是一種用于描述系統(tǒng)中一個對象或者多個對象的動態(tài)行為圖形化工具，適用于業(yè)務(wù)流程建模、需求分析、多線程程序設(shè)計。

STEP2：以入庫清點質(zhì)檢場景為例，繪制UML活動圖。

首先，我們要了解活動圖的圖例：

圖片 45 UML活動圖圖例

• 活動狀態(tài)：活動狀態(tài)表示在狀態(tài)機(jī)中的一個活動或操作，通常用來描述在特定狀態(tài)下執(zhí)行的動作。在狀態(tài)機(jī)圖中，活動狀態(tài)通常用帶有名稱的圓角矩形表示。
• 開始節(jié)點：開始節(jié)點是狀態(tài)機(jī)的起點，通常用一個實心圓點表示，并且有一個箭頭指向初始狀態(tài)。
• 結(jié)束節(jié)點：結(jié)束節(jié)點表示狀態(tài)機(jī)的結(jié)束，通常用一個帶有實心圓的圓圈表示，表示狀態(tài)機(jī)在此節(jié)點達(dá)到最終狀態(tài)。
• 控制流：控制流表示狀態(tài)之間的轉(zhuǎn)換路徑，通常用帶箭頭的直線表示，箭頭從當(dāng)前狀態(tài)指向下一個狀態(tài)。
• 決策節(jié)點：決策節(jié)點表示基于特定條件的決策點，通常用菱形表示。流程會根據(jù)條件的真假分支到不同的狀態(tài)。
• 分支：分支是從決策節(jié)點出發(fā)的多個路徑，每個路徑對應(yīng)一個條件的結(jié)果。在狀態(tài)機(jī)圖中，分支通常用從決策節(jié)點出發(fā)的多條帶箭頭的直線表示。
• 泳道：泳道用于將狀態(tài)機(jī)圖分割成不同的部分，每個部分代表不同的角色或執(zhí)行環(huán)境。泳道通常用垂直或水平的分隔線表示，每個泳道內(nèi)包含一系列狀態(tài)和轉(zhuǎn)換。
• 同步條：同步條用于表示多個并行路徑的同步點，即多個分支在某個點上需要等待彼此完成才能繼續(xù)執(zhí)行。在狀態(tài)機(jī)圖中，同步條通常用一條粗橫線表示，橫跨多個路徑。

我們以入庫場景為例，繪制UML活動圖：

圖片 46 UML活動圖舉例

動態(tài)圖5：UML-交互概觀圖：

STEP1：在進(jìn)行UML交互概觀圖的繪制之前，先要了解它適用于什么場景。

交互概覽圖是一種展示系統(tǒng)交互的高級抽象試圖，它忽略了消息和生命線，適合展示業(yè)務(wù)流程的控制流概覽；適用于需求分析和系統(tǒng)設(shè)計。

STEP2：以倉儲管理系統(tǒng)為例，繪制UML交互概觀圖。

首先我們要了解UML交互概覽圖的常規(guī)圖例：

圖片 47 UML交互概覽圖圖例

• 組合片段：用于表示一個特定的交互片段，可以包含順序圖、通信圖、交互概覽圖或時間圖。引用現(xiàn)有的交互圖，顯示為一個引用框，左上角顯示 “ref”。
• 決策點：用于表示流程中的分支點，類似于活動圖中的決策節(jié)點。
• 初始狀態(tài)：表示流程的開始，通常用實心圓點表示。
• 終止?fàn)顟B(tài)：表示流程的結(jié)束，通常用帶實心圓的圓圈表示。
• 控制流：表示流程中的控制流向，用帶箭頭的直線表示。

以入庫流程為例，繪制交互概覽圖：

圖片 48 UML交互概覽圖圖例

以上，我們就完成了產(chǎn)品經(jīng)理常用的幾種UML圖介紹。

4.3 建模語言：BPMN（Business Process Model and Notation）

為什么B端產(chǎn)品經(jīng)理要了解BPMN？

BPMN用圖形化的方式表示業(yè)務(wù)流程，使流程更加易懂，這有助于產(chǎn)品經(jīng)理更好地表達(dá)業(yè)務(wù)結(jié)構(gòu)和邏輯，能有效改善和開發(fā)的溝通質(zhì)量。

那么我們怎么繪制BPMN？

以一個簡單的人工月臺分派流程為例：

在司機(jī)到達(dá)倉庫后，需要先到門衛(wèi)簽到，接著門衛(wèi)會通過監(jiān)控查看月臺閑置情況，確定卸貨月臺之后通過手動寫紙條遞交給司機(jī)，司機(jī)開車到卸貨月臺，下車把裝貨清單給操作工，操作工開始卸貨清點，完成卸貨之后操作工在裝貨清單上簽字，復(fù)印裝貨清單，把復(fù)印件交給司機(jī)，司機(jī)拿到后，開車駛離月臺。

STEP1：首先我們需要了解BPMN的元模型。

圖片 49 BPMN元模型示例

STEP2：梳理繪圖要點。

劃分泳道：在這個案例中，涉及兩個角色的操作，為了更清晰地表達(dá)，我們需要劃分兩個泳道，倉庫和司機(jī)。

確認(rèn)數(shù)據(jù)對象：在這個案例中，涉及卸貨月臺信息和裝貨清單兩種信息的流轉(zhuǎn)。

STEP3：開始繪制BPMN圖。

圖片 50 人工月臺分配流程

通過上面的BPMN圖，我們就大致明晰在進(jìn)行物流全面的信息化時，在月臺分派環(huán)節(jié)，我們需要線上化的信息和流程有哪些了。

4.4 功能建模工具：功能樹

B端產(chǎn)品經(jīng)理為什么要了解功能樹？

功能樹（Function Tree）是一種通過層次結(jié)構(gòu)展示產(chǎn)品功能的工具，能夠幫助產(chǎn)品經(jīng)理設(shè)計產(chǎn)品。

怎么在產(chǎn)品設(shè)計中應(yīng)用功能樹？

STEP1：明確產(chǎn)品目標(biāo)。

確定產(chǎn)品的主要目標(biāo)，繪制功能樹的頂點。

STEP2：構(gòu)建頂層功能。

根據(jù)產(chǎn)品目標(biāo)和用戶需求，定義產(chǎn)品的頂層功能。

STEP3：分解子功能。

將頂層功能分解成更具體的子功能，這些子功能支持頂層功能的實現(xiàn)。

圖片 51 某WMS功能樹

以上，我們就完成了功能樹的設(shè)計。

4.5 功能建模工具：IDEF0

為什么產(chǎn)品經(jīng)理需要了解IDEF0？

IDEF0通過自頂向下、逐層分解的方式構(gòu)造系統(tǒng)的功能模型，幫助我們逐層拆解系統(tǒng)的關(guān)系。

對于一個新需求或新系統(tǒng)，這個工具能夠進(jìn)行功能建模；在拆解一個成熟的競品系統(tǒng)時，這個工具可以分析系統(tǒng)的工作機(jī)制。

IDEF0包含哪些內(nèi)容？

IDEF0模型包括以下幾個主要元素：

• 功能（Functions）：這些是流程中執(zhí)行的主要活動或任務(wù)，通常在圖表中用矩形框表示。
• 輸入（Inputs）：這些是執(zhí)行功能所需的資源或數(shù)據(jù)，用箭頭表示，從左側(cè)進(jìn)入功能框。
• 輸出（Outputs）：這些是功能執(zhí)行后產(chǎn)生的結(jié)果或產(chǎn)品，用箭頭表示，從功能框的右側(cè)離開。
• 控制（Controls）：這些是管理功能執(zhí)行的規(guī)則、規(guī)章或約束，用箭頭表示，從頂部進(jìn)入功能框。
• 機(jī)制（Mechanisms）：這些是執(zhí)行功能所需的資源、工具或人員，用箭頭表示，從底部進(jìn)入功能框。

那么我們怎么使用IDEF0呢？

我們以倉庫“普貨入庫業(yè)務(wù)流程”展開A-0圖為例：

STEP1：確定展開的功能（Function）。

選用普貨入庫業(yè)務(wù)流程，這個流程包含著卸貨、收貨、上架三個子步驟。

STEP2：確定輸入（Input）。

輸入是執(zhí)行流程需要的資源或者信息，對于我們選用的入庫功能，輸入大致包括：

a.實物貨物。

b.貨物的詳細(xì)信息（生產(chǎn)日期、尺寸、重量、貨物質(zhì)量等），這些有的通過目視化獲取、有些通過測量得到。

c.入庫訂單

d.卸貨計劃作業(yè)單。

e.收貨計劃作業(yè)單。

f.上架計劃作業(yè)單。

這些是完成入庫流程所必須的。

STEP3：確定輸出（Output）。

輸出是流程執(zhí)行后產(chǎn)生的結(jié)果，對于貨物入庫流程，輸出大致包括：

a.上架后的庫存位置。

b.WMS打印出的入庫確認(rèn)單。

c.庫存管理中增補(bǔ)的庫存信息。

這些是完成入庫流程后產(chǎn)生的。

STEP3：確定機(jī)制（Mechanism）。

機(jī)制是完成功能所需的工具或資源，在我們進(jìn)行入庫流程時，機(jī)制大致包含：

a.倉儲管理軟件（WMS）。

b.叉車或AGV或線體等搬運(yùn)設(shè)備。

c.倉庫操作工。

上述機(jī)制是執(zhí)行入庫流程必須的。

STEP4：確定控制（Control）。

控制是影響功能執(zhí)行的條件或規(guī)則，在我們進(jìn)行入庫流程時，控制大致包含：

a.倉庫操作的標(biāo)準(zhǔn)操作程序（SOP）。

b.貨物接收和存放的安全規(guī)定。

c.貨物管理的法規(guī)和政策。

這些控制因素，保障了入庫業(yè)務(wù)流程按照既定的規(guī)則和標(biāo)準(zhǔn)運(yùn)行。

STEP5：完成繪圖

圖片 52普貨入庫業(yè)務(wù)流程A-0圖

以上，我們完成了以“普貨入庫業(yè)務(wù)流程”展開A-0圖的操作。

仔細(xì)觀察上述輸入、輸出、機(jī)制、控制的因素，我們不難發(fā)現(xiàn)，有些是由子流程產(chǎn)生的，例如輸入中的收貨計劃作業(yè)單，這是在WMS里完成卸貨操作后，才能輸出的，所以我們要進(jìn)一步拆解子流程，并將相應(yīng)的輸出關(guān)聯(lián)到A-0圖的輸入。

對于一個復(fù)雜的系統(tǒng)或業(yè)務(wù)，要逐層拆解很多層的IDEF0圖，才能完整的解釋工作機(jī)制，這里以INCOSE完整流程圖為例：

圖片 53 Process Flow Block Diagram-base on INCOSE Systems Engineering Handbook v.4.0

但是在實際的工作中，我們應(yīng)用A-0圖梳理自己的思路即可。

4.5 流程建模工具：泳道圖

為什么產(chǎn)品經(jīng)理熟練應(yīng)用泳道圖？

因為泳道圖貫穿了業(yè)務(wù)需求落地的整個過程：

在業(yè)務(wù)需求確認(rèn)環(huán)節(jié)，產(chǎn)品經(jīng)理可以繪制泳道圖，描述系統(tǒng)服務(wù)的業(yè)務(wù)流程，與業(yè)務(wù)方完成關(guān)鍵系統(tǒng)功能的需求確認(rèn)。

在產(chǎn)品設(shè)計環(huán)節(jié)，產(chǎn)品經(jīng)理可以通過泳道圖回溯需求要點，避免功能遺漏。

在需求評審環(huán)節(jié)，產(chǎn)品經(jīng)理可以通過泳道圖為開發(fā)、測試同事解釋業(yè)務(wù)背景及功能概要，便于技術(shù)側(cè)理解業(yè)務(wù)與需求。

在產(chǎn)品實施環(huán)節(jié)，產(chǎn)品經(jīng)理可以通過泳道圖串聯(lián)操作手冊，幫助培訓(xùn)用戶。

那么如何繪制泳道圖呢？

我們以某個出口倉庫的出庫流程為例：

STEP1：在繪制泳道圖之前，需要先搞清楚，我們設(shè)計的系統(tǒng)，服務(wù)于什么樣的業(yè)務(wù)鏈條？

以出口倉庫出庫流程為例：

圖片 54出口業(yè)務(wù)中，WMS服務(wù)的業(yè)務(wù)流程

梳理完上述鏈條之后，我們就明白了在整個出口業(yè)務(wù)中，出口倉庫WMS所服務(wù)的流程是什么。

STEP2：接著需要搞清楚，出庫流程需要哪些系統(tǒng)的什么功能支撐，會和哪些系統(tǒng)有交互，需要人工怎么操作串聯(lián)：

圖片 55出庫業(yè)務(wù)簡要流程

這樣，我們就畫出了出庫業(yè)務(wù)的簡要流程，知道了在出庫業(yè)務(wù)中數(shù)據(jù)的大致流向。

STEP3：接著我們繼續(xù)思考，在出庫流程中，是否需要倉庫外部的協(xié)作？

我們不難發(fā)現(xiàn)，在掃描裝箱前，需要有空集裝箱運(yùn)輸?shù)絺}庫，提空箱的操作是由車隊完成的，那么我們在繪制泳道圖的時候，就需要納入車隊。

以此類推，我們就可以完善泳道圖的所有相關(guān)方。

STEP4：最后，我們將作業(yè)細(xì)節(jié)完善，就可以繪制出服務(wù)于出口倉庫的出庫業(yè)務(wù)泳道圖：

圖片 56 某項目出庫業(yè)務(wù)流程圖示例

在繪制泳道圖時，有如下注意事項：

1.規(guī)范圖例：要應(yīng)用標(biāo)準(zhǔn)的泳道圖圖例。

2.減少箭頭交叉：盡量避免泳道之間的箭頭交叉，如果不可避免，使用清晰的標(biāo)記或顏色區(qū)分。

3.泳道劃分：要確保每個泳道對應(yīng)的任務(wù)和責(zé)任是清晰明確的。

4.流程命名規(guī)則：流程的命名應(yīng)使用動詞+名詞的動賓短語進(jìn)行描述，以確保流程的清晰和一致性。

4.7 信息建模工具：E-R

為什么B端產(chǎn)品經(jīng)理要了解E-R圖？

E-R圖是產(chǎn)品經(jīng)理對業(yè)務(wù)進(jìn)行深入分析后，從業(yè)務(wù)流程和表象中抽象出的實體；它可以幫助開發(fā)人員傳達(dá)系統(tǒng)的主要實體及其關(guān)系，讓開發(fā)人員準(zhǔn)確理解需求。

那么怎么繪制E-R圖？

我們以某服裝品牌官網(wǎng)下單流程案例舉例：

STEP1：思考在下單流程中，存在著哪些實體（Entities）。

在下單的過程中，主要的實體包括：

a.客戶。

b.客戶信息。

c.SKU類型。

d. SKU信息，即商品。

e.官網(wǎng)購物車。

f.收貨信息。

g.支付信息。

h.訂單。

STEP2：思考實體有哪些屬性（Attributes）。

梳理出每個實體的屬性：

a.客戶：

客戶是下單流程的主導(dǎo)者。

b.客戶信息：

客戶信息記錄著客戶的所有信息，需要記錄客戶的基礎(chǔ)信息，如客戶編碼、手機(jī)號、昵稱、密碼、郵箱。

此外，為了保障拓展性，為后續(xù)的會員系統(tǒng)做鋪墊，官網(wǎng)的客戶信息還要記錄客戶會員號、客戶生日、客戶積分。

最后，為了數(shù)據(jù)版本記錄，需要記錄客戶信息更新時間。

這樣，我們就總結(jié)出了客戶信息所需字段：客戶編碼、手機(jī)號、昵稱、密碼、郵箱、客戶會員號、客戶生日、客戶積分、客戶信息更新時間。

c.SKU類型:

在本例中，SKU類型為服裝，業(yè)務(wù)要求，客戶在進(jìn)行購物時，必須要先選擇品類（普拉提/瑜伽/舞蹈），點擊到商品面板后，一定需要能選擇不同的顏色，切換到不同的商品效果圖。（這里先不考慮需求合理性，僅為示例）

基于這個需求，在進(jìn)行SKU類型的設(shè)計時，需要考慮商品類型需要分級，例如，一級商品類型標(biāo)識這個商品大類，例如普拉提服裝；二級商品類型標(biāo)識到某款商品（包含著不同顏色、不同尺碼的該款商品）。然后根據(jù)顏色劃分不同的SKU編碼，最后，在SKU信息屬性中用尺寸字段記錄尺碼信息。

圖片 57 SKU類型劃分

這樣，我們就總結(jié)出了SKU類型所需字段：商品編碼類型、商品類型名稱、商品類型層級。

d.SKU信息：

在本例中，這個品牌有多個電商渠道，所以需要在推送渠道庫存時，需要分渠道拆分推送，避免庫存同步不及時，導(dǎo)致超賣。

基于這個需求，除了基礎(chǔ)信息，在進(jìn)行SKU信息設(shè)計時，需要考慮此渠道庫存和總庫存，此外，為了滿足SKU基礎(chǔ)的上下架需求，需要考慮上架時間、下架時間、和上架狀態(tài)標(biāo)識。

這樣，我們就總結(jié)出了SKU信息所需字段：SKU編碼、SKU名稱、單價、尺寸、SKU類型、此渠道庫存、總庫存、上架時間、下架時間、上架狀態(tài)。

e.官網(wǎng)購物車

在本例中，一個客戶可以將多個商品、多個數(shù)量加入購物車。

基于這個需求，我們可以梳理出官網(wǎng)購物車所需字段：購物車編碼、客戶編碼、加購時間、SKU編碼、數(shù)量。

f.收貨信息

在本例中，一個客戶可以有多個收貨信息，在下單時任選其一。

基于這個需求，我們可以梳理出收貨信息所需字段：收貨信息編碼、收貨省份、收貨城市、收貨街道、聯(lián)系人、聯(lián)系手機(jī)號、客戶編碼。

g.支付信息

在本例中，一個訂單只可以由一個客戶支付一次。

基于這個需求，我們可以梳理出支付信息所需字段：支付編碼、訂單編碼、支付方式、支付時間、客戶編碼、支付狀態(tài)。

h.訂單

基于以上的分析，訂單所需字段有：訂單編碼、客戶編碼、下單時間、SKU編碼、數(shù)量、單價、訂單狀態(tài)、支付狀態(tài)、收貨信息編碼。

STEP3：思考實體之間的關(guān)系（Relationships）

• 客戶與訂單：一對多關(guān)系，一個客戶可以有多個訂單，可以通過客戶編碼關(guān)聯(lián)。
• 客戶與收貨信息：一對多關(guān)系，一個客戶可以有多個收貨信息，可以通過客戶編碼關(guān)聯(lián)。
• 客戶與SKU類型：間接的多對多關(guān)系，一個客戶可以檢索多個SKU類型信息，一個SKU類型信息可以被多個用戶檢索到。
• 客戶與官網(wǎng)購物車：一對一關(guān)系，一個客戶唯一對應(yīng)一個官網(wǎng)購物車，可以通過客戶編碼關(guān)聯(lián)。
• 客戶與支付信息：一對多關(guān)系，一個客戶可以創(chuàng)建多個支付信息，可以通過客戶編碼關(guān)聯(lián)。
• 官網(wǎng)購物車與SKU信息：多對多關(guān)系，一個官網(wǎng)購物車可以包含多個SKU信息，一個SKU可以被多個官網(wǎng)購物車包含，可以通過SKU編碼關(guān)聯(lián)。
• SKU類型與SKU信息：一對多關(guān)系，一個SKU類型可以包含多個SKU信息，可以通過SKU編碼關(guān)聯(lián)。
• 訂單與支付信息：一對一關(guān)系，一個訂單唯一對應(yīng)一個支付信息，可以通過訂單編碼關(guān)聯(lián)。
• 收貨信息與訂單：多對一關(guān)系，一個收貨地址可以被多個訂單使用，但一個訂單包含一個收貨地址，可以通過收貨信息編碼關(guān)聯(lián)。
• 訂單與SKU信息：多對多關(guān)系，一個訂單包含多個SKU信息，一個SKU可以被多個訂單使用，可以通過SKU信息關(guān)聯(lián)。
• 客戶信息與客戶：一對一關(guān)系，每個客戶有且僅有一個客戶信息。

STEP4：利用繪圖軟件（Visio、Process on等）開始畫圖

1.畫出實體：客戶、客戶信息、SKU、SKU類型、官網(wǎng)購物車、訂單、支付信息、地址信息。

2.畫出屬性：將每個屬性繪制為橢圓形，并將其連線到所屬的實體。

3.畫出關(guān)系：將每個關(guān)系繪制為菱形，并將其連線到相關(guān)的實體。

4.添加主鍵：在每個實體中，選取一個屬性作為主鍵，并在矩形內(nèi)用下劃線標(biāo)記出來。

圖片 58某官網(wǎng)下單流程E-R圖

這樣我們就完成了一張E-R圖的繪制。

4.8 決策建模工具：決策樹

為什么B端產(chǎn)品經(jīng)理要了解決策樹？

B端產(chǎn)品經(jīng)常會涉及復(fù)雜的決策問題，決策樹能幫助產(chǎn)品經(jīng)理處理非線性的關(guān)系和交互，為解決這種問題提供一種直觀的方法。

圖片 59決策樹示例

那我們怎么應(yīng)用決策樹呢？

以某業(yè)務(wù)提出的自動補(bǔ)貨需求為例：

某企業(yè)計劃部門，向信息技術(shù)部門提出了一個新需求，希望每天凌晨2點，根據(jù)SKU的庫存水平、供應(yīng)商的歷史交貨時間、市場需求變化，自動生成補(bǔ)貨單。

STEP1:獲取到這個需求后，首先產(chǎn)品經(jīng)理要識別到，這個需求是模糊的，要和業(yè)務(wù)方追問決策標(biāo)準(zhǔn)。

在本案例中，需要和業(yè)務(wù)方確定如下決策標(biāo)準(zhǔn)：

1.觸發(fā)庫存水平低補(bǔ)貨的閾值是多少？系統(tǒng)怎么獲悉？

2.怎么衡量供應(yīng)商交貨時間長短？閾值是多少？

3.怎么衡量市場需求變化？系統(tǒng)怎么獲悉市場變化？

STEP2:假設(shè)經(jīng)過幾輪磋商，產(chǎn)品引導(dǎo)業(yè)務(wù)方有了如下需求反饋：

1.觸發(fā)庫存水平低的閾值每個SKU都不一樣，系統(tǒng)可以將SKU主數(shù)據(jù)中維護(hù)的安全庫存作為閾值，低于安全庫存則觸發(fā)低庫存補(bǔ)貨；高于安全庫存則根據(jù)市場需求補(bǔ)貨。

2.供應(yīng)商歷史交貨時間（供應(yīng)商歷史采購訂單獲批，到對應(yīng)貨物入庫的間隔），大于兩周則視為長交貨時間。此外，只有在低庫存補(bǔ)貨時需要考慮供應(yīng)商交貨時間問題。

3.市場需求包含季節(jié)性變化和促銷活動。系統(tǒng)可以根據(jù)SKU類型區(qū)分受季節(jié)影響明顯的貨物，業(yè)務(wù)會給出高季節(jié)性的SKU類型清單。另外參加大促的SKU，也需要提前補(bǔ)貨，業(yè)務(wù)部門會給出所有大促SKU清單，大促的優(yōu)先級要比季節(jié)性高，有促銷就不考慮季節(jié)性變化。

STEP3:需求已經(jīng)有了大致輪廓，產(chǎn)品經(jīng)理可以嘗試畫出決策樹：

在決策樹中，我們用矩形代表決策節(jié)點；用橢圓形代表機(jī)會節(jié)點；用三角形代表機(jī)會節(jié)點。

圖片 60 補(bǔ)貨案例決策樹

決策節(jié)點說明：

決策點1.系統(tǒng)可以將SKU主數(shù)據(jù)中維護(hù)的安全庫存作為閾值，低于安全庫存觸發(fā)低庫存補(bǔ)貨，高于安全庫存，觸發(fā)市場需求補(bǔ)貨。

決策點4.增補(bǔ)數(shù)據(jù)表及功能頁面，記錄業(yè)務(wù)手動上傳目前參加促銷活動的所有SKU清單，這里判斷SKU是否在此清單就好。

決策點5.計算供應(yīng)商歷史交貨時間（計算公式：采購入庫時間-采購訂單獲批時間），大于兩周則視為長交貨時間。

決策點10. 增補(bǔ)數(shù)據(jù)表及功能頁面，記錄業(yè)務(wù)手動上傳所有高季節(jié)性的SKU類型；這里判斷SKU對應(yīng)的SKU類型是否在此清單就好。

決策結(jié)果：

關(guān)于補(bǔ)貨量A、B、C、D、E的具體值，需要向業(yè)務(wù)追問，由業(yè)務(wù)磋商后反饋。

以上，我們就完成了一個復(fù)雜決策問題的建模與落地設(shè)計。

4.9 產(chǎn)品設(shè)計集合工具：原型圖

產(chǎn)品經(jīng)理為什么要熟練使用原型圖？

原型圖是產(chǎn)品和產(chǎn)品相關(guān)人（客戶、用戶、設(shè)計師、開發(fā)、測試等）溝通需求和設(shè)計想法的工具，可以幫助團(tuán)隊成員理解產(chǎn)品的結(jié)構(gòu)和功能。

那么產(chǎn)品經(jīng)理怎么繪制原型圖？

STEP1：確定目標(biāo)和需求。

在前面的章節(jié)，我們已經(jīng)用了很大的篇幅介紹該怎么收集需求、分析需求、進(jìn)行功能建模，在繪制原型圖之前，一定要明確每個功能頁面的目標(biāo)用戶和使用場景。

STEP2：進(jìn)行草圖設(shè)計和構(gòu)思。

在這一步中，需要用紙筆繪制出原型草圖，去構(gòu)思界面布局和流程，確定好頁面結(jié)構(gòu)。

這一步驟不用將時間浪費(fèi)在美化草圖上，只要能夠精準(zhǔn)地表達(dá)訴求就好。

STEP3：選擇繪圖工具。

在常見的繪圖工具中，選擇順手的裝備，請注意，如果你所在的產(chǎn)品團(tuán)隊已經(jīng)有了常用的工具，請延續(xù)團(tuán)隊的選擇，避免不互通。

以下是主流原型工具的優(yōu)劣點：

圖片 61 原型工具優(yōu)劣勢

STEP4：開始繪制原型圖。

根據(jù)草圖和框架，把內(nèi)容和元素放在頁面上。

調(diào)整布局，注意對齊、對比、重復(fù)和強(qiáng)調(diào)（一個頁面只有一個突出按鈕），提高頁面的整潔度和視覺一致性。

進(jìn)行交互設(shè)計，引導(dǎo)用戶參與，增加點擊、滑動、頁面切換等。

圖片 62某項目原型圖

STEP5：增補(bǔ)注釋和說明。

在每個功能按鈕、涉及邏輯處增補(bǔ)注釋和說明，便于開發(fā)和測試?yán)斫庑枨?；補(bǔ)充交互邏輯。

以上，我們就完成了原型圖的分步驟介紹；如果不知道如何上手，建議從模仿優(yōu)秀競品頁面開始，熟悉工具。

4.10 競品分析工具：競品分析報告

B端產(chǎn)品經(jīng)理為什么要熟悉競品分析報告？

競品分析報告，能夠幫助產(chǎn)品經(jīng)理了解自身產(chǎn)品在市場中的位置，及與競爭對手相比的劣勢和優(yōu)勢，提前準(zhǔn)備相應(yīng)的應(yīng)對策略。

如何應(yīng)用競品分析？

STEP1：確定競品分析的目標(biāo)。

明確競品分析的目的，比如了解市場趨勢、評估競爭對手的優(yōu)勢和劣勢、尋找差異化機(jī)會等。

STEP2：選擇競品。

根據(jù)產(chǎn)品特性、目標(biāo)市場和客戶群體，選擇直接和間接的競爭對手。

STEP3：收集數(shù)據(jù)。

利用多種渠道，收集競品的產(chǎn)品信息，包含目標(biāo)客群、產(chǎn)品功能、定價策略、市場定位、用戶反饋、訂購流程、適用價格、定制化人天開發(fā)費(fèi)用、實施費(fèi)用、運(yùn)維費(fèi)用、增值服務(wù)等。

圖片 63某產(chǎn)品競品分析圖舉例

STEP4：利用戰(zhàn)略規(guī)劃工具SWOT進(jìn)行分析，尋找產(chǎn)品切入點：

以某物流系統(tǒng)產(chǎn)品為例：

1.優(yōu)勢（Strengths）。

a. 引入了最新技術(shù)：通過技術(shù)創(chuàng)新，如物聯(lián)網(wǎng)、大數(shù)據(jù)、云計算等技術(shù)的應(yīng)用，實現(xiàn)了物流過程的智能化、自動化和可視化，提高了物流效率和降低了成本。

b. 政策支持：國家層面出臺了一系列政策和法律法規(guī)，為物流信息行業(yè)提供了良好的宏觀市場環(huán)境。

c. 順應(yīng)綠色環(huán)保趨勢：物流行業(yè)趨向綠色化、低碳化發(fā)展，本系統(tǒng)實現(xiàn)了全流程碳足跡計算

d. 集成了多種物流設(shè)備：物流系統(tǒng)通過自動化設(shè)備和技術(shù)，實現(xiàn)了物流運(yùn)輸過程的高效、快速、安全、精準(zhǔn)，同時降低了物流成本。

2.劣勢（Weaknesses）。

a.服務(wù)價格下滑：物流系統(tǒng)產(chǎn)品競爭激烈，同質(zhì)化競爭現(xiàn)象嚴(yán)重，導(dǎo)致服務(wù)價格下滑，增加了運(yùn)營壓力。

3.機(jī)會（Opportunities）。

a. “一帶一路”倡議：為物流系統(tǒng)行業(yè)提供了參與國際競爭和合作的平臺，拓寬了發(fā)展路徑。

b.跨境市場需求增長：跨境電子商務(wù)的蓬勃發(fā)展和海外消費(fèi)者需求的多樣化，促使物流系統(tǒng)的業(yè)務(wù)量增加。

4.威脅（Threats）。

a. 國際貿(mào)易摩擦：頻發(fā)的國際貿(mào)易摩擦，導(dǎo)致物流信息行業(yè)面臨外部不確定性，增加運(yùn)營成本和風(fēng)險。

b. 行業(yè)監(jiān)管加強(qiáng)：國家對物流信息行業(yè)的監(jiān)管不斷加強(qiáng)，對于不規(guī)范運(yùn)營的企業(yè)，可能面臨更嚴(yán)格的處罰和更高的合規(guī)成本。

c. 新商業(yè)模式涌現(xiàn)：新型商業(yè)模式的快速發(fā)展，對智能物流系統(tǒng)提出了更高的要求，增加了行業(yè)的挑戰(zhàn)。

圖片 64 某物流系統(tǒng)產(chǎn)品SWOT分析

4.9 產(chǎn)品設(shè)計整合工具：產(chǎn)品設(shè)計文檔（PRD）模板

五、開發(fā)測試階段工具

5.1 產(chǎn)品評審工具：評審會

為什么B端產(chǎn)品經(jīng)理要重視評審會？

評審會是由產(chǎn)品經(jīng)理主導(dǎo)的，但不是一言堂。在評審會上可以通過澄清需求，確保需求理解一致性、收集開發(fā)測試的反饋、進(jìn)行系統(tǒng)需求的可行性評估。

那么，我們怎么高效地組織評審會呢？

STEP1：明確會議目的。

在組織會議之初，就要明確好一個會議的目標(biāo)和預(yù)期成果是什么。

假設(shè)是倉儲管理系統(tǒng)的收貨模塊需求評審，那么會議的目標(biāo)就是“通過需求評審”，預(yù)期成果是產(chǎn)出“收貨模塊可開發(fā)需求”、“收貨模塊需求優(yōu)先級”、“收貨模塊需求預(yù)計工時”。

STEP2：選擇合適的利益相關(guān)人作為參會者。

根據(jù)會議目標(biāo)，確認(rèn)合適的利益相關(guān)人，協(xié)調(diào)他們的時間，擬定會議時間，發(fā)送會議邀請。

假設(shè)需要組織倉儲管理系統(tǒng)的需求評審，可以邀請此系統(tǒng)的開發(fā)團(tuán)隊、測試團(tuán)隊、用戶體驗團(tuán)隊、業(yè)務(wù)側(cè)代表（倉庫需求對接人，他是這個系統(tǒng)的關(guān)鍵用戶）等參與需求評審，為了減少評審會外的溝通，要盡量選擇他們都可行的時間，一定要確保所有選定的參會人都收到會議邀請。

STEP3：制定會議議程。

在會議議程的制定時，要詳細(xì)地注明每個議題的時間和負(fù)責(zé)人。

例如：

表格 17 某需求評審會議程安排

STEP4：進(jìn)行會前準(zhǔn)備。

a.會前資料分享。

會前一天，提前將需求相關(guān)的文檔和原型附在會議邀請附件，并提醒與會人提前查看并準(zhǔn)備問題。

b.會前檢查。

會議的組織者要提前到場，檢查會議開展的軟硬件條件，避免會議質(zhì)量受到影響。

如果是線下會議，要提前檢查會議室預(yù)定情況（酌情比預(yù)計會議時長多預(yù)定會議室半個小時）、投屏是否正常、座位是否足夠。

如果是線上會議，要提前檢查會議網(wǎng)絡(luò)情況，麥克風(fēng)和攝像頭情況。

如果是線上線下會議，要檢查現(xiàn)場撥入的同事是否閉麥，避免回聲。

STEP5：推進(jìn)會議進(jìn)程

與會簽到:

如果是線下會議，請做好出席的簽到記錄（簽到表），這是會議紀(jì)要的一部分。

如果是線上會議，請檢查會議出席情況，并做好截屏備份。

開場介紹:

產(chǎn)品經(jīng)理清晰地闡明需求背景、本次會議目標(biāo)及預(yù)計產(chǎn)出成果。

需求介紹:

結(jié)合原型及產(chǎn)品設(shè)計文檔，產(chǎn)品經(jīng)理依次進(jìn)行需求的介紹。

鼓勵提問:

為了提升提問質(zhì)量，在提問環(huán)節(jié)要引導(dǎo)提問者，使用“問題-背景-影響-解決方案”（Question-Background-Impact-Solution, QBIS）的結(jié)構(gòu)來提出問題。

例如：“我注意到這個需求可能會影響進(jìn)單性能（問題），因為涉及復(fù)雜的數(shù)據(jù)處理（背景），這可能會導(dǎo)致進(jìn)單時間大幅提升（影響）。我們是否要增加考慮過優(yōu)化數(shù)據(jù)處理流程（解決方案）。

記錄和總結(jié):

記錄：在闡述需求和提問的同時，需要專人記錄問題和建議。

總結(jié)：在會議結(jié)束前，要將記錄下的問題和建議逐條復(fù)述，避免遺漏。

時間控制:

建議單次需求評審時間不要超過一個半小時，給與會人員預(yù)留消化時間，嚴(yán)格按照議程推進(jìn)，避免會議逾期過久。

STEP6：會后行動。

會議紀(jì)要分享:

建議在評審會完成后半天內(nèi)，發(fā)出會議紀(jì)要，評審會的會議紀(jì)要，既要有議程的記錄，又要有決策和行動計劃（例如開發(fā)需要在什么時候反饋工時評估情況）。

表格 18某項目評審會會議紀(jì)要

會議跟進(jìn):

更新PRD：會后要及時根據(jù)反饋，調(diào)整產(chǎn)品設(shè)計文檔（PRD）。

更新需求預(yù)計工時：會后持續(xù)和開發(fā)溝通，確保工時評估（這是迭代的拆分依據(jù)），如有需求預(yù)計交付時間需要大幅調(diào)整，請回復(fù)給用戶。

5.2 需求管理工具：敏捷開發(fā)（Scrum）

為什么B端產(chǎn)品經(jīng)理要重視敏捷開發(fā)？

經(jīng)典的軟件開發(fā)遵循著瀑布模型，推動流程是線性的，不同階段銜接清晰，適用于需要嚴(yán)格規(guī)劃和管控的大型項目（如汽車入廠物流項目），這種開發(fā)模型，有利于進(jìn)行成本預(yù)測和預(yù)算控制，能夠有效避免項目需求范圍的蔓延。

圖片 65瀑布式開發(fā)流程

在實際的系統(tǒng)落地過程中，由于種種局限（開發(fā)資源有限、需求變化大等），我們并不能一次性就完美落實瀑布模型，于是就有了最小可行版本（MVP）的概念。

MVP是一種開發(fā)策略，即用最少的資源快速驗證產(chǎn)品概念，在獲取用戶反饋后，再及時調(diào)整產(chǎn)品方向（這種開發(fā)模式起源于C端產(chǎn)品，在B端產(chǎn)品中也有廣泛應(yīng)用）。落地這個策略的行事規(guī)則，我們可以稱作敏捷開發(fā)框架（Scrum），每一個增量發(fā)布時間段，我們可以稱作迭代沖刺周期（Sprint）。

圖片 66 簡單理解敏捷開發(fā)流程

那么我們怎么進(jìn)行敏捷開發(fā)呢？

STEP1：確定產(chǎn)品愿景

愿景（Vision）是一個組織、一個團(tuán)隊或個人對未來理想狀態(tài)的描述，它回答了“我們想成為什么樣子”。

在制定愿景的時候有以下注意事項：

• 長遠(yuǎn)性：愿景關(guān)注的是長遠(yuǎn)的目標(biāo)，不是短期的結(jié)果，在制定的時候無需加明確的時間范圍。
• 激勵性：愿景能夠激發(fā)人們的熱情和動力，促使個人或團(tuán)體為了目標(biāo)努力。
• 清晰性：愿景應(yīng)該是具體而清晰的，這樣人們才可以認(rèn)同。
• 可實現(xiàn)性：雖然愿景是長遠(yuǎn)的，但它應(yīng)該是可實現(xiàn)的。
• 指導(dǎo)性：愿景要提供一個清晰的方向，幫助人們在面對挑戰(zhàn)時做出決策。

例如，我個人的愿景就是：做大灣區(qū)最好的物流產(chǎn)品經(jīng)理；一套跨境物流管理系統(tǒng)的愿景是：服務(wù)好600w跨境物流賣家。

STEP2：確定Scrum的參與方

a.產(chǎn)品經(jīng)理：負(fù)責(zé)維護(hù)產(chǎn)品待辦列表，代表利益相關(guān)者的利益。

b.Scrum Master：負(fù)責(zé)監(jiān)督Scrum過程的正確實施，組織敏捷開發(fā)相關(guān)會議，這個角色可以由產(chǎn)品經(jīng)理兼任。

c.開發(fā)測試團(tuán)隊：負(fù)責(zé)交付產(chǎn)品增量。

STEP3：準(zhǔn)備系統(tǒng)需求表

在需求分析與產(chǎn)品設(shè)計階段，已經(jīng)分享了很多，可以用于梳理用戶需求的工具，可以將用戶需求轉(zhuǎn)化為系統(tǒng)需求，這里不再重復(fù)。

但是在敏捷開發(fā)的過程中，系統(tǒng)需求需要明確的分類，分類方式可參考下述表格：

圖片 67敏捷開發(fā)系統(tǒng)需求分類表

STEP4：確定迭代沖刺周期（Sprint）

建議選擇1-4周，每個迭代只安排固定Sprint的任務(wù)量，在后續(xù)的發(fā)版中，嚴(yán)格按照這個節(jié)奏執(zhí)行迭代。

STEP5：召開計劃會議和制定開發(fā)計劃

Scrum Master組織召開計劃會議，產(chǎn)品經(jīng)理和開發(fā)測試團(tuán)隊一起確定需求的開發(fā)優(yōu)先級，進(jìn)行工作量預(yù)估，并制定迭代開發(fā)計劃。

STEP6：每日站會

Scrum Master組織每日站會，團(tuán)隊成員分享進(jìn)展和障礙，確保Sprint目標(biāo)的實現(xiàn)。

STEP7：構(gòu)建MVP版本

根據(jù)確定的核心功能，通過一個或者多個Sprint，快速開發(fā)出一個最小化可行產(chǎn)品，以便盡快獲取用戶反饋。

STEP8：由真實用戶測試MVP版本

將MVP版本交付給用戶使用，并收集用戶反饋。

STEP9：持續(xù)推進(jìn)產(chǎn)品迭代

根據(jù)用戶反饋，以Sprint的節(jié)奏，對產(chǎn)品進(jìn)行持續(xù)迭代。

以上，我們就完成了敏捷開發(fā)的簡要介紹。

這個部分只是淺顯地介紹了敏捷開發(fā)，如果想要進(jìn)一步深入學(xué)習(xí)，建議可以看以下書籍：

《敏捷軟件開發(fā)：原則、模式與實踐》

《敏捷開發(fā)的藝術(shù)》

《高效程序員的45個習(xí)慣：敏捷開發(fā)修煉之道》

5.3 補(bǔ)充工具：開發(fā)測試流程

為什么產(chǎn)品經(jīng)理要了解開發(fā)測試流程？

因為產(chǎn)品的交付需要產(chǎn)品團(tuán)隊協(xié)同配合，產(chǎn)品經(jīng)理要熟悉開發(fā)測試成員，在產(chǎn)品落地過程中的分工與任務(wù)，幫助團(tuán)隊成員在不同階段理解需求，貫徹落實產(chǎn)品設(shè)計。

那么在產(chǎn)品交付的過程中，開發(fā)測試人員都要進(jìn)行哪些工作呢？

表格 19系統(tǒng)開發(fā)測試分工

以上，就是B端產(chǎn)品經(jīng)理工具包的第二部分，由于單篇文章字?jǐn)?shù)有限，后續(xù)將持續(xù)更新第三部分-實施運(yùn)維工具，歡迎收藏、評論或轉(zhuǎn)發(fā)給有需求的小伙伴~