第1章 原型与Roadmap对齐的适用场景与基础清单
原型交付与Roadmap衔接的成败，首先取决于团队是否在正确的时机、以正确的准备条件启动对齐流程。本章界定对齐动作的适用场景、必须满足的前置条件、需要准备的输入/输出物清单，以及各参与方的责任边界，为后续章节的操作步骤提供清晰的范围锚点。
1.1 适用场景
原型与Roadmap对齐并非所有项目阶段的通用动作，仅在以下场景中必须执行标准化对齐流程：
- 战略级里程碑校准：季度/半年度Roadmap更新时，需将已交付原型的高价值功能反馈回Roadmap，确保规划不偏离用户验证结果。
- 重大原型交付后评审：高保真原型（通常包含用户测试数据）完成后，需与产品、技术、业务方共同决策是否将原型中的特性纳入Roadmap。
- 跨团队资源冲突协调：多个原型并行开发导致工程资源分配紧张时，需通过对齐会议明确Roadmap优先级与资源投入。
- 需求变更引发红线风险：业务方提出新需求、且该需求严重影响既定Roadmap里程碑时，必须重新对齐原型范围与Roadmap承诺。
- 版本发放边界模糊：原型中部分功能尚未成熟但需抢先发布时，需通过对齐活动界定MVP范围与后续迭代计划。
1.2 前置条件
| 条件类别 | 具体条件 | 检查方 |
|---|---|---|
| 数据就绪 | 原型用户测试报告（含关键指标：任务完成率、NPS、错误率）已产出 | 用户体验研究员 |
| 制品完整性 | 原型具备可交互、可评审的完整流程（非单页Mockup），设计标注与交互说明已附 | 产品设计师 |
| Roadmap状态 | 产品Roadmap工具（如Aha!、Productboard、协同表格）中已维护最新版本，且所有条目有状态标记 | 产品经理 |
| 组织权限 | 对齐决策者（如VP、CTO、业务负责人）已确认出席时间，或已授权代表 | 项目经理 |
| 时间窗口 | 在Roadmap锁定期（通常为月中、季末前2周）之外至少留出3个工作日 | 项目经理 |
前置条件未满足的典型风险： 若原型测试数据缺失，对齐会议容易陷入主观争论；若Roadmap版本陈旧，对齐结论可能在执行时发现与已锁定发布计划冲突。因此项目经理应在前置条件清单检查全部通过后，方可启动对齐流程。
1.3 输入物清单
- 原型交付包（含可交互原型链接、设计源文件、交互说明文档）
- 用户测试摘要报告（用户画像、测试任务、量化指标、定性发现）
- 当前Roadmap快照（产品线、版本、特性列表、优先级、预估工时）
- 工程资源占用表（当前迭代各团队人力资源、关键依赖、风险项）
- 历史对齐决议记录（上次对齐会议纪要、未关闭项清单）
1.4 输出物清单
| 输出物名称 | 内容说明 | 负责角色 |
|---|---|---|
| 对齐决议书 | 每个原型功能的最终决策：纳入/暂缓/拒绝/分拆至后续版本，并说明理由与责任人 | 产品经理 |
| 更新版Roadmap | 根据决议更新后的产品版本规划，包含新的特性条目、优先级调整、预估时间线 | 产品经理 |
| 原型-功能映射表 | 将原型中每个交互模块对应至Roadmap中的具体特性ID，形成可追溯关联 | 产品设计师 |
| 风险备注单 | 对齐过程中识别的资源冲突、技术债、依赖风险及其缓解措施 | 项目经理 |
| 决议通知与待办清单 | 向所有干系人分发决议摘要，并附上各角色的后续行动项（含截止日期） | 项目经理 |
1.5 责任角色边界
| 角色 | 职责范围 | 输出责任 | 否决权 |
|---|---|---|---|
| 产品经理 | 主持对齐流程、维护Roadmap、决策优先级 | 决议书、更新版Roadmap | 是（对功能取舍） |
| 产品设计师 | 演示原型逻辑、提供设计约束、制作映射表 | 原型-功能映射表、交互说明 | 否（但可建议） |
| 技术负责人 | 评估原型实现可行性、提供工时预估 | 工程资源占用表更新 | 是（对技术可行性） |
| 用户体验研究员 | 呈现测试数据、解读用户行为 | 测试摘要报告 | 否 |
| 项目经理 | 检查前置条件、组织会议、跟踪决议执行 | 检查清单、决议通知、风险备注单 | 否（但可中止流程） |
1.6 操作步骤（概要流程）
- 前置检查：项目经理按1.2节清单确认所有条件满足，未满足项标记为阻断项。
- 输入聚合：各对应角色在会前36小时提交输入物至共享知识库。
- 对齐会议：产品经理主持，依次评审每个原型功能与Roadmap的匹配度，形成决议。
- 决议产出：即时生成决议书，并指定更新Roadmap、映射表等输出物的完成时限。
- 分发与存档：项目经理将决议通知与待办清单发送所有干系人，并将全量记录归档。
1.7 异常处理
常见异常及处理策略：
- 关键角色缺席：若持有否决权的角色（产品经理/技术负责人）缺席，会议自动降级为预备会，不得产出正式决议。需另约时间。
- 原型测试数据不完整：由用户体验研究员在会议前4小时补测2-3个核心任务，或标注数据缺失部分，在会议中声明置信度。
- Roadmap冲突不可调和：暂停该功能的对齐，启动“红色通道”上报至VP级决策，并在风险备注单中记录。
- 输出物逾期：项目经理每日跟进，逾期超24小时则升级至对应角色主管，并调整对齐会议后续节点。
1.8 验收标准
- 所有前置条件检查项均已通过（有项目经理签字及时间戳）。
- 每个原型功能在决议书中均有明确状态（纳入/暂缓/拒绝/分拆），且附决策理由。
- 更新后的Roadmap与决议书内容一致，且所有变更均有版本号记录。
- 原型-功能映射表100%覆盖原型中所有交互模块，且每个模块关联至Roadmap特性ID。
- 决议通知已发送至所有干系人，待办清单中无未分配责任人的项。
- 风险备注单完成率100%，且每项风险均有缓解措施或升级路径。
1.9 记录材料
归档要求：每次对齐活动后，项目经理需将以下材料打包至指定知识库目录（路径：
projects/{project_code}/alignment/{yyyy-mm}/）：- 对齐会议录音/录屏文件
- 决议书PDF（含与会人员手写签名或电子审批）
- 原型-功能映射表（CSV+截图版）
- 更新前的Roadmap快照（作为对比基准）
- 风险备注单（Excel，含跟踪状态列）
注意：归档遗漏或延迟将直接影响下一次对齐流程的输入完整性。建议项目经理在团队协作工具中设置自动化提醒（如Jira/Asana规则），在决议书创建时自动生成归档任务。
图1-1：原型与Roadmap对齐的典型流程与输入/输出关系
1.10 关键提示与检查清单
新手常见错误：
- 将“前置条件”与“输入物”混淆——前置条件是状态（如“测试报告已产出”），输入物是制品（如“测试报告文件”）。
- 输出物仅完成决议书，遗漏风险备注单或映射表，导致后续执行无法溯源。
- 项目经理未核实关键角色的否决权是否到位，造成会议无效。
□ 前置条件检查表已全部打勾
□ 输入物已上传至共享库（会前36小时）
□ 会议邀请已发送给所有决策角色，且已确认出席
□ 原型-功能映射表初始版本已由设计师准备
□ 历史对齐决议记录已下载供参考
□ 会议后归档任务已创建并指定负责人