如何交付高质量的产品需求(二)(如何做到有质量的交付)

如何做好一份高质量的产品需求,作者从完整、具体、准确、友好四个方面出发,分析做好产品需求所需要具备的要点,希望通过阅读本篇文章,能对你有所帮助。

交付高质量的产品需求:

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

一、完整

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

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个月的理解:

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

自然月份: -07-01 00:00:00 到 -09-30 23:59:59?非自然月份:-07-10 00:00:00 到 -10-09 23:59:59?

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

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

四、友好

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

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

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

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

更友好的展示应该是:

结算方式:取客户后台-
(0)
上一篇 2023年07月14日
下一篇 2023年07月14日

相关推荐