4. Roadmap的常见类型与适用场景
章节导读：需求池预处理是版本节奏规划的“原料车间”。在正式排期之前，必须将散落在各处的原始需求统一归集、打上优先级标签、识别依赖关系并完成初步排期筛选。本章提供一套标准操作流程，确保需求池干净、有序、可排序。
4.1 适用场景
- 版本启动前准备：每个版本迭代开始前，需要从需求池中筛选候选需求。
- 需求池日常治理：定期（如每周）对新增需求进行预处理，防止需求池膨胀失序。
- 跨团队协作对齐：多个产品线或业务方提交需求时，需要统一预处理标准。
- Roadmap 初稿构建前：在绘制版本路线图之前，必须完成需求池的预处理动作。
4.2 前置条件
- 已建立统一的需求登记模板（字段：来源、描述、提出方、期望时间、关联系统）。
- 优先级标签体系已定义并全员共识（P0/P1/P2/P3 或类似分级）。
- 依赖识别 checklist 已准备好（含技术依赖、业务依赖、外部依赖三类）。
- 排期初筛的“时间窗口”已明确（如本季度可投入的资源总量）。
4.3 操作步骤
步骤一：需求收集与渠道归集
- 激活渠道列表：确认以下渠道是否已纳入采集范围——客户反馈系统、内部产品工单、销售/CSM 周报、竞品分析报告、技术债务看板、战略规划文件。
- 分类登记：将原始需求填入统一模板，标记来源渠道代码（如 CH01=客户反馈，CH02=内部工单）。
- 去重合并：按需求标题+提出方+系统模块 三个字段进行模糊匹配，发现重复需求则合并为一条，并保留所有来源备注。
步骤二：需求优先级标签设定
- 业务价值评估：从“用户影响面”、“收入贡献度”、“战略匹配度”三个维度打分（1~5 分），取加权总分。
- 标签赋值：根据总分区间赋予优先级标签——P0（紧急且重要，13~15 分）、P1（重要不紧急，10~12 分）、P2（一般价值，7~9 分）、P3（低优先级，<7 分）。
- 类型标注：同时为需求打上类型标签：FEAT（功能）、ENHANCE（优化）、BUG（缺陷）、TECH（技术债）。
步骤三：需求依赖关系识别
- 前置依赖检查：询问“本需求必须等到哪个需求/平台能力/外部条件就绪后才能启动？”记录依赖项 ID。
- 后置依赖标记：询问“本需求上线后，哪些后续需求或流程才能启动？”记录被依赖项 ID。
- 外部依赖标注：对第三方服务、供应商交付、合规审批等外部依赖，标注预计交付时间与风险等级。
步骤四：排期初筛与分类
- 工作量预估：由技术负责人给出初步人天估算，按规模标记 S（≤3 人天）、M（4~10 人天）、L（11~25 人天）、XL（>25 人天）。
- 固定节点识别：标注带有硬性时间约束的需求（如合同约定、合规截止日期），这些需求不可调整排期。
- 归入候选池：将预处理完成的需求分别移入“当前版本候选”、“未来版本候选”、“暂缓/待定”三个子池。
关键检查点：每完成一个步骤，都需要在需求条目上更新状态字段（渠道归集✅ / 标签已设✅ / 依赖已识✅ / 初筛完成✅）。只有四个状态全部为 ✅ 的需求才能进入版本排期环节。
4.4 输入输出物
| 类型 | 名称 | 说明 |
|---|---|---|
| 输入 | 原始需求集合 | 来自各渠道的未处理需求，含客户反馈、内部工单、战略任务等 |
| 输入 | 优先级标签定义矩阵 | P0~P3 的分级标准与赋值规则文档 |
| 输入 | 依赖识别 Checklist | 前置/后置/外部依赖的检查模板 |
| 输出 | 已预处理需求池 | 每条需求含渠道代码、优先级标签、依赖关系、工作量规模、候选池归属 |
| 输出 | 需求预处理状态看板 | 记录每条需求在四个步骤中的完成状态（✅ 或 ❌） |
4.5 责任边界
- 产品经理：负责需求收集、渠道归集、优先级标签设定、类型标注，是预处理流程的第一责任人。
- 技术负责人：负责依赖识别（尤其是技术依赖）、工作量预估、固定节点可行性判断。
- PMO/版本经理：负责排期初筛的分类裁决、资源冲突协调、预处理进度跟踪。
- 业务方/需求提出人：配合提供需求背景、补充缺失信息、确认优先级合理性。
边界常见问题：产品经理容易跳过“依赖识别”直接进入排期初筛，导致版本执行阶段频繁阻塞。务必在初筛之前完成依赖识别，且技术负责人必须签字确认。
4.6 记录材料
| 材料名称 | 格式 | 使用时机 |
|---|---|---|
| 需求收集登记表 | Excel / 在线表格 | 步骤一：渠道归集时逐条填写 |
| 优先级标签对照卡 | PDF / 共享文档 | 步骤二：赋值时对照使用 |
| 依赖关系记录表 | Excel / 关系图谱工具 | 步骤三：逐项填写依赖与被依赖 ID |
| 排期初筛分类表 | Excel / 看板视图 | 步骤四：记录工作量规模与候选池归属 |
| 需求预处理状态看板 | 在线看板（如 Jira/Teambition） | 全流程：跟踪每条需求的四步完成状态 |
4.7 异常处理
| 异常情形 | 产生原因 | 处理措施 |
|---|---|---|
| 需求信息严重缺失 | 提出方未填写完整模板 | 退回至提出方补充，标记“等待补充”状态，48 小时内未回复则移入暂缓池 |
| 多个渠道重复提交 | 同一需求被不同角色分别录入 | 合并为一条，保留所有渠道来源附注，并通知各提交人 |
| 依赖关系闭环冲突 | A 依赖 B，B 又依赖 A，形成循环 | 召集双方技术负责人进行解耦设计，或引入中间层打破循环 |
| 优先级争议无法达成一致 | 产品经理与业务方对价值判断分歧 | 升级至版本委员会或产品总监进行裁决，以 24 小时内给出结论为限 |
| 排期资源严重不足 | 所有初筛需求的总人天超出可用资源 50% 以上 | 将 P3 及部分 P2 需求移入未来候选池，并公示资源分配逻辑 |
4.8 验收标准
- ✅ 需求池中每条需求均已填写渠道代码，来源可追溯。
- ✅ 每条需求均携带唯一的优先级标签（P0/P1/P2/P3）和类型标签（FEAT/ENHANCE/BUG/TECH）。
- ✅ 依赖识别覆盖率达到 100%，且依赖关系记录表中无未解决的循环依赖。
- ✅ 排期初筛分类完成，所有需求已归入“当前版本候选”、“未来版本候选”或“暂缓/待定”之一。
- ✅ 需求预处理状态看板中，四项检查状态均为 ✅ 的需求占比 ≥ 90%。