第2章：前置条件与准备工作——需求池整理、干系人确认、数据可用性检查、评分模板准备
2.1 适用场景
本章所述的准备工作适用于以下场景：
- 首次引入RICE框架时：团队尚未建立标准化的排序流程，需从零构建输入规范。
- 周期性的需求优先级评审（如每季度）：在开始大规模评分之前，需确保需求池数据质量与评分模板一致性。
- 跨团队或跨项目协作的优先级排序：涉及产品、开发、运营、数据等多方参与者，需统一输入口径和评估基准。
- 需求积压严重（Backlog超过100条）：直接评分会导致效率低下，必须通过准备工作先行清洗与分类。
2.2 前置条件
在执行本章准备工作之前，需确保已满足以下条件：
| 前置条件 | 具体要求 | 检查方式 |
|---|---|---|
| 需求来源已确认 | 所有待评估需求均已录入统一的需求管理工具（如Jira、Notion、飞书多维表格） | 查看工具有无未入池的遗留需求 |
| 需求格式标准化 | 每条需求包含：标题、描述、提出方、提出时间、关联业务模块 | 随机抽查5条需求，检查字段完整性 |
| 干系人清单就绪 | 已识别参与评分的角色：产品经理、技术负责人、运营负责人、数据分析师 | 核对会议邀请列表或干系人登记表 |
| 数据访问权限 | 用于估算Reach（触达）和Effort（投入）的数据源已开放查询权限 | 测试数据查询账户能否正常读取基础数据表 |
| 评分模板初始版本 | 基于RICE四要素（Reach, Impact, Confidence, Effort）的评分表格已创建 | 确认模板包含5列以上（需求ID、Reach打分、Impact打分等） |
常见前置条件失败场景：如果部分需求仍以口头形式或零散邮件存在，未进入统一需求管理工具，则跳过本章跳过直接评分将导致评分结果错乱——重复需求会被当作两条独立需求评分，影响最终排序的公平性。
2.3 操作步骤
本节将准备工作拆解为4个连续的子步骤，每个子步骤均具备明确的输入、操作要点和输出。
步骤2.3.1：需求池清洗与分类
- 输入：来自各个需求入口的原始需求列表（至少包含标题和提交人）。
- 操作：
- 去重：按标题和描述相似度识别重复需求，合并或标记为“Duplicate”。
- 补充字段：补齐缺失的“需求价值描述”和“预期目标”。
- 分类：按业务模块或功能域标记标签（如：用户增长、支付体验、后台自动化）。
- 暂存不可评分需求：将描述模糊、缺少关键数据、处于“想法”状态的需求移入“待澄清”列表，不在本轮评分范围内。
- 输出：清洗后的候选需求池（Ready-for-RICE list），每个需求至少有清晰描述和业务标签。
步骤2.3.2：干系人确认与角色分配
- 输入：项目或产品线的组织架构图、参与者名单。
- 操作：
- 定义RICE评分角色：每个需求必须至少有1人负责Effort（投入）估算（通常是技术负责人），1人负责Reach（触达）和Impact（影响力）估算（通常是产品经理或数据分析师）。
- 确认评分权限：明确谁拥有最终打分权，谁拥有争议裁决权。
- 制定分工表：例如，产品经理A负责1-30号需求的Reach/Impact评分，技术负责人B负责该批需求的Effort评分。
- 输出：评分角色与分工表，含需求范围、评分人姓名、裁决人。
步骤2.3.3：数据可用性检查
- 输入：候选需求池、各需求关联的数据指标来源。
- 操作：
- Checklist方法：对每项需求，回答以下三个问题：
- 是否有历史数据（或可靠估算）支撑Reach的预估？
- 是否有用户反馈或商业分析支撑Impact的等级判定？
- 是否有开发团队工时估算或类似功能的历史工时作为Effort参考？
- 标记“数据缺乏”的需求：对于无法回答以上三个问题的需求，降低其Confidence（信心值），并记录缺失的数据来源。
- 建立数据字典：明确每个打分项的默认估算基准（例如：Reach以MAU（月活跃用户）为基准单位，Effort以人天为基准单位）。
- Checklist方法：对每项需求，回答以下三个问题：
- 输出：数据就绪度报告，标明哪些需求评分可信度高、哪些需特别注明依赖估算。
步骤2.3.4：评分模板准备
- 输入：候选需求池、RICE评分字段要求。
- 操作：
- 创建主模板：使用电子表格工具或项目管理软件，设计包含以下字段的模板表：
- 需求ID（唯一标识）
- 需求标题/简短描述
- Reach（数值型，如：预估触达用户数）
- Impact（枚举型：0.25, 0.5, 1.0, 2.0, 3.0）
- Confidence（百分比型：20%, 50%, 80%, 100%）
- Effort（数值型，如：预估人天数）
- RICE Score（计算列：
(Reach * Impact * Confidence) / Effort）
- 创建说明页：在模板中附带“评分参考指南”，解释每项的定义和取值案例。
- 设置数据验证：为Impact和Confidence字段添加下拉选项，防止输入非法值。
- 创建主模板：使用电子表格工具或项目管理软件，设计包含以下字段的模板表：
- 输出：可用的RICE评分模板（预填需求ID和标题，其余字段为空，待后续评分填写）。
2.4 输入输出物清单
| 步骤 | 输入物 | 输出物 | 交付形式 |
|---|---|---|---|
| 2.3.1 需求池清洗 | 原始需求列表 | 候选需求池（Ready-for-RICE list） | 电子表格或项目管理工具中的筛选视图 |
| 2.3.2 干系人确认 | 组织架构图 | 评分角色与分工表 | 成员分工说明表（Excel或飞书文档） |
| 2.3.3 数据检查 | 候选需求与数据源映射 | 数据就绪度报告 | 标注型注释或独立文档 |
| 2.3.4 模板准备 | RICE字段要求 | 可用的RICE评分模板 | 带数据验证的电子表格 |
2.5 责任边界
为确保准备工作有序推进，需明确各角色的职责划分：
| 角色 | 责任内容 | 非责任内容 |
|---|---|---|
| 产品经理（Lead） | 需求池清洗与分类、创建评分模板、组织干系人确认会议 | 不负责具体Reach和Impact的数据提取（由数据分析师支持） |
| 数据分析师 | 提供Reach和Impact的估算数据来源，参与数据可用性检查 | 不参与需求业务价值判断（由产品经理决策） |
| 技术负责人 | 确认Effort估算的数据来源（如历史工时记录），审查模板中的Effort字段合理性 | 不负责需求的商业价值排序 |
| 项目协调人/PMO | 跟踪准备工作进度，确保各干系人在截止日前完成步骤 | 不参与具体的评分事实输入 |
2.6 记录材料
本章工作完成后，应向项目归档以下记录材料：
- 需求池清洗日志：记录被移除、合并或标记为“待澄清”的需求及原因。
- 干系人确认邮件/会议纪要：确认各评分人的职责范围与截止时间。
- 数据就绪度检查表：逐项标记“数据可用”、“部分可用（需估算）”、“数据不可用”。
- 评分模板快照：保存刚创建、未填写的模板副本，作为版本基线。
2.7 异常处理
| 异常场景 | 处理措施 | 应急预案 |
|---|---|---|
| 需求池中有大量重复或有冲突的需求 | 由产品负责人召开10分钟澄清会议，合并同类项 | 若无法当场解决，暂标记为“待合并”，不放入本轮候选池 |
| 关键干系人（如技术负责人）无法参与准备工作 | 指定技术团队中具备工时估算经验的替代人，并由原负责人事后确认 | 若替代人无法确认Effort基准值，则将所有涉及该技术模块的Confidence降级为“50%” |
| 某条需求的Reach数据完全无法获取 | 使用同类功能的历史数据均值作为替代值，并在备注中标注“基于估算” | 若仍无法估算，则将该需求从本轮评分中移除，归入“需数据采集”队列 |
| 评分模板创建后发现字段缺失 | 立即补充字段并通知所有评分人，更新模板版本号 | 回收旧模板，统一替换为新版本，并重发通知 |
2.8 验收标准
本章所有准备工作完成后，需通过以下验收标准，方可进入第3章正式评分环节：
- 标准1：需求池完备性——候选需求池中的每条需求都包含标题、业务标签、描述，去重率为100%（无重复条目）。
- 标准2：干系人覆盖率——评分角色与分工表中，每个候选需求均已分配至少1名Reach/Impact评分人和1名Effort评分人。
- 标准3：数据就绪度——所有候选需求的Reach、Impact、Effort三要素中，至少有两项有数据支撑（不随意留空），且数据源已确认可用。
- 标准4：模板可用性——评分模板已包含所有必要字段，且Confidence和Effort字段已设置正确的数据验证或选项列表。
- 标准5：归档完整性——清洗日志、干系人确认记录、数据检查表、模板基线均已归档至项目文档目录。
验收通过标志：所有验收标准项均通过“是”或“符合”。若有任一标准未通过，均需返回对应步骤修正，直至全部达标。