第4章 需求清单整理：从业务方/用户/竞品收集需求、去重、合并、标准化描述
4.1 适用场景
本章流程适用于以下典型场景：
- 产品团队完成多轮需求收集（业务访谈、用户调研、竞品分析）后，需将分散的原始需求归拢为统一清单。
- 跨部门协作中，多个来源的需求存在内容重叠、表述不一、颗粒度差异大等问题，需要进行系统化整理。
- 在进入KANO模型分类和矩阵评估之前，必须确保需求清单无重复、无歧义、描述标准化，为后续优先级排序奠定数据基础。
- 版本规划或需求评审前，需要一份经过清洗和结构化的“待评估需求池”。
📌 判断是否需要本章流程：如果从不同渠道收集到的需求中，存在“看起来很像但又不完全一样”的条目，或者同一个需求被人用不同话术提了多次，就应该启动本章的整理流程。
4.2 前置条件
执行需求清单整理前必须确认以下条件已满足：
- 原始需求已收拢：来自业务方、用户、竞品三个渠道的需求已记录在案，每条需求有原始出处（提出人/来源文档/会议纪要ID）。
- 需求记录载体就绪：已建立统一的需求收集表（Excel、在线表格或需求管理工具），包含“需求描述”、“来源渠道”、“提出人”、“提出时间”等基础字段。
- 团队角色到位：至少指定一名需求整理负责人（通常为产品经理或需求分析师），以及各渠道需求确认接口人。
- 术语基准明确：团队已初步约定需求描述的核心术语（如“用户”指代C端还是B端，“工单”与“任务单”是否为同一概念），避免整理过程中产生新的歧义。
⚠️ 常见前置缺失：如果没有统一的需求收集载体，直接开始去重和合并，很容易造成需求遗漏或重复统计。务必先建立结构化的需求登记表再执行本章流程。
4.3 操作步骤
需求清单整理分为五个子步骤，建议按顺序执行，每一步完成后再进入下一步：
-
收集原始需求并登记入池
- 将业务方提出的业务目标、功能诉求、非功能要求逐条录入需求登记表。
- 将用户调研/访谈/反馈中提取的痛点、期望、使用场景转化为需求条目。
- 将竞品分析中识别出的功能亮点、差异化能力、市场趋势需求整理入库。
- 每条需求记录“来源渠道”、“提出人”、“提出时间”、“原始描述（原文）”。
-
需求去重
- 完全重复：标题或描述文字完全一致的需求，直接保留最早提出的一条，其余标记“已去重-完全重复”。
- 近似重复：核心内容相同但表述略有差异（如“增加搜索功能” vs “让用户能搜索商品”），由需求负责人人工判定，保留描述更完整或来源更权威的一条。
- 去重后更新需求登记表，在“去重状态”列标注“保留”或“已去重”，并填写被去重条目的编号。
-
需求合并
- 相似需求合并：核心功能相同但细节侧重不同的需求（如“PC端搜索”和“移动端搜索” 合并为“全平台搜索”），合并为一条综合性需求，保留所有细节标签。
- 关联需求合并：属于同一功能模块或同一用户旅程的需求（如“登录”+“注册”+“找回密码”合并为“账号管理”），合并为一条父需求，子需求作为附件说明。
- 冲突需求标记：两个需求在逻辑上互斥（如“页面极简” vs “页面信息丰富”），不强行合并，记录冲突关系并升级给产品负责人决策。
- 合并完成后，在“合并记录”字段中注明被合并的需求编号及合并理由。
-
标准化描述
- 所有需求采用统一描述结构：
作为<用户角色>，我希望<功能/行为>，以便<业务价值>。 - 统一术语：检查“用户”、“客户”、“会员”等词汇是否混用，按术语表统一替换。
- 统一粒度：每个需求描述应控制在50字以内，聚焦单一功能点或单一业务价值，避免一条需求包含多个诉求。
- 标准化后由第二人复审，确保描述无歧义、无缺失。
- 所有需求采用统一描述结构：
-
编号归档
- 为每条最终需求分配唯一编号，格式：
REQ-YYYYMMDD-三位顺序号（如 REQ-20250615-001）。 - 在需求清单中补充“需求编号”、“标准化描述”、“去重状态”、“合并记录”、“版本号”列。
- 将整理完成的需求清单导出为正式文档，进入下一阶段（KANO分类）评审。
- 为每条最终需求分配唯一编号，格式：
4.4 输入输出物
| 输入物（来源） | 输出物（交付件） |
|---|---|
| 业务方原始需求记录（会议纪要/邮件/PRD草稿） | 标准化需求清单（含编号、标准化描述、来源、状态） |
| 用户调研/访谈记录、反馈汇总表 | |
| 竞品分析报告、竞品功能对比表 | |
| 现有需求库/历史需求列表 | 需求去重记录（含被去重条目ID及理由） |
| 团队术语表/产品词典 | 需求合并记录（含被合并条目ID及合并理由） |
4.5 责任边界
| 角色 | 职责 | 权限边界 |
|---|---|---|
| 需求分析师 / 产品经理 | 主导需求收集、去重、合并、标准化、编号归档全流程 | 可判定近似重复、合并逻辑，但涉及冲突需求需升级决策 |
| 业务方接口人 | 提供原始需求、参与需求澄清、确认最终标准化描述是否准确 | 对业务类需求的合并与标准化有一票否决权 |
| 用户研究员 | 移交用户原始反馈，协助判断用户需求的真实意图 | 不直接修改需求清单，但可对描述提出修正建议 |
| 竞品分析师 | 提供竞品功能原文和对比数据 | 确认竞品需求的技术可行性，不参与合并决策 |
| 项目经理 | 监督整理进度，协调跨部门确认，组织需求评审 | 不直接介入整理操作，但有权要求返工或补充信息 |
4.6 记录材料
执行本流程时需使用以下模板和工具，建议在团队内统一版本：
- 需求清单模板（主表）：包含字段——需求编号、原始描述、标准化描述、来源渠道、提出人、提出时间、去重状态、合并记录、所属模块、备注。
- 去重核对表：用于逐条比对已登记需求，记录“疑似重复对”及判定结果。
- 合并审批单：当需要跨模块合并或涉及冲突需求时，由产品负责人签字确认。
- 术语统一对照表：记录团队常用词汇的标准化映射，如“会员=VIP用户”、“工单=任务单”。
- 需求编号分配登记册：记录已分配的编号区间，防止编号冲突。
📎 实操建议：使用在线协作表格（如飞书多维表格、Notion Database、Confluence）来承载需求清单，每次修改自动保存历史版本，方便追溯和回滚。
4.7 异常处理
| 异常场景 | 处理方式 | 升级路径 |
|---|---|---|
| 需求描述模糊，无法判断是否重复 | 标记为“待澄清”，退回给提出方补充描述，补充完成前暂不归入最终清单 | 需求负责人发起“一对一”澄清会议 |
| 多个来源需求在核心逻辑上互斥 | 不合并，记录冲突关系，生成“冲突需求报告” | 升级至产品负责人或业务决策委员会裁决 |
| 需求颗粒度差异过大（一条是宏观诉求，另一条是具体功能） | 将宏观需求拆解为多个原子需求，或将过细的需求合并到父需求下 | 拆合方案需与提出方确认，避免信息失真 |
| 需求来源不可追溯（找不到原始提出人/文档） | 标记为“来源待确认”，暂不进入正式清单，发布公告寻找知情人 | 如3个工作日内无人认领，视为无效需求删除 |
| 同一需求被三个以上渠道同时提出，但表述完全不同 | 保留最完整或最权威的一条，其余合并为“引用来源”，在合并记录中列出所有渠道 | 需求负责人做终审，确保无信息遗漏 |
4.8 验收标准
完成本章流程后，需求清单必须同时满足以下条件方可进入下一阶段（KANO分类）：
- 完整性：所有已收集的原始需求都经过处理，无遗漏条目，清单中每个需求都有唯一编号。
- 无重复：经去重核对，清单中不存在完全重复或近似重复的需求（可追溯到去重记录）。
- 合并可追溯：所有合并操作都有记录，包含被合并的需求编号、合并理由、审批人。
- 描述标准化：每条需求均采用“用户角色 + 期望行为 + 业务价值”的结构，术语与团队术语表一致，无歧义。
- 来源可追溯：每条需求都能追溯到原始来源（提出人/文档/会议ID），不存在“幽灵需求”。
- 粒度一致：清单中需求的颗粒度大致相当，没有“做大系统”和“改个按钮”混在一起的情况。
✅ 验收自检：随机抽取10%的需求条目，由另一名未参与整理的同事独立审核，如果发现重复、歧义或来源缺失等问题超过2条，则整批返工。