需求变化太快,快速迭代已经不够用了
作者:张鑫
链接:https://zhuanlan.zhihu.com/p/20796800
快速迭代不够快
一提到互联网产品开发,大家马上就会想到“快速迭代”,但本文的核心观点是,“迭代”与是否“快速”并不相关,甚至是相矛盾的。
经典的迭代模式可能需要两周发布一次,但我们的实际情况是一周要发布两次,迭代模式明显不合适。
对于一个正在迭代周期中的团队,新增的需求如果排在后面的迭代的话,要将近两周之后才能开始规划评估,再等两周之后才能最终上线,对于一个需要快速反应的互联网团队而言,这样显然太慢了。
通常所谓的“快速迭代”,实际上只是人为地将迭代的周期缩短了而已。我所接触到的很多团队已经把迭代看得越来越弱,只保留了定期总结的意义,甚至直接认为团队并不需要迭代。
所谓迭代
迭代从广义上来说是指对于特定过程的重复。具体到互联网产品开发领域,说的是一种项目管理模式。互联网团队常用的Scrum模式也好,“小瀑布”模式也好,基础都是迭代模式,也就是整个团队不断重复一个人为设定的过程,分阶段达到目标。
一个迭代的开发周期一般设为两周,模式大概是这样:
(迭代周期示意图 - 图片来源)
为什么我们喜欢用迭代
迭代模式的核心优势:
使用固定的时间窗以便于协调资源
对齐整个团队的开发流程以促进协作
如果测试、设计、运营资源为整个事业部或者事业群共有,项目管理者必须去预定资源,要“排期”,甚至“PK”,这时候有一个固定的开发周期明显更靠谱一些。
在迭代内部开发流程是对齐的。团队先是进入需求评审,然后集体规划,规划完毕之后投入开发,迭代结尾一起发布。处在同一个阶段的团队成员更容易沟通,模块之间相互关联的部分更容易被照顾到,成员之间还能相互抵消风险。
迭代模式的缺点
人为限定的时间窗不符合实际需要。 迭代模式通常约定在固定周期内打包发布一组需求:
(需求按期打包发布示意图 - 图片来源)
一个需求的真实开发周期只应该与客观需要有关,不应该被人为设定的时间窗所限制。时间不足会降低质量,时间过多则降低效率。即使不考虑项目的变更风险,如上图所示的完美打包和时间窗适配现实中也是很少见的。如果需求之间的关联性不强的话,本身也没有必要打包在一起。
迭代模式的管理成本高 。为了得到一个靠谱的迭代规划,项目成员需要做很多的预估工作,迭代进行中要不断Check整个团队的进度,一旦有变化就要重新规划,无法按预期交付的时候就要砍需求,如果需求不能砍的话就要延期,这背后都是各种会议和不必要的相互博弈。
(监控项目进展的燃尽图 - 图片来源)
迭代模式通常用各种测量方法和变更流程来保证迭代能够按期交付,但为此付出的成本也是不可忽视的,要整体考虑投入产出比。
迭代模式不能很好地应对变化。 由于迭代规划是在一开始的时候就制定好了,一旦变更就会产生各种成本,所以整个团队都会倾向于保持原有的计划,而无论是团队内部的开发状态还是外部的商业环境都是在动态变化之中,迭代模式的变更成本会影响团队的应变能力。
过度承诺导致Buffer膨胀 。 整个迭代的顺利进行依赖于太多假设,由于项目风险客观存在,很多假设并不能实现,迭代进行得不顺利将是常态。如果我们过于在意各个环节的交付时间是否符合预期,那么引起延期的参与者就会受到指责,导致大家都要为自己的工作留足够的Buffer以应对风险。
我总结的Buffer膨胀定律:
需求和风险水平不变的情况下,迭代按期交付的概率越高,成本评估中含有的Buffer就越多,团队整体效率就越低。
去迭代化
互联网产品的发布成本越来越低,团队内部的协作关系也更加灵活,组结构织趋向于网状化。固定的时间周期和统一的开发流程带来的优势已经逐渐消减,反而成为团队响应速度和开发效率的障碍。
所谓去迭代化,包括但不限于以下转变:
项目管理方面:
不再设定人为的时间周期,一切以实际需要为准
不要将不相关的需求打包在一起
减少不必要的规划行为和测量行为
聚焦于需求的实际开发质量和流动效率,而非既定规划的实现程度
团队管理方面:
从集体推进到分头出击
从定期反馈到即时反馈
从阶段性改进到持续改进
产品策略方面:
从宏观规划到局部创新
从冲刺式产出到流动式产出
适合去迭代化的场景:
业务需求相对分散,不稳定性强
发布成本低。比如应用能够动态更新,不需要地面实施。
资源协调成本低,内部沟通充分
人员素质高,能够独立推动项目
总结
If you're in control, you're not going fast.
迭代模式有其优势,但不一定适合你的团队特质和商业环境。一个团队不能想当然地认为有严谨的迭代过程就是管理水平高的体现。管理模式要随着客观条件动态演进。去迭代化绝对不是要削弱管理,反而是为了实现管理升级。
我相信管理能力是一个团队的基础资源。管理升级促进技术升级,技术升级促进产品升级,产品升级才能适应消费升级背景下的商业竞争。
其它
题图:Not fast enough sonic (图片来源)
关键字:产品经理, 迭代
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!