第四章 评审邀请与日程安排
评审邀请环节决定了评审能否在正确的时间点，把正确的人召集到同一个会场。本章的目标是建立一套标准化的邀请函生成、时间窗口划定、参会方确认的SOP，避免“临时拉人”“时间冲突”“遗漏关键角色”等典型问题。
4.1 适用场景
- 需求评审、设计评审、原型走查、Demo演示等所有需提前安排日程的正式评审活动。
- 跨团队（产品、设计、开发、测试、运营、业务方）协作的评审。
- 远程/混合办公模式下需要同步时区的评审。
- 涉及外部客户或供应商的评审。
4.2 前置条件
- 评审发起人已完成原型/文档最终版（或锁定版本号）。
- 已确定评审类型（内部快速走查 vs 正式里程碑评审）及对应的参会角色清单（见第三章）。
- 评审材料已上传至共享空间（如Figma、Confluence、飞书文档），并获得“可预览/可评论”权限。
4.3 操作步骤
| 步骤 | 动作 | 负责人 | 关键检查点 |
|---|---|---|---|
| 1 | 根据评审类型选择邀请函模板 | 发起人 | 模板中必须包含：评审目的、材料链接、时长、地点/会议号 |
| 2 | 设定时间窗口（建议3～5个可选时段） | 发起人 | 避开团队固定例会、午餐、临近下班时段；跨时区标注UTC |
| 3 | 发送预邀请并收集参会人空闲时段 | 发起人 | 使用投票工具（如Doodle、腾讯投票）24h内截止 |
| 4 | 锁定最终时间，生成正式日历邀请 | 发起人 | 添加评审材料链接及预读要求 |
| 5 | 确认关键角色必须出席，不可出席时触发替补机制 | 发起人+经理 | 产品/设计/开发各至少1位决策权人 |
| 6 | 发出正式邀请并设置提醒（评审前30min、10min） | 发起人 | 检查日历冲突，必要时私信再次确认 |
4.4 输入与输出物
输入物
- 角色清单（第三章输出）
- 评审材料锁定的版本号
- 团队日历（已同步的忙闲状态）
- 邀请函模板库
输出物
- 正式日历事件（含链接、描述）
- 参会人员确认清单（含替补信息）
- 时间窗口投票结果记录
4.5 邀请函模板（标准版）
以下为经过验证的邀请函模板，可直接复制修改。模板遵循“5W1H”结构：
主题：【原型评审】{项目名称} – {评审阶段} （预估时长）
正文：
Hi 各位，
我们将对 {模块/页面名称} 进行原型评审，以下是详细信息：
📌 评审目的：{一句话，如“确认用户注册流程是否符合预期”}
📌 评审材料：{共享链接，并注明版本号}
📌 预读要求：请在评审前 {时长} 浏览材料，记录标注点。
时间窗口（请选择你方便的时段）：
- 选项A：{日期} {开始时间} – {结束时间}（{时区}）
- 选项B：{日期} {开始时间} – {结束时间}（{时区}）
- 选项C：{日期} {开始时间} – {结束时间}（{时区}）
预计时长：{分钟}分钟
会议方式：{线下会议室/线上链接}
必须出席角色：产品经理、交互设计、前端开发、后端开发、QA。
请于 {截止日期} 前回复你可行的时段，或直接填写投票链接：{Doodle/飞书投票地址}。
谢谢！
{发起人姓名}
4.6 时间窗口规则
核心原则：时间窗口应覆盖目标参会人80%以上的空闲重叠区，且窗口长度建议控制在3～5个选项，过多选项会导致投票分散、决策缓慢。
- 窗口跨度：建议未来3～5个工作日，避开周一上午（周会高峰期）和周五下午（周末前精力分散）。
- 单选项长度：基础评审45min，复杂评审90min；不设超过120min的单次窗口。
- 跨时区处理：在投票选项中同时显示发起人时区和参会人常用时区，避免换算错误。
- 截止规则：投票截止时间为窗口最晚开始时间的12小时前，剩余6小时内不调整。
4.7 参会人员确认
参会确认不仅仅是“回复同意”，还需要明确“是否具有决策权”。使用下表进行确认：
| 角色 | 是否必须出席 | 决策人 | 可选替补 | 确认状态 |
|---|---|---|---|---|
| 产品负责人 | 是 | 是 | 业务方代表 | 已确认 |
| 交互设计师 | 是 | 否 | 设计团队其他成员 | 已确认 |
| 前端开发 | 否（但技术评估需要） | 否 | 前端Leader | 待确认 |
| QA Lead | 是 | 是 | 测试经理 | 请假，已通知替补 |
如果关键决策人（标绿）在锁定时间无法出席，发起人必须启动升级机制：联系其上级或调整时间窗口重新投票。
4.8 责任边界
- 发起人：负责邀请函的生成、投票发起、时间锁定、日历邀请发送及确认状态追踪。
- 参会人：有义务在截止时间前回复空闲时段，如无法按时参加须提前说明并派出有同等权限的替补。
- 项目经理/主管：当出现不可调和的时间冲突时，负责协调决策层资源，必要时做出优先级判定。
4.9 异常处理
| 异常场景 | 处理方案 |
|---|---|
| 投票截止后无满足80%重叠率的时段 | 扩展窗口至第7个工作日，或由PM直接指定一个强推时段，并标注“无法出席者需指派替补” |
| 关键决策人在正式邀请发出后突发请假 | 立即联系替补；若无替补则重新评估是否推迟评审，并将决定通知所有参会人 |
| 邀请函中材料链接失效或版本过旧 | 在评审开始前至少4小时更新链接并群发通知，同时更新日历事件描述 |
| 多人使用不同日历系统（Outlook vs GCal） | 发起人统一使用ICS格式导出，或使用飞书/钉钉等支持跨平台同步的工具 |
4.10 验收标准
评审邀请环节满足以下条件，视为完成：
- ✅ 邀请函包含评审5W1H且无信息错误
- ✅ 时间窗口已通过投票确定（或强推后已通知所有人）
- ✅ 参会人员确认清单中，关键决策人状态为“已确认”或“已安排替补”
- ✅ 日历事件已创建，并至少提前2小时设置了提醒
- ✅ 所有参会人在评审开始前24小时内收到过一条确认提醒（系统或人工）
4.11 本章SVG：评审邀请与日程安排流程图
4.12 记录材料
- 投票结果截图或原始投票链接存档（存入项目wiki）
- 最终时间窗口确认邮件/消息记录
- 参会人员确认清单（含替补信息）→ 可存储为
confirmation-checklist.md - 日历邀请的ICS文件备份
归档路径：{项目根目录}/docs/reviews/{评审日期}-评审安排/