deliver-launch-checklist
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
Launch Checklist
上线检查清单
A launch checklist is a comprehensive verification document that ensures all functions are ready before releasing a feature or product. It coordinates across engineering, QA, design, marketing, support, legal, and operations to prevent launch-day surprises. Good launch checklists surface blockers early and create shared accountability for launch readiness.
上线检查清单是一份全面的验证文档,用于确保功能或产品发布前所有环节均准备就绪。它协调工程、QA、设计、营销、客服、法务和运营等跨职能团队,避免上线当天出现意外情况。优质的上线检查清单能提前发现阻碍因素,并明确各方对上线准备工作的责任。
When to Use
使用场景
- 1-2 weeks before any significant launch
- During launch planning kickoff meetings
- When coordinating cross-functional releases
- Before major version releases or feature rollouts
- After incidents to improve launch processes
- 重大上线前1-2周
- 上线规划启动会议期间
- 协调跨职能发布时
- 重大版本发布或功能推出前
- 发生事故后优化上线流程时
Instructions
使用说明
When asked to create a launch checklist, follow these steps:
-
Define Launch Context Document what is launching, when, and who the key stakeholders are. Establish the launch tier (major release, minor feature, experiment) as this affects checklist scope.
-
Gather Functional Requirements For each function (engineering, QA, marketing, etc.), identify what must be complete, verified, or in place before launch. Distinguish between blockers (must-have) and nice-to-haves.
-
Assign Owners and Dates Every checklist item needs an owner and a target completion date. Ownership creates accountability; dates enable tracking.
-
Identify Dependencies and Blockers Flag items that block other work or are blocked by external factors. Surface these early so teams can unblock.
-
Define Go/No-Go Criteria Establish clear criteria for making the launch decision. What conditions must be met? Who makes the final call?
-
Document Rollback Plan Every launch should have a rollback strategy. Document how to revert if critical issues emerge post-launch.
-
Schedule Check-in Cadence Establish when the team will review checklist progress (daily standups, T-2 days review, launch day sync).
当需要创建上线检查清单时,请遵循以下步骤:
-
明确上线背景 记录即将上线的内容、时间以及关键利益相关方。确定上线层级(重大版本发布、次要功能更新、实验性发布),这会影响检查清单的范围。
-
收集职能需求 针对每个职能领域(工程、QA、营销等),确定上线前必须完成、验证或落实的事项。区分阻碍项(必备)和锦上添花项(可选)。
-
分配负责人和截止日期 每个检查清单项都需要指定负责人和目标完成日期。明确负责人能建立问责制;设置日期便于跟踪进度。
-
识别依赖关系和阻碍因素 标记那些会阻碍其他工作或受外部因素阻碍的事项。尽早提出这些问题,以便团队解决阻碍。
-
定义上线/不上线标准 制定明确的上线决策标准。需要满足哪些条件?谁拥有最终决定权?
-
记录回滚计划 每次上线都应有回滚策略。记录如果上线后出现关键问题,如何进行回退操作。
-
安排进度检查节奏 确定团队审查检查清单进度的时间(每日站会、上线前2天审查、上线当日同步会议)。
Output Format
输出格式
Use the template in to structure the output.
references/TEMPLATE.md使用中的模板来构建输出内容。
references/TEMPLATE.mdQuality Checklist
质量检查清单
Before finalizing, verify:
- All functional areas are represented
- Every item has an owner and target date
- Blockers are clearly distinguished from nice-to-haves
- Go/No-Go criteria are specific and measurable
- Rollback plan is documented and tested
- Check-in cadence is scheduled
最终确定前,请验证:
- 涵盖所有职能领域
- 每个事项都有负责人和目标日期
- 阻碍项与锦上添花项区分明确
- 上线/不上线标准具体且可衡量
- 回滚计划已记录并经过测试
- 已安排进度检查节奏
Examples
示例
See for a completed example.
references/EXAMPLE.md请查看获取完整示例。
references/EXAMPLE.md