在职场上，如果有一些工具能让我们顺手使用，工作效率会高很多。本文作者汇总整理了一份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方法中的一种，可以分成需求分析、系统功能分析和设计综合三个阶段：

1. 需求分析：会将涉众需求转化为系统需求，包括功能性需求和非功能性需求。
2. 系统功能分析：在这个阶段会把系统功能性需求，通过建模语言转化为库可执行的模型，一般可以通过三种SysML图来展现模型的内容（活动图、顺序图、状态机图）。
3. 设计综合：在这个阶段会通过架构分析和架构设计，确定系统的解决方案，并将系统的功能性需求和非功能性需求，分配到系统架构中。

我们以仓储物流环节的车辆到达-分配月台-卸货-驶离月台业务流程为例，详细讲解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包图的绘制之前，先要了解它适用于什么场景。

包图可以帮助进行系统的分析和设计。可以在软件架构设计的高层次系统结构分析时使用。

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端产品经理工具包的第二部分，由于单篇文章字数有限，后续将持续更新第三部分-实施运维工具，欢迎收藏、评论或转发给有需求的小伙伴~