LaunchCal

在所有需要评审的职能之间协调发布。发布负责人拿到自动生成的清单，评审者拿到清爽的队列，其他人拿到日历。

为什么会有它

灵感来自这件事在 Google 的做法：留下真正管用的部分，去掉只有在那种规模下才成立的部分。

你会得到什么

• 按职能团队设置的发布步骤模板
• 支持通过、拒绝、例外的评审队列
• 新闻稿、仪表盘与复盘作为交付物
• 面向相关同事的发布日历与甘特图

如何运作

1. 1每个职能只写一次自己的步骤法务、隐私、安全、支持、市场：凡是需要过目发布的职能，都维护一份模板，写清自己需要什么、什么时候需要。写一次，之后每次发布都适用。
2. 2发布负责人描述这次发布是什么、影响谁、打算什么时候上线。清单会根据适用的模板自动生成，所以不必先懂流程才能照着走。
3. 3评审者处理一个队列每个职能只看到等着自己的步骤，然后批准、驳回，或给出带理由的例外。发布负责人不用追着谁跑，就能看着整件事往前走。

团队用它来做什么

• 赶一个已经推迟过一次的日期

  日历会显示哪些步骤在卡着、卡在谁手里，于是讨论的是真实的依赖关系，而不是谁没回消息。

• 带一个第一次做发布的人

  不需要那些口口相传的经验。清单说明要求是什么，例外说明什么被豁免了、为什么。

• 回答「这个季度会上线什么」

  发布日历和步骤甘特图就是答案，而且始终是最新的，因为它和发布负责人正在用的是同一份东西。

常见问题

我们需要改变现在的发布方式吗？

不需要。模板描述的就是你们已有的流程：LaunchCal 是它存放的地方，不是另一套流程。多数团队先把现在就在要求的东西写下来，经过一两次发布再打磨。

某个步骤不适用怎么办？

由评审者给出例外，并附上理由。它会记录在这次发布上，而不是被悄悄跳过，这样之后有人追问原因时能看到答案。

相关方需要席位才能看到发布吗？

席位是给真正做事的人用的：发布负责人和评审者。大多数人想要的那份日历，并不需要席位。

这和我们的任务系统是什么关系？

任务系统承载工程工作。LaunchCal 承载审批和日期，也就是平时会散落在聊天和表格里的那一部分。