产品经理如何推进产品版本升级?-蜗牛派

产品经理如何推进产品版本升级?

产品的版本升级看似简单,但是其实很复杂,有许多情况需要注意,例如任务数量、执行周期、时间节点等。曾有一段时间,每周的版本升级都像是一次次“赌博”,赌赢了早早下班回家,赌输了第二天早上下班回家,几乎每次版本升级都充满了不确定性和不可控性,这几乎成了团队中难以消散的“阴影”。

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

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

可能多数产品经理都有过这样的体验:还有几个小时就要升级了,突然又测试出来一个新的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)如果必须在周三进行,则需要单独为紧急升级的任务发起代码合并请求,与计划中的正常升级区别开来。

产品经理如何推进产品版本升级?

本文作者: 鱼既,其版权均为原作者所有,文章内容系作者个人观点,不代表蜗牛派对观点赞同或支持,未经许可,请勿转载,题图来自Unsplash,基于CC0协议。
分享到:更多 ()
Copyright © 2015-2024 woniupai.net 蜗牛派 版权所有
皖ICP备18016507号-1 | 本站内容采用创作共用版权 CC BY-NC-ND/2.5/CN 许可协议