prd|5000字教你写ToB产品需求文档( 三 )

目标价值：指该方案上线后能够为用户带来什么价值、给公司又能带来什么样的商业价值。

衡量指标：常言之，无法衡量就无法优化。因此，我们需要明确出1-3个能够真正衡量方案价值的指标，便于我们未来进行优化和迭代。

风险评估：指迭代上线前，需要对整个迭代可能遭遇或造成的风险进行评估，包含技术风险、用户体验变更风险、数据修复风险、并发风险等。

笔者曾经有一次惨痛的迭代教训就和缺少风险评估有关。那次迭代是对原有的一些“糟糕”交互进行了优化，当时并没有考虑到是否会对用户原有使用习惯造成影响，最终上线后，“收获”了一大批的负面反馈。如果能提前对此有所评估，也许就会考虑通过一键切换回旧版本等一些缓和性的方案来进行平滑过渡了。
2）需求清单
需求清单指我们需要满足哪些需求、各需求的优先级是什么样的。其中包含但不限于需求名称、需求描述、需求类型、所属模块、优先级等。

需求名称：指核心需求的简称、需求描述需说明具体的功能范围及内容。
需求类型：分为功能、优化模块：指该核心需求所归属的业务模块需求优先级说明：P0-优先级最高的需求；P1-版本核心需求；P2-与核心需求存在关联关系的业务调整；P3-其他调整需求；T0-承诺上线需求（优先级分明，避免全部需求都为P0）。

3）业务架构/流程

业务架构：描述业务的整体架构、业务模型、数据关系等（选写，视版本所需确定）业务流程：前后端通用的核心业务流程绘图标准：基本符合主流绘图标准，关系/条件描述清晰无歧义。关于业务架构/流程这里，笔者推荐3种比较常见的UML图：活动图、状态机图、时序图。
活动图：按照时间顺序将活动的逻辑整理出来，与我们常见的流程图类似；
状态机图：围绕一个事物的状态为中心来讲述流程；
时序图：在描述流程时，能够清晰地定义角色的具体职责边界和通信交互；

具体UML的介绍，可以参考此前笔者写的这篇《一文解决产品经理对UML的全部疑问》。
4）页面说明
在描述好业务逻辑之后，就需要对页面中的元素、组件、交互进行一定的说明。C端产品经理往往会花费较多的时间在于细节体验和交互之上，而B端产品则全然不同。
因为toB行业业务逻辑庞大、流程复杂，产品经理的核心要务就是梳理业务和流程，交互和体验则更多是锦上添花的作用。用一句客户的话来说“业务都跑不动了，细节做那么好有什么用？”因此，对于B端产品经理而言，我们要合理分配好文档中业务流程和交互体验上的精力。
在写页面注释这里，笔者为大家提供2个非常实用的小tips，帮助你在保证质量的前提下节约大量的时间。
Tip1: 将重复逻辑创建为一个母版master
Axure中的母版可以简单理解为公共元件模板，将母版应用到相应页面中后，母版内容或样式发生变化，那么引用母版的页面内容或样式同样会跟着变化，常用于制作页面头部或底部内容。因此，母版master常常被我们用于创建一些组件样式或标准页等，例如web端标准底页、iPhone6标准底页等。
但是，笔者这里要分享的是将一些重复性的逻辑也可以整理为母版。选中某段注释文字，右键点击创建母版Create Master，即可生成如下图所示的逻辑母版：

文章插图
这样做有什么好处呢？
【 prd|5000字教你写ToB产品需求文档】① 重复的组件或模块的逻辑注释只用写一遍，第二次第三次直接拖拽母版使用即可，无须多次重复撰写。
如上图所示，若一次迭代中有3、5处都需要显示这个冲突提示气泡，那么我们只需写一次，后续直接找到母版拖拽到页面里即可。
② 文档免不了要多次修改，那么当这些重复逻辑一旦被修改，我们就只能挨个去穷尽，而且很容易出现遗漏。
但是如果使用了注释母版，那么只需要在母版处一次修改，剩余引用母版的逻辑注释部分将自动变更。不仅减轻了工作量，更能帮助我们避免遗漏、保证重复逻辑的统一性。
Tips2: 将标准化组件的逻辑注释整理为元件库libraries
我们常常会去Axure社区及各大资源平台搜集各式各样的元件库lib，例如element、antd、iOS、Android的标准元件库等，方便自己在画图时可以快速进行样式引用。
而B端产品以PC端、Web端为主，样式整体较少（以表单、tab、列表等为主），同时相对较为标准化。因此，我们不仅可以将这些标准化组件的样式整理为元件库lib，也可以将这些组件对应的逻辑注释整理为元件库lib。