launch-plan

根据赌注大小，而非抱负大小来决定发布方式。大多数功能都适合静默发布或软发布。只有真正的新产品或重大转型才值得采用盛大发布。Linear 的原则：尽早发布、频繁发布、多次发布。

发布层级

第 1 级：静默发布

发布并启用，然后观察情况。不做公告。

**适用场景：**错误修复、小幅改进、内部工具、基础设施变更、实验。

检查清单：

• 功能受功能标志控制，或采用渐进式发布
• 已设置监控和告警
• 已制定回滚计划
• 安排一人负责观察指标 24 小时

第 2 级：软发布

发布后告知现有用户，在全面推广前收集反馈。

**适用场景：**面向现有用户的新功能、重大的 UX 变更、定价调整、测试计划。

检查清单：

• 已撰写更新日志条目或应用内通知
• 已更新（或创建）帮助文档
• 已向支持团队介绍情况并提供常见问题解答
• 已建立反馈收集机制（调查问卷、反馈按钮、Slack 频道）
• 已记录已知限制
• 已制定回滚计划
• 全面推广前留出 1-2 周收集反馈

示例：发布实时协作功能——更新日志：“一起编辑，实时查看光标。”支持常见问题解答说明延迟预期和同时编辑人数上限。通过功能标志先向 20% 的团队开放 3 天，然后推广至 100%。回滚方案：禁用 WebSocket 同步，改用轮询。反馈组件开放 2 周。成功指标：至少有 2 位编辑者同时在线的团队占比。

第 3 级：盛大发布

统筹进行、面向公众，旨在最大限度扩大影响力。需要投入大量时间和精力。

**适用场景：**新产品发布、重大转型、品牌重塑、进入新市场。每年最多 2-3 次。

检查清单：

产品

• 功能已完成，并经过规模化测试
• 已与 5 位或更多新用户测试引导流程
• 已在预期负载下完成性能基准测试

内容

• 落地页或产品页已上线
• 已撰写博客文章 / 公告
• 已准备演示视频或截图
• 已起草发布当天及第 +1、+3、+7 天的社交媒体帖子

推广渠道

• 已安排向现有用户发送邮件
• 已排队准备好社交媒体帖子
• 已起草社区帖子（相关 subreddit、Slack 群组、Discord）
• 已准备好 Product Hunt 发布（如适用）
• 已提前 1 周联系影响者 / 合作伙伴

支持

• 已向支持团队介绍情况，并安排人员在发布当天值守
• 已记录常见问题和已知问题
• 已明确升级处理流程

衡量

• 已在发布前定义成功指标（而非发布后）
• 已验证分析追踪
• 已安排首周的每日复盘

发布后

无论采用哪个层级：

1. **第 1 天：**关注指标。修复所有故障。回复所有反馈。
2. **第 3 天：**首次复盘——哪些方面有效，哪些无效，有什么意外之处。
3. **第 1 周：**决定是继续迭代、扩大推广，还是收缩范围。
4. **第 2-4 周：**整理经验总结。根据实际数据更新路线图。

指南

• CRITICAL：默认采用第 1 级或第 2 级。只有理由充分时才升级为第 3 级。过度发布会让用户对公告感到疲劳。
• NEVER 在没有回滚计划的情况下发布。如果无法回退，就还没准备好。
• ALWAYS 在发布前定义成功指标，而非发布后。事后设定指标不过是在编故事。
• NEVER 在星期五发布。选择星期一至星期三发布，以便有一整周进行监控和迭代。
• ALWAYS 安排一人负责发布后的首个 24 小时。没有负责人的发布容易失去方向。
• NEVER 为已知存在 Bug 的功能举行盛大发布。先软发布、修复，再全面推广。

---

秉承 Linear 的“多次发布”理念。技能来自 productskills。