第2章 适用场景与前置条件
适用场景
本教程适用于以下硬件产品规划与需求管理场景，当团队需要将用户需求有依据地排入硬件开发里程碑时，必须使用本映射方法。
关键适用场景
- 产品立项阶段：初步收集用户需求后，需判断哪些需求可进入近期硬件迭代，哪些需推迟或降级。
- 季度/年度路线图刷新：定期更新硬件Roadmap时，需将新增/变更需求重新映射到对应的时间窗口。
- 需求变更评审：已立项需求发生优先级、技术方案或规格变更时，重新计算其对交付时间节点的影响。
- 多项目资源冲突场景：在同一硬件平台承载多个产品线需求时，按时间节点有序分配开发资源。
不适用场景提示：纯软件功能需求、非硬件依赖的运营类需求、未经过技术可行性评估的设想性需求，不应直接使用本映射流程，需先完成独立的技术预研阶段。
前置条件
开始进行需求—时间节点映射前，必须确认以下四项前置条件均已满足，否则映射结果不可靠，可能导致后续开发延期或返工。
| 序号 | 前置条件 | 验证物/凭证 |
|---|---|---|
| 1 | 用户需求清单已分类、去重并标注优先级 | 经产品经理签发的需求池条目（含ID、来源、优先级标记） |
| 2 | 硬件平台技术基线已冻结 | 系统架构师签发的技术基线文档（主芯片、内存、传感器选型等） |
| 3 | 项目日历已对齐公司级里程碑 | 项目总监发布的本财年硬件版本时间窗口（含EVT/DVT/PVT日期） |
| 4 | 资源池评估已输出可用开发人力/台位 | 项目总监签发的资源负载表（各开发团队剩余容量） |
前置条件缺失处理：若任一条件不满足，应暂停映射流程，由对应角色补齐后重新发起。尤其注意“技术基线”若未冻结，过早映射会导致后期选型变更引发全线时间节点重算。
操作步骤
在确认前置条件后，按以下四个步骤完成需求—时间节点映射的准备阶段。本章仅涉及步骤1至步骤2，详细映射计算将在后续章节展开。
- 步骤1：需求排序 — 产品经理按商业价值、用户影响、技术依赖度对需求进行二维排序，输出“最终优先级队列”。
- 步骤2：技术依赖检查 — 系统架构师对排队需求逐条检查硬件依赖链，标记“必须前置完成”的需求关系。
- 步骤3：窗口初分配 — 项目总监根据资源负载和版本日历，为每个需求分配目标版本窗口（V1.0/V1.1/V2.0等）。
- 步骤4：冲突仲裁 — 三方联合会议（产品经理+系统架构师+项目总监）裁决资源或时间冲突，形成最终映射表。该步骤产出详见《验收标准》。
其中步骤1、2的详细操作规范如下：
# 步骤1 需求排序输出示例（经产品经理签发）
需求ID 优先级 商业价值分 技术依赖 目标窗口（初分配）
REQ-001 P0 9 None V1.0
REQ-002 P1 7 依赖REQ-001 V1.1
REQ-003 P0 8 None V1.0（需仲裁）
REQ-004 P2 4 None V2.0输入输出物
| 类型 | 名称 | 格式 | 责任人 |
|---|---|---|---|
| 输入 | 需求池（经分类去重） | JSON / Excel | 产品经理 |
| 输入 | 技术基线文档 | PDF / Wiki | 系统架构师 |
| 输入 | 项目日历及资源负载表 | Gantt / 表格 | 项目总监 |
| 输出 | 需求—时间节点初映射表（含依赖标记） | SVG矩阵 / Excel | 产品经理（汇总） |
| 输出 | 已识别风险清单 | 表格 | 系统架构师 |
责任边界
| 角色 | 职责 | 不负责事项 |
|---|---|---|
| 产品经理 | 需求优先级定义、输出最终排序列表；对用户需求真实性和价值主张负责。 | 技术实现细节评估、硬件选型判断、资源分配决策。 |
| 系统架构师 | 技术可行性评估、依赖链分析、输出技术风险清单；对映射结果的技术可实现性负责。 | 商业优先级调整、项目日历制定、跨产品资源协调。 |
| 项目总监 | 资源负载平衡、版本窗口分配、冲突最终裁决；对整体交付时间线和资源利用率负责。 | 需求排序、技术依赖细节、用户需求验证。 |
记录材料
- 会议纪要：每次映射评审会的书面记录，含排序、依赖、窗口分配结论及争议点。
- 需求评审记录表：每个需求的技术可行性评估结果（通过/不通过/需预研），由系统架构师签署。
- 映射矩阵：SVG格式（见下文）或Excel格式的需求横轴、时间节点纵轴、状态标记（绿色/黄色/红色）。
- 变更追溯日志：记录每次映射版本迭代的变更原因、变更人、变更时间。
异常处理
异常场景1：需求无法在最近一个版本窗口实现
- 处理方案：由产品经理评估是否需要拆分为更小颗粒度（MVP+后续迭代），或将该需求降级至后续版本窗口。
- 升级路径：若涉及战略客户承诺，需升级到产品决策委员会仲裁。
异常场景2：技术预研未完成导致窗口不可靠
- 处理方案：系统架构师提出预研时间表，映射表中该需求标记为“待预研通过后确认窗口”，不占用正式开发资源。
- 回滚条件：预研失败时，该需求整体移除当前Roadmap版本，进入储备池。
异常场景3：多个P0需求争夺同一开发团队资源
- 处理方案：项目总监调用资源负载表，协商是否可增加外包/借调资源；若不可行，启动优先级仲裁会议。
验收标准
完成第2章学习后，学员应能产出以下可验收结果：
- 独立完成需求池的优先级排序（产品经理角色）。
- 识别需求间的硬件依赖关系并用有向图表示（系统架构师角色）。
- 根据项目日历和资源负载表，为需求分配初始版本窗口（项目总监角色）。
- 三方角色均能在各自责任边界内完成输入输出物的签署。
以下SVG图展示了本章核心概念：适用场景、前置条件与映射入口之间的关系。请学员对照流程图检查自己是否已满足所有前置条件。
图2-1 适用场景→前置条件→映射流程入口逻辑图