重大或跨团队产品发布前，用跨职能上线检查清单提前发现阻塞并明…

在重大或跨团队功能/产品发布前 1-2 周，协调工程、QA、设计、市场、支持、法务和运营等职能的就绪状态，避免发布日意外。

适用场景

解决思路

1. 定义 Launch Context：记录发布内容、发布时间和关键干系人；确定发布层级（major release、minor feature、experiment），因为它会影响清单范围。
2. 收集 Functional Requirements：对每个职能（engineering、QA、marketing 等），识别发布前必须完成、验证或就位的事项；区分 blockers（must-have）和 nice-to-haves。
3. 分配 Owners 和 Dates：每个清单项都需要 owner 和目标完成日期；所有权建立问责，日期便于跟踪。
4. 识别 Dependencies 和 Blockers：标记阻塞其他工作或受外部因素阻塞的事项；尽早暴露，以便团队解除阻塞。
5. 定义 Go/No-Go Criteria：建立明确的发布决策标准；明确必须满足哪些条件，以及谁做最终决定。
6. 记录 Rollback Plan：每次发布都应有回滚策略；记录发布后出现严重问题时如何回退。
7. 安排 Check-in Cadence：确定团队何时审查清单进度（daily standups、T-2 days review、launch day sync）。
8. 使用 `references/TEMPLATE.md` 中的模板组织输出；完整清单填写每个模板部分：Launch Overview；Engineering Readiness；QA & Testing；Design & UX；Marketing & Communications；Customer Support；Legal & Compliance；Operations & Infrastructure；Analytics & Monitoring；Go/No-Go Criteria；Rollback Plan；Check-in Schedule；Open Issues。
9. 定稿前验证所有职能领域都有代表。
10. 定稿前验证每个事项都有 owner 和目标日期。
11. 定稿前验证 blockers 与 nice-to-haves 清晰区分。
12. 定稿前验证 Go/No-Go criteria 具体且可衡量。
13. 定稿前验证 rollback plan 已记录并测试。
14. 定稿前验证 check-in cadence 已安排。
15. 参考 `references/EXAMPLE.md` 查看完整示例。

适用边界 · 注意事项

• 不要用于判断是否应该发布（通过实验验证）——应使用 `measure-experiment-design`。
• 不要用于面向客户的已发布内容公告——应使用 `deliver-release-notes`。
• 不要用于发布已发生后的结果或复盘——应使用 `measure-experiment-results` 或 `iterate-retrospective`；也不适用于小型、单团队、无跨职能面的变更，这类变更用 launch checklist 只会增加仪式感，直接在 sprint 中跟踪即可。