在《产品需求文档完全指南（一）：核心思路》先容了整体设计的目的：
让文档阅读者有整体的观点，能够让他站在更加宏不雅观的视角理解方案。为后续理解详细的功能用例供应铺垫。本篇将紧张讲述整体设计的写作思路和技巧，技巧部分会侧重于先容图形的浸染，但由于篇幅所限不会详细阐述画图的技巧，若读者认为某些部分须要详细，我会考虑出单独的文章帮助大家建立画图技巧。
什么时候该当写整体设计？
虽然不是所有的需求都必须要写整体设计，但我仍建议新手同学在每个需求都考试测验着写，同时如果你的需求只要知足了以下个中一个条件，我会强烈建议一定要写。
一、方案涉及到多个用户角色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 用例图
方向于从用户的角度出发能够实行的动作。当一个功能较大须要不同的角色参与时，从不同角色触发的用例图可以让阅读者知道这里包含了一定的「权限」范围，以及不同的角色须要处理的事情详细是什么。
以上就说关于整体设计的部分，这个系列的第三篇文章将会为大家先容关于《产品需求文档：需求详情》的写作技巧。
如果你有疑问请直接打在评论区，别忘了收藏加关注！
本文由 @秀明 原创发布于大家都是产品经理。未经容许，禁止转载。
题图来自Unsplash，基于CC0协议。
该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事。
