### 第3章：RICE四要素定义
#### 1. 适用场景
本章适用于硬件开发团队在需求评审、功能立项、版本规划或资源投入决策前，对候选任务进行量化评分。当团队需要从多个硬件特性或技术方案中确定优先顺序时，RICE四要素定义提供了统一的度量标尺，尤其适用于资源受限、多项目并行推进的硬件开发环境。
#### 2. 前置条件
- 已完成市场需求文档（MRD）或产品需求文档（PRD）初稿
- 已组建跨职能评分小组（包含硬件、软件、测试、市场代表）
- 已准备评分数据采集模板
- 团队已达成共识：评分是动态过程，不追求绝对精确
#### 3. 操作步骤
| 步骤 | 任务 | 负责人 | 输出物 |
|------|------|--------|--------|
| 1 | 召集评分小组，讲解四要素定义 | 产品经理 | 会议纪要 |
| 2 | 收集每个候选功能的预估用户基数 | 市场代表 | 用户规模估算表 |
| 3 | 评估功能对核心业务指标（如出货量、返修率、用户留存）的预期影响 | 产品经理+硬件架构师 | 影响评估矩阵 |
| 4 | 基于原型数据、竞品分析或专家经验，给出信心指数（1～10分） | 硬件架构师+测试代表 | 信心指数评分卡 |
| 5 | 估算从方案设计到量产验证所需的总人天 | 硬件项目经理+各模块Owner | 人天估算表 |
| 6 | 汇总四要素数据，生成初始评分 | 产品经理 | RICE评分草表 |
#### 4. 输入输出物
**输入物：**
- PRD v0.5 或需求池清单
- 历史项目人力基线数据
- 竞品功能表现快照
**输出物：**
- RICE要素定义卡片（每人一份）
- 已标注四要素的需求清单（电子版或纸质版）
- 评分小组签字确认的初始评分记录表
#### 5. RICE四要素定义详表
| 要素 | 英文全称 | 定义 | 硬件场景示例 | 量化单位 |
|------|----------|------|-------------|----------|
| **覆盖用户数** | Reach | 预期在功能交付周期内，直接或间接受益的目标用户数量 | 支持低功耗蓝牙升级，覆盖存量设备100万台 | 万台/百万用户 |
| **业务指标影响** | Impact | 该功能对核心商业或产品KPI的拉动幅度 | 优化散热结构使设备平均无故障时间（MTBF）提升20%，对应年返修率降低15% | 百分比（%）、具体数值 |
| **信心指数** | Confidence | 团队基于现有证据对前两个要素预估准确度的确信程度 | 已完成2轮工程原型验证，竞品方案已量产，信心指数8分 | 1～10分制 |
| **投入人天** | Effort | 从需求锁定到量产发布，所有涉及团队（硬件、软件、测试、认证、生产）所需的总人天 | 重新设计天线方案需硬件2人×15天+测试1人×5天+认证1人×3天 = **38人天** | 人天 |
#### 6. 责任边界
| 角色 | 责任范围 |
|------|----------|
| **产品经理** | 提供用户规模基线、业务指标定义；主持评分会议；维护评分记录 |
| **硬件架构师** | 提供技术影响预估；参与信心指数评分；识别技术风险 |
| **项目经理** | 统筹人天估算；管控评分节奏；保证评分过程按时完成 |
| **测试代表** | 提供历史测试数据辅助影响评估；为信心指数贡献测试覆盖率维度 |
| **市场代表** | 提供用户分层数据、竞品市占率；验证覆盖用户数合理性 |
#### 7. 异常处理
| 异常场景 | 处理方法 |
|----------|----------|
| 同一功能覆盖用户数估算差异超过30% | 重新采集用户分层数据，按中位数评分，并在信心指数中扣减2分 |
| 信心指数长期低于5分 | 标记为“待探索”，要求补充原型或仿真数据后再评分 |
| 人天估算跨度超过50% | 拆解子任务到模块级别，逐项交叉复核工时 |
| 评分小组无法达成一致 | 投票表决，保留异议意见作为附录 |
#### 8. 核心结构关系图
#### 9. 日常应用示例
假设一个硬件团队需要决定是否优先开发“支持-40℃低温启动”功能。
| 要素 | 数据 | 说明 |
|------|------|------|
| **Reach** | 8000台设备 | 北方寒区存量设备预估数 |
| **Impact** | -12%故障率 | 基于年度低温反馈数据测算的MTBF提升 |
| **Confidence** | 7分 | 已完成2轮极限温箱测试，但量产批次存在一致性风险 |
| **Effort** | 32人天 | 包括方案设计8天、打样测试15天、产线适配5天、文档4天 |
> 该功能RICE评分 = (8000 × 12%) × 7 / 32 = **210分**
#### 10. 常见误区
⚠ 常见误区
- 信心指数虚高：团队在缺乏原型数据时仍给出8分以上，导致评分失真。建议“无原型不超5分”。
- 投入人天遗漏认证环节：硬件开发常忽略合规认证（FCC、CE、3C等）所需人天，这部分平均占项目总人天的10%～15%。
- 覆盖用户数错用潜在市场而非真实用户：应基于实际可触达存量设备数，而非行业总市场容量。
#### 11. 验收标准
- 每个候选功能均完成四要素数据记录，缺失任何一项不得进入评分流程
- 信心指数须附有依据说明（如：已完成xx验证、基于竞品A的数据、行业专家匿名投票结果）
- 投入人天拆解到子任务级别，且有人天汇总校验签名
- 评分会议产生会议纪要，包含争议点及最终结论
- 异常场景处理记录附入评分档案，方便复盘