下面这篇文章是笔者以一家真实公司真实业务（关键内容脱敏）为背景，介绍如何在产品规划完成的情况下，快速出原型图的相关内容，大家一起往下看了解更多关于修订记录与全局说明的内容吧！

这一系列文章我会以一家真实公司真实业务（关键内容脱敏）为背景，介绍如何在产品规划完成的情况下，快速出原型图。之所以要用真实的公司和业务，是因为这样才会有更多的细节可以给大家解释，而不是泛泛的画一些标准的操作流程。很多时候，产品设计的不好就是因为挖掘需求的时候没有挖掘到关键细节导致流程断点、功能缺失等从而导致用户体验差。

本文大纲

这次先向大家介绍一下产品原型模板中的修订记录与全局说明。它们在文档中的位置：

• 修订记录：文档的修订历史，方便以后备查文档的各个版本更改了哪些内容。
• 全局说明：整份文档的整体说明，主要包含背景、术语定义、规范说明。

一、修订记录

1. 是什么

在发布产品文档时，需要在修订记录中增加本次发布与之前发布内容的关键差异点，以后备查、复盘会用到。

• 发布产品文档时记录：一般是每次公开、正式发布文档时，需要添加一条修订记录，比如向产品组正式提交需求评审或需求评审有条件通过的更改稿。除此之外，日常工作中对文档的修改、产品小组内部讨论后的调整等都可以不记录，不然就太杂太细，失去焦点了。
• 记录的是关键差异点，并不是所有的细枝末节都记录在这里。关键差异点包括什么可以看下面的解释。

2. 为什么

1. 记录产品发布轨迹。一般这个信息会在周期性复盘（如季度、半年）时收集使用，发布产品的轨迹是如何支撑业务发展的，这个优先级安排有没有问题等。
2. 备忘备查。这次发布如果涉及到对之前已发布的关键要素内容的调整，需要添加说明，这是为了避免扯皮。比如线上系统出现了功能冲突，我们就需要查产品原型文档，发现V2.0对V1.3的部分要素做了调整，但是研发没有完全落实，测试也没测试到。

修订记录在文档中一般长这样：

• 版本号：这里记录的是文档的修订版本号，而不是产品的版本号。在一个产品版本中，产品原型文档可能会发布好几次，比如需求评审提交多次修改多次。版本号的编码规则不同公司不一样，按公司的产品版本规划（迭代计划）来定义就行。这是更高一层的产品规划方面要考虑的问题，跟产品原型文档没太大关系。
• 日期：一般是指发布的日期。
• 修订人：对这次发布负责的人。可能是你，也可能是你的领导（比如你只为这份文档贡献了一个小模块）。
• 修订内容：本次发布与之前已发布内容的关键差异点。主要包含这四个要素：①业务背景（要解决的问题），②业务流程，③业务对象（关键数据与操作），④UI与UE。从①到④重要性依次递减，影响的范围依次递减。至于为什么是这四个关键要素，等到画页面原型时再展开说明吧。
• 备注：其他说明信息，比如①本次发布由多人配合，除了修订人之外，还有谁参与，贡献了哪些模块，②这次发布对应的是产品迭代的哪个版本号或迭代计划等。

二、全局说明

1. 是什么

主要包含：业务背景、上层的应用规划、本文档对应产品的产品规划、整份文档都会用到的术语、整份文档都需要遵循的规范等。

2. 为什么

因为这些信息对整份文档的所有内容都有影响或约束。举例子来说：

业务背景、规划等，是这份文档的上层文档，约束了这份文档的范围。没有业务背景，就没有要解决的业务问题。没有应用规划、产品规划，就缺失了解决问题的方案的顶层规划。这些都是本文档（OMS系统原型）的上层约束信息。具体可以看看下面我画的草图。

术语：主要包含业务语言中的术语，以及产品技术语言中的术语。你在跟业务方沟通时，经常用的一些名词、动词可能就是业务语言。大家有空可以了解技术领域的DDD的思想，这个我以后在业务建模相关内容时会展开介绍。技术语言就是你和其他产品、技术团队沟通时用到的名词、动词。一般来说，业务语言和技术语言要尽可能一致，避免理解差异，这样业务和技术团队的沟通成本才比较低。

举几个例子吧：

业务术语：业务方口中的订单、渠道、商品分别指代什么？订单是客户原始订单，还是OMS中的标准订单？渠道是分销渠道，还是商城店铺？商品是SPU、SKU还是ERP中的物料等等。

技术术语：虚拟库存、实物库存是什么？物料是什么？订单头、物料行、配送行等是什么？。

规范：对文档中的样式、描述方法等作出统一规范。比如文档的框架、流程图画法的规范、页面原型的框架等，文档中重复做的事情尽量形成统一的规范。比如文档中有大量的页面（列表页、详情页等），那就制定一个页面原型框架；比如有非常多的操作流程，那就制定一个流程图规范；比如每个页面都会有功能的解释说明，那就制定一个功能解释的规范等。跟你配合过几次的技术同事熟悉这套规范后，以后看文档就很舒心，可以很轻松的定位和查找。最好一个产品团队使用一套规范。

下面对全局说明的关键信息展开讲一下。

3. 业务背景

1） 业务背景介绍

