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

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

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

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

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

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

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

對(duì)于產(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è)計(jì)綜合三個(gè)階段：

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

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

STEP1：需求分析

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

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

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

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

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

圖片 22人工月臺(tái)分配流程BPMN圖

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

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

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

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

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

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

表格 16 SysML活動(dòng)圖圖例分類

圖片 23 SysML活動(dòng)圖圖例

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

->在活動(dòng)圖里，通過控制流（ControlFlow）和對(duì)象流（ObjectFlow）將動(dòng)作串聯(lián)起來；控制流可以簡(jiǎn)單理解成“告訴讀者步驟如何執(zhí)行”，比如在倉(cāng)儲(chǔ)物流作業(yè)里“檢查裝車清單”和“卸載貨物”，就需要用控制流串聯(lián)，因?yàn)樗鼈冇星昂舐?lián)系。對(duì)象流可以簡(jiǎn)單理解成“告訴讀者（數(shù)據(jù)或物品）是如何在過程中傳遞的”，比如在倉(cāng)儲(chǔ)物流作業(yè)里，貨物從卡車卸下，搬運(yùn)到暫存區(qū)，就需要用對(duì)象流串聯(lián)。

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

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

圖片 24 SysML活動(dòng)圖

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

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

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

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

STEP3：設(shè)計(jì)綜合

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

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

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

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è)計(jì)語言，掌握了UML之后，產(chǎn)品經(jīng)理可以更好地梳理業(yè)務(wù)邏輯，并且更順暢的與開發(fā)溝通。

UML圖有哪些種類呢？

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

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

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

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

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

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

STEP2：以自動(dòng)化倉(cāng)庫的WMS為例，繪制UML組件圖。

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

圖片 28 UML組件圖圖例

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

接著我們來繪制自動(dòng)化倉(cāng)庫WMS的組件圖：

圖片 29自動(dòng)化倉(cāng)庫WMS的UML組件圖

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

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

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

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

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

圖片 30 UML用例圖圖例

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

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

圖片 31 UML用例圖

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

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

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

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

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

圖片 32 UML類圖圖例

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

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

圖片 33 UML類圖

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

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

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

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

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

圖片 34 UML包圖圖例

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

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

圖片 35 UML包圖

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

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

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

STEP2：以訂單為例，繪制UML對(duì)象圖。

首先要了解對(duì)象圖的常見圖例：

圖片 36 UML對(duì)象圖圖例

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

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

圖片 37 UML對(duì)象圖舉例

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

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

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

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

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

圖片 38 UML部署圖圖例

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

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

圖片 39 部署圖舉例

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

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

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

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

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

圖片 40 UML順序圖常見圖例

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

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

圖片 41 UML順序圖舉例

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

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

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

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

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

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

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

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

圖片 42 UML協(xié)作圖

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

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

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

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

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

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

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

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

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

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

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

STEP2：以入庫清點(diǎn)質(zhì)檢場(chǎng)景為例，繪制UML活動(dòng)圖。

首先，我們要了解活動(dòng)圖的圖例：

圖片 45 UML活動(dòng)圖圖例

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

我們以入庫場(chǎng)景為例，繪制UML活動(dòng)圖：

圖片 46 UML活動(dòng)圖舉例

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

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

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

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

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

圖片 47 UML交互概覽圖圖例

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

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

圖片 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ì)量。

那么我們?cè)趺蠢L制BPMN？

以一個(gè)簡(jiǎn)單的人工月臺(tái)分派流程為例：

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

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

圖片 49 BPMN元模型示例

STEP2：梳理繪圖要點(diǎn)。

劃分泳道：在這個(gè)案例中，涉及兩個(gè)角色的操作，為了更清晰地表達(dá)，我們需要?jiǎng)澐謨蓚€(gè)泳道，倉(cāng)庫和司機(jī)。

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

STEP3：開始繪制BPMN圖。

圖片 50 人工月臺(tái)分配流程

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

4.4 功能建模工具：功能樹

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

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

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

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

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

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

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

STEP3：分解子功能。

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

圖片 51 某WMS功能樹

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

4.5 功能建模工具：IDEF0

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

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

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

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

IDEF0模型包括以下幾個(gè)主要元素：

• 功能（Functions）：這些是流程中執(zhí)行的主要活動(dòng)或任務(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)入功能框。

那么我們?cè)趺词褂肐DEF0呢？

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

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

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

STEP2：確定輸入（Input）。

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

a.實(shí)物貨物。

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

c.入庫訂單

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

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

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

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

STEP3：確定輸出（Output）。

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

a.上架后的庫存位置。

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

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

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

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

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

