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

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

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

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

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

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

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

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

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

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

1.该知道的人知道了吗

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

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

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

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

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

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

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

2.脑子里排练过吗

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

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

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

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

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

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

3.万一出意外有退路吗

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

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

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

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

总结

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

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

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