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

一、产品需求的重要性

产品需求在互联网产品开发中非常重要，想象一下你正在建造一座房子。产品需求就像是你的建筑图纸，它告诉你需要什么样的房子，有多少房间，每个房间的大小，窗户在哪里，门在哪里，甚至墙壁的颜色和屋顶的形状都会在需求中定义。如果没有清晰的需求，你就无法开始建造，因为你不知道要建造什么样的房子。

产品需求是产品成功的基础。它们确保产品满足用户的需求和期望，因此能够吸引更多的用户并取得市场成功。如果没有明确的需求，产品可能会失去方向，最终无法满足用户的需求，从而失败。

二、产品需求差的表现

1. 模糊不清

2. 需求不完整

3. 需求矛盾

4. 频繁的需求变更

5. 不符合用户需求

6. 需求无法量化

7. 没有考虑性能和可延展性

三、交付高质量的产品需求

1. 是否必填：在表单中，每个字段的必填性状态都应该清晰地指定。例如，用户姓名字段必填，电子邮件地址字段非必填。

2. 是否可编辑：说明数据项是否允许编辑，是否只允许特定用户、特定条件才能编辑，允许哪些用户、哪些特定条件才可编辑。

3. 数据唯一性：如果某些字段需要保持数据的唯一性，这也应该在需求中说明。例如，手机号必须是唯一的，不允许重复。

4. 长度：字符串字段的最大长度和最小长度应该定义。例如，密码字段的最小长度为8个字符。

5. 格式：对于日期、时间或其他特定格式的字段，格式要求应该明确。例如，生日字段应该按照"YYYY-MM-DD"格式输入。

6. 默认值和选项：如果字段有默认值或者需要提供特定选项，这些值应该在需求中列出。例如，性别字段的默认值为"男性"，且用户可以选择"女性"或"其他"。

7. 隐藏字段：如果表单包含隐藏字段，它们的作用和值应该在需求中解释清楚。

8. 非输入字段：任何不需要用户输入的字段，如计算字段或自动生成的字段，也需要在需求中说明其生成或计算方式。

9. 表单验证触点：需要明确指定在何时进行表单验证，例如，当用户点击"提交"按钮之前或实时验证。

10. 验证提示：需要提供用户在输入无效数据时会收到的错误提示信息。例如，如果用户输入的电子邮件地址格式不正确，需告知用户应该输入有效的电子邮件地址。

11. 提交数据：需要明确说明用户提交表单后数据应该被发送到哪里，以及如何处理提交的数据。

新增数据的示例：

1. 查询条件：用户需要能够指定查询条件，以筛选数据。例如，可以按日期、类别、作者等条件进行筛选。

2. 查询：用户应该能够执行查询操作，以获取满足其指定条件的数据。

3. 查询的数据量：需要明确规定每次查询返回的数据量，以确保页面加载性能。

4. 数据展示形式：说明数据如何在列表中展示，包括列的显示内容和格式，以及是否支持缩略图或详细视图。

5. 排序：用户可以选择按照某个字段升序或降序排列数据，例如按时间、字母顺序等。

6. 分页：如果数据量大，需明确规定每页显示的数据数量，并允许用户浏览不同页的数据。

7. 其他配套功能：除了基本的查询和展示，需明确是否需要其他功能，如导出数据、保存查询条件、列的定制、数据批量操作等。

• 字段的用途、业务类型、长度：说明新字段的用途（例如，存储用户的出生日期）、业务类型（例如，日期类型）、以及长度（例如，10个字符）。

• 字段默认值、取值规则：指定字段的默认值（如果有），例如新用户的出生日期默认为空。描述字段的取值规则，例如日期必须在特定范围内。

• 字段的展示：解释字段在用户界面上的展示方式，例如，出生日期可能以日/月/年的形式显示在用户的个人资料中。

• 字段的查询、编辑：确定用户是否可以在界面上查询或编辑这个字段。例如，用户可以在个人资料页面编辑出生日期字段。

• 对外接口：如果这个字段需要与其他系统或服务进行数据交互，需描述接口的规范，包括数据格式、传输方式等。

• 存量数据：如果已经有现有数据（存量数据），需说明如何处理这些数据，以使新字段适用于现有数据，例如，将现有用户的出生日期设置为默认值或进行数据迁移。

• 删除限制：说明是否存在删除的限制条件，例如，是否只允许管理员删除数据或是否有特定的权限要求。

• 删除提示：定义删除操作时是否需要用户确认，例如，在点击删除按钮后显示一个提示框，要求用户确认删除操作。

• 批量删除：说明是否支持批量删除，用户是否可以一次删除多条数据，如果支持，需说明如何选择多个数据项进行删除。

• 级联删除：如果删除某个数据项会影响其他关联数据，需明确描述级联删除的情况，以及如何处理这些关联数据，例如，删除文章时是否同时删除相关评论。

• 数据恢复：是否支持数据恢复，即用户可以在一定时间内恢复已删除的数据。如果支持，需要说明恢复的时间限制和方式。

