第4章：Roadmap优先级拆解至原型交付优先级

本章聚焦如何将宏观 Roadmap 中的优先级有序拆解为原型交付环节可执行的优先级列表。通过优先级评分模型量化各需求项，借助冲突处理规则化解多维度矛盾，并利用决策记录表留存完整的拆解依据，确保每一次原型交付都“有理有据、可追溯”。

适用场景

• Roadmap 包含多个并行特性或需求，需要确定原型制作顺序时。
• 不同利益相关方对需求优先级存在分歧，需要统一衡量标准时。
• 资源（设计人力、开发环境、测试周期）受限，必须排定原型交付节奏时。
• 项目进入季度/月度规划窗口，需要将战略优先级转化为可执行的原型任务。

前置条件

1. 已维护一份经过评审的Roadmap 需求清单（含功能描述、预期价值、关键里程碑）。
2. 已定义评分维度与权重（如：业务价值、紧急程度、技术风险、用户影响等）。
3. 已选定冲突仲裁人（通常为产品负责人或项目总监）。
4. 具备基本的决策记录模板（电子表格或文档）。

操作步骤

以下流程将 Roadmap 优先级逐级拆解为原型交付优先级，共 6 个步骤：

1. 汇总 Roadmap 需求项 —— 从 Roadmap 中提取待原型验证的需求条目，形成候选列表。
2. 多维度评分 —— 使用统一的评分模型对每条需求进行打分，计算加权总分。
3. 初步排序 —— 依据加权总分从高到低生成初始优先级序列。
4. 冲突检测 —— 识别评分相近、资源冲突或利益相关方诉求矛盾的需求对。
5. 应用冲突处理规则 —— 按预设规则（见下文）调整冲突项的顺序。
6. 填写决策记录表 —— 将最终排序结果与决策依据写入记录表，归档签批。

输入输出物

责任边界

• 产品经理：提供完整的需求描述与价值预估，确保 Roadmap 条目可评分。
• 原型设计负责人：基于交付优先级分配 UI/UX 资源，反馈排期可行性。
• 技术代表：评估需求的技术复杂度与风险，为评分提供输入。
• 项目总监 / 仲裁人：当冲突无法通过规则自动解决时，做出最终裁决。

记录材料

每次拆解过程必须留存以下三种记录：

1. 评分原始数据表 —— 包含每条需求的各维度得分、权重及加权总分。
2. 冲突处理日志 —— 记录冲突对、所触发的规则编号以及调整结果。
3. 决策记录表 —— 最终优先级列表及签批信息。

决策记录表建议采用以下结构（JSON 格式便于自动化归档）：

{
  "sessionId": "SPRINT-2025-Q2",
  "decisions": [
    {
      "需求ID": "REQ-0421",
      "需求名称": "用户积分兑换入口",
      "加权总分": 4.6,
      "冲突项": "REQ-0419",
      "冲突规则": "RULE-03：高用户影响优先",
      "最终排名": 2,
      "决策人": "张薇",
      "决策日期": "2025-03-10"
    }
  ]
}

异常处理

验收标准

1. 所有 Roadmap 需求均已评分，无遗漏项。
2. 冲突处理日志中每条冲突均标记了所引用的规则编号。
3. 决策记录表已完成签批，版本号清晰。
4. 原型交付优先级列表可直接用于下一阶段（原型设计排期）。
5. 评分原始数据、冲突日志、决策记录表三者可联合追溯，任一需求的排序变动都有明确记录。

核心流程：Roadmap 到原型交付优先级拆解

下图展示了从 Roadmap 优先级列表到最终原型交付优先级的完整拆解链路，包含评分模型、冲突处理与决策记录三大核心环节：

附：优先级评分模型参考

以下为推荐使用的 5 维度评分模型，各团队可根据业务特点调整权重：

附：冲突处理规则一览

当检测到优先级冲突时，按以下顺序依次判断：