CategoryResourceRepost/极客时间专栏/邱岳的产品实战/模块一：增长你的产品：一款产品的诞生与增长/07 | 产品发布的那些坑儿.md

<audio id="audio" title="07 | 产品发布的那些坑儿" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/83/f4/8386e5d7e0f82fb8394c2a388676f5f4.mp3"></audio>

你好，我是邱岳，今天我分享的主题是：产品的发布。

上次的分享，我们讲到了产品的立项以及立项过程中的一些关注点。在项目立项后，就需要组成项目团队、设计、评审、开发、做项目管理与执行等等。这部分内容在上一季专栏中聊过，这里就不再展开了，今天的分享，我想跟你说说关于发布的一些经验和注意事项。

产品发布是临门一脚，虽然不算是决定性的关键时刻，但如果做得不好，也会导致慌乱，影响大家对项目和项目组的信心。过去我在发布中碰过无数的钉子，有很多有意思的经历，讲出来或许可以帮你避免类似的坑。

我过去在发布上摔了很多跟头，经常是信心满满地发布，灰头土脸地回滚。

我遇到的问题也五花八门，比如先发了代码没做数据库变更，或者发了数据库变更忘了及时订正数据，又或者时间没协调好，发布计划中第一步还没做完第三步就到点儿执行了，甚至是临发布了发现有个流程负责人在飞机上不能接电话等等。

我一度很纳闷，感觉自己是不是被诅咒了。为什么周围人的发布都很顺利，一到我手里就要出各种幺蛾子。

这个事情为我养成了两个习惯，一个是每到项目发布就非常紧张，如临大敌，草木皆兵，为此经常被同事调侃；另一个是我自己一直以来悄悄记录着一个发布时的检查清单，在很长一段时间里，每当自己负责的项目发布时，我都会对着看一遍。

我特意去旧硬盘里把这份检查清单翻了出来，有些杂乱，而且其中有一些检查项现在看起来显得很幼稚，或已经过时了，但从这列表中，你仿佛看到一个年轻产品经理的伤痕和反思，所以我也不怕丢人，决定一字不改贴出来。

<img src="https://static001.geekbang.org/resource/image/ec/de/ec443ba38fbc765ef6fb722064cff2de.png" alt="" />

这里面的每一条，基本都是因为碰过钉子，我才会记下来，有的还碰了不止一次。相信大部分产品经理都没有这么丰富的发布掉坑经验，所以今天我想分享一下我的伤痕和反思，希望帮你避免在这个环节掉入一些没必要的坑。

要在发布环节做到“一切尽在掌握”，我总结了三个检查思路。

## 1.该知道的人知道了吗

这是最关键的一步，大部分的发布问题都出在“有人不知道”，也就是相关方对发布的范围或时间不知情。

这里指的相关方首先是技术和流程上的相关方。比如上面检查列表中的第一条，就是项目发布了，该互相庆祝也庆祝完了，大家收拾东西准备下班了，这时发现隔壁部门的系统挂了，原因是我们改了某个业务状态逻辑没有提前通知对方。

类似的还有检查列表的 17 和 18，有时我们依赖别人的接口或服务，甚至是业务刚上线借用了别人的服务器，结果发布的时候没提前跟人家说好，流量一下上来了，把人家的服务或服务器给干挂了。

还有业务部门和用户的相关方，这个我们在前面讲立项过程的时候也提过，就不重复了，列表中的 9、15、16 都是这类问题。

最后还要多提一句发布通知，这是在大公司里养成的习惯，简短地跟相关人说一下什么东西发布了，可能会带来些什么改变等等。发布通知尽可能冷静克制，发到合适的人就好了，别漏掉谁，也别什么事儿都兴师动众给全公司发邮件。

另外一般发布通知最后会有一两句致谢，感谢兄弟部门的配合之类的就好了，真诚简短足矣，不要加戏。

经常看到大公司的致谢特别长，其实显得特别不真诚，反而过犹不及，有点官僚主义，我觉得不是很有必要。

## 2.脑子里排练过吗

这个过程跟做产品设计时理解用户场景的过程类似，我们应当尽量在脑海中把整个发布过程演一遍。有时候严肃一点的项目会有明确的发布计划，发布计划会列明每一步做什么，先后顺序和负责人，可能的异常情况和预案。

几乎所有的发布意外都会跟准备不充分有关系，比如列表中的第 4、5、6 条，如果我们没有提前做好计划，或者某些环节被忽略、没有预留出足够的时间等等情况下，那就很有可能在发布的过程中出了问题。

而且类似的问题经常是：测试环境一切正常，发布到生产环境就不工作了。慌乱中很可能会节外生枝，比如早先我们没有服务治理之类的东西，有一些特定的服务需要在负载均衡上指定特定的服务器。

但是测试环境是单点，不会出问题，结果发到生产环境集群上就忘记了这个步骤，导致连环挂，查了很久才找到原因。

除了技术问题之外，把所有的流程在脑海中排练一遍，也可以帮助我们去识别流程上一些关键步骤的权限人，比如管数据库或服务器的同事，不要到了执行到了某一步的时候才去找人。

像我们之前在分享的时候说过，我们就遇见过一次，在执行某一次变更，有权限的人恰好在飞机上，然后找他的备份，找了很久。

## 3.万一出意外有退路吗

凡事都应当往好的方向努力，往坏的方向打算，发布也是如此，充分准备的同时也要准备好出现意外时的预案。

发布过程中出现问题的时候，可以根据影响用户的范围决定是回滚还是在线修，能不回滚尽量别回滚，毕竟会伤害团队士气。

所以为了尽量留出余量，发布时间也尽可能慎重选择。不要在业务高峰时间段发布，即便真出了问题也可以坚持一会儿尽量修复掉。另外也尽量避免在周末晚上发布，可能发完大家回家过周末了，万一出问题想召集人解决都很难。

如果确实救不回来了，就开始按部就班地回滚，如果项目规模很大，回滚的顺序也很重要，这个没有什么特别的技术含量，提前有个准备就可以。常在河边走，早晚要湿鞋，遇到了不要慌乱，沉住气处理好就行了。

## 总结

今天我们分享了产品或项目的发布，它其实是一个非常小而且不怎么核心的环节，我在准备这篇内容的时候也曾经犹豫过，担心它会不会太微不足道了。

但是，考虑到一方面发布具有很重要的里程碑意义，另一方面作为产品经理（也可能是项目经理）需要在各种环节中保持稳定和专业，也是职业素养的体现。

希望今天的分享能够给你带来启发，也欢迎你分享在自己的项目发布中经历过的糗事或积累的经验，我们下次见。