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

摘要：如果完全没有计划，团队一定会过一天算一天，项目陷入一片混乱，商业模式、产品愿景都功亏一篑，无法落地实现。

常见误区：

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

这是对敏捷价值观的误解。如果完全没有计划，团队一定会过一天算一天，项目陷入一片混乱，前几节介绍的商业模式、产品愿景都功亏一篑，无法落地实现。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（迭代计划）

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

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