产品原型（简单的OMS为例）演习一：修订记录与全局说明

文章目录 [+]

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

本文大纲

产品原型（简单的OMS为例）演习一：修订记录与全局说明人工智能

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

修订记录：文档的修订历史，方便往后备查文档的各个版本变动了哪些内容。
全局解释：整份文档的整体解释，紧张包含背景、术语定义、规范解释。

一、修订记录1. 是什么

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

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

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

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

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

二、全局解释1. 是什么

紧张包含：业务背景、上层的运用方案、本文档对应产品的产品方案、整份文档都会用到的术语、整份文档都须要遵照的规范等。

2. 为什么

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

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

术语：紧张包含业务措辞中的术语，以及产品技能措辞中的术语。
你在跟业务方沟通时，常常用的一些名词、动词可能便是业务措辞。
大家有空可以理解技能领域的DDD的思想，这个我往后在业务建模干系内容时会展开先容。
技能措辞便是你和其他产品、技能团队沟通时用到的名词、动词。
一样平常来说，业务措辞和技能措辞要尽可能同等，避免理解差异，这样业务和技能团队的沟通本钱才比较低。

举几个例子吧：

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

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

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

下面对全局解释的关键信息展开讲一下。

3. 业务背景

1）业务背景先容

紧张先容本文档设计的系统，用来支撑的业务线的情形，创造的问题，系统培植的代价预期是什么。
这是所有产品方案、业务流程、产品功能设计的出发点。

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

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

不会重复。
业务线的情形，业务最痛的问题，办理方案和代价，问题办理的优先级等是分层级逐步剖析拆解出来的，在不同的层级会形身分歧的输出物。
上层输出物相对更宏不雅观、整体，下层输出物相对更微不雅观、详细、局部，因此不才层输出物中一样平常不会重复的把上层输出物再阐述一遍。
信息同等。
由于下层输出物引用上层输出物，以是当上层输出物中的部分结论产生变更，只须要变更上层输出物即可。
如果同一个结论在不同输出物中都重新写了一遍，那更新不完全时会导致信息不一致，进而导致实行涌现偏差。
这类问题在公司流程、制度等文件中广泛存在。
聚焦。
下层输出物要聚焦到某一个详细问题的办理上，因此在这一层不要过多关注整体，只须要知道我办理的问题在整体中的位置、在整体方案中的代价就可以了。

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

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

上面的逻辑是企业架构（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模板），先容了修订记录、全局解释的内容，并用实际案例给了一些示例图。
在全局解释部分，轻微展开先容了一下产品方案的完全逻辑链，可能稍显啰嗦，欢迎大家在评论区磋商。