9244a183c95f459fe043a6f655df2f67
需求变化太快,快速迭代已经不够用了

快速迭代不够快

一提到互联网产品开发,大家马上就会想到“快速迭代”,但本文的核心观点是,“迭代”与是否“快速”并不相关,甚至是相矛盾的。

经典的迭代模式可能需要两周发布一次,但我们的实际情况是一周要发布两次,迭代模式明显不合适。

对于一个正在迭代周期中的团队,新增的需求如果排在后面的迭代的话,要将近两周之后才能开始规划评估,再等两周之后才能最终上线,对于一个需要快速反应的互联网团队而言,这样显然太慢了。

通常所谓的“快速迭代”,实际上只是人为地将迭代的周期缩短了而已。我所接触到的很多团队已经把迭代看得越来越弱,只保留了定期总结的意义,甚至直接认为团队并不需要迭代。

所谓迭代

迭代从广义上来说是指对于特定过程的重复。具体到互联网产品开发领域,说的是一种项目管理模式。互联网团队常用的Scrum模式也好,“小瀑布”模式也好,基础都是迭代模式,也就是整个团队不断重复一个人为设定的过程,分阶段达到目标。

一个迭代的开发周期一般设为两周,模式大概是这样:

(迭代周期示意图 - 图片来源

为什么我们喜欢用迭代

迭代模式的核心优势:

  • 使用固定的时间窗以便于协调资源
  • 对齐整个团队的开发流程以促进协作

如果测试、设计、运营资源为整个事业部或者事业群共有,项目管理者必须去预定资源,要“排期”,甚至“PK”,这时候有一个固定的开发周期明显更靠谱一些。

在迭代内部开发流程是对齐的。团队先是进入需求评审,然后集体规划,规划完毕之后投入开发,迭代结尾一起发布。处在同一个阶段的团队成员更容易沟通,模块之间相互关联的部分更容易被照顾到,成员之间还能相互抵消风险。

迭代模式的缺点

人为限定的时间窗不符合实际需要。迭代模式通常约定在固定周期内打包发布一组需求:

(需求按期打包发布示意图 - 图片来源

一个需求的真实开发周期只应该与客观需要有关,不应该被人为设定的时间窗所限制。时间不足会降低质量,时间过多则降低效率。即使不考虑项目的变更风险,如上图所示的完美打包和时间窗适配现实中也是很少见的。如果需求之间的关联性不强的话,本身也没有必要打包在一起。

迭代模式的管理成本高。为了得到一个靠谱的迭代规划,项目成员需要做很多的预估工作,迭代进行中要不断Check整个团队的进度,一旦有变化就要重新规划,无法按预期交付的时候就要砍需求,如果需求不能砍的话就要延期,这背后都是各种会议和不必要的相互博弈。

(监控项目进展的燃尽图 - 图片来源

迭代模式通常用各种测量方法和变更流程来保证迭代能够按期交付,但为此付出的成本也是不可忽视的,要整体考虑投入产出比。

top Created with Sketch.