第4章：RICE评分维度详解

本章对RICE评分法的四个核心维度——Reach（覆盖人数/影响范围）、Impact（对业务目标影响程度）、Confidence（信心分数）、Effort（人天/工期）——进行逐一定义、量化标准拆解与跨职能对齐要点说明。产品、研发、运营、设计同学将在同一套维度语言下对需求形成无歧义的评估共识，为后续的评分对齐会议提供精确输入。

4.1 适用场景

• 跨团队需求优先级排序：产品侧提出的多个需求需要统一框架进行比较时，使用RICE四维度分别打分，避免单一指标偏颇。
• 资源投入决策：在研发产能有限的情况下，通过Effort与Impact的比值（RICE总分）判断投入产出比。
• 版本路线图规划：将RICE总分从高到低排列，形成版本迭代的候选需求池。
• 跨职能对齐拉齐：当不同角色对需求价值判断不一致时，用四个维度的拆解对话代替主观争论。

4.2 前置条件

• 已完成需求收集与初步筛选，形成需求清单（含用户故事）。
• 团队已对齐核心业务目标（如DAU、转化率、留存率、营收等），且目标可量化。
• 各角色代表（产品、研发、运营、设计）已就位，并理解RICE评分的基本规则。
• 准备一份RICE评分空白模板（电子表格或协作文档），包含四个维度的打分列。

4.3 操作步骤：四维度逐项详解

以下按照定义→量化标准→评估方法→典型用户场景→跨职能对齐要点的顺序，逐一拆解每个维度。

4.3.1 Reach（覆盖人数/影响范围）

• 定义：该功能上线后，在指定时间周期（通常为1季度或1个月）内预期能覆盖到的独立用户数或业务事件量。
• 量化标准（0-10分）：

  分数	覆盖量级（月活基准）	典型场景
  10	≥ 全量用户（如100万+）	登录页改版、全局导航优化
  7-9	核心用户群体（如30万-100万）	会员中心升级、核心功能入口调整
  4-6	特定用户分层（如5万-30万）	新用户引导流程、高活跃用户专属功能
  1-3	小众或长尾用户（如<5万）	后台管理优化、特定权限角色功能

• 评估方法：基于当前用户量基数 × 功能触达比例（由产品与运营共同估算）。
• 用户场景示例：

  场景：“注册流程增加手机号一键验证”功能。运营数据显示当前注册页月均UV为80万，预计该功能可覆盖70%的注册用户，即56万用户。对照量表，Reach评8分。

• 跨职能对齐要点：研发需确认技术限制是否会降低实际覆盖（如仅支持Android端），运营需提供真实用户分层数据，避免估算偏差。

4.3.2 Impact（对业务目标影响程度）

• 定义：该功能对核心业务指标（如转化率、留存率、ARPU等）的提升程度，而非用户满意度或体验优化等间接指标。
• 量化标准（0-10分）：

  分数	指标提升幅度	典型效果
  10	≥ 20% 核心指标提升	支付转化率从5%升至6%+
  7-9	10%-20% 核心指标提升	次日留存率提升12%
  4-6	3%-10% 核心指标提升	注册转化率提升5%
  1-3	< 3% 核心指标提升	后台导出效率优化，间接影响有限

• 评估方法：使用历史AB测试数据、行业基准或最小可行产品（MVP）验证结果进行预估。
• PRD片段示例：

  ## 3. 业务目标与Impact预估
  
  功能名称：购物车凑单推荐
  核心指标：客单价（ASP）
  当前基准：客单价 ¥128
  预期提升：客单价 → ¥142（+10.9%）
  对标Impact量表：8分
  数据支撑：2024年Q3「凑单推荐」AB测试实验组
           客单价提升11.2%，置信区间95%

• 跨职能对齐要点：Impact必须绑定一个可量化且团队一致认可的核心指标，避免各角色使用不同的成功标准。建议在评分前由数据分析师提供基准数据。

4.3.3 Confidence（信心分数）

• 定义：评分者对Reach和Impact预估的确信程度，反映数据和经验支撑的充分性。
• 量化标准（0-100%，或折算为0-10分）：

  分数	确信程度	数据支撑情况
  90%-100%	高度确信	有直接AB测试数据、完整用户行为日志或权威第三方报告
  70%-89%	比较确信	有间接数据或相似功能历史表现可参考
  50%-69%	中等确信	基于用户调研、行业经验或逻辑推演
  < 50%	低确信	主要凭直觉、猜测或未经验证的假设

