谁说敏捷了不用做产品长远规划:洋葱圈规划法

2021-04-13 09:00:00
敏捷助理
原创
186
摘要:如果完全没有计划,团队一定会过一天算一天,项目陷入一片混乱,商业模式、产品愿景都功亏一篑,无法落地实现。

常见误区:


很多团队以为,敏捷不是有个价值观叫做“拥抱变化胜于执行计划”吗?咱们做敏捷了,那就不用做什么计划了。

这是对敏捷价值观的误解。如果完全没有计划,团队一定会过一天算一天,项目陷入一片混乱,前几节介绍的商业模式、产品愿景都功亏一篑,无法落地实现。Scrum里Sprint计划是敏捷里的重要计划活动之一,但是敏捷计划还不止有这些。

常见误区:

很多敏捷团队非常聚焦眼前的工作,只关注当前迭代的交付,或者是那些已经进入看板就绪队列的需求的交付,对于产品下一步要做什么、未来要做什么不清楚。

这样的团队陷入了只低头走路不抬头看路的微观计划视角。产品规划是在多个层面上持续进行的活动,我称之为洋葱圈规划,如图所示。


洋葱圈规划


下面介绍了各层计划活动的时间节奏、活动参与人、和计划重点内容。

各层计划内容

第1层:Portfolio Planning(投资组合规划)


一个企业或业务部门一般会有多个产品并行管理,这时需要在整个组织层面规划要投资做哪些产品、哪些产品要撤出投资,以及哪些正在做的产品何时上市。

Portfolio规划的来源与公司的战略紧密相关。逻辑关系如下图金字塔所示:



公司的使命和愿景:
     一个公司使命和愿景是持续数年有效的,不随时间的演进而改变
战略:
    公司依据市场研究、竞争对手研究为输入,制定制定未来3-5年的战略
年度目标:
    公司根据战略,分解出一年内需要达成的目标
产品规划:

    公司依据3-5年的战略和年度目标,制定产品投资组合规划


案例:

下图是多年前在Nokia工作时,移动手机事业部2013年做的Portfolio Plan,详细规划了计划在2013年至2015年之间的上市的所有手机产品。虽然期望是做出三年的规划,但是发现2015年有些遥远,无法规划,因此自2015年第1季度开始标识灰色底色,底部注明“Under Clarification(待澄清)”。由于Nokia手机在2014年被微软并购,在这个规划里的很多手机产品没有等到上市被撤掉投资。

以个人做产品的经验,就现在时代的变化速度来说,规划三年以上的Portfolio基本都没有办法按规划执行。


Portfolio规划案例

Portfolio除了规划整个组织的产品时间,还需要规划产品的预算、人力等成本等。

第2层:Roadmap Planning产品路线图规划


对于一个创新产品而言,在我们创建了商业模式和产品愿景,用第一个最小可行产品探索了市场的反馈之后,对产品需要做什么心里更加有谱。这时可以规划相对长期的产品路线图(Roadmap)。

产品路线图通常以季度或月度为单位,规划产品要发布哪些重大特性。产品路线图包括以下内容:

  •     重要版本的发布时间
  •     重要版本的名称
  •     发布的重要版本的目标
  •     为了实现版本的目标,要交付的特性有哪些。
  •     这里列出的特性不需要详细拆分。

案例:

下图是曾经在诺基亚工作时,移动终端事业部的一个产品Nokia Xpress浏览器在2013年至2014年的产品路线图。该产品按季度规划,每个季度发布一个大版本。每个季度的版本代号分别为:“Haonoi(越南河内)”,“Ibi(日本揖斐郡)”,“Jakarta(印尼雅加达)”,对于每个版本都有其特殊的使命。此外,对于当前季度(2013年Q4)规划的特性,标识为“Committed(已承诺)”,表示承诺在当前季度交付;而对于2014年Q1规划的特性,标识为“Backlogged(已纳入Backlog里)”,表示已经纳入到Backlog里规划,但是不承诺时间;对于2014年Q2规划的特性,标识为“Identified(已识别)”,表示初步识别出的有价值的需求,但是需要进一步评估或验证其价值,不承诺交付。每个特性都是粗粒度的大特性,比如特性“Save to Cloud (保存到云端)”,这个特性只有几个字,没有详细描述,也许能拆分出几十个的用户故事,但是在路线图规划里保持这样的粗粒度足矣。


产品路线图案例

由此可见,产品路线图也是渐进明晰的。越近的时间规划的特性越明确,时间越靠谱;越远的时间越不清楚要做什么,也不确定什么时候开始做。在路线图时间节点到的时候,一般会召集对路线图实施情况的评审,并对后续时间点的路线图更新。

第3层:Release Planning(版本计划)

在路线图的每个时间段内都会有一个或多个版本发布。路线图规划了大的时间节点上交付哪些大特性,而版本计划更加详细,不仅将特性拆分最小价值单元的用户故事,还要依据团队的速率数据计划一个版本需要多少迭代完成。版本计划也是渐进明晰的,当前版本的计划要准确,越往后的版本计划越粗略,特性拆分的粒度也越粗。

一个版本交付后,一般会召集版本评审和回顾会议,其流程与Sprint评审和Sprint回顾会议相当。所以,在版本最后一个迭代的时候,可以将Sprint的评审会议和回顾会议范围拓宽为对整个版本的评审和回顾。

第4层:Sprint Planning(迭代计划)

一个版本可能会划分为多个迭代完成。每个迭代都有明确的计划流程,迭代结束有评审和回顾活动。这层计划是广大的敏捷团队所熟知的。

需要说明的是,很多互联网团队的交付能力比较成熟,每个迭代甚至每天都发布多个版本。这种情况下,版本的周期小于迭代,在洋葱圈规划中,迭代周期会出现在版本的外循环,对这样的版本一般不需要做评审和回顾。

第5层:Daily Standup每日站会

团队的每日站会是对每天对项目情况进行审视,以及计划当天工作的活动。因此,每日站会是最小单元的计划活动。
联系我们
联系人: 柴老师
电话: +86 185 1045 6582
Email: clientservice@hardenx.cn
地址: 北京市海淀区善缘街1号立方庭1-105