第2章：陷阱类型总览

2.1 适用场景

本章适用于以下硬件产品决策场景中需要进行RICE优先级评分的团队和个人：

• 新产品立项评审——首次使用RICE对多个硬件方案进行优先级排序时，需提前识别四大陷阱
• 版本路线图规划——对已有产品线的迭代需求进行批量评分时，防止评分体系系统性偏差
• 跨部门联合评审——硬件、软件、供应链、质量等多团队共同参与评分时，统一对陷阱的认知口径
• RICE框架导入初期——团队首次引入RICE方法，尚未建立评分成熟度时，作为前置风险教育

2.2 前置条件

在开始识别陷阱类型之前，需满足以下条件：

序号	前置条件	验收方式
1	团队成员已完成RICE基础概念培训	培训签到表 + 课后测验通过率 > 80%
2	已确立至少一个硬件产品的待评分需求池（不低于10条）	需求池清单已归档至共享文档
3	定义了RICE四要素（触达、影响、信心、努力）的初步度量标尺	度量标尺文档已评审通过
4	指定了本次评分活动的数据采集责任人与仲裁人	角色分工表已确认

2.3 操作步骤

本节通过 四步识别法 帮助团队系统定位四种陷阱类型。每步均包含定义、典型案例和自查问题。

步骤1：识别量化陷阱

定义：过度追求数字精确，将主观感受、模糊概念强行赋予精确数值，导致评分失去区分度。

• 硬件典型案例：将“散热手感舒适度”量化为3.2分（精确到小数点后一位），但实际不同测试人员手感差异极大，该数字并无统计意义。
• 自查问题：该指标的评分是否基于可复现的物理测量？如果换一个人重新打分，结果是否仍在同一区间？

步骤2：识别定义陷阱

定义：RICE四要素中的某个要素缺乏清晰、无歧义的操作定义，导致不同评分者对同一要素的理解不一致。

• 硬件典型案例：对“影响”（Impact）要素，硬件团队理解为“功能对销量的直接拉动”，而软件团队理解为“功能对用户活跃度的提升”，双方评分偏差超过40%。
• 自查问题：每个要素是否都有唯一的、可举例的操作定义？是否所有评分者对该定义的理解一致？

步骤3：识别权重陷阱

定义：在RICE总分计算时，未根据硬件产品阶段合理分配四要素的权重，导致关键要素被稀释。

• 硬件典型案例：在原型验证阶段，“信心”（Confidence）权重设为10%，而“触达”（Reach）权重设为40%，导致一个高风险的创新方案因触达数据好看而获得高分，最终在工程验证时失败。
• 自查问题：当前权重分配是否与产品阶段目标一致？是否经过了团队评审？

步骤4：识别数据源陷阱

定义：用于计算RICE分数的原始数据存在来源偏差、样本不足、时效过期或测量方法错误等问题。

• 硬件典型案例：引用“竞品用户调研数据”时，样本量仅有30份且全部来自同一个线下门店，数据严重偏差；另一案例使用2年前的供应链BOM成本数据，已无法反映当前晶圆价格。
• 自查问题：数据是否标注了采集时间、样本量、采集方法？数据责任人是否签字确认？

2.4 输入输出物

类型	名称	格式/载体	责任人
输入	硬件需求池清单（含初步RICE评分）	Excel / 在线表格	产品经理
输入	RICE度量标尺文档	PDF / Wiki	数据分析师
输出	陷阱类型识别清单（每项需求标注陷阱归属）	Excel / JIRA标签	产品经理
输出	陷阱风险热力图（四种陷阱的分布占比）	图表 / PPT	数据分析师

2.5 责任边界

角色	对量化陷阱	对定义陷阱	对权重陷阱	对数据源陷阱
产品经理	初审评分精度	组织定义对齐会	提议权重方案	核验数据来源说明
数据分析师	出具精度阈值建议	提供量化定义支持	模拟权重敏感性	负责数据质量审计
技术负责人	判断工程可测量性	确认技术指标定义	评审资源分配权重	提供实验数据来源
决策委员会	裁定争议条目	最终确认定义版本	审批权重调整	审核数据源变更申请

2.6 记录材料

以下模板用于记录每种陷阱的发现位置、描述和处置状态：

【陷阱类型识别记录表】

| 需求ID | 陷阱类型 | 具体描述 | 影响要素 | 严重程度 | 状态 | 处理人 |
|--------|----------|----------|----------|----------|------|--------|
| HWR-023 | 量化陷阱 | 散热手感评分3.2，无实测依据 | Confidence | 中 | 待确认 | 张三 |
| HWR-047 | 定义陷阱 | Impact定义团队间未对齐 | Impact | 高 | 讨论中 | 李四 |
| HWR-061 | 权重陷阱 | Reach权重45%过高，与阶段目标不符 | Reach | 高 | 已修正 | 王五 |
| HWR-088 | 数据源陷阱 | BOM数据为2年前，未更新 | Effort | 中 | 已更新 | 赵六 |

2.7 异常处理

异常场景	处理措施	输出物
同一需求被标记为2种以上陷阱	召集产品经理+数据分析师+技术负责人三方会审，填写《陷阱交叉判定表》，确定主要陷阱和次要陷阱	《陷阱交叉判定表》
团队对陷阱类型存在争议（超过30分钟无法达成一致）	升级至决策委员会，由仲裁人做最终裁定；同时将该案例记入《陷阱案例库》作为日后培训材料	《陷阱案例库》新增记录
数据源无法提供采集时间或样本量信息	立即冻结该数据的使用，由数据分析师启动数据溯源审计，48小时内给出可用性结论	《数据源审计报告》
权重陷阱修正后导致其他需求排名剧烈波动	运行敏感性分析（蒙特卡洛模拟），输出排名变化区间，确保调整后的top-5需求变动不超过2个	《权重敏感性分析报告》

2.8 验收标准

完成本章节学习后，团队需通过以下验收项：

1. 识别率达标：在模拟需求池（20条样本）中，每位成员至少正确识别出6个预先埋入的陷阱，准确率 ≥ 80%
2. 定义复述：每位成员能用自己的语言准确复述四种陷阱的定义（偏差不超过核心关键词的20%）
3. 文档归档：完成《陷阱类型识别记录表》的填写，覆盖当前实际需求池中不少于90%的需求条目
4. 角色确认：责任边界表中的角色分工已获得对应角色本人签字确认
5. 异常预案：团队已演练至少1种异常处理场景，并形成会议纪要