4. 优先级评估维度定义：业务价值、紧迫度、实施成本、风险影响

4.1 适用场景

• 需要从多个B端业务需求中筛选出高优先级项，制定开发或实施路线图。
• 在项目启动会、迭代规划会或需求评审会上，作为统一打分与排序标准。
• 跨部门协作时，需要透明、可量化的优先级评判依据，减少主观争议。

4.2 前置条件

1. 已完成需求澄清与业务流程建模（如用户故事、业务流程图）。
2. 已收集关键干系人对需求价值的初步反馈或数据支撑。
3. 已明确当前项目周期、预算上限及可用技术资源。
4. 已识别需求潜在的法律合规、安全与数据风险边界。

4.3 操作步骤

1. 定义“业务价值”评分标准：衡量需求对业务目标（如营收、效率、客户留存）的贡献。 1分=无直接价值；3分=局部流程优化；5分=核心业务突破或新市场机会
2. 定义“紧迫度”评分标准：衡量需求在时间窗口上的紧迫性。 1分=无时间限制；3分=下一季度前需完成；5分=法规/合约强依赖，必须在当前迭代交付
3. 定义“实施成本”评分标准：衡量开发、集成、培训与运维的总投入。 1分=极高（>200人天）；3分=中等（50~200人天）；5分=极低（<10人天）
4. 定义“风险影响”评分标准：衡量需求实施可能引入的系统稳定性、安全或合规风险。 1分=极高风险（影响全站数据）；3分=中等风险（局部功能降级）；5分=几乎无风险（已有成熟方案）
5. 建立四维评估表：将每个需求的四个维度分数填入矩阵，生成权重或简单求和排序。
6. 可视化对比：使用气泡图或四象限图（如紧迫度 vs 业务价值）进行直观对比。

4.4 输入输出物

4.5 责任边界

• 产品经理（PO）：主导业务价值与紧迫度评分，收集客户与业务方输入。
• 技术负责人/架构师：主导实施成本与风险影响评分，提供技术可行性分析。
• 项目经理/Scrum Master：组织多维打分会议，确保流程透明、标准一致。
• 关键干系人：审核与质询评分结果，确认最终优先级排序符合业务目标。

4.6 记录材料

需求ID | 需求名称 | 业务价值(1-5) | 紧迫度(1-5) | 实施成本(1-5) | 风险影响(1-5) | 综合优先级分 | 备注
REQ-01 | 合同电子签章 | 5           | 5         | 2            | 4           | 16          | 法规要求年底前上线
REQ-02 | 报表导出优化 | 3           | 2         | 4            | 5           | 14          | 用户反馈强烈，成本低
REQ-03 | 多语言界面    | 2           | 1         | 1            | 3           | 7           | 未来规划，当前不紧急

4.7 异常处理

• 维度打分争议：业务价值与紧迫度常存在主观分歧。对策是规定所有打分必须在会议上公开并附上简短理由，最后取多人加权平均或由产品总监仲裁。
• 成本与风险数据缺失：若没有技术评估，则先标记为“待调研”，暂不参与排序，待评估完成后再加入矩阵。
• 大批量需求涌入：建议设置最低门槛（如业务价值低于2分的不进入排序），避免矩阵过度拥挤。
• 紧急需求打断：允许每周一个“紧急通道”重新评估紧迫度为5的需求，更新排序表。

4.8 验收标准

1. 所有需求已至少拥有四个维度的评分，且评分理由可追溯。
2. 优先级排序矩阵已完成，并经过产品经理与技术负责人双方确认签字。
3. 排序结果已同步至项目管理系统（如Jira、TAPD），作为迭代规划的直接输入。
4. 评分标准文档已面向团队全员发布，后续新需求按相同流程执行。

4.9 四维评估结构图