第四章 前置条件检查清单

在启动RICE模型进行MVP范围界定前，必须完成四项前置条件的系统性检查。本章提供结构化的检查流程，确保数据可用、团队齐备、标准一致、时限明确，避免后续评估过程中出现基础断言失效或协作混乱。

适用场景

当产品经理或敏捷团队计划使用RICE模型对需求池中的候选特性进行评分和优先级排序，且需要将范围收缩为可交付的MVP时，必须执行本章的前置条件检查。具体场景包括：

• 季度规划会议前，需从产品待办列表（Backlog）中筛选MVP范围。
• 跨职能团队（PM、开发、设计、数据）首次合作使用RICE模型。
• 历史数据不完整或评分标准未经验证的项目重启阶段。
• 需要确认时间窗口（如冲刺周期、发布冻结日）与评估节奏匹配。

前置条件

在开始本章检查之前，团队必须已具备以下基础条件：

• 已形成至少一个候选特性列表（Feature List），每条特性有唯一标识和简要描述。
• 已指定一名RICE模型协调人（通常为产品经理或Scrum Master）。
• 业务目标（OKR/KPI）已明确，且团队已对齐优先级期望。
• 基础工具链就绪（评分表、共享文档、或专用工具如Airfocus/Notion）。

操作步骤

1. 步骤1：数据完整性检查
   • 确认每个候选特性的 Reach（覆盖用户数）、Impact（影响力）、Confidence（信心指数）、Effort（工作量）所需的基础数据来源。
   • 检查数据是否存在超过30%的缺失：若缺失，标记为“待补充”，并记录缺失字段。
   • 对定量数据（如DAU、转化率）要求提供最近90天的均值；定性数据（如用户调研反馈）需注明样本量。
2. 步骤2：评估团队组建
   • 组建至少3人评估小组，涵盖产品、技术、设计角色。
   • 指定一名主评人（负责最终评分仲裁）和一名记录员（负责在表格中写入评分理由）。
   • 确保所有成员已阅读RICE定义文档并通过一致性校准测试（
     校准测试：每个成员对同一个典型特性独立评分，分歧超过1个等级则需讨论对齐。
     ）。
3. 步骤3：评分标准对齐
   • 组织一次30分钟的对齐会议，对照以下表格确认每个维度的刻度含义：

   维度	1分	2分	3分	4分
   Reach	极少用户（<100）	部分用户（100~1k）	主要用户（1k~10k）	全部用户（>10k）
   Impact	微小改进	中等提升	显著提升	突破性影响
   Confidence	极低（猜测）	低（间接证据）	中（定量+定性）	高（A/B测试或历史数据）
   Effort	极大（>80人天）	大（20~80人天）	中（5~20人天）	小（<5人天）

   • 记录对齐会议结论，若有分歧，写入《评分标准勘误记录》。
4. 步骤4：时间窗口确认
   • 确定评估截止时间（DDL）和评审会议时间。
   • 确认评估周期内不会发生重大数据变动（如版本发布、运营活动）。
   • 若时间窗口小于48小时，需调整评估数量或启用快速评分模式（仅使用Reach×Impact作为初筛）。

输入输出物

类型	输入物	输出物
数据	候选特性列表（含描述、初步数据来源）	数据完整性检查报告（缺失字段标记）
人员	项目干系人名单、角色分工草案	评估团队登记表（含签名和校准结果）
标准	RICE刻度初始草案（可来自历史项目）	对齐后的评分标准表（含示例说明）
时间	项目日历、主要里程碑	时间窗口确认单（含截止时间和风险备注）

责任边界

• 产品经理（协调人）：主导数据完整性检查和时间窗口确认；对数据缺失负首要责任。
• 评估团队全体成员：参与评分标准对齐会议并签署理解承诺；缺席者需在24h内单独补考校准测试。
• 技术负责人：提供Effort的初步估算范围，确保工作量维度数据可重复验证。
• 记录员：在检查表中如实记录每个步骤的通过/失败状态，且签字确认。
• 责任不可交叉：协调人不应同时担任记录员，避免单方误判不可追溯。

记录材料

所有记录材料统一使用以下模板（JSON格式，可导入工具或打印）：

{
  "checklist_id": "RICE-PRE-2025-0301",
  "team": ["PM: Alice", "DEV: Bob", "DESIGN: Carol"],
  "data_integrity": {
    "total_features": 12,
    "missing_fields": ["feature_07_effort", "feature_10_reach"],
    "status": "FAIL (need supplement)"
  },
  "team_formation": {
    "members": ["Alice", "Bob", "Carol"],
    "calibration_score": 92,
    "status": "PASS"
  },
  "scoring_alignment": {
    "meeting_date": "2025-03-01",
    "discrepancies_resolved": 3,
    "status": "PASS"
  },
  "time_window": {
    "evaluation_deadline": "2025-03-05T18:00",
    "confidence_note": "Avoid major release on Mar 3",
    "status": "PASS"
  },
  "overall_verdict": "PASS"
}

异常处理

异常场景	处理措施	升级路径
数据缺失>30%	暂停检查，协调数据团队补充；若无法补充，标记为“低置信度”并限定只能在Confidence维度给1分。	上报项目总监，决策是否推迟MVP界定。
评估团队不足3人	从相邻项目借调人员；或使用PM+Dev两人制加外部顾问（需在记录中注明“缩减团队”）。	向Scrum Master申请临时资源。
评分标准无法对齐	以历史项目评分均值为基准，强制使用4档固定刻度；差异部分由产品经理最终裁定。	召开加时对齐会，最迟2小时内解决。
时间窗口不足48h	启用快速评分模式（仅评估Reach×Impact），后续迭代再补Confidence和Effort。	通知所有干系人调整预期。

验收标准

1. 所有四项检查步骤均标记为“PASS”或“带条件通过”。
2. 记录材料JSON字段完整且合法（可使用jsonlint验证）。
3. 评估团队所有成员已完成校准测试且分歧率低于15%。
4. 时间窗口确认单上无超过24h的未关闭风险项。
5. 协调人、记录员、技术负责人三方签字（电子签名或实体签名）归档。