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

产品经理，如何平稳推进产品版本升级？ / 曾有一段时间，每周的版本升级都像是一次次“赌博”，赌赢了早早下班回家，赌输了第二天早上下班回家，几乎每次版本升级都充满了不确定性和不可控性，这几乎成了团队中难以消散的“阴影”。 为了解决这个头疼的问题，我梳理和规范了整个开发和升级流程，并经过多次实践的检验与迭代，形成了比较成熟的流程规范，大幅度提升了升级的成功率，缓解了了团队闻“升级”而忧愁的情绪。 一、明确一次版本升级包含的任务数量 可能多数产品经理都有过这样的体验：还有几个小时就要升级了，突然又测试出来一个新的bug，要求开发改完再上线，不知不觉中就使得该版本的任务数发生了变化。产品经理认为这是对产品高度的负责，对瑕疵的零容忍的表现，但实际上，却干扰了开发同事们有序的升级准备工作。 因此，我们需要约定好每一次版本升级包含了有多少个需求任务，多少个优化任务，多少个bug修复任务，并记录下来。推荐使用简单项目管理工具，如果没有，用Excel在线文档也可以。一旦需要增加任务，产品经理需要综合考量，而不是一味地“逼着”开发立即执行 二、明确一次版本升级的执行周期 每周固定一天作为“升级日”是很早就形成的惯例，相信很多公司也是这样。但与开发同事沟通后，发现当周任务当周升级的方式会让开发工作很仓促，其中免不了出现赶工而导致的问题。 我们按照惯例定在每周四晚固定时间升级，考虑到测试和修改问题的时间，如果当周开发当周升级的话，真正的开发时间只有3个工作日左右。因此，我将版本迭代的周期拉长为两周：分别为开发周期和测试、升级周期。当周任务，下周升级，也就是在当周用足足一周的时间完成开发工作，下一周经过测试和问题的修复后，再升级。开发工作与测试升级工作在两周的周期中交替进行。 三、确定好一次版本升级在各环境发布的时间节点和重要事项 在未搭建开发环境（以下称为DEV环境）时，开发全部在测试环境（以下均称为BETA环境）上开展工作，常常导致版本发布时的混乱，明明在BETA环境验证无误的任务，发布到正式环境（以下均称为WWW环境）后又有一堆问题。 DEV环境搭建完成后，终于算是有了全套的发开工作环境，根据团队的工作习惯等实际情况，我规定了一次版本升级的周期内，什么时候发布DEV环境，什么时候发布BETA环境，什么时候发布WWW环境的时间节点，以及发布前后要执行的测试和验证动作。 DEV环境的发布节点为开发周期结束的周五晚上，下周一一上班就开始进行测试。在DEV环境，每一个任务要经过2轮测试，一次是发开工程师自检测试，一次是产品或测试同事进行验证测试。 BETA环境在测试、升级周期的周二晚上进行，在BETA环境下的测试分别由不同的两位产品或测试同事进行交叉验证。 最后的WWW环境发布节点在测试、升级周期的周四晚上进行，发布后再进行一轮整体验收，即可宣告发布完成 测试、升级周期的周五对本次版本升级进行复盘，总结经验教训，同时安排下一个开发周期的任务。 四、对常见的突发问题做好预案 无论多么严密的计划，总不可避免一些意外情况，做好应对突发问题的预案，才能遇事不慌，冷静地处理问题。经过一段时间“踩坑”的经验，总结出突发问题主要集中在两个方面： 1. 任务无法按照计划的时间全部完成 其原因可能是开发过程中遇到了问题，在某个任务上消耗了过多的时间；也可能是产品经理安排的任务工作量就超出了计划时间；也或者是由于上游协同部门问题影响了正常的工作进度；亦或者是有人请假、临时有事等等，最终导致计划任务没有在开发周期内完成。 遇到这种情况，如果不是特别紧急的任务，比较反对通过赶工的方式加班加点开发，在计划时间里“硬上”，这样做大概率开发质量不高，升级时不稳定风险很高。 针对这样的突发情况，我提供了2种预案： （1）保证发布时间不变，舍弃掉部分未完成开发的任务，调整发布计划，只发布完成并能够充分测试的任务。 （2）保证发布任务量不变，重新调整发布时间，一般延迟到下一个升级周期，保证全部任务的完成度和质量后与下一开发周期的任务一并升级。但要注意这种情况只允许延期一次，如果多次延期发布，会导致待发布的任务越积越多，进而增大升级风险。 2. 在开发周期内，正式环境有紧急任务或紧急bug需要优先处理 当正式环境的产品出现紧急问题时，其优先级往往都高于计划的任务，修复后还需要尽快发布。这势必会影响整个开发与升级计划。为了避免这种突发事件带来的混乱，我做了以下预案： （1）根据修复问题的工作量，开发可以与产品经理等量置换计划任务，产品经理做开发计划的变更。 （2）修复好的问题，尽可能在升级窗口与计划任务一并升级。我们约定的升级窗口在周四，如果是周三发现的问题并且修复了，建议等到周四一起升级。如果是周一发现并修复的问题，就要看其紧急和严重程度来判断了。 （3）如果要解决的问题重要且紧急，等不到升