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:
  1. 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.
  2. 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.
  3. Assign Owners and Dates Every checklist item needs an owner and a target completion date. Ownership creates accountability; dates enable tracking.
  4. Identify Dependencies and Blockers Flag items that block other work or are blocked by external factors. Surface these early so teams can unblock.
  5. Define Go/No-Go Criteria Establish clear criteria for making the launch decision. What conditions must be met? Who makes the final call?
  6. Document Rollback Plan Every launch should have a rollback strategy. Document how to revert if critical issues emerge post-launch.
  7. Schedule Check-in Cadence Establish when the team will review checklist progress (daily standups, T-2 days review, launch day sync).
当需要创建上线检查清单时,请遵循以下步骤:
  1. 明确上线背景 记录即将上线的内容、时间以及关键利益相关方。确定上线层级(重大版本发布、次要功能更新、实验性发布),这会影响检查清单的范围。
  2. 收集职能需求 针对每个职能领域(工程、QA、营销等),确定上线前必须完成、验证或落实的事项。区分阻碍项(必备)和锦上添花项(可选)。
  3. 分配负责人和截止日期 每个检查清单项都需要指定负责人和目标完成日期。明确负责人能建立问责制;设置日期便于跟踪进度。
  4. 识别依赖关系和阻碍因素 标记那些会阻碍其他工作或受外部因素阻碍的事项。尽早提出这些问题,以便团队解决阻碍。
  5. 定义上线/不上线标准 制定明确的上线决策标准。需要满足哪些条件?谁拥有最终决定权?
  6. 记录回滚计划 每次上线都应有回滚策略。记录如果上线后出现关键问题,如何进行回退操作。
  7. 安排进度检查节奏 确定团队审查检查清单进度的时间(每日站会、上线前2天审查、上线当日同步会议)。

Output Format

输出格式

Use the template in
references/TEMPLATE.md
to structure the output.
使用
references/TEMPLATE.md
中的模板来构建输出内容。

Quality 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
references/EXAMPLE.md
for a completed example.
请查看
references/EXAMPLE.md
获取完整示例。