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

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

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

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

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

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

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

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

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

目标层面

执行层面

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

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

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

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

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

有时候

来源【抖音特训营】自媒体，更多内容/合作请关注「辉声辉语」公众号，送10G营销资料！