3. 对齐前的准备工作清单
对齐会议的成功与否，80%取决于会前的准备工作。缺乏准备的对齐会议往往演变为“信息宣讲会”或“需求辩论赛”，而非高效的共识达成。本章提供一套标准化的准备清单，确保你在发起对齐前，已经完成了必要的信息、人员与材料储备。
核心原则：准备阶段每投入1小时，可节省对齐会议中3-4小时的无效争论。不要跳过这一环节直接发起会议。
3.1 适用场景
本清单适用于以下所有PRD对齐前的准备阶段：
- 首次需求对齐：新产品、新模块或重大功能变更首次与跨团队沟通。
- 关键里程碑对齐：涉及多团队依赖、资源承诺或时间承诺的重要节点。
- 变更影响对齐：原有需求发生重大变更，需要重新评估影响范围。
- 复杂依赖对齐：需求涉及3个以上技术团队或外部系统对接。
3.2 前置条件
在启动准备清单之前，需要确认以下条件已满足：
| 前置条件 | 验收标准 | 负责人 |
|---|---|---|
| PRD完成内部评审 | 产品团队内部已完成至少1轮评审，核心逻辑无严重矛盾 | 产品经理 |
| 需求边界已界定 | 明确本次对齐的范围（MVP/迭代/全部功能） | 产品经理 |
| 技术可行性初步评估 | 技术负责人已确认不存在原理性不可行的需求 | 技术负责人 |
| 排期资源初步摸底 | 各团队已知晓存在排期冲突可能，并同意在会议中讨论 | 项目经理/Scrum Master |
3.3 操作步骤：准备工作三步法
步骤一：收集背景信息
全面收集与本次PRD相关的业务、技术、市场和历史信息，避免对齐会议中频繁出现“我以为你知道”的情况。
- 业务背景：本次需求的商业目标、用户价值、预期收益（KPI/OKR）。
- 技术背景：现有系统架构、关键技术选型、历史技术债点。
- 市场/竞品背景：竞争对手的同功能表现、市场反馈、行业趋势。
- 历史背景：类似功能的以往决策记录、遗留问题、未关闭的Bug或需求。
- 约束条件：合规要求、安全红线、性能基线、上线时间硬约束。
步骤二：明确关键干系人
识别并确认需要参与对齐的核心干系人，以及各自的关注点和决策权限。
| 干系人类别 | 典型角色 | 关注重点 | 决策授权 |
|---|---|---|---|
| 决策者 | 产品总监、技术总监、业务负责人 | ROI、资源投入、时间承诺、业务风险 | 可审批/否决需求 |
| 执行者 | 前端/后端/算法/数据开发、测试 | 技术实现、工时评估、依赖、可测试性 | 可反馈可行性/设计建议 |
| 支持者 | UI/UX设计、运营、市场、法务 | 用户流程、上线触达、合规风险 | 可反馈非功能需求/风险 |
| 依赖方 | 外部系统负责人、API对接方 | 接口定义、排期冲突、数据质量 | 可确认/拒绝依赖 |
步骤三：准备输入材料模板
使用标准化的输入材料模板，确保所有参会者在会前拥有统一的信息基线。
- PRD精简版：去除评审记录、草稿批注，仅保留最终决策后内容，控制页数（建议不超过15页）。
- 变更对照表：标注本次变更与上一版本或现有功能的差异点，便于快速聚焦。
- 依赖关系图：明确各方依赖顺序、输入输出、时间窗口。
- 预读指南：列出建议重点阅读部分、需提前思考的问题。
- 会前反馈收集表：提前2个工作日发送，收集参会方初步观点和顾虑。
3.4 输入输出物
| 输入物 | 来源 | 输出物 | 去向 |
|---|---|---|---|
| 已定稿的PRD | 产品经理 | PRD精简版（对齐用） | 全体参会人 |
| 技术可行性报告 | 技术负责人 | 依赖关系图 | 全体参会人 |
| 干系人列表 | 项目经理/产品经理 | 干系人权限矩阵 | 决策者、会议主持人 |
| 历史变更记录 | Wiki/项目管理工具 | 变更对照表 | 全体参会人 |
| 会前反馈收集表 | 各参会方 | 会前问题汇总清单 | 会议主持人、产品经理 |
3.5 责任边界
- 产品经理：准备PRD精简版、变更对照表、预读指南，并确保业务背景信息准确完整。
- 技术负责人：确认技术可行性，协助绘制依赖关系图，标注技术风险点。
- 项目经理/Scrum Master：确认干系人列表、发送会前材料、收集会前反馈、协调会议时间。
- 各参会方：按时完成预读，填写会前反馈收集表，明确自己是否有决策授权。
3.6 记录材料
准备阶段完成后，应保留以下记录材料以便追溯：
- 会前材料发送记录：包含发送时间、版本号、接收人列表。
- 会前反馈收集表（原始数据）：保存所有参会方返回的原始反馈。
- 干系人确认记录：确认各核心干系人或其授权代表能够出席。
- 变更对照表（含日期）：作为后续需求变动的基线参考。
3.7 异常处理
| 异常场景 | 处理建议 |
|---|---|
| 关键干系人无法到场 | 确认是否有授权代表；如无，延期会议，不能缺位进行决策。 |
| 背景信息存在重大冲突 | 暂停准备，升级至干系人层面先行澄清，确认统一信息源后再推进。 |
| 技术可行性有争议 | 单独组织技术可行性讨论会，产出明确结论后再进入对齐流程。 |
| 会前反馈数量过多或质量过低 | 会议主持人判断是否扩展为“异步反馈+线下沟通”，避免会议室大量重复讨论。 |
3.8 验收标准
- 所有核心干系人及其授权代表已被识别并确认参会。
- PRD精简版、变更对照表、依赖关系图、预读指南、会前反馈收集表已全部就绪。
- 会前材料已提前至少2个工作日分发给所有参会人。
- 已收到至少2/3核心参会方的会前反馈，且无明显信息缺失或矛盾。
- 技术可行性已获技术负责人书面确认，不存在原理性分歧。
- 变更对照表已与历史记录核对，无遗漏项。
关键检查项：如果某个团队表示“需要先内部对齐再参加你的对齐”，说明你的准备材料尚未满足该团队的预读需求。此时应暂停，补充分团队内部分工或提供更细粒度的材料。