07 | 产品发布的那些坑儿

Aug 15, 2018

07 | 产品发布的那些坑儿-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

07 | 产品发布的那些坑儿

2018-08-15 邱岳来自北京

《邱岳的产品实战》

课程介绍



讲述：邱岳

时长09:00大小4.12M



你好，我是邱岳，今天我分享的主题是：产品的发布。
上次的分享，我们讲到了产品的立项以及立项过程中的一些关注点。在项目立项后，就需要组成项目团队、设计、评审、开发、做项目管理与执行等等。这部分内容在上一季专栏中聊过，这里就不再展开了，今天的分享，我想跟你说说关于发布的一些经验和注意事项。
产品发布是临门一脚，虽然不算是决定性的关键时刻，但如果做得不好，也会导致慌乱，影响大家对项目和项目组的信心。过去我在发布中碰过无数的钉子，有很多有意思的经历，讲出来或许可以帮你避免类似的坑。
我过去在发布上摔了很多跟头，经常是信心满满地发布，灰头土脸地回滚。
我遇到的问题也五花八门，比如先发了代码没做数据库变更，或者发了数据库变更忘了及时订正数据，又或者时间没协调好，发布计划中第一步还没做完第三步就到点儿执行了，甚至是临发布了发现有个流程负责人在飞机上不能接电话等等。
我一度很纳闷，感觉自己是不是被诅咒了。为什么周围人的发布都很顺利，一到我手里就要出各种幺蛾子。
这个事情为我养成了两个习惯，一个是每到项目发布就非常紧张，如临大敌，草木皆兵，为此经常被同事调侃；另一个是我自己一直以来悄悄记录着一个发布时的检查清单，在很长一段时间里，每当自己负责的项目发布时，我都会对着看一遍。
我特意去旧硬盘里把这份检查清单翻了出来，有些杂乱，而且其中有一些检查项现在看起来显得很幼稚，或已经过时了，但从这列表中，你仿佛看到一个年轻产品经理的伤痕和反思，所以我也不怕丢人，决定一字不改贴出来。
这里面的每一条，基本都是因为碰过钉子，我才会记下来，有的还碰了不止一次。相信大部分产品经理都没有这么丰富的发布掉坑经验，所以今天我想分享一下我的伤痕和反思，希望帮你避免在这个环节掉入一些没必要的坑。
要在发布环节做到“一切尽在掌握”，我总结了三个检查思路。
1. 该知道的人知道了吗这是最关键的一步，大部分的发布问题都出在“有人不知道”，也就是相关方对发布的范围或时间不知情。
这里指的相关方首先是技术和流程上的相关方。比如上面检查列表中的第一条，就是项目发布了，该互相庆祝也庆祝完了，大家收拾东西准备下班了，这时发现隔壁部门的系统挂了，原因是我们改了某个业务状态逻辑没有提前通知对方。
类似的还有检查列表的 17 和 18，有时我们依赖别人的接口或服务，甚至是业务刚上线借用了别人的服务器，结果发布的时候没提前跟人家说好，流量一下上来了，把人家的服务或服务器给干挂了。
还有业务部门和用户的相关方，这个我们在前面讲立项过程的时候也提过，就不重复了，列表中的 9、15、16 都是这类问题。
最后还要多提一句发布通知，这是在大公司里养成的习惯，简短地跟相关人说一下什么东西发布了，可能会带来些什么改变等等。发布通知尽可能冷静克制，发到合适的人就好了，别漏掉谁，也别什么事儿都兴师动众给全公司发邮件。
另外一般发布通知最后会有一两句致谢，感谢兄弟部门的配合之类的就好了，真诚简短足矣，不要加戏。
经常看到大公司的致谢特别长，其实显得特别不真诚，反而过犹不及，有点官僚主义，我觉得不是很有必要。
2. 脑子里排练过吗这个过程跟做产品设计时理解用户场景的过程类似，我们应当尽量在脑海中把整个发布过程演一遍。有时候严肃一点的项目会有明确的发布计划，发布计划会列明每一步做什么，先后顺序和负责人，可能的异常情况和预案。
几乎所有的发布意外都会跟准备不充分有关系，比如列表中的第 4、5、6 条，如果我们没有提前做好计划，或者某些环节被忽略、没有预留出足够的时间等等情况下，那就很有可能在发布的过程中出了问题。
而且类似的问题经常是：测试环境一切正常，发布到生产环境就不工作了。慌乱中很可能会节外生枝，比如早先我们没有服务治理之类的东西，有一些特定的服务需要在负载均衡上指定特定的服务器。
但是测试环境是单点，不会出问题，结果发到生产环境集群上就忘记了这个步骤，导致连环挂，查了很久才找到原因。
除了技术问题之外，把所有的流程在脑海中排练一遍，也可以帮助我们去识别流程上一些关键步骤的权限人，比如管数据库或服务器的同事，不要到了执行到了某一步的时候才去找人。
像我们之前在分享的时候说过，我们就遇见过一次，在执行某一次变更，有权限的人恰好在飞机上，然后找他的备份，找了很久。
3. 万一出意外有退路吗凡事都应当往好的方向努力，往坏的方向打算，发布也是如此，充分准备的同时也要准备好出现意外时的预案。
发布过程中出现问题的时候，可以根据影响用户的范围决定是回滚还是在线修，能不回滚尽量别回滚，毕竟会伤害团队士气。
所以为了尽量留出余量，发布时间也尽可能慎重选择。不要在业务高峰时间段发布，即便真出了问题也可以坚持一会儿尽量修复掉。另外也尽量避免在周末晚上发布，可能发完大家回家过周末了，万一出问题想召集人解决都很难。
如果确实救不回来了，就开始按部就班地回滚，如果项目规模很大，回滚的顺序也很重要，这个没有什么特别的技术含量，提前有个准备就可以。常在河边走，早晚要湿鞋，遇到了不要慌乱，沉住气处理好就行了。
总结今天我们分享了产品或项目的发布，它其实是一个非常小而且不怎么核心的环节，我在准备这篇内容的时候也曾经犹豫过，担心它会不会太微不足道了。
但是，考虑到一方面发布具有很重要的里程碑意义，另一方面作为产品经理（也可能是项目经理）需要在各种环节中保持稳定和专业，也是职业素养的体现。
希望今天的分享能够给你带来启发，也欢迎你分享在自己的项目发布中经历过的糗事或积累的经验，我们下次见。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 14

