4. 权重总览流程SOP：从评审发起→维度定义→权重分配→打分→汇总→决策
本 SOP 章节旨在固化 RICE 模型在 AI 产品评审中的权重操作流，形成从评审发起到最终决策的标准化闭环。通过明确的六步节点，确保每一次权重分配均有据可依、过程可溯、结果可信，避免因流程缺失导致的评审打架或权重失真。
适用场景
本流程适用于以下具体的 AI 产品评审活动：
- 新增 AI 功能模块的立项评审会；
- 季度性产品路线图的优先级排序会；
- 跨部门（产品、技术、运营）资源协调的权重确认会；
- 突发风险项（如数据合规）的权重紧急调整会。
前置条件
💡 入场检查清单：请在进入权重总览流程前逐条确认以下条件。
- 评审委员会成员已确认，并持有 RICE 模型基础认知；
- 当前评审项的 MRD/PRD 已完成内部初审；
- 历史评审数据（如有）已完成脱敏与归档，可供权重参考；
- 权重投票工具或打分平台已就绪（如 Confluence 插件、Arena 或专用打分表）；
- 主持人已准备好 RICE 维度标准模板。
操作步骤
遵循以下六个标准节点，按序推进评审流程：
- 评审发起：Product Owner（PO）在系统中创建评审单，锁定评审目标与范围。
- 维度定义：评审委员会共同明确 R（覆盖度）、I（影响度）、C（置信度）、E（投入度）的取值口径。
- 权重分配：委员背靠背打分或用 AHP 层次分析法，输出初始权重配置。
- 打分：各委员依据维度定义对每项进行独立打分（1-10 分制）。
- 汇总：助理收集打分表，执行加权汇总，输出综合排序。
- 决策：评审委员会基于排序结果做出最终决策。
在步骤 3. 权重分配 中，建议采用如下 JSON 结构记录权重配置，便于后续自动汇总：
{
"review_id": "REVIEW-20231027-001",
"method": "Delphi",
"weights": {
"reach": 0.40,
"impact": 0.30,
"confidence": 0.15,
"effort": 0.15
},
"version": "1.0"
}输入输出物与责任边界
下表界定了各节点的输入、输出及责任归属，确保角色边界清晰：
| 流程节点 | 输入物 | 输出物 | 责任边界 (R) |
|---|---|---|---|
| 1. 评审发起 | MRD / PRD Draft | 评审单 (Issue) | Product Owner |
| 2. 维度定义 | RICE 模型模板 | 维度标准定义书 | 主持人 / DS |
| 3. 权重分配 | 历史数据 / 专家意见 | 权重配置表 | 评审委员会 |
| 4. 打分 | 维度标准 + 权重 | 维度评分表 | 评审委员 |
| 5. 汇总 | 维度评分表 + 权重 | 综合评分排序表 | 评审助理 |
| 6. 决策 | 综合评分排序表 | 评审决议书 | 评审委员会 |
除责任方（R）外，所有委员对步骤 2-4 享有参与权（P），PMO 对全流程享有知情权（I）。
记录材料
所有过程文件应统一归档至项目 Wiki 或共享知识库，命名规范如下：
{YYYYMMDD}_评审发起单_{项目名称}.pdf{YYYYMMDD}_维度定义书_{项目名称}.docx{YYYYMMDD}_权重配置表_{项目名称}.xlsx{YYYYMMDD}_委员打分表_{委员姓名}_{项目名称}.xlsx{YYYYMMDD}_综合排名与决策书_{项目名称}.pdf
异常处理
⚠️ 权重分配异常：若第一轮背靠背权重分配结果标准差大于 15%，必须启动第二轮讨论对齐，直至组内极差小于 10%。三轮不收敛则升级至技术委员会仲裁。
⚠️ 维度冲突：当某委员对某维度定义存在疑义时，暂停评审，由数据科学组现场解释口径，并记录在案。
💡 数据缺失处理：如某个评审项在“覆盖度 (Reach)”维度缺乏历史数据，默认取该维度权重的中间值（权重值 × 0.5），并在备注中标注“预估”，后续季度复盘时修正。
验收标准
决策结果输出后，由 PMO 或 QA 角色进行流程验收：
- 完整性校验：确认所有委员均已完成打分，无遗漏项。
- 一致性校验：确认权重总和为 100%（允许 ±0.5% 的浮点误差）。
- 可追溯性：确保从决策结果能逐级追溯回原始打分表与权重定义书。
- 归档确认：检查所有记录材料已上传至指定路径，命名规范与版本号无误。