第4章：需求池清洗与标准化

需求池中的原始条目往往是碎片化、模糊甚至不可验证的。本章提供一套SOP，将非结构化需求转为统一模板、剔除无法通过A/B测试验证的条目、标记相互依赖关系，为后续P0/P1优先级排序打下可执行的基线。

适用场景

• 从多个渠道（用户访谈、客服工单、产品反馈、竞品分析）聚合需求后，需统一格式。
• 存在“实现方式”与“业务目标”混杂、度量标准缺失的需求条目。
• 需求之间存在明显的前置、冲突或并行关系，需提前梳理以降低排序风险。

前置条件

• 已创建初始需求池（第3章输出物：requirements_pool.csv 或 requirements_pool.md）。
• 团队已确认统一描述模板（见下方模板标准）。
• 产品经理、数据分析师、开发代表至少各1人参与清洗会议。

操作步骤

1. 描述格式化 – 使用统一模板重写每条需求，要求包含：用户角色、触发情境、期望行为、预期指标、验收假设。
2. 可测性检查 – 对照 “不可测需求” 判定清单（见下方表1），标记 可测/不可测。不可测需求移入 “待补充” 池，不进入后续排序。
3. 依赖关系标记 – 使用 前置需求ID、冲突需求ID、并行需求ID 字段在需求表格中建立关联。
4. 审核与签署 – 清洗后的需求池由三方签字确认，锁定版本。

输入输出物

不可测需求判定清单（表1）

责任边界

• 产品经理：主导需求重写、格式审核、依赖关系初步梳理。
• 数据分析师：判断指标可测性、协助定义验收假设。
• 开发代表：评估技术可行性、确认依赖关系对实现的影响。
• 记录员（建议轮值）：维护清洗后需求池版本、记录剔除理由。

记录材料

• 清洗会议纪要（含每项争议的讨论结论）
• 清洗后需求池 CSV（版本号 v4.1）
• 不可测需求回溯表（含原始ID、剔除原因、建议补充时间）

异常处理

• 需求描述与指标冲突：暂停清洗，由PM与数据岗线下对齐，再次提交会议决议。
• 依赖关系网状复杂：定义“依赖深度”字段（1级/2级/3级），只标记直接前置关系，不无限递归。
• 无法达成三方一致：将争议需求标记为“待仲裁”，上升至项目负责人，限时48小时回复。

验收标准

• 100% 需求条目已完成格式化重写，模板字段无缺失。
• 所有“不可测”条目已移入独立清单，且注明具体不符合条件。
• 依赖关系字段中不存在循环依赖（需通过脚本校验）。
• 清洗后需求池经三方签字确认，锁定版本并归档至共享目录。