1. 对齐场景与前置条件
本章是启动“PRD-原型”对齐工作的第一个里程碑。目标是明确“什么情况下需要对齐、如何才算准备好、哪些人必须参与”。在流程SOP体系中，前置条件的严谨度直接决定后续步骤的返工率。以下内容将作为全课程的操作基线。
1.1 适用场景
本 SOP 适用于以下 4 类典型场景。不在列表中的对齐需求（如非正式沟通、口头确认）应首先补充进入以下场景再启动流程。
| 场景编号 | 场景名称 | 触发条件 |
|---|---|---|
| S-01 | 新需求首次对齐 | PRD 初版完成，尚未进入 UI 设计阶段 |
| S-02 | 版本迭代对齐 | 已有线上原型，PRD 关键字段变更（如状态机、交互规则） |
| S-03 | 临时/紧急需求对齐 | 业务方要求 48 小时内上线，PRD 为极简版（仅包含逻辑骨架） |
| S-04 | 原型走查与纠偏 | UI 设计师完成高保真后，发现与 PRD 存在 3 处以上差异 |
提示：如果当前场景不属于以上 4 类，不要直接跳过前置检查。应先在项目组内以“对齐启动”名义创建一次轻量级预审，然后再确定适用场景分类。
1.2 前置检查项
在进入“准备-执行-验收”主线流程之前，必须完成以下 6 项检查。任何一项未通过，流程自动挂起。
- PRD 状态检查：文档已完成至少 1 轮内部 Review，变更标记采用“修订模式”或颜色批次标注。
- 原型基线锁定：UI 设计师提供的原型文件已上传至协作平台，并打上“待对齐”标签。
- 依赖项确认：相关的后端 API 定义、埋点方案、文案资源至少完成 60% 以上。
- 团队饱和度：产品经理、UI 设计师、前端开发负责人在未来 48 小时内无 P0 级紧急任务。
- 工具链就绪：团队采用
中的同一款原型工具，且版本兼容。Figma / Sketch / Axure / MasterGo - 数据回传通路：如果有数据驱动的交互逻辑，需确认后端模拟数据或 Mock 服务可用。
避坑：如果 PRD 与原型存在版本不一致（如 PRD 已更新 3 次但原型仍为初版），严禁直接发起对齐会议。必须先执行“版本归一”操作——通常需要产品经理与 UI 设计师开一次 15 分钟的站会拉平基线。
1.3 责任角色对齐清单
每一个对齐活动都涉及 3 个核心角色与 2 个支撑角色。下表中的职责边界是硬性要求，不允许交叉或代庖。
| 角色 | 在“检查与对齐”环节中的职责 | 必须产出的物项 | 否决权范围 |
|---|---|---|---|
| 产品经理 (PM) | 提供 PRD 最终版；逐项讲解业务逻辑与异常流程 | PRD 基线清单（含版本号） | PRD 内容与业务需求不符时一票否决 |
| UI 设计师 (DES) | 展示原型交互动态；标注与 PRD 不一致的视觉约束 | 原型批注文件（含差异标记） | 交互实现成本超出预期时可提议重新评估 |
| 前端开发工程师 (FE) | 从实现角度提出原型与 PRD 的矛盾点 | 技术实现可行性反馈表 | 功能逻辑在当前架构下不可实现时行使否决权 |
| 测试工程师 (QA) | 接收对齐后的最终结论，更新用例基线 | 测试用例对齐跟踪记录 | 无本质否决权，但有状态变更提醒义务 |
| 业务方 (BIZ) | 确认对齐结果是否符合原始业务诉求 | 业务验收签字（钉钉/飞书/邮件） | 业务目标未达成时一票否决 |
1.4 对齐场景与前置条件流程图
1.5 输入 / 输出物
| 类型 | 物项名称 | 格式/规范 | 责任人 |
|---|---|---|---|
| 输入 | PRD 终稿（含版本号） | Word / Confluence / Notion | PM |
| 输入 | 高保真原型文件（.fig / .sketch / .rp） | 协作平台，带草稿或批注图层 | DES |
| 输出 | 对齐角色责任清单（本章产出） | 表格或协作文档，含角色与否决权 | PM |
| 输出 | 前置检查通过标志（绿灯/红灯） | 流程卡片/看板绿标 | ALL |
1.6 记录材料要求
- 对齐会议纪要：必须包含场景编号、版本基线与前置检查通过状态。
- 角色签字记录：至少 PM + DES 两方签字，如有分歧记录“否决方”与“否决原因”。
- 验收快照：对齐后的原型与 PRD 关键截图，作为后续变更追溯的依据。
1.7 异常处理
| 异常类型 | 触发条件 | 处理方式 | 超时处理 |
|---|---|---|---|
| 前置检查挂起 | 6 项检查任意一项不通过 | PM 24h 内补齐；发起“快速预审” | 超时则自动降级为下一迭代 |
| 角色否决 | FE 或 BIZ 行使否决权 | 启动“版本归一”或“设计仲裁”子流程 | 48h 内未解决则升级至项目总监 |
| 验收不通过 | 验收标准未达成 | 回退至前置检查第1步重新走流程 | 每次回退记录在案，超过 3 次则变更控制 |
1.8 验收标准
本章节点是否结束，由以下 3 项硬性条件全部满足为准：
- 适用场景已明确标注（S-01/02/03/04）并记录在会议纪要中。
- 6 项前置检查全部显示“通过”（绿灯），无挂起项。
- 角色责任清单（PM/DES/FE/QA/BIZ）已完成初始签字，否决方记录清晰。