4. 对齐会议流程：邀请、议程、演示、记录、决议
4.1 适用场景
对齐会议适用于以下关键业务节点：
- 交互方案设计完成，准备进入研发评审之前。
- 业务需求有重大变更，需要确认原型是否准确反映新需求。
- 跨部门协作（如产品、设计、开发、测试）需对界面逻辑达成共识。
- 阶段里程碑交付，需要产出经签批的Solution Design基线。
4.2 前置条件
必要条件检查清单：
- 原型已冻结：当前版本的原型（Figma/Axure/Sketch）已完成内部设计师审批，不再包含草稿或临时占位。
- Solution Design文档已草拟：包含业务规则、数据字段定义、页面流转关系。
- 参会方已确认：明确产品经理、架构师、研发Owner、测试Leader必须出席。
- 会议白板/共享屏幕设备就绪：确保投屏或远程会议工具的录制功能可用。
4.3 操作步骤（五大阶段）
| 阶段 | 动作 | 负责人 | 输出 |
|---|---|---|---|
| 1. 邀请 | 提前48小时发出会议邀请，附加原型链接与预读材料 | 产品经理 | 会议邀请邮件（含议程） |
| 2. 议程 | 明确会议时长（通常60分钟）、分环节时间盒、决策点 | 产品经理 | 议程文档 |
| 3. 演示 | 按预设流程逐页讲解原型，重点展示异常边界与状态变化 | 设计师 / 产品经理 | 标注到位的演示笔记 |
| 4. 记录 | 实时在会议纪要中记录决议、待办项与争议点 | 会议记录员 | Aligned Meeting Notes |
| 5. 决议 | 逐条确认是否通过、退回修改或挂起 | 产品Owner | Signed-Off Decision Log |
4.4 输入输出物
| 类型 | 名称 | 说明 |
|---|---|---|
| 输入 | 交互原型（链接/导出包） | 冻结版原型，包含所有页面及交互连线 |
| 输入 | Solution Design草案 | 含业务逻辑、字段字典、校验规则 |
| 输入 | 产品需求文档（PRD） | 业务描述及验收标准 |
| 输出 | 会议纪要 + 决议日志 | 经所有参会方签字的最终对齐记录 |
| 输出 | 更新后的原型 / Solution Design | 根据决议产生的修订版本 |
4.5 责任边界
关键角色职责矩阵：
- 产品经理：主持议程，决策业务规则是否满足需求；负责最终决议签署。
- 设计师：演示原型，解释交互设计意图；记录界面层技术难以实现的点。
- 研发代表：评估原型在技术栈下的实现可行性；提出可行性限制。
- 测试代表：确认测试用例能否覆盖原型所有路径；暴露边界条件缺失。
4.6 记录材料与模板
对齐会议必须使用标准化的记录模板，确保后续可追溯。以下为推荐记录结构：
会议记录模板示例：
【对齐会议纪要】
日期/时间：2025-03-20 14:00
项目名称：客户管理模块 V2.0
参会人：张三（PM）、李四（UI）、王五（Dev）、赵六（QA）
| 页面/组件 | 讨论重点 | 决议 | 责任人 | 截止日 |
|-----------|----------|-----------|--------|------------|
| 客户列表 | 分页是否加「全部」按钮 | 同意不加，统计量小 | 李四 | 立即关闭 |
| 新增表单 | 必填项校验时机 | 失焦校验 + 提交前二次校验 | 王五 | 下次迭代 |
待办：
- 王五评估表单校验对前端性能的影响（3/25前反馈）
- 赵六补充分页场景的边界测试用例（3/22前完成）4.7 异常处理
| 异常场景 | 应对策略 |
|---|---|
| 关键角色缺席 | 立即暂停会议，改期；或要求缺席者提前书面授权代理 |
| 原型演示中途发现逻辑矛盾 | 记录为HOT ISSUE，挂起当前流程，优先解决矛盾后再继续演示 |
| 会议超时（超过90分钟） | 强制休会，将未决议项列为待办专会 |
| 决议无法达成一致 | 产品Owner行使最终决策权，并写入会议纪要归因 |
4.8 验收标准
对齐会议结束后，需满足以下条件才算对齐成功：
- 会议纪要中无未解决的HOT ISSUE。
- 所有页面/流程的决议状态为「通过」或「退回重做」，不存在「暂缓」状态。
- 原型与Solution Design的版本号已更新至对齐后版本。
- 会议记录已由产品经理、研发代表、设计师三方电子签名。
- 形成一份完整的决策日志，包含每个决议的日期、决策人、依据。