• 评估方法：每位评分者独立打分后取平均值，并标注最高与最低分差异。若差异超过30个百分点，需在对齐会议中重点讨论。
• 用户场景示例：

  实用技巧：Confidence评分不是对功能好坏的判断，而是对数据基础的诚实评估。如果团队对一个需求的Reach和Impact预估高度一致且有数据支持，Confidence自然提高；反之，则需优先补充调研或实验。

• 跨职能对齐要点：研发同学容易因为「技术实现不确定」而给低Confidence——此时应区分业务信心与技术信心，本章的Confidence特指业务预估信心，技术不确定性应在Effort维度中体现。

4.3.4 Effort（人天/工期）

• 定义：实现该功能所需的总人天或日历工期，包含设计、开发、测试、联调、上线等全流程。
• 量化标准（人天数为绝对值，RICE总分计算时取倒数或减分处理）：

  Effort等级	人天范围	典型类型
  小（10分档）	≤ 5人天	文案修改、样式调整、简单埋点
  中（7-9分档）	6-20人天	新增页面、表单交互、基础接口对接
  大（4-6分档）	21-60人天	模块重构、复杂业务逻辑、多端联调
  特大（1-3分档）	≥ 61人天	系统架构变更、底层数据库迁移、跨团队大型项目

• 评估方法：由研发负责人或技术团队给出初步工作量估算，并使用缓冲系数（通常为1.2-1.5倍）应对不确定性。
• PRD片段示例：

  ## 5. 工作量估算
  
  功能名称：购物车凑单推荐
  前端开发：8人天（含UI适配）
  后端开发：6人天（含推荐算法接口）
  测试联调：4人天
  合计：18人天
  缓冲（1.3x）：23.4人天 → 取整24人天
  Effort等级：中（7分档）

• 跨职能对齐要点：Effort必须由实际执行方（研发）主导估算，产品与运营不应擅自压缩。同时，Effort应包含非开发环节（如设计评审、UE测试、灰度观察期），避免低估实际工期。

4.4 输入输出物

类型	名称	格式/载体	责任人
输入	需求清单（含用户故事）	在线文档 / Jira Epics	产品经理
输入	核心业务指标定义与基准数据	数据看板 / 分析报告	数据分析师
输入	技术实现方案与初步工作量估算	技术评估文档	研发负责人
输出	RICE评分表（含四维度分值）	协作表格 / Airtable	产品经理（汇总）
输出	维度分歧记录（用于对齐会议）	评论 / 标注 / 单独文档	全体参与者

4.5 责任边界

• 产品经理：发起Reach与Impact的初始预估，提供用户场景与业务目标关联说明；组织Confidence评分并记录分歧。
• 研发负责人：主导Effort估算，明确技术约束与工期风险；对Impact中的技术可行性提供判断。
• 运营同学：提供用户分层数据、渠道触达数据，辅助Reach估算；从运营视角验证Impact的业务逻辑。
• 设计师（可选）：在涉及UI/UX调整的需求中，提供设计工作量输入，辅助Effort估算。
• 数据分析师：提供历史数据基准、AB测试参考数据，支撑Confidence评分的客观性。

4.6 记录材料

材料名称	核心字段	保存位置
RICE评分总表	需求ID、需求名称、Reach、Impact、Confidence、Effort、RICE总分、评分人、备注	项目协作文档 / 飞书多维表格
维度分歧记录表	需求ID、分歧维度、评分人A值、评分人B值、差异原因、是否已对齐	同上（作为RICE总表的附属Sheet）
工作量估算明细	需求ID、前端人天、后端人天、测试人天、联调人天、缓冲系数、总人天	技术评估文档 / Wiki

4.7 异常处理

4.8 验收标准

• 每个需求在RICE总表中已完成四个维度全部打分，无空白项。
• 每个维度的评分均附带简要依据说明（如“基于Q3注册漏斗数据”），而非仅数字。
• Confidence评分中，若存在≥30个百分点的差异，已记录分歧原因并安排对齐讨论。
• Effort估算已包含全流程人天（设计+开发+测试+联调+上线），并标注缓冲系数。
• 所有评分人的姓名与角色已记录在评分表中，确保可追溯。