第2章 RICE优先级模型概述
适用场景
RICE 优先级模型适用于硬件产品从 EVT 到 DVT 阶段的任务排序，尤其是当多个验证缺陷、设计变更或测试用例需要资源分配时。该模型可帮助团队在有限时间和预算内选择影响最大、置信度最高的任务优先执行。
- 多维度评估：需同时考虑影响范围、影响强度、证据可靠性、投入工作量。
- 数据驱动决策：已有早期测试数据或用户反馈提供量化支撑。
- 跨角色协调：硬件、固件、测试、产品经理需对优先级达成共识。
前置条件
- 已完成 EVT 阶段至少一个测试轮次，积累初步缺陷/任务清单。
- 团队已定义 Reach、Impact、Confidence、Effort 的评分标准（如 1~5 分制）。
- 每项任务已具备初步描述和可评估的客观依据（如测试报告、用户反馈、工程估算）。
- 已指定至少一名 RICE 评分协调人（通常为测试经理或产品经理）。
操作步骤
| 步骤 | 动作 | 输出 |
|---|---|---|
| 1. 列出待排任务 | 将当前 backlog 中的缺陷、需求、优化项整理为任务列表 | 任务清单（编号+描述） |
| 2. 评估 Reach | 估算每个任务在目标用户/设备/场景中的覆盖比例（0~1 或 1~5） | Reach 分数 |
| 3. 评估 Impact | 估算任务解决后对用户满意度、性能、合规性的提升程度 | Impact 分数 |
| 4. 评估 Confidence | 基于已有数据、经验判断的可信度（1~5） | Confidence 分数 |
| 5. 评估 Effort | 估算所需人天、工时、设备成本（1~5，越大越费力） | Effort 分数 |
| 6. 计算 RICE 分 | RICE = (Reach × Impact × Confidence) / Effort | 优先级排序表 |
输入输出物
输入物
- EVT 阶段缺陷清单（含严重等级、重现概率）
- 用户场景/用例覆盖率矩阵
- 工程工作量预估（小时/人天）
- 历史测试数据或行业对标数据
- RICE 评分表（每项任务四个维度的分值及计算分数）
- 按 RICE 分数降序排列的任务优先级队列
- 讨论纪要（争议项的裁剪理由记录）
责任边界
| 角色 | 职责 | 不可越界 |
|---|---|---|
| 测试工程师 | 提供 Reach、Impact 的客观数据与测试证据 | 不能仅凭主观感觉赋分 |
| 开发工程师 | 提供 Effort 估算与 Confidence 的技术依据 | 不能偏向自己负责的模块 |
| 产品经理 | 主持评分会议，裁决歧义分数，输出最终排序 | 不得越过团队直接决定优先级 |
| 测试经理 | 维护 RICE 评分模板，归档记录材料 | 不允许修改评分逻辑而不通知团队 |
记录材料
- 评分表模板：固定字段（任务编号、描述、Reach、Impact、Confidence、Effort、RICE分、备注）
- 讨论录音/会议纪要：记录争议点、投票结果、异常处理决策
- 版本变更日志：每次重新评分时记录修改原因和参与者
异常处理
- 多任务 RICE 分数相等：优先选择 Confidence 更高的任务；若仍相同，由产品经理结合业务战略决策。
- 缺少可靠数据无法评估 Confidence：先分配最低分（1），标记为“需补充测试”，安排快速验证实验后重新评估。
- Effort 估算出现±50%以上偏差：暂停评分，要求开发工程师重新分解工作包后再次估算。
- 团队对 Impact 评分分歧过大：按照“最小影响”原则取平均值，并记录反对意见。
验收标准
- 每项任务均填写 Reach、Impact、Confidence、Effort 四个维度的分值，且分值处于预定义范围内（如1~5）。
- RICE 分数计算正确，且经两人以上复核。
- 生成的优先级队列前三项有明确的执行负责人和计划开始时间。
- 所有异常处理场景在会议纪要中有对应记录和决策依据。