• 导入模板：提供导入数据所需的模板，其中包括列名和格式示例，以便用户准备要导入的数据。

• 模板格式：说明模板的格式，例如，是一个Excel文件、CSV文件还是其他格式，以及是否支持不同版本的模板。

• 导入验证：指定导入数据时的验证规则，例如，数据是否必须符合特定格式、字段是否必填，以及如何处理不合格的数据行。

• 导入结果：定义导入完成后的结果反馈，包括成功导入的记录数、失败的记录数，以及导入失败的原因。还需说明如何让用户查看导入结果和可能的错误信息。

• 导出模板：提供导出数据所需的模板，包括列名和格式示例，以便用户了解导出数据的结构。

• 导出大批量数据：能够处理大批量数据的导出，确保系统可以高效地导出大量数据而不会导致性能问题。

• 导出数据以及结果：指定导出的数据内容，例如，用户可以选择导出整个数据集、特定时间范围的数据，或者按照某些筛选条件导出数据。同时，需要定义导出结果的格式，如导出为Excel、CSV、PDF等文件类型，并明确如何提供给用户。

• 接口的调用场景：说明接口将被用于哪些具体业务场景，例如，用于用户注册、订单查询、支付等。

• 接口调用方：指明谁会调用这个接口，是内部系统还是外部合作伙伴或第三方应用。

• 接口调用量：确定接口的预期调用量，以便为系统资源规划和性能优化提供基准数据。

• 接口功能描述：清晰地描述接口的功能和作用，例如，注册接口用于创建新用户帐户。

• 输入参数：列出接口需要接受的所有输入参数，包括参数名称、数据类型、是否必填、范围等信息。例如，注册接口可能需要接受用户名、密码、电子邮件地址等参数。

• 输出参数：列出接口将返回的所有输出参数，包括参数名称、数据类型、可能的返回值等信息。例如，注册接口可能返回成功或失败的状态、用户ID等信息。

四、高质量产品需求特性

1、完整

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

1.1、分支、异常流程

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

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

• 提交OA申请后，没有撤销申请的步骤，以及撤销申请后是否可修改再次提交申请。

• 审批人超时未审批 流程该怎么走，超24小时未审、超48小时未审 流程如何处理。

• 审批人驳回OA申请，是否可以直接修改原申请内容 再次提交申请。

• 申请人职级不同，审批层级不同的情况，这种多级审批流程如何定义和说明。

• 审批流程结束后，是否有需要 回写的数据、或需要更新的状态。

1.2、列举完整的业务场景

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

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

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

• 商品已下架。

• 商品无库存。

• 商品被删除。

• 商品不在配送区域内。

• 商品属于不同的商家（涉及需拆单）。

• 商品属于不同的仓库（涉及需拆单）。

• 包含需冷链运输的商品（涉及需拆单）。

• …

1.3、上下游相关联的逻辑

• 比如：客户信息中 客户类型的枚举值由5个变成了3个，在统计报表中原来根据5个客户类型统计数据的逻辑，就需要做同步的变更。

• 再比如：客户信息中 渠道类型由1个字段拆成了2个字段，对外接口中读取渠道类型的逻辑，需要指明是否需要调整。

1.4、原有的规则和逻辑

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

1.5、提供关联的附件资料

• 导入、导出模板文件：涉及导入、导出数据的系统功能，需提供导入、导出数据的模板文件。

• 初始化的数据：功能上线后需立即展示初始数据的需求，应提供初始化的数据源文件。

• 消息、短信模板：如需发送短信，需提供短信模板，包括短信签名。如需给用户发送即时消息，需提供消息模板文件，包括发送人、消息模板内容。 同时指明，短信或消息模板中的变量，以及变量的取值规则。

• 产品提示文案：固定的提示文案，如有变量，需指明变量如何取值。

1.6、非功能性需求

• 权限需求：所有功能权限、数据权限点的权限分配规则，涉及数据接口的，还需说明接口范围的权限要求。

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

如以下示例：

• 数据需求：如果涉及存量数据的处理(比如加字段），需描述存量数据的处理方案；描述哪些功能项需做数据埋点。

• 兼容性需求： 不同移动端系统（Android、iOS等）及其版本、手机及其型号的兼容性；新老数据接口的兼容性等；不同浏览器及其版本的兼容性。

• 性能需求：系统并发量的要求；页面打开速度、响应速度的要求。

2、具体

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

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

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

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

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

• 满足的2个条件是且、还是或的关系。

• 跟进中的客户有跟进中-未拜访、跟进中-已拜访2个状态，那 跟进中 该如何判定，只包括其中一个状态，还是2个状态都包括。

• 最后跟进时间在7天内，是否包括7天。

再比如以下需求：

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

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

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

3、准确

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

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

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

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

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

• “不加时效” 费，不加 货物运输时效  的一种费用。

比如以下产品需求：

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

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

• 自然月份：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？或者是再往前多取一个月的营业额？

4、友好

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

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

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

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

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

• 客户分值：取客户后台->基础信息->基本信息中的客户分值字段。

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

5、另外

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

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

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