**输入物清单**
- 已录入的《硬件需求池》（至少包含需求 ID、标题、描述、提出人）
- 各需求对应的：覆盖用户数（Reach）、对核心指标的影响权重（Impact）、可行性评估结论（Confidence）、预计人/天（Effort）
- 团队角色确认：至少需要 1 名硬件产品经理、1 名系统架构师、1 名测试负责人参与打分
### 操作步骤
本章节不涉及具体打分操作（第 2～5 章展开），仅建立框架认知与评分模板。
1. **定义四个因子**（本章完成概念对齐）
2. **统一打分基准**：Reach 用“覆盖用户数区间”，Impact 用“对 OKR 的贡献度（0.25/0.5/1/2/3）”，Confidence 用百分比估计，Effort 用预估人/天
3. **计算 RICE 分数**：`RICE = (Reach × Impact × Confidence) / Effort`
4. **排序并检查一致性**：分数高的需求优先；若分数相近则由架构师仲裁
### 输入输出物
| 阶段 | 输入物 | 输出物 |
|------|--------|--------|
| **概述阶段**（本章） | 市场调研报告、竞品分析、用户反馈摘要 | 团队共识：RICE 适用于本产品线的范围声明 |
| **后续章节** | 需求池 + 因子打分表 | 排序后的《硬件需求优先级矩阵》 |
### 责任边界
| 角色 | 职责 | 不负责 |
|------|------|--------|
| 硬件产品经理 | 维护需求池，组织 RICE 打分会议 | 具体技术方案评审 |
| 系统架构师 | 提供 Reach/Effort 的工程估算 | 商业价值判断（由 PM 负责） |
| 测试代表 | 评估 Confidence（测试风险） | 开发资源分配 |
| 项目负责人 | 最终批准排序结果 | 因子打分细节（授权给团队） |
### 记录材料
必须归档以下文件至项目共享目录：
- **RICE 因子评分卡**（Excel 模板）：每季度归档一次
- **仲裁记录**：当分数相同或团队争议时，架构师写仲裁说明
- **版本对照表**：对比 RICE 排序与最终实际执行顺序，用于框架校准
### 异常处理
| 异常情况 | 处理方式 |
|----------|----------|
| 某需求 Reach 数据缺失 | 采用最小可获取范围（例如仅统计内部测试用户）并在 Confidence 中标记 ±20% |
| Effort 估算差异超过 50% | 要求架构师与开发 Lead 背对背估算后取平均值 |
| 团队对 Impact 因子产生分歧 | 以产品线 OKR 权重强制对齐：若需求对“上市时间”贡献大，Impact 不低于 2 |
| 总分排名出现并列 | 优先 Confidence 高的需求；若仍然并列，由项目负责人票决 |
### 验收标准
本章结束后，团队成员必须能够：
- 不需要查阅资料，准确说出 RICE 四个字母代表的含义及单位
- 在新需求进入池子时，快速判断是否需要启动 RICE 排序（与“前置条件”匹配）
- 识别出至少 2 种可能导致 RICE 失效的场景（例如：Reach 数据造假、Confidence 被有意压低）
**RICE 框架 vs 传统优先级方法（KANO / MoSCoW / 加权评分）**
| 维度 | RICE | KANO | MoSCoW | 加权评分 |
|------|------|------|--------|----------|
| 量化程度 | 高（四因子连续值） | 中（分类） | 低（Must/Should…） | 高（但权重主观） |
| 硬件适配性 | 好（Effort 可精确算出） | 一般（用户体验难量化） | 差（不区分投入回报） | 较好（需自定义指标） |
| 团队协作成本 | 中等（需一次会议） | 低（问卷即可） | 低 | 高（频繁调权重） |
| 推荐硬件阶段 | 开发迭代期 | 概念验证期 | 资源极度受限期 | 长期路线图规划 |
### 核心框架流程（内联 SVG）
### 框架起源与传统方法对比
RICE 由产品管理专家 **Intercom** 团队提出，最初用于 SaaS 功能排序，后经硬件行业改造加入 **Effort 精确估算**（人/天 vs 故事点）和 **Confidence 工程评审流程**。与硬件行业常用的 **加权评分法** 相比，RICE 的核心优势在于：
- **Reach 因子** 直接关联硬件出货量或用户触达数，避免“拍脑袋”
- **Confidence 因子** 强制要求技术验证，降低“PPT 功能”进入优先级
- **Effort 因子** 使用硬工时而非敏捷点，更适配硬件长周期开发
**注意**：RICE 不适用于以下场景：
- 需求属于法律/合规强制项（必须做，无需排序）
- 需求为 P1 级 Bug（直接进入紧急通道）
- 缺乏基本数据（Reach/Effort 均为未知）时，应先用调研确定最低置信度再打分