第1章 对齐场景识别：前置条件、干系人、输出物
对齐场景识别是原型与 Solution Design 对齐工作的起点。本章建立标准化识别框架，帮助团队在需求变更、新需求提出或技术方案调整时，快速判断“是否需要对齐”“谁参与对齐”“对齐产出什么”，避免因场景误判导致返工或信息断层。
1.1 适用场景
以下三种触发条件必须启动对齐场景识别流程：
| 场景类型 | 触发条件 | 典型示例 | 对齐紧急程度 |
|---|---|---|---|
| 需求变更 | 产品需求文档发生修订 | 用户登录流程增加短信验证 | 高 |
| 新需求提出 | 新增功能或模块 | 首页新增个性化推荐卡片 | 中 |
| 技术方案调整 | 因实现成本或可行性变更设计 | API 接口由 REST 改为 GraphQL | 中 |
💡 识别技巧：是否启动对齐，可用“影响范围”快速判断——只要涉及原型交互逻辑或设计文档中已确认的方案，就必须执行对齐场景识别。
1.2 前置条件
启动对齐场景识别前，必须确认以下三项就绪：
- 原型就绪：设计稿已完成关键页面布局及交互标注，并通过内部初审。
- 文档就绪：Solution Design 文档（或需求规格说明书）已包含完整的业务流程、判定逻辑及异常说明。
- 环境就绪：评审环境（在线原型链接 / 本地演示环境）可被所有干系人正常访问。
⚠️ 常见遗漏：团队常忽略“环境就绪”检查，导致对齐会议中原型无法加载或交互演示卡顿，直接降低对齐效率。建议在会议前 30 分钟由专人完成环境预检。
1.3 操作步骤
- 确认触发事件：由产品经理识别需求变更、新需求或技术方案调整，并记录触发来源与变更范围。
- 执行前置条件检查：对照检查清单逐项确认原型、文档、环境是否就绪，不满足则返回补充。
- 识别干系人：根据变更影响范围确定必须参与对齐的角色（PM / UX / DEV / QA），确保无遗漏。
- 分类对齐场景：按影响面与复杂度分为“简单对齐”“正式评审”“紧急对齐”三类，确定对齐方式与时长。
- 定义输出物：明确本次对齐需产出的交付件（确认书 / 更新后原型 / 会议记录），指定责任人与交付时间。
- 发起对齐确认：由产品经理发起对齐会议或异步评审，推动干系人达成一致并签署确认。
1.4 输入输出物
| 类别 | 名称 | 格式 | 来源 / 去向 |
|---|---|---|---|
| 输入 | 需求变更申请单 | 文档 / 工单 | 产品经理 → 对齐流程 |
| 输入 | 原型设计稿（初版） | Figma / Sketch / Axure | UX 设计师 → 对齐流程 |
| 输入 | Solution Design 文档 | Confluence / 飞书文档 | 产品经理 → 对齐流程 |
| 输出 | 对齐确认书 | PDF / 邮件 | 对齐流程 → 全体干系人 |
| 输出 | 更新后原型 | 原型文件 | 对齐流程 → 开发团队 |
| 输出 | 对齐会议纪要 | 文档 | 对齐流程 → 项目归档 |
1.5 责任边界
| 角色 | 对齐前职责 | 对齐中职责 | 对齐后职责 |
|---|---|---|---|
| 产品经理 | 准备需求文档与变更说明 | 讲解需求背景 & 判定逻辑 | 签发对齐确认书 |
| UX 设计师 | 交付可交互原型与交互说明 | 演示原型 & 记录修改点 | 输出更新后原型 |
| 开发工程师 | 预审技术可行性 | 评估实现成本 & 影响范围 | 确认开发计划调整 |
| 测试工程师 | 了解需求变更范围 | 补充测试场景 & 边界条件 | 更新测试用例 |
1.6 记录材料
以下模板 / 记录必须归档至项目知识库：
- 对齐场景识别检查表：包含触发条件、前置条件勾选、干系人签到、场景分类结论。
- 前置条件预检记录：原型版本号、文档链接、环境访问状态及预检人签字。
- 对齐会议纪要模板：议程、结论、待办事项（含责任人与截止时间）。
- 确认书签署记录：各角色电子签名或已读确认的截图 / 邮件记录。
📌 归档