a.倉(cāng)儲(chǔ)管理軟件（WMS）。

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

c.倉(cāng)庫操作工。

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

STEP4：確定控制（Control）。

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

a.倉(cāng)庫操作的標(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)生的，例如輸入中的收貨計(jì)劃作業(yè)單，這是在WMS里完成卸貨操作后，才能輸出的，所以我們要進(jìn)一步拆解子流程，并將相應(yīng)的輸出關(guān)聯(lián)到A-0圖的輸入。

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

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

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

4.5 流程建模工具：泳道圖

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

因?yàn)橛镜缊D貫穿了業(yè)務(wù)需求落地的整個(gè)過程：

在業(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è)計(jì)環(huán)節(jié)，產(chǎn)品經(jīng)理可以通過泳道圖回溯需求要點(diǎn)，避免功能遺漏。

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

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

那么如何繪制泳道圖呢？

我們以某個(gè)出口倉(cāng)庫的出庫流程為例：

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

以出口倉(cāng)庫出庫流程為例：

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

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

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

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

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

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

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

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

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

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

在繪制泳道圖時(shí)，有如下注意事項(xiàng)：

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

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

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

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

4.7 信息建模工具：E-R

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

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

那么怎么繪制E-R圖？

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

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

在下單的過程中，主要的實(shí)體包括：

a.客戶。

b.客戶信息。

c.SKU類型。

d. SKU信息，即商品。

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

f.收貨信息。

g.支付信息。

h.訂單。

STEP2：思考實(shí)體有哪些屬性（Attributes）。

梳理出每個(gè)實(shí)體的屬性：

a.客戶：

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

b.客戶信息：

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

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

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

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

c.SKU類型:

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

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

圖片 57 SKU類型劃分

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

d.SKU信息：

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

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

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

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

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

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

f.收貨信息

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

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

g.支付信息

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

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

h.訂單

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

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

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

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

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

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

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

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

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

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

4.8 決策建模工具：決策樹

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

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

圖片 59決策樹示例

那我們?cè)趺磻?yīng)用決策樹呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

決策節(jié)點(diǎn)說明：

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

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

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

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

決策結(jié)果：

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

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

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

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

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

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

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

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

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

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

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

STEP3：選擇繪圖工具。

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

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

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

STEP4：開始繪制原型圖。

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

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

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

圖片 62某項(xiàng)目原型圖

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

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

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

4.10 競(jìng)品分析工具：競(jìng)品分析報(bào)告

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

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

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

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

明確競(jìng)品分析的目的，比如了解市場(chǎng)趨勢(shì)、評(píng)估競(jìng)爭(zhēng)對(duì)手的優(yōu)勢(shì)和劣勢(shì)、尋找差異化機(jī)會(huì)等。

STEP2：選擇競(jìng)品。

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

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

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

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

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

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

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

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

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

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

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

2.劣勢(shì)（Weaknesses）。

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

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

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

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

4.威脅（Threats）。

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

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

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

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

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

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

5.1 產(chǎn)品評(píng)審工具：評(píng)審會(huì)

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

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

那么，我們?cè)趺锤咝У亟M織評(píng)審會(huì)呢？

STEP1：明確會(huì)議目的。

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

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

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

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

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

STEP3：制定會(huì)議議程。

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

例如：

表格 17 某需求評(píng)審會(huì)議程安排

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

a.會(huì)前資料分享。

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

b.會(huì)前檢查。

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

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

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

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

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

與會(huì)簽到:

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

如果是線上會(huì)議，請(qǐng)檢查會(huì)議出席情況，并做好截屏備份。

開場(chǎng)介紹:

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

需求介紹:

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

鼓勵(lì)提問:

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

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

記錄和總結(jié):

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

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

時(shí)間控制:

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

STEP6：會(huì)后行動(dòng)。

會(huì)議紀(jì)要分享:

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

表格 18某項(xiàng)目評(píng)審會(huì)會(huì)議紀(jì)要

會(huì)議跟進(jìn):

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

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

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

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

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

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

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

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

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

那么我們?cè)趺催M(jìn)行敏捷開發(fā)呢？

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

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

在制定愿景的時(shí)候有以下注意事項(xiàng)：

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

例如，我個(gè)人的愿景就是：做大灣區(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過程的正確實(shí)施，組織敏捷開發(fā)相關(guān)會(huì)議，這個(gè)角色可以由產(chǎn)品經(jīng)理兼任。

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

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

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

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

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

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

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

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

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

STEP6：每日站會(huì)

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

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

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

STEP8：由真實(shí)用戶測(cè)試MVP版本

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

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

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

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

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

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

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

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

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

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

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

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

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

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