在第一篇指南中，我们介绍了产品需求文档的核心思路。这篇文章，我们来看看其整体设计部分，需要关注那些问题。

在《产品需求文档完整指南（一）：核心思路》介绍了整体设计的目的：

• 让文档阅读者有整体的概念，能够让他站在更加宏观的视角理解方案。
• 为后续理解具体的功能用例提供铺垫。

本篇将主要讲述整体设计的写作思路和技巧，技巧部分会偏重于介绍图形的作用，但由于篇幅所限不会详细阐述画图的技巧，若读者认为某些部分需要详细，我会考虑出单独的文章帮助大家建立画图技巧。

什么时候应该写整体设计？

虽然不是所有的需求都必须要写整体设计，但我仍建议新手同学在每个需求都尝试着写，同时如果你的需求只要满足了以下其中一个条件，我会强烈建议一定要写。

• 涉及多个业务角色
• 横跨多个系统领域
• 涉及到了新的单据流

一、方案涉及到多个用户角色

1.1 条件

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

一个角色（从权限管理角度是代表某一类具有相同职能的统称）能够被涉及到某个功能/流程，说明这个角色在流程中需要进行操作/决策，因此在跨角色的项目中，需要让不同角色明确自己在功能中的位置，前后的流程，以及自己到底要在这个流程中做什么，同时也让产研侧明确业务场景。

1.2 推荐的表达方式

泳道流程图：一种展示业务流程或工作流程的图表，表示不同的业务部门或参与者（不同系统等），以及它们之间的交互和流程。会涉及到纵向和横向两个维度，两个维度分别表示的是角色和流程阶段，至于是纵向表示角色还是横向表示角色依据个人喜好即可，与时序图相比，强调角色执行的动作/逻辑判断，弱化时间顺序/系统间交互。

1.3 泳道图实例

申请报销流程

二、横跨多个系统/领域

2.1 条件

• 单个系统的多个模块（例如订单履约系统中订单、库存、商品等）
• 多个系统（例如订单履约系统和仓库管理系统）

2.2 推荐的表达方式

无论是什么样的表达方式，尽量使用图+文字说明的方式，让阅读者更容易理解。

2.2.1 实体关系图

表明不同领域之间的关系，是1:1还是1：N还是N：1，能清晰画出模块间关系需要一定的垂直业务沉淀和领域抽象能力。

（产品画到示例这个程度即可，更详细可以了解ERD图）

垂直业务沉淀：这属于知识层面的经验能力，只要去学就能学得到。例如我们要打造账号体系中的母子账号，母账号有超级管理权限，子账号可以被母账号分配权限，一个母账号可以关联多个子账号。那么母账号和子账号的关系就是1:N。同时还要考虑，1个子账号是否能对应多个母账号，业务层面有没有这样的需求，如果有就是N:N。

领域抽象能力：抽象能力不属于知识，是一种技能，要靠悟性和大量训练。最核心的是要有给领域下定义的能力。例如我们在做会员管理的时候，需要拆分账号和商家两个细分领域，就要给账号和商家下定义。

• 定义账号：账号是主要管授权登录用的，能不能被登录验证通过，就是账号领域的事情；包括如果想做第三方登录（如微信登录），这个只和账号体系打通就可以，跟商家领域就没有关系。
• 定义商家：商家则关系到很多业务能力，例如结算方式是先款后货，还是账期。

与此同时，账号和商家又要有绑定关系，商家和账号（母子账号）的关系是1：N。

再举一个例子，说明一下抽象定义的重要性：我们先看四个词，黑马、白马、河马、盒马，针对这个四个词我们应该怎么分类呢？

若定义一个类为：名字中带马的词，那他们都可以归为一类；若定义一个类为：按动物科属划分，白马黑马属于马科，河马属于河马科，盒马是超市不是动物。

不同的关系在产品设计上意味着什么?

• 领域A与领域B的关系为1:1，这是关系中最简单的，无论从A到B还是从B到A都能找到唯一值。
• 领域A与领域B的关系为1:N，从领域A触发的时候要有决策的逻辑找到领域B中的某个值。
• 领域A与领域B的关系为N:1，从领域A触发任一值都能找到唯一，反之则不是。
• 领域A与领域B的关系为N:N，不管从A到B还是从B到A都需要有决策的逻辑，这是关系中最复杂的，若能避免一定要尽量避免，避免不了一定要做好决策逻辑。

梳理清楚关系为什么那么重要？

• 能加强/外显对业务的理解： 领域的关系图能确保软件系统能够准确地反映业务逻辑，当你能够精准的画出领域关系说明这个整体是真的搞懂了，基本上这个关系上在了解清楚业务需求后瞬间形成的，如果你需要冥思苦想，说明功夫还不到家。
• 系统的可维护性： 更容易维护和更新，因为变更可以更精准地在领域模型中进行反映，能够有效的避免不同系统和模块间的撕逼，帮助划清产品边界。
• 模块化和扩展性： 不同领域之间清晰的边界和关系使得系统更容易进行模块化设计，同时也更容易扩展。这是高阶产品经理的必备能力，当你重构过几个系统以后才知道模块化和拓展性到底有多重要。
• 有助于团队协作： 帮助不同团队成员更好地理解系统的整体结构和各个部分之间的协作方式。如果你是系统负责人或某个项目的主产品，这个图能够很好的帮助各个领域的产品理解自己的逻辑，同时也能有效的帮助研发、测试无歧义的理解需求。