主要介绍本文档设计的系统，用来支撑的业务线的情况，发现的问题，系统建设的价值预期是什么。这是所有产品规划、业务流程、产品功能设计的起点。

一般来说，在某个系统的原型图这种最底层的文档中，会直接引用上层的文档（如产品规划文档、应用架构规划文档等），而不会直接对业务背景做详细阐述。可以看一下我下面画的草图，了解不同层次的输出物的关系。

底层文档引用上层文档的好处是：

1. 不会重复。业务线的情况，业务最痛的问题，解决方案和价值，问题解决的优先级等是分层级逐步分析拆解出来的，在不同的层级会形成不同的输出物。上层输出物相对更宏观、整体，下层输出物相对更微观、具体、局部，因此在下层输出物中一般不会重复的把上层输出物再阐述一遍。
2. 信息一致。因为下层输出物引用上层输出物，所以当上层输出物中的部分结论产生变更，只需要变更上层输出物即可。如果同一个结论在不同输出物中都重新写了一遍，那更新不完整时会导致信息不一致，进而导致执行出现偏差。这类问题在公司流程、制度等文件中广泛存在。
3. 聚焦。下层输出物要聚焦到某一个具体问题的解决上，因此在这一层不要过多关注整体，只需要知道我解决的问题在整体中的位置、在整体方案中的价值就可以了。

关于如何从业务出发，逐层分析拆解出某个系统的解决方案，版本迭代计划，是另一个话题，在这里不展开。我画了一个草图，大致逻辑如下：

本次系列文章，对标的就是第五、第六层级的原型设计文档。

上面的逻辑是企业架构（EA）设计的逻辑，大家感兴趣可以去了解一下TOGAF。对比了解过的同学，可以发现草图里缺少了技术架构。原因是①技术架构太专业了，我没有能力阐述完整。②技术架构一般由技术架构师、技术组长等角色提供，产品经理一般不参与技术架构设计。

2）应用规划

对标上面的草图，应用规划属于第三层，要描述整个业务线或整个企业的完整的数据架构与应用架构。

数据架构对企业非常重要，但是另一个专业话题，在这里我不展开了。

应用架构就是完整的IT系统规划，除了各位比较熟悉的应用层系统（如OMS、SRM、OA、ERP等），还包括了底层的平台系统（如用户系统（含统一鉴权）、网关系统、门户系统、BI系统等）、底层技术系统（如租户系统、PaaS等）。

应用规划要回答的问题是，如何通过一系列的IT系统来支撑业务发展，解决业务问题。

3）产品规划

对标上面的草图，产品规划属于第四层，描述单个系统的整体规划，包括系统支撑的业务描述、系统关键用例、系统关键业务对象模型、关键业务流程等。

产品规划要回答的问题是，这个IT系统要解决什么业务问题，如何解决。

4）业务背景的模板示例

有的同学可能会问，系统价值怎么能精确到数值的？这主要看调研的深度和业务方的重视程度，如果业务方对这个问题非常痛，我们调研的深度能足够深入，那每个具体问题解决后预估的人效提升是能估算出来的，就能转换成业务的具体数值。

比如自动对账与结算功能，解决的问题主要是：①出我方账单，②与客户账单自动比对并输出差异报告，③快速调账，④出结算单，⑤推送开票与应收。

• 出账单：原来是人工导出明细表格筛选，每个账期的账单要20分钟。出账单功能只需要1分钟。同时减少了人工筛选出错的问题。
• 自动对账：原来是人工用表格对账（各种Vlookup），每次对比要1~2小时（因为要比对的参数很多，比如订单号、产品名称、单价、数量、总金额、时间、活动促销等）。自动对账功能只需要1分钟，同时减少人工比对出错的问题。
• 人工调账：表格调账比较复杂，涉及到要不停地与对方沟通，修正错误，一般需要1~2天。人工调整功能基于自动对账的差异结果，耗时的是确认差异处理方式（如挪到下一账期、取消本条明细对账等），一般需要半天。
• 自动结算：人工创建结算单、发起开票流程一般需要0.5~1小时。自动结算功能会根据调账后的结果（一般是要经过双方确认审批的），生成结算单，并根据结算单一键发起开票请求，推送财务系统的应收暂估等，一般几分钟。

整体评估下来，对账功能整体提效80%以上。业务方领导可以根据这些方案描述，预估出是不是可以减少编制、减少出错而避免的经济损失等。减少编制不意味着裁员哈，只意味着这个岗位不需要那么多人了，多出来的人天可以调岗到别的岗位，或做别的工作。

4. 全局术语

我这里给出示例，大家要根据自己公司的具体情况整理提炼。

5. 全局规范

我给出几个示例供大家参考。

1）流程图规范

2）系统首页规范（截取）

3）列表页示例（截取）

4）创建页、编辑页示例（截取）

5）各种弹框的规范示例（截取）

三、总结

本篇文章承接上一篇文章（PRD模板），介绍了修订记录、全局说明的内容，并用实际案例给了一些示例图。在全局说明部分，稍微展开介绍了一下产品规划的完整逻辑链，可能稍显啰嗦，欢迎大家在评论区探讨。

本文所有内容均为原创，示例图仅供参考，大家要结合实际调整。大家要自己练习找手感。