第3章：前置条件清单

前置条件清单是启动 RICE 评分前的准入检查层，确保待筛选功能列表、用户故事、已有数据、产品路线图和利益相关者确认五类物料全部就位。缺少任何一项都会导致评分结果失真或评审流程阻塞。

适用场景

本章节适用以下三类典型场景：

  • 首次引入 RICE 评分：团队尚无标准化前置检查流程，需要建立清单模板。
  • 季度/迭代评审前：已有功能池但物料散乱，需集中核查完整性。
  • 跨职能协作分歧：产品、数据、业务方对评分输入认知不一致，需统一基线。
💡 建议：前置条件清单建议在迭代计划会前 2 个工作日由 PM 发起核对，预留异常处理时间。

前置条件

执行本章操作前，团队必须已完成以下准备：

  1. 原始需求池已完成初步去重与归类，形成候选功能列表草稿。
  2. 用户故事已通过 INVEST 原则 自检（Independent, Negotiable, Valuable, Estimable, Small, Testable）。
  3. 数据团队已导出近 3 个月可用数据集（含埋点事件、转化漏斗、DAU 等）。
  4. 产品路线图已更新至当前版本，并标注了里程碑时间点。
  5. 利益相关者名单已确认，且至少 2/3 的 key stakeholder 已承诺参与评审。
⚠️ 常见遗漏：数据字段定义不统一（如“活跃用户”各系统口径不同）是前置条件阶段最容易被忽略的问题。建议提前与数据工程师对齐字典。

操作步骤

按照以下 5 个步序依次检查并补全前置物料：

步骤 操作 要点说明
Step 1 收集待筛选功能列表 从需求池中导出所有候选功能，标注编号、提出方、提出日期；剔除重复项与已废弃需求。
Step 2 整理用户故事 为每个功能编写标准用户故事（As a … I want … So that …）；附加验收条件 1~3 条。
Step 3 准备已有数据 确认数据源表、时间范围、粒度；对缺失值做标记，不强制补全但需记录影响范围。
Step 4 对齐产品路线图 将候选功能与路线图现有史诗/特性对照，标注“已规划”“未规划”“冲突”状态。
Step 5 确认利益相关者 发送确认函并收集回执；记录每位 stakeholder 的关注维度（用户/营收/技术/风险）。
📋 执行建议：Step 1~3 由产品经理主导，Step 4 需与技术负责人联合完成，Step 5 由 PM 或 PO 统一协调。

输入输出物

类别 具体内容
输入物 原始需求池（Excel / Jira 导出）、用户调研报告、数据仓库表结构文档、产品路线图 v2.3+、利益相关者通讯录
输出物 前置条件清单检查表（含 5 个一级状态 & 15 个二级检查项）、就绪/阻塞标识、未达标项的 Action 清单

责任边界

角色 职责范围
产品经理 主导功能列表与用户故事的收集、完整性审核；发起前置条件核查会议。
数据分析师 提供可用数据清单及字段说明；标记数据质量风险（缺失、延迟、口径不一）。
技术负责人 确认路线图中技术依赖项是否就绪；评估功能与现有架构的兼容性。
业务方 / 利益相关者 确认功能价值主张；反馈业务侧优先级信号；签署准入确认书。
Scrum Master 监督流程合规性；推动阻塞项的升级与解决。
📌 权责分界：PM 对清单的完整性负责，数据工程师对数据可用性负责，stakeholder 对价值判断负责。三方不可互相替代。

记录材料

以下为前置条件清单的标准记录模板（JSON 结构），建议存入项目 Wiki 或共享文档：

{
  "checklistId": "RICE-PRE-2025-001",
  "generatedAt": "2025-01-20T10:00:00+08:00",
  "items": {
    "待筛选功能列表": {
      "status": "✅ 已就绪",
      "count": 28,
      "lastVerified": "2025-01-19",
      "owner": "PM-张三"
    },
    "用户故事": {
      "status": "⚠️ 部分缺失",
      "count": 24,
      "missingIds": ["F-009", "F-014"],
      "lastVerified": "2025-01-18",
      "owner": "PM-李四"
    },
    "已有数据": {
      "status": "✅ 已就绪",
      "dataSources": ["clickstream_v3", "order_flat"],
      "coverageDays": 90,
      "lastVerified": "2025-01-17",
      "owner": "DA-王五"
    },
    "产品路线图": {
      "status": "✅ 已对齐",
      "version": "v2.4",
      "conflicts": [],
      "lastVerified": "2025-01-16",
      "owner": "TL-赵六"
    },
    "利益相关者确认": {
      "status": "✅ 已确认",
      "stakeholders": ["CPO", "CTO", "业务总监-陈七"],
      "confirmationRate": "3/3",
      "lastVerified": "2025-01-15",
      "owner": "PO-孙八"
    }
  },
  "overallStatus": "🟢 可进入 RICE 评分"
}
📁 归档要求：每次迭代评审前更新该 JSON 并附带版本标签（如 pre-check-v1.2.json），历史版本保留至少 3 个月。

异常处理

异常场景 影响 处置措施
功能列表超过 50 项且未分类 无法确定评分优先级，评分会议超时 按「用户价值/实现成本」二维矩阵预分组，每组≤10 项再进入 RICE
用户故事缺少验收条件 评分时 Reach/Impact 难以量化 冻结该功能评分，要求提出方 24h 内补全；紧急情况下由 PM 代写后确认
已有数据时间范围不足 30 天 Confidence 评分偏差大 标记为“低信度”，评分时 Confidence 上限设为 0.5；同步数据团队加速采集
路线图版本与当前迭代不匹配 功能被误判为“未规划” 暂停清单核对，由 PM 与技术负责人 1h 内对齐路线图版本后重新校验
关键利益相关者未回复确认 评审结果可能被事后推翻 升级至项目发起人，设置截止时间；截止前未确认则标注“待回溯”
⛔ 红线原则：若 5 项前置条件中有 2 项及以上处于“阻塞”状态，禁止启动 RICE 评分，必须先行开展清障 Sprint。

验收标准

本章操作完成后，需同时满足以下条件方可视为通过：

  1. 完整性：5 类前置条件均存在对应物料，且每类物料至少有 1 条记录。
  2. 一致性：功能列表与用户故事一一对应，无孤立项。
  3. 时效性：所有物料的 lastVerified 日期不超过当前日期 7 天。
  4. 可追溯：每个前置条件均标注了 owner，且 owner 已确认。
  5. 就绪率：整体状态标记为 🟢 可进入 或 🟡 有条件进入（阻塞项≤1 且有明确解决计划）。
✅ 通过标志：输出物《前置条件清单检查表》中 overallStatus 为 "🟢 可进入 RICE 评分"，且所有异常均已分配 Action 项。

前置条件清单五大要素关系图

下图展示了五类前置条件如何汇聚为统一的准入基线，并驱动 RICE 评分启动：

前置条件清单五大要素关系图 ① 功能列表 待筛选 ② 用户故事 已编写 + 验收条件 ③ 已有数据 30天 + 字段字典 ④ 产品路线图 版本已对齐 ⑤ 利益相关者 确认函回执 ≥2/3 前置条件清单整合验证 ✅ RICE 评分启动就绪 图例：五类物料 → 整合校验 → 评分启动 | 所有节点均需达到“就绪”或“有条件就绪”

该图应作为前置条件检查会议的共享视觉框架，每个节点可展开为子检查表，确保团队在同一基线上下文中讨论 RICE 评分。

← 上一章 📖 返回目录 下一章 →