产品经理，如何平稳推进产品版本升级？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 任务无法按照计划的时间全部完成

其原因可能是开发过程中遇到了问题，在某个任务上消耗了过多的时间；也可能是产品经理安排的任务工作量就超出了计划时间；也或者是由于上游协同部门问题影响了正常的工作进度；亦或者是有人请假、临时有事等等，最终导致计划任务没有在开发周期内完成。

遇到这种情况，如果不是特别紧急的任务，比较反对通过赶工的方式加班加点开发，在计划时间里“硬上”，这样做大概率开发质量不高，升级时不稳定风险很高。

针对这样的突发情况，我提供了2种预案：

（1）保证发布时间不变，舍弃掉部分未完成开发的任务，调整发布计划，只发布完成并能够充分测试的任务。

（2）保证发布任务量不变，重新调整发布时间，一般延迟到下一个升级周期，保证全部任务的完成度和质量后与下一开发周期的任务一并升级。但要注意这种情况只允许延期一次，如果多次延期发布，会导致待发布的任务越积越多，进而增大升级风险。

2. 在开发周期内，正式环境有紧急任务或紧急bug需要优先处理

当正式环境的产品出现紧急问题时，其优先级往往都高于计划的任务，修复后还需要尽快发布。这势必会影响整个开发与升级计划。为了避免这种突发事件带来的混乱，我做了以下预案：

（1）根据修复问题的工作量，开发可以与产品经理等量置换计划任务，产品经理做开发计划的变更。

（2）修复好的问题，尽可能在升级窗口与计划任务一并升级。我们约定的升级窗口在周四，如果是周三发现的问题并且修复了，建议等到周四一起升级。如果是周一发现并修复的问题，就要看其紧急和严重程度来判断了。

（3）如果要解决的问题重要且紧急，等不到升级窗口，那就在当天安排针对这一个事项单独的紧急升级。由于周三是正常计划中在BETA环境测试的时间，为了不打乱BETA环境下的测试工作，紧急升级尽可能避免在周三进行。

（4）如果必须在周三进行，则需要单独为紧急升级的任务发起代码合并请求，与计划中的正常升级区别开来。