在第一篇指南中，我们介绍了产品需求文档的核心思路。这篇文章，我们来看看其整体设计部分，需要关注那些问题。
在《产品需求文档完整指南（一）：核心思路》介绍了整体设计的目的：
本篇将主要讲述整体设计的写作思路和技巧，技巧部分会偏重于介绍图形的作用，但由于篇幅所限不会详细阐述画图的技巧，若读者认为某些部分需要详细，我会考虑出单独的文章帮助大家建立画图技巧。
什么时候应该写整体设计？
虽然不是所有的需求都必须要写整体设计，但我仍建议新手同学在每个需求都尝试着写，同时如果你的需求只要满足了以下其中一个条件，我会强烈建议一定要写。
方案涉及到多个使用角色：例如一个流程中涉及了用户A和用户B
一个角色（从权限管理角度是代表某一类具有相同职能的统称）能够被涉及到某个功能/流程，说明这个角色在流程中需要进行操作/决策，因此在跨角色的项目中，需要让不同角色明确自己在功能中的位置，前后的流程，以及自己到底要在这个流程中做什么，同时也让产研侧明确业务场景。
泳道流程图：一种展示业务流程或工作流程的图表，表示不同的业务部门或参与者（不同系统等），以及它们之间的交互和流程。会涉及到纵向和横向两个维度，两个维度分别表示的是角色和流程阶段，至于是纵向表示角色还是横向表示角色依据个人喜好即可，与时序图相比，强调角色执行的动作/逻辑判断，弱化时间顺序/系统间交互。
申请报销流程
无论是什么样的表达方式，尽量使用图+文字说明的方式，让阅读者更容易理解。
2.2.1 实体关系图
表明不同领域之间的关系，是1:1还是1：N还是N：1，能清晰画出模块间关系需要一定的垂直业务沉淀和领域抽象能力。
（产品画到示例这个程度即可，更详细可以了解ERD图）
垂直业务沉淀：这属于知识层面的经验能力，只要去学就能学得到。例如我们要打造账号体系中的母子账号，母账号有超级管理权限，子账号可以被母账号分配权限，一个母账号可以关联多个子账号。那么母账号和子账号的关系就是1:N。同时还要考虑，1个子账号是否能对应多个母账号，业务层面有没有这样的需求，如果有就是N:N。
领域抽象能力：抽象能力不属于知识，是一种技能，要靠悟性和大量训练。最核心的是要有给领域下定义的能力。例如我们在做会员管理的时候，需要拆分账号和商家两个细分领域，就要给账号和商家下定义。
与此同时，账号和商家又要有绑定关系，商家和账号（母子账号）的关系是1：N。
再举一个例子，说明一下抽象定义的重要性：我们先看四个词，黑马、白马、河马、盒马，针对这个四个词我们应该怎么分类呢？
若定义一个类为：名字中带马的词，那他们都可以归为一类；若定义一个类为：按动物科属划分，白马黑马属于马科，河马属于河马科，盒马是超市不是动物。
不同的关系在产品设计上意味着什么?
梳理清楚关系为什么那么重要？
2.2.2 时序图
时序图：描述不同领域/对象之间的交互与通信。
主体可以是不同系统，可以是同一个系统的不同模块，也可以是同一个系统的前端、后端（针对前后端分离的系统）。
大多数情况下时序图是研发侧在做技术设计时才会用到的，产品所画的时序图其实是没有办法真实体现技术的实现细节，但我认为他有其他图像不可比拟作用：与泳道流程图相比弱化了逻辑判断关系，但是强调了时间顺序，尤其在多个接口调用的先后以及表达同步异步关系上。
在复杂的B端系统中，产品经理一定要清楚以下情况，这些情况可能会限制功能设计。
举一个物流行业对接第三方物流服务商时经常碰到的场景：我们系统给第三方物流下单（可以理解为申请运单号）时，第三方物流系统同步返回的只有接口响应的成功/失败，这个成功/失败结果只代表了对方接收到了你的信息，只是通过了接口层面的一些基础校验逻辑，实际的能否真正的通过校验，拿到实际的运单号还未可知。
为什么会这样？第三方的物流系统可能是因为内部系统过于复杂不能同步返回，也可以他们也依赖了别人的系统。
因此第三方系统会在一段时间之后通过Webhook等方式回调给我方，告诉我们实际的结果。
这样一个比较简单的系统交互，用时序图+文字表示就再好不过：
当一个方案需要新增/修改状态机，一般来讲改动都较大。
以我在电商供应链的工作经历中，状态机一般是和单据流同时出现的，之所以有单据流是因为要持续一段时间追踪某一件事，这件事会不停的变更状态来反映当前的事实。例如销售订单会记录「新建」、「待支付」、「已支付」、「待发货」、「已发货」、「取消」等状态。
当然状态机其实也广泛用于各种领域，软硬件结合的比如自动零食售卖机，纯软件的比如网路游戏中。
我们常用的状态机叫做有限状态机。
有限状态机（Finite State Machine，简称FSM）是一种数学模型和计算机科学中的概念，用于描述系统的行为。它由一组状态、一组转移规则和一个初始状态组成。有限状态机可以处于这些状态之一，并根据输入执行状态转移。
状态机描述的是活动中状态的变化，突出的是「动作」引发「状态」变更，这对产品经理能力有3个要求：
（产品经理掌握确定性的「有限状态机」即可，此类的状态个数是可穷举的，且动作引发的条件是可枚举的。）
（简单的状态机）
以「电商的销售订单支付状态」简单展示下状态机如何画如何表述。
在这种流程中一般会建议加上开始和终止，尤其终止表示了某个状态为终态，终态是不可以再变更的。
以上三种情况是我遇到的比较常见的需要写整体设计的场景，还有三种看个人风格是否愿意写出来：
为了进一步明确表达我需求的核心诉求，往往我会把最核心的东西写出来，比如我在描述ERP系统库存上报模式的时候会给一个核心定义，然后再解释不同模式。
有时候一个问题可以有种模式和方案构成，我习惯于将不同的方案全部罗列出来，甚至标记出优劣势，最后再给出结论，这样做的好处是：
例如我做订单拆单时：
脑图和用例图均是为了有层次的表述全盘的功能点。脑图会更加站在全局的角度描述功能构成，而用例图则是以某一个用户的角度来描述此用户需要使用的功能，同时由于用例图不同线段也能代表不同关系，因此用例图的表述会更加的丰富。
例如，我们的功能是一个后台的订单管理功能，用脑图和用例图分别表示如下。
倾向于结构性的罗列出此次功能所包含的所有要点，阅读的人一目了然的知道本次功能不同层级的功能是什么。
倾向于从用户的角度出发能够执行的动作。当一个功能较大需要不同的角色介入时，从不同角色触发的用例图可以让阅读者知道这里包含了一定的「权限」范围，以及不同的角色需要处理的事情具体是什么。
以上就说关于整体设计的部分，这个系列的第三篇文章将会为大家介绍关于《产品需求文档：需求详情》的写作技巧。
如果你有疑问请直接打在评论区，别忘了收藏加关注！
本文由 @秀明 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。