起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識5W字講透 | 初階B端產品經理工具包（中）| 產品設計及開發測試階段工具
在職場上，如果有一些工具能讓我們順手使用，工作效率會高很多。本文作者匯總整理了一份B端產品的工具包，并以案例穿插其中，可以幫助大家更好掌握文中列舉的這些工具。
這篇推文僅包含前4、5節哦，由于單篇文章字數不宜過長，分為上、中、下三篇更新后續章節，歡迎收藏、評論或轉發給有需求的小伙伴~
四、產品設計工具
4.1 建模方法：MBSE （Model-Based Systems Engineering）
為什么B端產品經理要了解MBSE（Model-Based Systems Engineering）？
系統工程國際委員會（INCOSE）給MBSE的定義是：“從概念設計階段開始，并持續貫穿開發和后續生命周期階段，支持系統需求、設計、分析、驗證和確認活動的（模型）正規化應用”。簡單理解，就是用標準的模型語言替代自然語言，應用特定的方法論和工具，實現系統工程。
在MBSE出現之前，廣泛應用的是基于文檔的系統工程DBSE（Document-based Systems Engineering），即以諸多文檔貫穿需求到落地（如需求文檔、產品設計文檔等），其中雖然有少量插圖，但是主體還是文字，受制于文字的表達能力，不同工程師在理解同一段信息時，可能會產生不同的理解，從而無法保障需求收集、需求分析、產品設計、開發測試的一致性[3]。
對于產品經理來說，MBSE能夠有效地幫助我們，改善不同利益相關者的溝通，確保溝通的標準統一和準確，從源頭提升產品交付的質量。
那么B端產品經理怎么使用MBSE呢？
B端產品經理，可以了解Harmony SE ( Harmony for Systems Engineer-ing)。
圖片 21 Harmony diagram of Rational integrated system development process
它是MBSE方法中的一種，可以分成需求分析、系統功能分析和設計綜合三個階段：
- 需求分析：會將涉眾需求轉化為系統需求，包括功能性需求和非功能性需求。
- 系統功能分析：在這個階段會把系統功能性需求，通過建模語言轉化為庫可執行的模型，一般可以通過三種SysML圖來展現模型的內容（活動圖、順序圖、狀態機圖）。
- 設計綜合：在這個階段會通過架構分析和架構設計，確定系統的解決方案，并將系統的功能性需求和非功能性需求，分配到系統架構中。
我們以倉儲物流環節的車輛到達-分配月臺-卸貨-駛離月臺業務流程為例，詳細講解MBSE如何應用：
STEP1：需求分析
首先在進行需求分析之前，首先要明確在這個場景中的利益相關者都有哪些：
在這個業務場景下，利益相關者有倉庫和司機，具體執行人，倉庫下有門衛和裝卸操作工。
接著，通過現場調研，收集利益相關者在這個業務場景下的所有需求。
在這個業務流程中，可以使用BPMN來串聯業務流程，避免業務需求遺漏，繪制細節詳見“4.4建模語言：BPMN”章節。
在司機到達倉庫后，需要先到門衛簽到，接著門衛會通過監控查看月臺閑置情況，確定卸貨月臺之后通過手動寫紙條遞交給司機，司機開車到卸貨月臺，下車把裝貨清單給操作工，操作工開始卸貨清點，完成卸貨之后操作工在裝貨清單上簽字，復印裝貨清單，把復印件交給司機，司機拿到后，開車駛離月臺。
圖片 22人工月臺分配流程BPMN圖
通過上面的BPMN圖，我們就大致明晰在月臺分派環節，我們需要線上化的信息和流程有哪些了。
然后，梳理出系統需求概述：
- 司機提前通過電話完成預約，倉庫客服錄入倉庫管理系統。
- 司機到達倉庫后，根據提前預約信息，倉庫門禁可以自動抬桿。
- 系統根據當前月臺閑置情況，根據卸貨月臺優先級，進行推薦，推薦結果展示在倉庫門口的大屏。
- 司機查看大屏，將車開到指定的月臺處，此要有RFID設備校驗是否開到指定位置，如果開到指定位置，則修改月臺占用狀態到已占用；如果開錯月臺，則再根據月臺類型判斷是否能夠繼續卸貨，如果可以，則修改月臺狀態到已占用，如果不行，則通過大屏提示司機挪車。
- 操作工根據庫內大屏提示，到指定月臺開始卸貨，用WMS（倉儲管理系統）的PDA進行卸貨掃描，卸貨完成后，由PDA觸發自動打印卸貨清單，操作工根據卸貨清單信息對比司機提供的裝車單，完成簽字。
- 操作工復印簽字后的裝車單，遞交給司機，并且通過PDA提交裝車單照片，完成歸檔。
- 司機駛離月臺，RFID設備識別車輛離場狀態，修改月臺狀態到空閑。
STEP2：系統功能分析
利用SysML圖來展現模型的內容（活動圖、順序圖、狀態機圖）。
首先，我們來繪制活動圖中的頂級函數圖，在繪制之前，我們要了解基礎的圖例。
表格 16 SysML活動圖圖例分類
圖片 23 SysML活動圖圖例
->拆分系統需求中的最小動作，每個動作有輸入（輸入栓）和輸出（輸出栓）
->在活動圖里，通過控制流（ControlFlow）和對象流（ObjectFlow）將動作串聯起來；控制流可以簡單理解成“告訴讀者步驟如何執行”，比如在倉儲物流作業里“檢查裝車清單”和“卸載貨物”，就需要用控制流串聯，因為它們有前后聯系。對象流可以簡單理解成“告訴讀者（數據或物品）是如何在過程中傳遞的”，比如在倉儲物流作業里，貨物從卡車卸下，搬運到暫存區，就需要用對象流串聯。
->在控制流或對象流中傳遞的數據稱為“令牌”（token）
根據圖例及需求繪制出活動圖：
圖片 24 SysML活動圖
接著，我們繪制這個需求的狀態機圖：
圖片 25 SysML狀態機圖
然后，我們繪制這個需求的順序圖（序列圖）：
圖片 26 SysML順序圖（序列圖）
STEP3：設計綜合
在完成了系統功能分析之后，接著要進行架構分析和架構設計。
圖片 27 WMS架構圖舉例
以上，我們就在MBSE的指導下，完成了一個簡單的場景分析。
4.2 建模語言：UML（Unified Modeling Language）
SysML和UML圖有什么區別？
UML圖服務于軟件工程，SysML圖服務于系統工程，后者拓展了UML圖，可以支持軟件外的硬件、信息、人員、過程和設備的系統建模。
為什么B端產品經理要了解UML？
UML是一種面向對象的思考方式，是開發的通用設計語言，掌握了UML之后，產品經理可以更好地梳理業務邏輯，并且更順暢的與開發溝通。
UML圖有哪些種類呢？
截至UML2.0，產品經常用到的，一共有13種圖形，分為靜態圖和動態圖
- 靜態圖有7種：組件圖、用例圖、類圖、包圖、對象圖、部署圖、復核結構圖。
- 動態圖有6種：順序圖、協作圖、狀態機圖、活動圖、定時圖、交互概觀圖。
下面我們依次分享產品經常用到的圖：
靜態圖1：UML-組件圖：
STEP1：在進行UML組件圖的繪制之前，先要了解它適用于什么場景。
組件圖展示了系統的物理架構，包含組件及相互關系，可以用于系統分析、接口設計。
STEP2：以自動化倉庫的WMS為例，繪制UML組件圖。
首先我們要了解UML組件圖常見圖例：
圖片 28 UML組件圖圖例
- 組件：用來表示系統中的一個物理或邏輯單元。
- 組件包：用來組織和分組組件。
- 接口：表示組件提供或需要的接口。
- 組件間依賴關系：表示一個組件依賴于另一個組件提供接口。
- 節點：用來表示運行組件的物理節點，如服務器或工作站。
接著我們來繪制自動化倉庫WMS的組件圖：
圖片 29自動化倉庫WMS的UML組件圖
靜態圖2：UML-用例圖：
STEP1：在進行UML用例圖的繪制之前，先要了解它適用于什么場景。
用例圖是一種描述系統功能需求和系統交互的圖形化工具，適用于需求分析、功能分析和測試驗證階段。
STEP2：以WMS維護基礎數據場景為例，繪制UML用例圖。
首先我們要了解用例圖常見圖例：
圖片 30 UML用例圖圖例
- 角色：代表與系統交互的用戶、系統或其他實體。
- 用例：描述系統可以執行的特定功能或與用戶或系統交互的場景。
- 關聯：表示一條簡單的實線，連接用例和角色，表示二者的交互關系。
- 容器：用于組織和分組相關用例和角色。
接著我們來繪制用例圖，這里以WMS維護基礎數據場景為例：
圖片 31 UML用例圖
靜態圖3：UML-類圖：
STEP1：在進行UML類圖的繪制之前，先要了解它適用于什么場景。
類圖幫助定義了系統的結構，包括類、接口、屬性、方法和他們的關系。適用于系統架構規劃和需求分析場景。
STEP2：以上架后庫存變動業務場景為例，繪制UML類圖。
在我們進行UML類圖的繪制前，首先要了解類圖常見圖例。
圖片 32 UML類圖圖例
- 類：普通類可以用一個矩形表示，垂直分為三個部分；頂部是類名，中間是屬性，底部是操作或方法，其他類都是在普通類基礎上拓展的。
- 接口：表示為一個帶有“<< 接口>>”標記的矩形。
- 枚舉：是一種特殊的數據類型，它表示為一組固定的常量值。
- 約束：用來指定模型元素之間的關系或模型元素屬性的限制條件。
- 三元關聯：服務于三個類相互關聯的復雜場景。
- 端口：端口定義了組件與其他組件或系統環境之間的交互點。
接著我們來繪制UML類圖，這里以上架后的WMS庫存變動為例：
圖片 33 UML類圖
靜態圖4：UML-包圖：
STEP1：在進行UML包圖的繪制之前，先要了解它適用于什么場景。
包圖可以幫助進行系統的分析和設計?？梢栽谲浖軜嬙O計的高層次系統結構分析時使用。
STEP2：以簡單的倉庫管理系統為例，繪制UML包圖。
在繪制包圖之前，我們需要了解包圖的常見圖例：
圖片 34 UML包圖圖例
- 包：用來組織和封裝類、接口、協作以及子包等元素。包的名稱通常寫在矩形的頂部，內部可以包含其他包、類、接口。
- 類：普通類可以用一個矩形表示，垂直分為三個部分；頂部是類名，中間是屬性，底部是操作或方法，其他類都是在普通類基礎上拓展的。
- 接口：表示為一個帶有“<< 接口>>”標記的矩形。
- 依賴關系：表示為一條帶箭頭的虛線，箭頭指向依賴的元素，表示一個元素依賴于另一個元素。
- 泛化關系：表示為一條帶空心箭頭的實線，箭頭指向父元素，表示繼承關系。
- 實現關系：表示為一條帶空心箭頭的虛線，箭頭指向接口，表示類實現了該接口。
- 關聯關系：表示為一條實線，連接兩個類，表示類之間的結構性關系。
- 聚合關系：表示為一條帶有空心菱形的實線，菱形靠近聚合的一方，表示整體與部分的關系。
- 組合關系：表示為一條帶有實心菱形的實線，菱形靠近組合的一方，表示更強烈的整體與部分的關系，部分不能獨立于整體存在。
- 導入：一個包使用另一個包的元素。
接著，我們以簡單的倉庫管理系統為例，繪制包圖：
圖片 35 UML包圖
靜態圖5：UML-對象圖：
STEP1：在進行UML對象圖的繪制之前，先要了解它適用于什么場景。
UML適用于分析復雜系統，可以幫助理解系統中各個對象如何相互作用，可以在數據庫設計時展示數據庫表之間的關系。
STEP2：以訂單為例，繪制UML對象圖。
首先要了解對象圖的常見圖例：
圖片 36 UML對象圖圖例
- 對象：表示為矩形，頂部寫對象名，底部寫對象的屬性值。
- 鏈接：表示對象之間的關系，通常用實線連接兩個對象。
- 消息：表示對象間的通信，用帶箭頭的直線表示，箭頭指向接收消息的對象。
- 依賴關系：表示為一條帶箭頭的虛線，箭頭指向依賴的元素，表示一個元素依賴于另一個元素。
- 泛化關系：表示為一條帶空心箭頭的實線，箭頭指向父元素，表示繼承關系。
- 實現關系：表示為一條帶空心箭頭的虛線，箭頭指向接口，表示類實現了該接口。
- 關聯關系：表示為一條實線，連接兩個類，表示類之間的結構性關系。
- 聚合關系：表示為一條帶有空心菱形的實線，菱形靠近聚合的一方，表示整體與部分的關系。
- 組合關系：表示為一條帶有實心菱形的實線，菱形靠近組合的一方，表示更強烈的整體與部分的關系，部分不能獨立于整體存在。
接著我們以訂單為例，進行對象圖的繪制舉例：
圖片 37 UML對象圖舉例
靜態圖6：UML-部署圖：
STEP1：在進行UML部署圖的繪制之前，先要了解它適用于什么場景。
部署圖用于展示系統的物理架構，包括硬件、節點以及他們之間的通信。適用于系統架構設計。
STEP2：以倉儲管理系統為例，繪制UML部署圖。
首先我們要了解部署圖的常見圖例：
圖片 38 UML部署圖圖例
- 組件：表示系統中的一個邏輯單元，可以是一個類、服務、庫或者其他可替換的軟件單元。
- 節點：表示物理的或虛擬的計算資源，如服務器、手機等。
- 對象：實例化的組件或者節點，代表運行時的一個具體實體。
- 約束：表示部署圖中元素的特定限制或規則，用于說明如何部署或配置系統。
- 部署規范：表示部署的具體說明或要求，可能涉及技術標準、配置參數或性能指標。
- 部署關系：表示組件間的關系。
- 通信路徑：表示節點之間或節點與組件間的通信鏈接，可能是網絡連接、消息傳遞或其他通信機制。
我們以倉儲管理系統為例，進行部署圖的繪制：
圖片 39 部署圖舉例
動態圖1：UML-順序圖：
STEP1：在進行UML順序圖的繪制之前，先要了解它適用于什么場景。
順序圖用于描述系統中對象之間的交互過程，可以用于需求分析、系統設計階段。我們在MBSE章節提到過SYSML順序圖，SYSML順序圖是UML順序圖的拓展，會包含額外的元素，例如需求鏈接和參數，兩者在基礎理念上是相似的。
STEP2：我們仍以月臺管理業務場景為例，繪制UML順序圖。
首先我們要了解順序圖的常見圖例：
圖片 40 UML順序圖常見圖例
- 對象：在順序圖中，對象通常用矩形表示，內部可能包含對象的名稱和類名。對象代表參與交互的實體。
- 生命線：從對象矩形向下延伸的虛線，表示對象在交互過程中的存在和活躍時間。
- 同步消息：用實線箭頭表示，表示發送者發送消息給接收者，并等待接收者處理完畢。消息的發送和接收是同步進行的。
- 異步消息：用虛線箭頭表示，表示發送者發送消息后可以繼續執行，不需要等待接收者處理完畢。消息的發送和接收是異步的。
- 返回消息：用虛線箭頭指向發送者，表示方法調用的返回，通常在同步消息之后出現。
- 激活條：在生命線上的矩形條，表示對象在執行操作或等待消息時的激活狀態。激活條的存在表示對象在這段時間內是忙碌的。
- 自消息：箭頭指向同一對象，表示對象調用自己的操作或方法。
- 銷毀消息：用一個帶有“X”標記的生命線末端來表示，表示對象的生命周期結束，對象將被銷毀。
- 實體：在順序圖中，實體通常指的是具有持久狀態的對象，如數據庫中的記錄。它們可能用帶有下劃線的對象名稱來表示。
- 控制：控制對象在順序圖中可能指的是負責協調和控制流程的對象，如控制器或管理器。
- 綁定：在順序圖中，綁定可能指的是對象之間的關聯關系，通常用于表示對象如何相互引用或調用。
- 時間信號：時間信號在順序圖中用來表示在特定時間點發生的消息或事件，通常用帶有時間標記的箭頭表示。
- 約束：約束在順序圖中用來表示對消息或對象行為的限制條件，通常用大括號括起來的文本表示。
- 刪除：表示對象的生命周期結束，對象將被銷毀。
我們以月臺管理業務為例，進行順序圖的繪制：
圖片 41 UML順序圖舉例
動態圖2：UML-協作圖：
STEP1：在進行UML協作圖的繪制之前，先要了解它適用于什么場景。
UML協作圖用于闡述不同對象之間的交互方式，可以用于系統設計、需求分析階段。
STEP2：以倉庫管理系統入庫業務場景為例，繪制UML協作圖。
首先我們要了解協作圖的圖例：
圖片 42 UML協作圖圖例
- 角色：角色通常用來表示系統的外部用戶或者外部系統，它們與系統交互但不擁有系統內部的狀態。在UML協作圖中，角色通常用一個人形圖標或者帶有下劃線的矩形框來表示。
- 對象：對象是系統中的具體實例，它們擁有自己的狀態和行為。在UML協作圖中，對象通常用一個矩形框來表示，框內可以包含對象的名稱。
- 生命線：生命線表示對象在交互過程中的存在時間。它是從對象符號向下延伸的垂直虛線，用來表示對象在交互過程中的活動時間段。
- 同步消息：同步消息表示一個對象向另一個對象發送消息，并等待消息被處理完成。在UML協作圖中，同步消息用實線箭頭表示，箭頭指向接收消息的對象。
- 異步消息：異步消息表示一個對象向另一個對象發送消息，但不需要等待消息被處理完成。在UML協作圖中，異步消息用虛線箭頭表示，箭頭指向接收消息的對象。
- 自關聯：自關聯表示對象與自身交互，即對象內部的一個部分向另一個部分發送消息。在UML協作圖中，自關聯用一個從對象指向自身的帶箭頭的線表示。
- 激活條：激活條表示對象在某個時間段內執行操作。它是附著在對象生命線上的一個窄條，用來表示對象在這段時間內是活躍的。
- 組合：組合表示一種強擁有關系，即一個對象是另一個對象的一部分，而且部分對象不能獨立于整體對象存在。在UML協作圖中，組合用一條帶有實心菱形的直線表示。
- 聚合：聚合表示一種弱擁有關系，即一個對象是另一個對象的一部分，但部分對象可以獨立于整體對象存在。在UML協作圖中，聚合用一條帶有空心菱形的直線表示。
我們以倉庫管理系統的入庫場景為例，繪制UML協作圖：
圖片 42 UML協作圖
動態圖3：UML-狀態機圖：
STEP1：在進行UML狀態機圖的繪制之前，先要了解它適用于什么場景。
狀態機圖描述了一個對象在其生命周期內歷經的所有狀態及轉換，可以用于需求分析與系統設計階段。
STEP2：以倉庫管理系統的入庫訂單為例，繪制UML狀態機圖。
首先，我們要了解協作圖的圖例：
圖片 43 UML狀態機圖
- 狀態：狀態是對象在某個時間點的特定情況或條件，在這段時間內，對象滿足某些條件或執行某些活動。狀態通常用圓角矩形表示。
- 初始狀態：初始狀態是對象開始時所處的狀態。在UML狀態機圖中，初始狀態用一個帶實心黑點的圓表示，這個圓與開始狀態的邊相連。
- 終止狀態：終止狀態是對象生命周期結束時的狀態。在UML狀態機圖中，終止狀態用一個帶實心黑圓的圓表示。
- 轉換：轉換是從一個狀態到另一個狀態的變化。它由一條帶箭頭的線表示，箭頭從當前狀態指向新狀態。轉換通常伴隨著一個觸發事件和（可選的）動作。
- 守衛條件：守衛條件是轉換發生前必須滿足的條件。它是一個布爾表達式，只有當這個表達式為真時，轉換才會發生。守衛條件通常寫在轉換旁邊，用方括號表示。
- 同步條：同步條也稱為復合轉換，用于表示多個狀態同時結束和開始。它用一條粗橫線表示，橫跨多個狀態，表示這些狀態將同時結束，并觸發新的轉換。
我們以倉庫管理系統的入庫訂單為例，繪制UML狀態機圖：
動態圖44：UML-狀態機圖：
STEP1：在進行UML活動圖的繪制之前，先要了解它適用于什么場景。
UML活動圖是一種用于描述系統中一個對象或者多個對象的動態行為圖形化工具，適用于業務流程建模、需求分析、多線程程序設計。
STEP2：以入庫清點質檢場景為例，繪制UML活動圖。
首先，我們要了解活動圖的圖例：
圖片 45 UML活動圖圖例
- 活動狀態：活動狀態表示在狀態機中的一個活動或操作，通常用來描述在特定狀態下執行的動作。在狀態機圖中，活動狀態通常用帶有名稱的圓角矩形表示。
- 開始節點：開始節點是狀態機的起點，通常用一個實心圓點表示，并且有一個箭頭指向初始狀態。
- 結束節點：結束節點表示狀態機的結束，通常用一個帶有實心圓的圓圈表示，表示狀態機在此節點達到最終狀態。
- 控制流：控制流表示狀態之間的轉換路徑，通常用帶箭頭的直線表示，箭頭從當前狀態指向下一個狀態。
- 決策節點：決策節點表示基于特定條件的決策點，通常用菱形表示。流程會根據條件的真假分支到不同的狀態。
- 分支：分支是從決策節點出發的多個路徑，每個路徑對應一個條件的結果。在狀態機圖中，分支通常用從決策節點出發的多條帶箭頭的直線表示。
- 泳道：泳道用于將狀態機圖分割成不同的部分，每個部分代表不同的角色或執行環境。泳道通常用垂直或水平的分隔線表示，每個泳道內包含一系列狀態和轉換。
- 同步條：同步條用于表示多個并行路徑的同步點，即多個分支在某個點上需要等待彼此完成才能繼續執行。在狀態機圖中，同步條通常用一條粗橫線表示，橫跨多個路徑。
我們以入庫場景為例，繪制UML活動圖：
圖片 46 UML活動圖舉例
動態圖5：UML-交互概觀圖：
STEP1：在進行UML交互概觀圖的繪制之前，先要了解它適用于什么場景。
交互概覽圖是一種展示系統交互的高級抽象試圖，它忽略了消息和生命線，適合展示業務流程的控制流概覽；適用于需求分析和系統設計。
STEP2：以倉儲管理系統為例，繪制UML交互概觀圖。
首先我們要了解UML交互概覽圖的常規圖例：
圖片 47 UML交互概覽圖圖例
- 組合片段：用于表示一個特定的交互片段，可以包含順序圖、通信圖、交互概覽圖或時間圖。引用現有的交互圖，顯示為一個引用框，左上角顯示 “ref”。
- 決策點：用于表示流程中的分支點，類似于活動圖中的決策節點。
- 初始狀態：表示流程的開始，通常用實心圓點表示。
- 終止狀態：表示流程的結束，通常用帶實心圓的圓圈表示。
- 控制流：表示流程中的控制流向，用帶箭頭的直線表示。
以入庫流程為例，繪制交互概覽圖：
圖片 48 UML交互概覽圖圖例
以上，我們就完成了產品經理常用的幾種UML圖介紹。
4.3 建模語言：BPMN（Business Process Model and Notation）
為什么B端產品經理要了解BPMN？
BPMN用圖形化的方式表示業務流程，使流程更加易懂，這有助于產品經理更好地表達業務結構和邏輯，能有效改善和開發的溝通質量。
那么我們怎么繪制BPMN？
以一個簡單的人工月臺分派流程為例：
在司機到達倉庫后，需要先到門衛簽到，接著門衛會通過監控查看月臺閑置情況，確定卸貨月臺之后通過手動寫紙條遞交給司機，司機開車到卸貨月臺，下車把裝貨清單給操作工，操作工開始卸貨清點，完成卸貨之后操作工在裝貨清單上簽字，復印裝貨清單，把復印件交給司機，司機拿到后，開車駛離月臺。
STEP1：首先我們需要了解BPMN的元模型。
圖片 49 BPMN元模型示例
STEP2：梳理繪圖要點。
劃分泳道：在這個案例中，涉及兩個角色的操作，為了更清晰地表達，我們需要劃分兩個泳道，倉庫和司機。
確認數據對象：在這個案例中，涉及卸貨月臺信息和裝貨清單兩種信息的流轉。
STEP3：開始繪制BPMN圖。
圖片 50 人工月臺分配流程
通過上面的BPMN圖，我們就大致明晰在進行物流全面的信息化時，在月臺分派環節，我們需要線上化的信息和流程有哪些了。
4.4 功能建模工具：功能樹
B端產品經理為什么要了解功能樹？
功能樹（Function Tree）是一種通過層次結構展示產品功能的工具，能夠幫助產品經理設計產品。
怎么在產品設計中應用功能樹？
STEP1：明確產品目標。
確定產品的主要目標，繪制功能樹的頂點。
STEP2：構建頂層功能。
根據產品目標和用戶需求，定義產品的頂層功能。
STEP3：分解子功能。
將頂層功能分解成更具體的子功能，這些子功能支持頂層功能的實現。
圖片 51 某WMS功能樹
以上，我們就完成了功能樹的設計。
4.5 功能建模工具：IDEF0
為什么產品經理需要了解IDEF0？
IDEF0通過自頂向下、逐層分解的方式構造系統的功能模型，幫助我們逐層拆解系統的關系。
對于一個新需求或新系統，這個工具能夠進行功能建模；在拆解一個成熟的競品系統時，這個工具可以分析系統的工作機制。
IDEF0包含哪些內容？
IDEF0模型包括以下幾個主要元素：
- 功能（Functions）：這些是流程中執行的主要活動或任務，通常在圖表中用矩形框表示。
- 輸入（Inputs）：這些是執行功能所需的資源或數據，用箭頭表示，從左側進入功能框。
- 輸出（Outputs）：這些是功能執行后產生的結果或產品，用箭頭表示，從功能框的右側離開。
- 控制（Controls）：這些是管理功能執行的規則、規章或約束，用箭頭表示，從頂部進入功能框。
- 機制（Mechanisms）：這些是執行功能所需的資源、工具或人員，用箭頭表示，從底部進入功能框。
那么我們怎么使用IDEF0呢？
我們以倉庫“普貨入庫業務流程”展開A-0圖為例：
STEP1：確定展開的功能（Function）。
選用普貨入庫業務流程，這個流程包含著卸貨、收貨、上架三個子步驟。
STEP2：確定輸入（Input）。
輸入是執行流程需要的資源或者信息，對于我們選用的入庫功能，輸入大致包括：
a.實物貨物。
b.貨物的詳細信息（生產日期、尺寸、重量、貨物質量等），這些有的通過目視化獲取、有些通過測量得到。
c.入庫訂單
d.卸貨計劃作業單。
e.收貨計劃作業單。
f.上架計劃作業單。
這些是完成入庫流程所必須的。
STEP3：確定輸出（Output）。
輸出是流程執行后產生的結果，對于貨物入庫流程，輸出大致包括：
a.上架后的庫存位置。
b.WMS打印出的入庫確認單。
c.庫存管理中增補的庫存信息。
這些是完成入庫流程后產生的。
STEP3：確定機制（Mechanism）。
機制是完成功能所需的工具或資源，在我們進行入庫流程時，機制大致包含：
a.倉儲管理軟件（WMS）。
b.叉車或AGV或線體等搬運設備。
c.倉庫操作工。
上述機制是執行入庫流程必須的。
STEP4：確定控制（Control）。
控制是影響功能執行的條件或規則，在我們進行入庫流程時，控制大致包含：
a.倉庫操作的標準操作程序（SOP）。
b.貨物接收和存放的安全規定。
c.貨物管理的法規和政策。
這些控制因素，保障了入庫業務流程按照既定的規則和標準運行。
STEP5：完成繪圖
圖片 52普貨入庫業務流程A-0圖
以上，我們完成了以“普貨入庫業務流程”展開A-0圖的操作。
仔細觀察上述輸入、輸出、機制、控制的因素，我們不難發現，有些是由子流程產生的，例如輸入中的收貨計劃作業單，這是在WMS里完成卸貨操作后，才能輸出的，所以我們要進一步拆解子流程，并將相應的輸出關聯到A-0圖的輸入。
對于一個復雜的系統或業務，要逐層拆解很多層的IDEF0圖，才能完整的解釋工作機制，這里以INCOSE完整流程圖為例：
圖片 53 Process Flow Block Diagram-base on INCOSE Systems Engineering Handbook v.4.0
但是在實際的工作中，我們應用A-0圖梳理自己的思路即可。
4.5 流程建模工具：泳道圖
為什么產品經理熟練應用泳道圖？
因為泳道圖貫穿了業務需求落地的整個過程：
在業務需求確認環節，產品經理可以繪制泳道圖，描述系統服務的業務流程，與業務方完成關鍵系統功能的需求確認。
在產品設計環節，產品經理可以通過泳道圖回溯需求要點，避免功能遺漏。
在需求評審環節，產品經理可以通過泳道圖為開發、測試同事解釋業務背景及功能概要，便于技術側理解業務與需求。
在產品實施環節，產品經理可以通過泳道圖串聯操作手冊，幫助培訓用戶。
那么如何繪制泳道圖呢？
我們以某個出口倉庫的出庫流程為例：
STEP1：在繪制泳道圖之前，需要先搞清楚，我們設計的系統，服務于什么樣的業務鏈條？
以出口倉庫出庫流程為例：
圖片 54出口業務中，WMS服務的業務流程
梳理完上述鏈條之后，我們就明白了在整個出口業務中，出口倉庫WMS所服務的流程是什么。
STEP2：接著需要搞清楚，出庫流程需要哪些系統的什么功能支撐，會和哪些系統有交互，需要人工怎么操作串聯：
圖片 55出庫業務簡要流程
這樣，我們就畫出了出庫業務的簡要流程，知道了在出庫業務中數據的大致流向。
STEP3：接著我們繼續思考，在出庫流程中，是否需要倉庫外部的協作？
我們不難發現，在掃描裝箱前，需要有空集裝箱運輸到倉庫，提空箱的操作是由車隊完成的，那么我們在繪制泳道圖的時候，就需要納入車隊。
以此類推，我們就可以完善泳道圖的所有相關方。
STEP4：最后，我們將作業細節完善，就可以繪制出服務于出口倉庫的出庫業務泳道圖：
圖片 56 某項目出庫業務流程圖示例
在繪制泳道圖時，有如下注意事項：
1.規范圖例：要應用標準的泳道圖圖例。
2.減少箭頭交叉：盡量避免泳道之間的箭頭交叉，如果不可避免，使用清晰的標記或顏色區分。
3.泳道劃分：要確保每個泳道對應的任務和責任是清晰明確的。
4.流程命名規則：流程的命名應使用動詞+名詞的動賓短語進行描述，以確保流程的清晰和一致性。
4.7 信息建模工具：E-R
為什么B端產品經理要了解E-R圖？
E-R圖是產品經理對業務進行深入分析后，從業務流程和表象中抽象出的實體；它可以幫助開發人員傳達系統的主要實體及其關系，讓開發人員準確理解需求。
那么怎么繪制E-R圖？
我們以某服裝品牌官網下單流程案例舉例：
STEP1：思考在下單流程中，存在著哪些實體（Entities）。
在下單的過程中，主要的實體包括：
a.客戶。
b.客戶信息。
c.SKU類型。
d. SKU信息，即商品。
e.官網購物車。
f.收貨信息。
g.支付信息。
h.訂單。
STEP2：思考實體有哪些屬性（Attributes）。
梳理出每個實體的屬性：
a.客戶：
客戶是下單流程的主導者。
b.客戶信息：
客戶信息記錄著客戶的所有信息，需要記錄客戶的基礎信息，如客戶編碼、手機號、昵稱、密碼、郵箱。
此外，為了保障拓展性，為后續的會員系統做鋪墊，官網的客戶信息還要記錄客戶會員號、客戶生日、客戶積分。
最后，為了數據版本記錄，需要記錄客戶信息更新時間。
這樣，我們就總結出了客戶信息所需字段：客戶編碼、手機號、昵稱、密碼、郵箱、客戶會員號、客戶生日、客戶積分、客戶信息更新時間。
c.SKU類型:
在本例中，SKU類型為服裝，業務要求，客戶在進行購物時，必須要先選擇品類（普拉提/瑜伽/舞蹈），點擊到商品面板后，一定需要能選擇不同的顏色，切換到不同的商品效果圖。（這里先不考慮需求合理性，僅為示例）
基于這個需求，在進行SKU類型的設計時，需要考慮商品類型需要分級，例如，一級商品類型標識這個商品大類，例如普拉提服裝；二級商品類型標識到某款商品（包含著不同顏色、不同尺碼的該款商品）。然后根據顏色劃分不同的SKU編碼，最后，在SKU信息屬性中用尺寸字段記錄尺碼信息。
圖片 57 SKU類型劃分
這樣，我們就總結出了SKU類型所需字段：商品編碼類型、商品類型名稱、商品類型層級。
d.SKU信息：
在本例中，這個品牌有多個電商渠道，所以需要在推送渠道庫存時，需要分渠道拆分推送，避免庫存同步不及時，導致超賣。
基于這個需求，除了基礎信息，在進行SKU信息設計時，需要考慮此渠道庫存和總庫存，此外，為了滿足SKU基礎的上下架需求，需要考慮上架時間、下架時間、和上架狀態標識。
這樣，我們就總結出了SKU信息所需字段：SKU編碼、SKU名稱、單價、尺寸、SKU類型、此渠道庫存、總庫存、上架時間、下架時間、上架狀態。
e.官網購物車
在本例中，一個客戶可以將多個商品、多個數量加入購物車。
基于這個需求，我們可以梳理出官網購物車所需字段：購物車編碼、客戶編碼、加購時間、SKU編碼、數量。
f.收貨信息
在本例中，一個客戶可以有多個收貨信息，在下單時任選其一。
基于這個需求，我們可以梳理出收貨信息所需字段：收貨信息編碼、收貨省份、收貨城市、收貨街道、聯系人、聯系手機號、客戶編碼。
g.支付信息
在本例中，一個訂單只可以由一個客戶支付一次。
基于這個需求，我們可以梳理出支付信息所需字段：支付編碼、訂單編碼、支付方式、支付時間、客戶編碼、支付狀態。
h.訂單
基于以上的分析，訂單所需字段有：訂單編碼、客戶編碼、下單時間、SKU編碼、數量、單價、訂單狀態、支付狀態、收貨信息編碼。
STEP3：思考實體之間的關系（Relationships）
- 客戶與訂單：一對多關系，一個客戶可以有多個訂單，可以通過客戶編碼關聯。
- 客戶與收貨信息：一對多關系，一個客戶可以有多個收貨信息，可以通過客戶編碼關聯。
- 客戶與SKU類型：間接的多對多關系，一個客戶可以檢索多個SKU類型信息，一個SKU類型信息可以被多個用戶檢索到。
- 客戶與官網購物車：一對一關系，一個客戶唯一對應一個官網購物車，可以通過客戶編碼關聯。
- 客戶與支付信息：一對多關系，一個客戶可以創建多個支付信息，可以通過客戶編碼關聯。
- 官網購物車與SKU信息：多對多關系，一個官網購物車可以包含多個SKU信息，一個SKU可以被多個官網購物車包含，可以通過SKU編碼關聯。
- SKU類型與SKU信息：一對多關系，一個SKU類型可以包含多個SKU信息，可以通過SKU編碼關聯。
- 訂單與支付信息：一對一關系，一個訂單唯一對應一個支付信息，可以通過訂單編碼關聯。
- 收貨信息與訂單：多對一關系，一個收貨地址可以被多個訂單使用，但一個訂單包含一個收貨地址，可以通過收貨信息編碼關聯。
- 訂單與SKU信息：多對多關系，一個訂單包含多個SKU信息，一個SKU可以被多個訂單使用，可以通過SKU信息關聯。
- 客戶信息與客戶：一對一關系，每個客戶有且僅有一個客戶信息。
STEP4：利用繪圖軟件（Visio、Process on等）開始畫圖
1.畫出實體：客戶、客戶信息、SKU、SKU類型、官網購物車、訂單、支付信息、地址信息。
2.畫出屬性：將每個屬性繪制為橢圓形，并將其連線到所屬的實體。
3.畫出關系：將每個關系繪制為菱形，并將其連線到相關的實體。
4.添加主鍵：在每個實體中，選取一個屬性作為主鍵，并在矩形內用下劃線標記出來。
圖片 58某官網下單流程E-R圖
這樣我們就完成了一張E-R圖的繪制。
4.8 決策建模工具：決策樹
為什么B端產品經理要了解決策樹？
B端產品經常會涉及復雜的決策問題，決策樹能幫助產品經理處理非線性的關系和交互，為解決這種問題提供一種直觀的方法。
圖片 59決策樹示例
那我們怎么應用決策樹呢？
以某業務提出的自動補貨需求為例：
某企業計劃部門，向信息技術部門提出了一個新需求，希望每天凌晨2點，根據SKU的庫存水平、供應商的歷史交貨時間、市場需求變化，自動生成補貨單。
STEP1:獲取到這個需求后，首先產品經理要識別到，這個需求是模糊的，要和業務方追問決策標準。
在本案例中，需要和業務方確定如下決策標準：
1.觸發庫存水平低補貨的閾值是多少？系統怎么獲悉？
2.怎么衡量供應商交貨時間長短？閾值是多少？
3.怎么衡量市場需求變化？系統怎么獲悉市場變化？
STEP2:假設經過幾輪磋商，產品引導業務方有了如下需求反饋：
1.觸發庫存水平低的閾值每個SKU都不一樣，系統可以將SKU主數據中維護的安全庫存作為閾值，低于安全庫存則觸發低庫存補貨；高于安全庫存則根據市場需求補貨。
2.供應商歷史交貨時間（供應商歷史采購訂單獲批，到對應貨物入庫的間隔），大于兩周則視為長交貨時間。此外，只有在低庫存補貨時需要考慮供應商交貨時間問題。
3.市場需求包含季節性變化和促銷活動。系統可以根據SKU類型區分受季節影響明顯的貨物，業務會給出高季節性的SKU類型清單。另外參加大促的SKU，也需要提前補貨，業務部門會給出所有大促SKU清單，大促的優先級要比季節性高，有促銷就不考慮季節性變化。
STEP3:需求已經有了大致輪廓，產品經理可以嘗試畫出決策樹：
在決策樹中，我們用矩形代表決策節點；用橢圓形代表機會節點；用三角形代表機會節點。
圖片 60 補貨案例決策樹
決策節點說明：
決策點1.系統可以將SKU主數據中維護的安全庫存作為閾值，低于安全庫存觸發低庫存補貨，高于安全庫存，觸發市場需求補貨。
決策點4.增補數據表及功能頁面，記錄業務手動上傳目前參加促銷活動的所有SKU清單，這里判斷SKU是否在此清單就好。
決策點5.計算供應商歷史交貨時間（計算公式：采購入庫時間-采購訂單獲批時間），大于兩周則視為長交貨時間。
決策點10. 增補數據表及功能頁面，記錄業務手動上傳所有高季節性的SKU類型；這里判斷SKU對應的SKU類型是否在此清單就好。
決策結果：
關于補貨量A、B、C、D、E的具體值，需要向業務追問，由業務磋商后反饋。
以上，我們就完成了一個復雜決策問題的建模與落地設計。
4.9 產品設計集合工具：原型圖
產品經理為什么要熟練使用原型圖？
原型圖是產品和產品相關人（客戶、用戶、設計師、開發、測試等）溝通需求和設計想法的工具，可以幫助團隊成員理解產品的結構和功能。
那么產品經理怎么繪制原型圖？
STEP1：確定目標和需求。
在前面的章節，我們已經用了很大的篇幅介紹該怎么收集需求、分析需求、進行功能建模，在繪制原型圖之前，一定要明確每個功能頁面的目標用戶和使用場景。
STEP2：進行草圖設計和構思。
在這一步中，需要用紙筆繪制出原型草圖，去構思界面布局和流程，確定好頁面結構。
這一步驟不用將時間浪費在美化草圖上，只要能夠精準地表達訴求就好。
STEP3：選擇繪圖工具。
在常見的繪圖工具中，選擇順手的裝備，請注意，如果你所在的產品團隊已經有了常用的工具，請延續團隊的選擇，避免不互通。
以下是主流原型工具的優劣點：
圖片 61 原型工具優劣勢
STEP4：開始繪制原型圖。
根據草圖和框架，把內容和元素放在頁面上。
調整布局，注意對齊、對比、重復和強調（一個頁面只有一個突出按鈕），提高頁面的整潔度和視覺一致性。
進行交互設計，引導用戶參與，增加點擊、滑動、頁面切換等。
圖片 62某項目原型圖
STEP5：增補注釋和說明。
在每個功能按鈕、涉及邏輯處增補注釋和說明，便于開發和測試理解需求；補充交互邏輯。
以上，我們就完成了原型圖的分步驟介紹；如果不知道如何上手，建議從模仿優秀競品頁面開始，熟悉工具。
4.10 競品分析工具：競品分析報告
B端產品經理為什么要熟悉競品分析報告？
競品分析報告，能夠幫助產品經理了解自身產品在市場中的位置，及與競爭對手相比的劣勢和優勢，提前準備相應的應對策略。
如何應用競品分析？
STEP1：確定競品分析的目標。
明確競品分析的目的，比如了解市場趨勢、評估競爭對手的優勢和劣勢、尋找差異化機會等。
STEP2：選擇競品。
根據產品特性、目標市場和客戶群體，選擇直接和間接的競爭對手。
STEP3：收集數據。
利用多種渠道，收集競品的產品信息，包含目標客群、產品功能、定價策略、市場定位、用戶反饋、訂購流程、適用價格、定制化人天開發費用、實施費用、運維費用、增值服務等。
圖片 63某產品競品分析圖舉例
STEP4：利用戰略規劃工具SWOT進行分析，尋找產品切入點：
以某物流系統產品為例：
1.優勢（Strengths）。
a. 引入了最新技術：通過技術創新，如物聯網、大數據、云計算等技術的應用，實現了物流過程的智能化、自動化和可視化，提高了物流效率和降低了成本。
b. 政策支持：國家層面出臺了一系列政策和法律法規，為物流信息行業提供了良好的宏觀市場環境。
c. 順應綠色環保趨勢：物流行業趨向綠色化、低碳化發展，本系統實現了全流程碳足跡計算
d. 集成了多種物流設備：物流系統通過自動化設備和技術，實現了物流運輸過程的高效、快速、安全、精準，同時降低了物流成本。
2.劣勢（Weaknesses）。
a.服務價格下滑：物流系統產品競爭激烈，同質化競爭現象嚴重，導致服務價格下滑，增加了運營壓力。
3.機會（Opportunities）。
a. “一帶一路”倡議：為物流系統行業提供了參與國際競爭和合作的平臺，拓寬了發展路徑。
b.跨境市場需求增長：跨境電子商務的蓬勃發展和海外消費者需求的多樣化，促使物流系統的業務量增加。
4.威脅（Threats）。
a. 國際貿易摩擦：頻發的國際貿易摩擦，導致物流信息行業面臨外部不確定性，增加運營成本和風險。
b. 行業監管加強：國家對物流信息行業的監管不斷加強，對于不規范運營的企業，可能面臨更嚴格的處罰和更高的合規成本。
c. 新商業模式涌現：新型商業模式的快速發展，對智能物流系統提出了更高的要求，增加了行業的挑戰。
圖片 64 某物流系統產品SWOT分析
4.9 產品設計整合工具：產品設計文檔（PRD）模板
五、開發測試階段工具
5.1 產品評審工具：評審會
為什么B端產品經理要重視評審會？
評審會是由產品經理主導的，但不是一言堂。在評審會上可以通過澄清需求，確保需求理解一致性、收集開發測試的反饋、進行系統需求的可行性評估。
那么，我們怎么高效地組織評審會呢？
STEP1：明確會議目的。
在組織會議之初，就要明確好一個會議的目標和預期成果是什么。
假設是倉儲管理系統的收貨模塊需求評審，那么會議的目標就是“通過需求評審”，預期成果是產出“收貨模塊可開發需求”、“收貨模塊需求優先級”、“收貨模塊需求預計工時”。
STEP2：選擇合適的利益相關人作為參會者。
根據會議目標，確認合適的利益相關人，協調他們的時間，擬定會議時間，發送會議邀請。
假設需要組織倉儲管理系統的需求評審，可以邀請此系統的開發團隊、測試團隊、用戶體驗團隊、業務側代表（倉庫需求對接人，他是這個系統的關鍵用戶）等參與需求評審，為了減少評審會外的溝通，要盡量選擇他們都可行的時間，一定要確保所有選定的參會人都收到會議邀請。
STEP3：制定會議議程。
在會議議程的制定時，要詳細地注明每個議題的時間和負責人。
例如：
表格 17 某需求評審會議程安排
STEP4：進行會前準備。
a.會前資料分享。
會前一天，提前將需求相關的文檔和原型附在會議邀請附件，并提醒與會人提前查看并準備問題。
b.會前檢查。
會議的組織者要提前到場，檢查會議開展的軟硬件條件，避免會議質量受到影響。
如果是線下會議，要提前檢查會議室預定情況（酌情比預計會議時長多預定會議室半個小時）、投屏是否正常、座位是否足夠。
如果是線上會議，要提前檢查會議網絡情況，麥克風和攝像頭情況。
如果是線上線下會議，要檢查現場撥入的同事是否閉麥，避免回聲。
STEP5：推進會議進程
與會簽到:
如果是線下會議，請做好出席的簽到記錄（簽到表），這是會議紀要的一部分。
如果是線上會議，請檢查會議出席情況，并做好截屏備份。
開場介紹:
產品經理清晰地闡明需求背景、本次會議目標及預計產出成果。
需求介紹:
結合原型及產品設計文檔，產品經理依次進行需求的介紹。
鼓勵提問:
為了提升提問質量，在提問環節要引導提問者，使用“問題-背景-影響-解決方案”（Question-Background-Impact-Solution, QBIS）的結構來提出問題。
例如：“我注意到這個需求可能會影響進單性能（問題），因為涉及復雜的數據處理（背景），這可能會導致進單時間大幅提升（影響）。我們是否要增加考慮過優化數據處理流程（解決方案）。
記錄和總結:
記錄：在闡述需求和提問的同時，需要專人記錄問題和建議。
總結：在會議結束前，要將記錄下的問題和建議逐條復述，避免遺漏。
時間控制:
建議單次需求評審時間不要超過一個半小時，給與會人員預留消化時間，嚴格按照議程推進，避免會議逾期過久。
STEP6：會后行動。
會議紀要分享:
建議在評審會完成后半天內，發出會議紀要，評審會的會議紀要，既要有議程的記錄，又要有決策和行動計劃（例如開發需要在什么時候反饋工時評估情況）。
表格 18某項目評審會會議紀要
會議跟進:
更新PRD：會后要及時根據反饋，調整產品設計文檔（PRD）。
更新需求預計工時：會后持續和開發溝通，確保工時評估（這是迭代的拆分依據），如有需求預計交付時間需要大幅調整，請回復給用戶。
5.2 需求管理工具：敏捷開發（Scrum）
為什么B端產品經理要重視敏捷開發？
經典的軟件開發遵循著瀑布模型，推動流程是線性的，不同階段銜接清晰，適用于需要嚴格規劃和管控的大型項目（如汽車入廠物流項目），這種開發模型，有利于進行成本預測和預算控制，能夠有效避免項目需求范圍的蔓延。
圖片 65瀑布式開發流程
在實際的系統落地過程中，由于種種局限（開發資源有限、需求變化大等），我們并不能一次性就完美落實瀑布模型，于是就有了最小可行版本（MVP）的概念。
MVP是一種開發策略，即用最少的資源快速驗證產品概念，在獲取用戶反饋后，再及時調整產品方向（這種開發模式起源于C端產品，在B端產品中也有廣泛應用）。落地這個策略的行事規則，我們可以稱作敏捷開發框架（Scrum），每一個增量發布時間段，我們可以稱作迭代沖刺周期（Sprint）。
圖片 66 簡單理解敏捷開發流程
那么我們怎么進行敏捷開發呢？
STEP1：確定產品愿景
愿景（Vision）是一個組織、一個團隊或個人對未來理想狀態的描述，它回答了“我們想成為什么樣子”。
在制定愿景的時候有以下注意事項：
- 長遠性：愿景關注的是長遠的目標，不是短期的結果，在制定的時候無需加明確的時間范圍。
- 激勵性：愿景能夠激發人們的熱情和動力，促使個人或團體為了目標努力。
- 清晰性：愿景應該是具體而清晰的，這樣人們才可以認同。
- 可實現性：雖然愿景是長遠的，但它應該是可實現的。
- 指導性：愿景要提供一個清晰的方向，幫助人們在面對挑戰時做出決策。
例如，我個人的愿景就是：做大灣區最好的物流產品經理；一套跨境物流管理系統的愿景是：服務好600w跨境物流賣家。
STEP2：確定Scrum的參與方
a.產品經理：負責維護產品待辦列表，代表利益相關者的利益。
b.Scrum Master：負責監督Scrum過程的正確實施，組織敏捷開發相關會議，這個角色可以由產品經理兼任。
c.開發測試團隊：負責交付產品增量。
STEP3：準備系統需求表
在需求分析與產品設計階段，已經分享了很多，可以用于梳理用戶需求的工具，可以將用戶需求轉化為系統需求，這里不再重復。
但是在敏捷開發的過程中，系統需求需要明確的分類，分類方式可參考下述表格：
圖片 67敏捷開發系統需求分類表
STEP4：確定迭代沖刺周期（Sprint）
建議選擇1-4周，每個迭代只安排固定Sprint的任務量，在后續的發版中，嚴格按照這個節奏執行迭代。
STEP5：召開計劃會議和制定開發計劃
Scrum Master組織召開計劃會議，產品經理和開發測試團隊一起確定需求的開發優先級，進行工作量預估，并制定迭代開發計劃。
STEP6：每日站會
Scrum Master組織每日站會，團隊成員分享進展和障礙，確保Sprint目標的實現。
STEP7：構建MVP版本
根據確定的核心功能，通過一個或者多個Sprint，快速開發出一個最小化可行產品，以便盡快獲取用戶反饋。
STEP8：由真實用戶測試MVP版本
將MVP版本交付給用戶使用，并收集用戶反饋。
STEP9：持續推進產品迭代
根據用戶反饋，以Sprint的節奏，對產品進行持續迭代。
以上，我們就完成了敏捷開發的簡要介紹。
這個部分只是淺顯地介紹了敏捷開發，如果想要進一步深入學習，建議可以看以下書籍：
《敏捷軟件開發：原則、模式與實踐》
《敏捷開發的藝術》
《高效程序員的45個習慣：敏捷開發修煉之道》
5.3 補充工具：開發測試流程
為什么產品經理要了解開發測試流程？
因為產品的交付需要產品團隊協同配合，產品經理要熟悉開發測試成員，在產品落地過程中的分工與任務，幫助團隊成員在不同階段理解需求，貫徹落實產品設計。
那么在產品交付的過程中，開發測試人員都要進行哪些工作呢？
表格 19系統開發測試分工
以上，就是B端產品經理工具包的第二部分，由于單篇文章字數有限，后續將持續更新第三部分-實施運維工具，歡迎收藏、評論或轉發給有需求的小伙伴~
作者：再次擁抱富婆，公眾號：富婆物流系統筆記
本文由 @再次擁抱富婆 原創發布于人人都是產品經理。未經作者許可，禁止轉載
題圖來自Unsplash，基于CC0協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務
- 目前還沒評論，等你發揮！