2.2.2 时序图

时序图：描述不同领域/对象之间的交互与通信。

• 谁在什么时候请求了谁的接口，返回是什么？
• 一个动作中包含了哪些业务层面的不可缺少的服务调用，否则就从头开始？
• 是同步返回还是异步返回等？

主体可以是不同系统，可以是同一个系统的不同模块，也可以是同一个系统的前端、后端（针对前后端分离的系统）。

大多数情况下时序图是研发侧在做技术设计时才会用到的，产品所画的时序图其实是没有办法真实体现技术的实现细节，但我认为他有其他图像不可比拟作用：与泳道流程图相比弱化了逻辑判断关系，但是强调了时间顺序，尤其在多个接口调用的先后以及表达同步异步关系上。

在复杂的B端系统中，产品经理一定要清楚以下情况，这些情况可能会限制功能设计。

• 不同接口的作用
• 大流程上接口调用的顺序
• 同步/异步的接口消息响应

举一个物流行业对接第三方物流服务商时经常碰到的场景：我们系统给第三方物流下单（可以理解为申请运单号）时，第三方物流系统同步返回的只有接口响应的成功/失败，这个成功/失败结果只代表了对方接收到了你的信息，只是通过了接口层面的一些基础校验逻辑，实际的能否真正的通过校验，拿到实际的运单号还未可知。

为什么会这样？第三方的物流系统可能是因为内部系统过于复杂不能同步返回，也可以他们也依赖了别人的系统。

因此第三方系统会在一段时间之后通过Webhook等方式回调给我方，告诉我们实际的结果。

• 成功：返回运单号
• 失败：返回报错信息

这样一个比较简单的系统交互，用时序图+文字表示就再好不过：

三、方案涉及到了状态机

3.1 条件

当一个方案需要新增/修改状态机，一般来讲改动都较大。

以我在电商供应链的工作经历中，状态机一般是和单据流同时出现的，之所以有单据流是因为要持续一段时间追踪某一件事，这件事会不停的变更状态来反映当前的事实。例如销售订单会记录「新建」、「待支付」、「已支付」、「待发货」、「已发货」、「取消」等状态。

当然状态机其实也广泛用于各种领域，软硬件结合的比如自动零食售卖机，纯软件的比如网路游戏中。

3.2 推荐的表达方式

我们常用的状态机叫做有限状态机。

有限状态机（Finite State Machine，简称FSM）是一种数学模型和计算机科学中的概念，用于描述系统的行为。它由一组状态、一组转移规则和一个初始状态组成。有限状态机可以处于这些状态之一，并根据输入执行状态转移。

状态机描述的是活动中状态的变化，突出的是「动作」引发「状态」变更，这对产品经理能力有3个要求：

• 关于动作(action)：要明确知道谁在什么时候触发的动作是什么
• 关于状态(status)：要有明确的预期动作后的状态结果是什么
• 关于整体：一个单据流的状态掌握绝不仅仅是只针对自己修改的部分，关键状态的变更有可能是牵一发而动全身，因此产品要掌握整体的状态变化，才可以产出一个高质量的状态机。

（产品经理掌握确定性的「有限状态机」即可，此类的状态个数是可穷举的，且动作引发的条件是可枚举的。）

（简单的状态机）

3.3 有限状态机实例

以「电商的销售订单支付状态」简单展示下状态机如何画如何表述。

在这种流程中一般会建议加上开始和终止，尤其终止表示了某个状态为终态，终态是不可以再变更的。

以上三种情况是我遇到的比较常见的需要写整体设计的场景，还有三种看个人风格是否愿意写出来：

四、复杂功能的本质说明：

为了进一步明确表达我需求的核心诉求，往往我会把最核心的东西写出来，比如我在描述ERP系统库存上报模式的时候会给一个核心定义，然后再解释不同模式。

五、多个方案的选用记录

有时候一个问题可以有种模式和方案构成，我习惯于将不同的方案全部罗列出来，甚至标记出优劣势，最后再给出结论，这样做的好处是：

• 强化自己的思考：真正想清楚到底应该用什么方案。
• 用来说服别人：当你的老板、业务方、研测试同事看到你的优劣势对比时，他会能知道你是技能是专业的、态度是积极的从而更容易获取信任。
• 告知以后读文档的人：为什么“不得不”做出的「最符合当时情况的决策」。

例如我做订单拆单时：

六、功能地图：脑图/用例图

脑图和用例图均是为了有层次的表述全盘的功能点。脑图会更加站在全局的角度描述功能构成，而用例图则是以某一个用户的角度来描述此用户需要使用的功能，同时由于用例图不同线段也能代表不同关系，因此用例图的表述会更加的丰富。

例如，我们的功能是一个后台的订单管理功能，用脑图和用例图分别表示如下。

6.1 脑图

倾向于结构性的罗列出此次功能所包含的所有要点，阅读的人一目了然的知道本次功能不同层级的功能是什么。

6.2 用例图

倾向于从用户的角度出发能够执行的动作。当一个功能较大需要不同的角色介入时，从不同角色触发的用例图可以让阅读者知道这里包含了一定的「权限」范围，以及不同的角色需要处理的事情具体是什么。

以上就说关于整体设计的部分，这个系列的第三篇文章将会为大家介绍关于《产品需求文档：需求详情》的写作技巧。

如果你有疑问请直接打在评论区，别忘了收藏加关注！