提建议

06 | 如何做好产品立项

08 | 产品增长越来越难，到底应该怎么办？

 写留言

精选留言(30)

拾叔
2018-08-15
感谢二爷分享，二爷的第一期完整的学习了，第二期进行中，感觉两期的区别，第一期更加偏打基础，打前站，比如产品分析，产品设计，需求分析，用户调研等，时间轴不会特别明显，第二期，更多的是如何去实施，如何落地，有比较清晰的时间轴和路径，不过不管是哪一期，都是产品第一线的精华，非常实用，再次感谢二爷分享。而关于今天这一节，产品发布，二爷文中多次提到了官僚，很贴切，特别是大公司或者说人数规模比较大的公司，感受深刻，流程冗长，形式化的东西很多，产品经理在发布前，需要准备一系列的动作，比如金融系统的项目审批，从业务部门，到横向的风控，法务，财务，资金以及分管的大老板……然后系统层面走完，再走邮件层层审批，某一环节耽搁了，比如二爷说的，某审批人在飞机上或者关机等，都有可能项目发布审批要delay，这些流程走完，基本心力憔悴，都想放弃发布。我们发布一般是周二周四晚上，其他时间要发布基本需要走异常或者紧急发布。发布前本项目的开发负责人一般都会给全体项目组成员发一个发布通知邮件，主要说明哪些需要配置对接人是谁，哪些数据要准备对接人是谁，然后PMO会约个发布评审会，重新梳理一遍发布需要注意的核心事项，当然产品经理都需要参与。但是，即便如此流程，基本每次都会出些幺蛾子，比如某同学忘记配某系统生产环境配置了，发布项目太多，某个环境挂了等等，二爷列的很多坑，基本都深有体会。每笔发布第二天，我基本都会很早来公司，因为肯定会有问题恭候着。
展开
24
听天由己
2018-08-15
产品发布这事真的很重要，只有经历过各种异常情况和惨痛经历，我们才会有深切的感触。这份印象笔记检查项，能够看出二爷的全部经历，大公司的工作规范与制度化做得要好太多，其实这里面有一半检查项我一点都不了解，可能真的是创业公司的氛围和工作方式决定的，不过也能看出来自己的能力有待提升，考虑问题不够全面。除了二爷说的几点，我还想补充几句。 1、人，产品功能涉及到的公司同事是否通知到位？包括技术、市场、运营、客服、财务等； 2、物料，产品上线要准备的各种图片、宣传文案以及更新的需求文档等是否搞定； 3、事项，产品上线后需要关注的指标或是后续支持。关于亲身经历，最近出现的一次发布情况是，好不容易完成的 V1.0 上线 Appstore 后，却因为充值被要求说明虚拟服务等情况，此外，这是一次在原有产品上的改进，因业务需要暂时两套逻辑并行，同样受到了质疑。那时简直要奔溃了，最坏的结果是剥夺开发者权限，以前我从没接触过这些，这次意外让我大惊失色。好在重新调整几个小功能后，顺利上线了，却因此失去了最佳的时机，团队情绪太重要了。最后的最后，把这张图片存下来，给自己提醒。再次感谢。
展开
10
子悠
2018-10-11
每一个懂技术的产品经理都是值得尊敬的。
6
sylan215
2018-08-15
不知道大家项目中的发布具体是谁实施的，我们公司是测试干，作为质量保证人员，我们也同样的要保证发布质量，所以这一块上，我们的产品经理还是比较轻松的，经常是被我们催着去走流程……
共 2 条评论
3
大树
2019-02-20
经历过回滚之后，一到上线的时候和强迫症一样，反复确认，瑟瑟发抖.. 踩过两个坑： 1）产品相关人员没通知全... 因为之前在做的时候，没有了解到，我们这个模块的更改对另外一个业务有影响.. 上线之后，凌晨被业务方抓起来，回滚 QAQ，自责感溢出来了都... 2）兼容：大坑，做C端要小心再小心... 对安卓严加防范，因为型号和版本过多，做好低版本的兼容（要考虑用户性质，如果用户群体年龄稍长，低版本的兼容一定要做）最后，关于上线.. 我曾给自己立了个flag——“周五再上线就是狗！”
展开
作者回复: 哈哈哈哈哈哈，还有假期前要封网，否则假期人要疯。
2
桃园悠然在
2018-10-22
这个Checklist 形象的解释了什么叫不怕一万，就怕万一。临门一脚，千万不能松懈，“后天下之乐而乐”。
2
laulend™
2018-08-16
感谢二爷宝贵的经验和财富上线发布对每一条都罗列的很清晰很庆幸，前天在做活动复盘的时候，把运营、产品、研发、客服和供应链等其他协同部门的问题和需要改进的地方，刚好也罗列了一系列的清单和上线前需要测试和验收的清单详情…… 看了二爷的第54节课，回头发现，二爷的很多思维和处理问题的方式已经深深的引导着我，产品发布更多的是准备工作和配合工作，准备充分了，发布过程中可能会遇到的问题用清单罗列出来，问题尽量在发布前提前避免掉，这样上线发布的成功率会比那些不准备充分的情况更要高出很多，出现一点小问题都属于正常情况，重要的还是细心和用心。二爷说的测试环境一切正常，一上线就出问题，这个问题我们也遇到过很多次，对于这个问题，我和研发商量了一下，后期多加了一到测试环节，在仿真环境上测试，涉及到需要配置的地方，测试环境和线上环境配置保持一致，最终保证线上页面内容和输出以及流程保持一致，当然，考虑到数据量大和影响服务器这块，运营会提前给出预期以及预计用户量，一边研发提前做好准备工作。对于数据埋点，这块太重要了，无论是运营的漏斗数据，象限数据好的产品的交互数据以及按钮的位置、个数、形状以及文案和颜色等的影响，咱们都是需要经过争论的，最终会去促进线上发布的活动或者产品项目更好的发展和推进。甚至还包括给第三方投放的同学不同的来源链接，以便统计好对应的渠道效果数据。以上，二爷说的，可以说都经历过且深有同感，对了，我是个运营！跟着二爷学产品学跟项目，希望以后可以在做好运营的同时也能把整个项目更好的推进下去
展开
2
show
2018-08-15
之前每次发布都会有些小意外，都能对应到这个checklist里，还有很多可以做的，可以做的更好～最近在补《琅琊榜》，感觉二爷所做的一切推演，考虑等等都和梅常苏做的工作有异曲同工之效。
1
Dream.
2018-08-15
看到这自检表，突然发现自己也踩过不少其中的坑，却没有总结。还是要养成随时总结的习惯，不然一个坑里掉三四次，上头都该怀疑是不是智商问题了
2
Yezhiwei
2018-08-29
每个相关人多一点点责任心会变得很好
1
Novelty
2018-08-16
看着二爷所列的Checklist，让我想到了《清单革命》，只要经历过几次产品发布的人都会知道，需要考虑的点确实很多，但我们可以做好沉淀在大脑中搭建起一张认知防护网。就我个人而言，及时产品发布的流程再熟悉我也会拿出清单挨个进行检查，并且在每次发布完成后都会对清单进行持续改善，让清单始终确保安全，正确和稳定。
1
淘淘
2018-08-15
我们公司这一份checklist好像是开发来汇总和保证的，难道我遇到的都是假产品
1
BonnieFang
2018-08-15
看完Checklist ，😶这是一位被产品发布弄的异常紧张的产品经理，很仔细，也很有必要。
1
qzm
2021-03-23
很多项应该是TL，或者项目的技术负责人应该提前确认清楚。在流程上很多时候需要有发布计划评审。是的，发布多个应用系统、涉及到多个技术子部门、类似DBA、运维等必须要召开相关会议，然后checkList上面列清楚！在开会时有多个人会一起来看。
你是谁呀
2020-12-20
什么是回滚呐……上二爷的课没有技术背景每次都有一些词不懂🙉
共 1 条评论
黄康德
2020-07-07
我的观点是能回滚就立刻回滚，不能回滚就用功能开关，不要纠结，这样风险最小，对用户影响最小，上线过程也更轻松。
姜姜
2020-03-27
check list的受益者。
charlesybb
2019-08-26
我其实很感谢研发和项目管理团队，他们很好的帮产品避免了坑，所以产品更要腾出时间来做调研做复盘做逻辑推演
Tobin245
2019-06-05
测试环境正常，上线就出问题，感觉无法避免😭😭，之前出过一个问题是上线后发现用公司WiFi正常，业务方在外面用4G就打开白屏，后面开发找了半天才发现是引用的js包都还是测试环境的……
作者回复: 哈哈哈哈哈哈哈这个坑太大了…
共 2 条评论
Renee
2019-04-12
关于服务器非技术产品经理要懂多少呀
作者回复: 一般亲身体验几次发布，问问工程师都在干什么，大部分基础知识就能了解一点了。但注意不要招人烦就好。

