第2章 需求收集与整理：建立需求池模板、需求描述规范、原始数据收集责任边界

2.1 适用场景

本章流程适用于以下三类典型场景：

• 新需求涌入：业务方、用户、运营等多渠道同时提交原始需求，需要统一入口收口，避免遗漏或重复。
• 需求池初始化：产品从零搭建或重建需求池时，需要定义字段模板与描述标准，保证后续RICE评分的输入质量。
• 权责不清导致阻塞：团队中经常出现“谁负责描述需求”“谁评估可行性”等争议，需要明确责任边界。

2.2 前置条件

• 已完成第1章“RICE评分框架共识”培训，团队对RICE四要素（触达、影响、信心、努力）有统一理解。
• 已确定需求池的存放位置（如Confluence、Jira、飞书文档、Airtable），并开放编辑权限。
• 产品经理已获得业务方、开发、运营等角色的对接人清单。
• 团队已约定“需求提出→入库”的SLA时限（如≤2个工作日完成初步录入）。

2.3 操作步骤

本流程共5个步骤，各步骤与下方SVG流程图节点一一对应：

1. 原始需求收集：从用户反馈、业务方诉求、数据分析、竞品跟踪等渠道收拢原始信息，记录到临时收集表。
2. 需求描述规范：按用户故事格式（As‑I‑Want‑So that）撰写需求正文，并附验收条件，确保语义无歧义。
3. 需求池模板录入：将规范后的需求逐字段填入需求池模板（字段定义见2.4节），完成结构化存储。
4. 需求验证与分类：由产品经理主导，联合开发、业务方进行真伪判断、价值评估与技术可行性初筛。
5. 进入RICE优先级队列：通过验证的需求正式进入“待RICE评分”状态，等待第3章评分排序。

2.4 输入输出物

需求池模板字段定义

2.5 责任边界

为避免“需求没人写、写不清楚、写了没人审”等权责纠纷，按RACI模型锁定各角色职责：

R = 执行者（Responsible）  C = 参与/咨询（Consulted）  — = 不参与

2.6 记录材料

本章执行过程中需要留存以下材料，用于回溯和审计：

1. 原始需求收集日志：记录每条需求的来源渠道、提出人、提出时间、原始信息截图/邮件存档。
2. 需求池变更历史：通过版本管理（如飞书多维表格的历史记录）保留每次增、删、改的痕迹。
3. 需求退回与补充记录：因描述不合格被退回的需求，须记录退回原因、补充次数、最终通过时间。
4. 责任边界确认签字页：团队各角色负责人签署的RACI矩阵确认表（可电子签）。

2.7 异常处理

2.8 验收标准

本章所有流程执行完毕后，需满足以下标准方可视为完成：

• ✅ 需求池模板已定稿并在团队内发布，所有字段定义清晰、无歧义。
• ✅ 至少完成3条完整的需求从“原始收集→模板录入→验证分类”的全流程试跑。
• ✅ 各角色已阅读并确认RACI责任矩阵，无权责争议。
• ✅ 需求描述规范文档已存放至团队公共知识库，且阅读率≥80%（可通过文档阅读统计校验）。
• ✅ 异常处理机制已验证：模拟一次“描述模糊退回”场景，从触发到关闭的时长≤2个工作日。