4. EVT阶段第一轮优先级排序步骤：数据收集、评分计算、排序输出、评审责任人
4.1 适用场景
- EVT（工程验证测试）阶段首次集中评审所有新需求、设计变更、关联待办项。
- 产品团队需在资源有限（人力、测试设备、交期）条件下，筛选出该轮必须进入开发或验证的 TOP 事项。
- 适用于跨职能团队（硬件、固件、结构、测试、PM）统一对齐优先级语言，避免凭直觉打架。
4.2 前置条件
| 序号 | 条件 | 验证方式 |
|---|
| 1 | 需求池已完成 RICE 四维度初评分（Reach / Impact / Confidence / Effort） | 看板或电子表格中每项均有 R/I/C/E 数值 |
| 2 | Effort 工时估算已通过硬件/结构/固件三方确认 | 各领域 lead 签字或会议记录 |
| 3 | EVT 里程碑时间节点已锁定（例如：第 4 周投板，第 6 周功能验证） | 项目计划文件 |
| 4 | 评审责任人已任命（通常为系统工程师或硬件架构师） | 项目组公告 |
4.3 操作步骤
- 数据收集（30 分钟）：从需求管理系统（Jira / PLM / Excel）导出待办项清单，同步各领域 Effort 估算现值。若发现 Effort 缺省，立即标记并通知对应 owner 15 分钟内补齐。
- 评分计算（20 分钟）：对每一条待办项执行
RICE 总分 = (Reach × Impact × Confidence) / Effort。使用统一公式，避免人工四则运算错误。
- 排序输出（15 分钟）：按 RICE 总分降序排列，生成「EVT 第一轮优先级初排表」。同时增加“是否强制依赖”“是否截止日期敏感”两项辅助标记。
- 评审责任人确认（10 分钟）：评审责任人（通常为系统工程师）核对 TOP 10 项的技术可行性、资源冲突，确认后签字上线。
🎯 实战提示：第一轮排序不要超过 30 条待办项，否则计算和评审时间会失控。建议先做“粗筛”：把 Effort 超过 3 人周、且 Confidence < 50% 的项自动降级，不参与本轮排序。
4.4 输入输出物
| 类型 | 名称 | 格式 | 责任方 |
|---|
| 输入 | EVT 待办项清单（含 R/I/C/E） | CSV / Excel | PM + 各领域 Lead |
| 输入 | Effort 确认记录 | 会议纪要或 commit 记录 | 各领域 Lead |
| 输出 | EVT 第一轮 RICE 优先级排序表 | Excel（带公式） | 系统工程师 |
| 输出 | 排序结果评审签字单 | PDF 扫描件 | 评审责任人 |
4.5 责任边界
- PM：提供需求池、锁定 Effort 估算窗口、推动排序节奏。
- 各领域 Lead（硬件/结构/固件/测试）：在数据收集阶段确保 Effort 正确，并对自己领域的待办项评分合理性负责。
- 系统工程师（评审责任人）：执行评分计算、排序、最终确认；解决跨领域资源冲突，对 TOP 项的技术可实施性负总责。
- 项目总监：仅在评审责任人无法达成一致时介入仲裁，日常不参与本步骤。
4.6 记录材料
| 记录文件 | 保存位置 | 保留期限 |
|---|
| RICE 评分计算底表（含公式） | 项目共享盘 / Confluence 页面 | 项目结项后 6 个月 |
| 排序输出 Excel | 版本管理 Git LFS 或 SharePoint | 项目结项后 1 年 |
| 评审会议纪要（含签字） | 项目档案库 | 永久（追溯用） |
4.7 异常处理
| 异常 | 处理方式 | 升级路径 |
|---|
| Effort 缺失或冲突（多领域估算偏差 > 20%） | 临时召集 15 分钟对齐会，现场敲定统一值 | 领域 Lead 无法对齐时，由系统工程师拍板 |
| 某待办项 Confidence 为 0（完全无数据支撑） | 标记为“需预研”并剔除本轮排序，进入下一轮 | PM 确认是否安排快速原型验证 |
| 排序结果出现同分（RICE 总分相同） | 以 Effort 小优先；若 Effort 也相同，以 Impact 高优先 | 系统工程师最终裁决 |
| 评审责任人缺席 | 由其授权代理人（架构师）代为签字，24 小时内补签 | 通知项目总监 |
4.8 验收标准
- 所有 EVT 待办项（无漏项）均已完成 RICE 计算并填入排序表。
- 排序表中 TOP 10 项均标注了“依赖关系”和“截止日期敏感度”。
- 评审责任人已签字确认，电子或纸质均有存档。
- 排序结果在 4 小时内同步给所有领域 Lead 和测试团队。