第3章：准备输入材料——待评估功能列表、用户规模数据、业务目标、资源约束清单、历史置信度参考
RICE 评分的准确性高度依赖输入材料的质量。若输入材料缺失、格式不一或数据来源不可信，后续的 Reach、Impact、Confidence 三项评分将产生系统性偏差，最终导致 MVP 范围界定偏离实际业务方向。本章提供五类核心输入材料的准备标准与操作流程。
📌 章节定位：本流程位于 RICE 评分的“数据准备”阶段，是连接“需求收集”与“评分计算”的关键枢纽。建议在产品立项会议前 2 个工作日完成全部材料准备。
3.1 适用场景
- 产品团队已完成需求收集，待评估功能条目超过 15 条，需通过 RICE 模型筛选 MVP 范围。
- 涉及跨部门资源协调（如研发、运营、市场），需统一数据口径以降低沟通成本。
- 公司层面存在历史项目数据积累，需利用置信度参考提升评分可复现性。
- 产品经理首次主导 RICE 评分，希望建立标准化输入物模板以提升团队协作效率。
3.2 前置条件
- 已完成 MVP 目标声明：产品负责人与核心干系人对本轮 MVP 的核心指标（如 DAU 提升 20%、订单转化率提升 5%）达成共识。
- 已确定参与评分的功能候选清单：至少包含 10 条以上、已去重且表述一致的功能描述。
- 已识别关键干系人：数据工程师、业务运营负责人、技术架构师需承诺在本阶段提供数据支持。
- 基础数据采集通道就绪：埋点系统、BI 看板、历史项目文档库可正常访问。
3.3 操作步骤
本阶段共 5 个操作步骤，完成顺序不分先后，但所有步骤完成后需通过材料完整性检查方可进入评分环节。
| 步骤编号 | 步骤名称 | 操作描述 | 输出物 | 责任方 |
|---|---|---|---|---|
| S3-1 | 整理待评估功能列表 | 将原始需求描述统一为 “用户角色 + 预期行为 + 价值主张” 格式；每项功能附 1-2 句场景说明。 | 功能列表文档（.md / .xlsx） | 产品经理 |
| S3-2 | 采集用户规模数据 | 从数据平台获取近 30 天活跃用户数、目标用户分群人数、各渠道触达频次日均值。 | 用户规模数据表 | 数据工程师 |
| S3-3 | 对齐业务目标 | 复核 MVP 目标声明，拆解为可量化的北极星指标与 3 个以下的过程指标。 | 业务目标拆解卡片 | 产品负责人 |
| S3-4 | 梳理资源约束清单 | 统计可用研发人力（人/日）、设计工时、运营预算、外部依赖（如 SDK 接入周期）。 | 资源约束清单 | 技术负责人 / 项目经理 |
| S3-5 | 引用历史置信度参考 | 选取过去 3 个同类型项目的 RICE 评分记录，提取 Confidence 修正系数表。 | 历史置信度参考表 | 产品经理 / 数据工程师 |
⚠️ 关键避坑：步骤 S3-2 和 S3-3 容易产生“数据口径冲突”。例如，用户规模使用“日活”还是“周活”必须与业务目标中的时间粒度一致。若目标为“提升月留存”，用户规模应使用“月活跃用户（MAU）”。
3.4 输入输出物
| 类别 | 输入物 | 来源 | 输出物 | 接收方 |
|---|---|---|---|---|
| 功能 | 原始需求列表（用户反馈、竞品分析、内部提案） | 用户研究 / 运营 / 管理层 | 待评估功能列表（标准化格式） | 全部评分参与者 |
| 数据 | BI 系统原始查询结果、埋点事件表 | 数据平台 | 用户规模数据表（含口径说明） | 产品经理、评分人 |
| 目标 | MVP 目标声明（文字描述） | 产品负责人 | 业务目标拆解卡片（含北极星指标） | 全团队 |
| 资源 | 项目排期表、预算审批单、依赖方承诺函 | PMO / 财务 / 技术 | 资源约束清单（结构化字段） | 产品经理、评分人 |
| 置信度 | 历史项目 RICE 评分档案、复盘文档 | 知识库 / 文档系统 | 历史置信度参考表（含修正系数） | 产品经理、评分人 |
3.5 责任边界
- 产品经理：主导材料收集全流程，对功能列表格式正确性、数据口径一致性负总责。
- 数据工程师：负责用户规模数据的提取与清洗，需在数据表内标注口径定义与数据采集时间窗口。
- 技术负责人：提供资源约束清单中研发人力、技术依赖项评估，并签字确认。
- 产品负责人：终审业务目标拆解卡片，确保北极星指标与公司战略对齐。
- 评分参与者：有权要求材料提供方补充说明或提供原始数据溯源路径。
📋 责任边界检查点：在材料收集完成后，产品经理应组织一次 15 分钟的“输入材料轻量评审”，逐项核对五类材料是否均已满足“可读、可算、可追溯”三个标准，并签字确认。
3.6 记录材料
以下记录材料需归档至项目文档库，作为后续评分争议时的回溯依据：
- 材料完整性检查清单：包含五类材料的文件名、版本号、提交人、提交时间、审核状态。
- 数据溯源记录表：用户规模数据的 SQL 查询语句、查询时间、数据源表名、过滤条件。
- 历史置信度参考来源清单：项目名称、评分时间、评分人、是否通过复盘验证。
【材料完整性检查清单 模板示例】
| 材料类别 | 文件名 | 版本 | 提交人 | 提交时间 | 审核状态 |
|------------------|----------------------------|------|--------------|------------|----------|
| 待评估功能列表 | feature_list_v1.2.xlsx | 1.2 | 张昊(PM) | 2025-03-10 | ✅ 通过 |
| 用户规模数据表 | user_scale_v1.0.xlsx | 1.0 | 李薇(DE) | 2025-03-11 | ✅ 通过 |
| 业务目标拆解卡片 | business_goals_v1.1.md | 1.1 | 王磊(PO) | 2025-03-09 | ⏳ 待审 |
| 资源约束清单 | resource_constraints_v1.0.xlsx | 1.0 | 陈晨(TechLead) | 2025-03-11 | ✅ 通过 |
| 历史置信度参考表 | confidence_ref_v2.0.xlsx | 2.0 | 张昊(PM) | 2025-03-10 | ✅ 通过 |3.7 异常处理
| 异常类型 | 典型表现 | 处理措施 | 升级路径 |
|---|---|---|---|
| 数据缺失 | 某功能领域完全无埋点数据，无法估算用户规模 | 1. 使用行业对标数据进行估算（标注置信度折扣 0.5） 2. 将该项功能标记为“数据待补充”，评分时 Confidence 直接取值 0.3 |
数据工程师 -> 数据负责人 |
| 数据口径冲突 | 用户规模表使用 MAU，业务目标使用“日新增用户数” | 1. 统一转换为“日均活跃用户（DAU）”作为桥梁指标 2. 在材料中附口径换算说明 |
产品经理 + 数据工程师联合处理 |
| 业务目标不清晰 | 目标描述为“提升用户体验”，无法量化 | 1. 产品负责人在 1 个工作日内将目标拆解为具体指标 2. 若超时则暂缓该轮评分，等待目标明确后继续 |
产品经理 -> 产品负责人 |
| 历史置信度参考不适用 | 历史项目类型与当前项目差异较大（如 B2C vs B2B） | 1. 扩大历史参考范围，选取 5 个以上背景相似项目求中位数 2. 若无相似项目，则 Confidence 基准值设为 0.5 |
产品经理 + 数据工程师 |
| 资源约束超出预期 | 可用研发人力仅为计划值的 40% | 1. 触发 MVP 范围缩减预案，将功能按优先级重新分组 2. 在评分前附加“资源超限”标签，提醒评分人调整 Effort 权重 |
技术负责人 -> PMO 负责人 |
💡 经验值：在历史项目中，数据缺失和业务目标不清晰是导致 RICE 评分返工的两大主因，占全部异常事件的 68%。建议团队在材料准备阶段预留 4 小时专门用于“数据口径对齐会”和“目标拆解工作坊”。
3.8 验收标准
以下五项验收标准全部满足后，方可进入下一章“RICE 评分执行”环节：
- 完整性：五类材料均已提交，且通过材料完整性检查清单的审核。
- 一致性：用户规模数据、业务目标、资源约束清单之间的时间粒度与指标口径完全一致。
- 可追溯：每类材料均附带数据来源说明或 SQL 查询附件。
- 可理解：所有参与评分的人员阅读材料后，能独立说出每项功能的 Reach 基数来源。
- 签名确认：产品负责人、技术负责人、数据工程师三方在“输入材料验收确认单”上签字或钉钉/企业微信确认。
⏰ 硬性时间约束：材料准备阶段最长不超过 3 个自然日（从需求列表定稿到验收确认单签署）。超时则触发异常升级流程，由项目总监介入裁决是否调整 MVP 时间窗口。
3.9 本章核心流程视图：输入材料准备全景图
下图展示了五类输入材料的来源、准备步骤与交付物之间的整体关系，帮助团队在开始材料收集前建立全局认知：
🧭 SVG 视图导读：左列展示五类输入材料及其责任方，中间为四步标准准备流程，右列为三类交付物。材料准备从左侧出发，经过流程节点处理后汇聚到右侧输出物，形成“材料 -> 流程 -> 交付”的完整链路。