用途
发布检查清单（Launch Checklist）是一份全面的验证文档，用于确保在发布某个功能或产品之前，所有职能都已就绪。它协调工程、QA、设计、营销、支持、法务和运营等多个团队，防止发布当天出现意外。好的发布检查清单能提前暴露阻塞项，并建立对发布就绪状态的共同责任。
何时使用
- 任何重大发布前 1-2 周
- 发布规划启动会议期间
- 协调跨职能发布时
- 重大版本发布或功能上线之前
- 事故发生后，用于改进发布流程
何时不使用
- 你正在通过实验验证是否应该发布：使用 measure-experiment-design
- 你需要面向客户的已发布内容公告：使用 deliver-release-notes
- 发布已经发生，你想要结果或复盘：使用 measure-experiment-results 或 iterate-retrospective
- 变更很小且仅涉及单一团队、没有跨职能影响：发布检查清单会增加仪式感而无价值，改为在冲刺中跟踪即可
使用方式
当被要求创建发布检查清单时，按以下步骤操作：
- 定义发布背景：记录发布内容、时间以及关键利益相关者。确定发布层级（重大版本、次要功能、实验），因为这会影响检查清单的范围。
- 收集职能需求：针对每个职能（工程、QA、营销等），确定发布前必须完成、验证或就位的事项。区分阻塞项（必须完成）和锦上添花项。
- 分配负责人和日期：每个检查清单条目都需要一个负责人和目标完成日期。负责人建立问责制，日期便于跟踪。
- 识别依赖和阻塞项：标记那些会阻塞其他工作或受外部因素阻塞的条目。尽早暴露，以便团队解除阻塞。
- 定义 Go/No-Go 标准：建立明确的发布决策标准。必须满足哪些条件？谁做最终决定？
- 记录回滚方案：每次发布都应有回滚策略。记录如果发布后出现严重问题如何回退。
- 安排检查节奏：确定团队何时审查检查清单进度（每日站会、T-2 天审查、发布日同步）。
输出格式
使用 references/TEMPLATE.md 中的模板来组织输出。完整的检查清单应填写模板的每个部分：发布概览；工程就绪；QA 与测试；设计与 UX；营销与传播；客户支持；法务与合规；运营与基础设施；分析与监控；Go/No-Go 标准；回滚方案；检查时间表；以及未决问题。
质量检查
在最终确定之前，验证：
- 所有职能领域都有代表
- 每个条目都有负责人和目标日期
- 阻塞项与锦上添花项清晰区分
- Go/No-Go 标准具体且可衡量
- 回滚方案已记录并经过测试
- 检查节奏已安排
示例
参见 references/EXAMPLE.md 获取完整示例。