如何交付高质量的产品需求（二）

交付高质量的产品需求：

一份高质量的产品需求，应该是具备以下重要特性：完整、具体、准确、友好。

一、完整

产品需求的完整性，包括标配需求，分支流程、异常流程的闭环；包括功能逻辑的齐全；包括不同的业务场景；包括上下游关联影响的说明；包括附件资料；包括非功能性需求…

1. 分支、异常流程

业务流程中涉及有分支流程，需说明每种分支流程的走向、流程节点的具体规则、不应出现有去无回、断头路的情况；涉及有异常流程，同样需需说明异常流程的触发条件、走向、异常流程节点的具体业务规则。

比如在常见的OA审批流程中，就存在以下容易被忽略的流程状况：

• 提交OA申请后，没有撤销申请的步骤，以及撤销申请后是否可修改再次提交申请。
• 审批人超时未审批 流程该怎么走，超24小时未审、超48小时未审 流程如何处理。
• 审批人驳回OA申请，是否可以直接修改原申请内容 再次提交申请。
• 申请人职级不同，审批层级不同的情况，这种多级审批流程如何定义和说明。
• 审批流程结束后，是否有需要 回写的数据、或需要更新的状态。

2. 列举完整的业务场景

对于业务场景众多、且复杂的需求，需列举出所有相关的业务场景，以及每种情况对应的业务规则和逻辑、或处理方案。

这点上，就比较考验产品同学的业务熟悉程度、以及业务分析能力了。

在以下购物车的示例中，在提交订单时，就需考虑各种业务场景下的逻辑处理：

• 商品已下架。
• 商品无库存。
• 商品被删除。
• 商品不在配送区域内。
• 商品属于不同的商家（涉及需拆单）。
• 商品属于不同的仓库（涉及需拆单）。
• 包含需冷链运输的商品（涉及需拆单）。
• …

3. 上下游相关联的逻辑

修改某项功能点（尤其涉及到基础数据变更的情况），需列举出上下游相关的修改点，或通知下游系统变更的影响以及可能需要做哪些修改；包括相关模块的功能点、对外接口、权限规则、数据报表、数据的导入导出等。

• 比如：客户信息中 客户类型的枚举值由5个变成了3个，在统计报表中原来根据5个客户类型统计数据的逻辑，就需要做同步的变更。
• 再比如：客户信息中 渠道类型由1个字段拆成了2个字段，对外接口中读取渠道类型的逻辑，需要指明是否需要调整。

4. 原有的规则和逻辑

涉及需要描述原有功能逻辑的需求，产品同学普遍的会写：与原有逻辑保持一致、或翻看原有逻辑，同时又不指明原有逻辑是怎样的，或在哪个地方以查看。如果是新同学遇到这种情况，就不知所措，要开始怼人了。

对于业务逻辑复杂的中后台系统，并且是经历1-100的迭代过程，更需要注意描述清楚原功能的逻辑和规则，或者指明在哪个文档、文档的哪个部分可以查看现。如原有逻辑已找不到有文档记录，可能就需要提前找技术同学翻查代码，以核验原有逻辑的正确性。

5. 提供关联的附件资料

• 导入、导出模板文件：涉及导入、导出数据的系统功能，需提供导入、导出数据的模板文件。
• 初始化的数据：功能上线后需立即展示初始数据的需求，应提供初始化的数据源文件。
• 消息、短信模板：如需发送短信，需提供短信模板，包括短信签名。如需给用户发送即时消息，需提供消息模板文件，包括发送人、消息模板内容。 同时指明，短信或消息模板中的变量，以及变量的取值规则。
• 产品提示文案：固定的提示文案，如有变量，需指明变量如何取值。

6. 非功能性需求

• 权限需求：所有功能权限、数据权限点的权限分配规则，涉及数据接口的，还需说明接口范围的权限要求。
• 安全需求：说明哪些字段或数据需配置为监控字段，即默认展示位***，点击再查看明文。对于业务复杂的后台系统，可能还需再深入一步，指明哪些级别或类型的用户可直接看明文、哪些需点击再看明文、哪些只能看到***。 安全类与权限类的需求，关联度比较高，有时需结合在一起，尤其是重业务、重流程的B端产品，需单独列为一份产品需求来对待。

如以下示例：

