编辑导读：产品的版本升级看似简单，但是其实很复杂，有许多情况需要注意，例如任务数量、执行周期、时间节点等。本文作者从实际工作出发，分享了帮助产品平稳升级的几点建议，希望对你有所帮助。

曾有一段时间，每周的版本升级都像是一次次“赌博”，赌赢了早早下班回家，赌输了第二天早上下班回家，几乎每次版本升级都充满了不确定性和不可控性，这几乎成了团队中难以消散的“阴影”。

为了解决这个头疼的问题，我梳理和规范了整个开发和升级流程，并经过多次实践的检验与迭代，形成了比较成熟的流程规范，大幅度提升了升级的成功率，缓解了了团队闻“升级”而忧愁的情绪。

一、明确一次版本升级包含的任务数量

可能多数产品经理都有过这样的体验：还有几个小时就要升级了，突然又测试出来一个新的bug，要求开发改完再上线，不知不觉中就使得该版本的任务数发生了变化。产品经理认为这是对产品高度的负责，对瑕疵的零容忍的表现，但实际上，却干扰了开发同事们有序的升级准备工作。

因此，我们需要约定好每一次版本升级包含了有多少个需求任务，多少个优化任务，多少个bug修复任务，并记录下来。推荐使用简单项目管理工具，如果没有，用Excel在线文档也可以。一旦需要增加任务，产品经理需要综合考量，而不是一味地“逼着”开发立即执行

二、明确一次版本升级的执行周期

每周固定一天作为“升级日”是很早就形成的惯例，相信很多公司也是这样。但与开发同事沟通后，发现当周任务当周升级的方式会让开发工作很仓促，其中免不了出现赶工而导致的问题。

我们按照惯例定在每周四晚固定时间升级，考虑到测试和修改问题的时间，如果当周开发当周升级的话，真正的开发时间只有3个工作日左右。因此，我将版本迭代的周期拉长为两周：分别为开发周期和测试、升级周期。当周任务，下周升级，也就是在当周用足足一周的时间完成开发工作，下一周经过测试和问题的修复后，再升级。开发工作与测试升级工作在两周的周期中交替进行。

三、确定好一次版本升级在各环境发布的时间节点和重要事项

在未搭建开发环境（以下称为DEV环境）时，开发全部在测试环境（以下均称为BETA环境）上开展工作，常常导致版本发布时的混乱，明明在BETA环境验证无误的任务，发布到正式环境（以下均称为WWW环境）后又有一堆问题。

DEV环境搭建完成后，终于算是有了全套的发开工作环境，根据团队的工作习惯等实际情况，我规定了一次版本升级的周期内，什么时候发布DEV环境，什么时候发布BETA环境，什么时候发布WWW环境的时间节点，以及发布前后要执行的测试和验证动作。

1. DEV环境的发布节点为开发周期结束的周五晚上，下周一一上班就开始进行测试。在DEV环境，每一个任务要经过2轮测试，一次是发开工程师自检测试，一次是产品或测试同事进行验证测试。
2. BETA环境在测试、升级周期的周二晚上进行，在BETA环境下的测试分别由不同的两位产品或测试同事进行交叉验证。
3. *后的WWW环境发布节点在测试、升级周期的周四晚上进行，发布后再进行一轮整体验收，即可宣告发布完成
4. 测试、升级周期的周五对本次版本升级进行复盘，总结经验教训，同时安排下一个开发周期的任务。

四、对常见的突发问题做好预案

无论多么严密的计划，总不可避免一些意外情况，做好应对突发问题的预案，才能遇事不慌，冷静地处理问题。经过一段时间“踩坑”的经验，总结出突发问题主要集中在两个方面：