发布频率-越快越好吗

快速的发布是互联网应用的显著特点,老板巴不得今天说完一个想法,明天、哦不、最好今晚就可以看到结果。产品经理总是力争在计划里把产品需求排的满满的,这还不够,在开发过程中还总是见缝插针的挤入临时的需求。如果你问到:这个特性准备在什么时候发布?回答也许永远是越快越好。为了满足产品经理和老板的要求,于是项目团队就经常性的发版本,有的时候一周发五、六个版本,并且习以为常。

当我看到这种情况时,我总觉得不对劲,又不能一下子说明白哪里不对劲。于是我就在想:对于项目团队来说,什么样的发布频率比较好?是每天一次?每两天一次、还是每周一次?

在思考的过程中我把这个问题换成三个问题:

1) 团队的发布能力如何?在敏捷开发中,我们希望软件是随时可发布的,这就要求团队具备随时发布的能力,这意味着:

A.发布的成本非常低,例如:团队的任何成员通过运行一个自动发布脚本,就可以在短时间内完成一次发布。如果发布需要审批流程,那么这个流程必须非常轻量和快捷。

B.发布对用户的正常使用影响非常的小,用户根本感知不到系统已经被更新。这个要求系统支持各个应用组件的平滑更新,基于服务端的互联网应用在这方面有很大的优势。

C.发布的特性在预定义范围内,这个要求团队对于代码版本和分支的管理非常的清晰。

如果团队的发布能力还不是很高,每次发布都有很多人工操作,耗时较长的话,那么频繁的发布会消耗很多的投入。


2) 什么样的东西可以发布出去?互联网应用的快速发布中有大部分是缺陷修复和改进用户体验,这些版本往往修改量小,对于缺陷来说当然是要尽快Fix;对于用户体验的改进,用户往往比较迫切,而且改进后对于产品口碑的提升和增加用户对产品的认同都很有好处,这样的版本通常是运营版本,运营版本的发布频率通常是快一些更好。然后很多产品经理把运营版本和新特性的版本混同起来看待,对于新特性来说,用户还没有在这个产品中使用,这些特性是否符合用户的期望是未知的,如果用户用了它觉得很不爽,反过来是对产品的伤害。所以产品经理对于新特性在什么时候发,发哪些东西,发布后如何快速的获取反馈,都应该要事先仔细想清楚。从快速获取反馈并且控制负面影响范围的角度讲,灰度发布永远是好的。当团队发布频率很快时,我们是否把我们已知的不成熟的特性推到用户面前,这些特性可能是不完整的,我们已经规划了它的剩余部分在下个版本中,例如:我们在这个版本中提供了增加/删除/修改相片分类功能,而调整分类的前后顺序规划在下个版本中,当这个版本发布出来,用户会很郁闷,因为他在使用时一定会想把某个分类排到前面,结果系统不提供,如果是这样我们真的应该在这个版本中发布这些特性吗?也许产品经理要认真的思考一下了。受到运营版本的影响认为特性版本也是可以随时发出去的想法是危险的,新功能点的最小完整性和保障基础体验这个应该是底线。


3)(什么样的东西可以发布出去?)明知道质量很差的东西你会发出去吗?在互联网的开发中,有些人把快速获取用户反馈和让用户帮忙测试混为一谈。如果你自己测试一把就会发现问题的产品,放出去除了让用户郁闷以外还能带了什么好处?快速获取用户反馈的前提,依然是团队把质量当做自尊心。获取的用户反馈应该是无法在开发环境或者测试环境中暴露的问题。低质量的产品会很快让用户丧失兴趣。在互联网的应用中,测试人员的比例往往不高,免费和永远的beta版不是低质量的挡箭牌,当我们在要求越来越快的发布时,质量是否已经成为了一种可以妥协的目标?

发表评论

电子邮件地址不会被公开。 必填项已用*标注