• 数据需求：如果涉及存量数据的处理(比如加字段），需描述存量数据的处理方案；描述哪些功能项需做数据埋点。
• 兼容性需求： 不同移动端系统（Android、iOS等）及其版本、手机及其型号的兼容性；新老数据接口的兼容性等；不同浏览器及其版本的兼容性。
• 性能需求：系统并发量的要求；页面打开速度、响应速度的要求。

二、具体

交付给技术、测试同学的需求，一定是具体可编码的、可执行测试验证的。

很多时候产品同学以为是清楚的描述了，实际上会包括潜在的多个选项指明不清、或与且的关系、多个操作入口该修改哪些地方、以及边界性的问题等。

在曾经团队中出现过如此产品需求：

满足状态在跟进中、最后跟进时间在7天内的客户需由销售管理层手动分配销售经理。

在该需求描述中就存在不够清晰，具体的问题：

• 满足的2个条件是且、还是或的关系。
• 跟进中的客户有跟进中-未拜访、跟进中-已拜访2个状态，那 跟进中 该如何判定，只包括其中一个状态，还是2个状态都包括。
• 最后跟进时间在7天内，是否包括7天。

再比如以下需求：

替换销售经理时，不能填写自己的姓名。

实际上替换销售经理的操作入口有N个，并且有的特殊地方其逻辑是不同的，最好把替换的入口列举出来的，不然技术同学容易做漏、测试同学容易测漏、上线后也便于自己验收。

另外不能填写自的姓名该怎么判断，可编码的具体描述应该是不能填写当前操作用户的姓名。

三、准确

同样的文字描述加上标点符号、或断句不同，其表达出来的意思就可能有多种。需求的准确性主要指需求的描述应该是唯一确定、理解上没有歧义的。

类似时间/日期相关的描述，应具体说明是哪个时间段，精确到日期还是时分秒；涉及连续多个且、或的逻辑判断，需明确描述“或者”， “并且”的判断规则。对于理解可能有歧义，又很难文字描述逻辑需求，加以释义说明、或示例说明。

团队曾经做过一个增值服务相关的费用：不加时效费。

从字面上脑回路不同的人就有不同的理解：

• 不加 “时效费”，不加上  货物运输时效的费用，即是要减去相应的费用。
• “不加时效” 费，不加 货物运输时效  的一种费用。

比如以下产品需求：

营业额均值取值规则：取当前时间前3个月客户的营业额之和的均值

当前时间前3个月的理解：

假如当前时间为2020-10-10 10:00，则当前时间前三个月含义可能有2种：

• 自然月份： 2020-07-01 00:00:00 到 2020-09-30 23:59:59？
• 非自然月份：2020-07-10 00:00:00 到 2020-10-09 23:59:59？

前3个月营业额之和均值的理解：

假如3个月中有1个月的营业额为0，则取均值时除以2、还是除以3？或者是再往前多取一个月的营业额？

四、友好

产品需求描述清楚、准确了，最后展示给用户（技术、测试同学）时，也需漂亮的颜值，友好的展示形式。

需求文档需设置好文档结构图，标明清晰文档的结构、层次，难易理解的逻辑给予示例说明，大段文字的空行、格式、间隔等，也都是需要考虑的因素。能用图形、表格的尽量使用图表展示，避免大坨的文字堆积。

比如以下示例中的格式、符号问题：

在申请信息页面要增加 结算方式、客户分值2个新的字段，以下团队成员给出的文字描述，就没太注意文字的格式、标点符号等展示细节：

更友好的展示应该是：

• 结算方式：取客户后台->财务信息->结算信息中的结算方式字段。
• 客户分值：取客户后台->基础信息->基本信息中的客户分值字段。

再比如以下的文档结构图示例，设置了文档结构图的文档就更便于阅读：

五、另外

清晰明了的产品需求， 能有效提高产研的效率，节省团队的沟通成本，也能体现出产品同学的专业度，赢取团队的信任。

但也并无意味着沟通的减少，产研整个过程的产品、技术、测试同学之间积极、及时性、无障碍的沟通始终是不可缺少的，在项目跟进过程中，产品同学大部分的时间其实都会花在沟通上。

沟通是门大学问，也是一生的学问。

本文作者 @天晴一把刀 。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！