当App更新版本时，我们在更新什么？

刚入行的时候，我对于一帮人通宵达旦地调试代码、要求发布时间的产品跟要求发布质量的测试激烈争吵、产品狗跪在设计师旁边陪加班的时候，有些不太理解。

那时的我问老司机们：为什么不多留一点时间、等产品功能完善了再发出去呢？晚发几天又有什么问题啊，我们又没有对用户承诺什么。

类似问题后来一些跨界入互联网的人也问过我：为什么即便只是改几个bug这种用户看不见的功能，你们也要保持每周发版呢？

● ● ●

• 对内，固定发版节奏能将大家调动起来，持续迭代优化；
• 对外，每次发版都能激活老用户、吸引新用户；

反过来说，你看到一个app最后一次更新时间是2015年4月，会不会觉得它们已经不维护了呢？

● ● ●

可是，这样频次的发版，很容易陷入到「为发版而发版」的尴尬境地。有时候我调侃只要写一个「修复若干bug」+改大一个版本号就能完成一次发版工作。

本来我们是想通过发版让软件越来越好用的，结果因为老板要加xxx、销售要加xxx、竞争对手已经有了xxx、老用户建议xxx、现在流行xxx、其他部门找你加xxx，还有原本遗留的疑难杂症汹涌而来，使得团队迷失方向，只是让软件越来越大、越来越难用。

这样的问题在我工作中无数次出现，道理我都懂，可是做起来的时候就是会因为陷入到执行的细节和吵架的情绪中，完完全全地忘记了。

● ● ●

如果你喜欢看NBA比赛，会留意到主教练在比赛的间隙，会掏出一张事前写好的小纸条–重新温习取胜的原则性策略，防止陷于激烈的赛况而忘记它们。

发版工作也是一样的，在需求收集之初就应该把你的「发版说明书」写下来。

目标层面

• 我们公司/产品的使命是什么；
• 发版的哪些功能，能支持我们的使命；
• 谁是新版服务的主要用户；
• 你希望他们看到新版本以后有啥反应；

执行层面

• 需要多少人*日完成发版工作；
• 明确几个主要关键输出的时间点（比如需求文档时间，设计稿时间，提测时间，大工程还需要拆解成几个小任务发布，以激励大家信心）；
• 关键团队的负责人是否清楚自己的工作内容和时间表；
• 对于内容型产品，发版时有没有足够的内容支撑冷启动（这是我常犯的问题，发布了才发现整个页面空无一物）；
• 哪些功能是这个版本必须得有，哪些在时间紧迫的时候可以砍掉；

上线后的运营维护工作怎么衔接（一开始不计划，会坑死你自己）；

● ● ●

上面有不少是些范畴比较大的问题，真实的发版工作会更多细节、更多变化、也更多不确定性。

尽管如此，我推荐大家在发版之前把上面这些「大问题」写下来，能写多少写多少。在每天焦头烂额的工作时拿出来看一看，特别是在「需求变更」的时候。

对了，我差点漏了数据监测

上面的部分讨论的是「我们为什么而出发」，一个好的「发版说明书」还应该加入2、3个简明的数据指标，说明发版要达到的产品/收入/市场/或别的什么效果。

有时候的数据指标可以很明确（比如新增安装量10万，收入增加10%），有时候就比较模糊（日活增加、增加多少不知道，崩溃率下降、下降多少看统计），不管怎样，有一个目标总比没有好。

因为当你有了目标以后，开发的时候肯定会埋入一些数据指标，用于新版发布后的评估工作（万一不幸地数据指标比前一个版本还要差，可以通过回滚的方式止血）。

通过这样有意识的对比，你会发现整个团队有一种无形的力量在逼着前进。

希望大家的新版发布工作，都能更有效。

作者：黎晨，从零开始参与迅雷史上最赚钱业务（迅雷会员）的工作。