这是敏捷生态系统系列的第四篇（​​之一​​​，​​之二​​​，​​之三​​​，​​之四​​​，​​之五​​）。一半内容属于需求管理生态，一半内容属于计划跟踪生态。

在实际开发环境中，产品负责人常常和开发组存在潜在的利益对立。前者往往希望在更短的时间开发出更多的功能，而后者的绩效则多数来自于计划按时率/缺陷率这些会因“更短-更多”而下降的数据，于是两者的隔阂从此开始。

敏捷开发中的计划跟踪生态II大致如此（黑体字即图片中的元素）：

☺ 产品负责人（PO）与团队的正确互动是自组织团队正常运转的核心机制之一。

☺ 产品负责人的权利是统一管理和讲解需求以及需求优先级排序，而义务则是接受开发团队的估算，并承诺迭代期内不变更。

☺ 团队的权利在于开发人员自己估算，而义务则是接受产品负责人所设定的需求内容、实现标准、优先级排序，并对自己的估算做出团队承诺，这种承诺会造成整个团队受到激励。

☺ 产品负责人不能干预团队的估算，却可以挑战估算。挑战估算可以通过对比两个团队处理同类任务、对比以往同类任务与本次任务等方式进行。团队的荣誉感会令团队产生团队间的同行压力（与其他团队及与自己的过去相比），并进而产生受激励的个体。

☺ 作为自组织团队，产品负责人与团队互相没有领导关系，却通过分权与承诺管理，使得两者互相管理，从而产生更高的工作效率。

自组织团队-开发团队自己估算-PO挑战估算-同行压力是这个生态的主线之一。

让我们重新看一下前面产品负责人与团队矛盾的例子。

简单粗暴的解决办法无外乎此：

1. 规定产品负责人完全不得干预估算

2. 规定无论接受了任何挑战（质询），团队最终对估算结果拥有决定权

这些看起来都是很好很符合Scrum思想的制度，但是执行起来却早晚出问题。 我们假设在项目开发环境中，产品负责人是一个销售/售前*（或者拥有与其相似的绩效机制的人），他的绩效来自于合同额+客户满意度，从合同额中提取X%作为奖金；而开发团队的绩效来自于与计划相比的按时完成率+缺陷率。这个结构已经确定了两者的心法将背道而驰，无论任何研发方法论都不可能统一两者的思维。很快前者就会祭出客户来打破公司制度，而高层捍卫Scrum的决心远远低于捍卫销售额的决心，制度很快名存实亡。

怎么办？从“自组织团队”的根基下手。

笔者正在筹备一个“自组织团队系列”，其中第一篇已经处于草稿状态（截至2011-08-16）。这一篇的名字叫“用中医理论管理团队”。由于限于医学技术，中医始终不知道“细菌”“病毒”这些外部因素的存在，而只知道生病是人体自身存在了问题，比如“肝火上升致邪气入侵”，因此类似针灸这种完全没有任何药物的治疗方法也非常有效。对于一个敏捷团队，要理顺产品负责人和团队的关系，首要的就是调理好团队的利益。

在​​敏捷外包工程之二：人员结构​​中提到过三个公司，一个将项目额的10%给予团队作为奖金，一个将研发成本计入产品部门的成本，一个将实施成本计入销售人员的销售成本，从而很大程度上统一了产品负责人和团队的认识。这三个团队及其他类似团队的做法可归纳为两条：

1. 将研发成本计入销售成本。

此举将保证产品负责人（有时是一个团队）将非常在意客户是否真的需要某个功能，而不是本着越多越好、盲目讨好客户的原则办事。

2. 将项目收入下放到研发团队

此举将保证研发团队正视“盈利”这一开发人员很少在意但却是公司立足之本的元素。

做好这两条后，一个自组织团队的雏形就出现了。现在公司高层不用天天做仲裁了，双方会很平心静气地坐下来思考问题，查找关键解决方案。

这两点做得最好的是网络游戏团队，笔者去过很多家游戏开发公司，其中多数都拥有几个乃至几十个游戏研发团队，每个团队内部拥有产品负责人（策划团队）和开发团队。他们都高度自治，除了影响投资和收益的重大里程碑评审，领导几乎不过问细节，比如他们是用什么开发方法，最近在做什么等等。因为他们的核心内部机制就一个：赚钱大家分。不赚钱的功能不会有人提出来，赚钱的功能也不会有人偷懒不做。

在项目开发中这一点可能有点困难，不过在​​敏捷外包系列​​中可以看出其实还是有很多实际工作可做的。

 

完成自组织团队的初步建设后，开发人员自己估算和PO挑战估算就完全变成另外一个样子，而产生的同行压力也与之前截然不同。人们会：

1. 团队尽可能缩短估算，尝试最快的实现方法--------因为没有人考核“按时完成率”，完成早了多了来自客户的奖金也多。

2. “偷懒的人”将不复存在，因为他不但挡在自己的财路上，还挡在团队的财路上----------所以领导不用安装摄像头和屏幕监视软件了。

3. 赶工期的PO也不复存在，我见过一个PO很担心地问团队是否真的能完成，因为一旦延期客户会很失望，大家都遭殃。

4. ……

本篇的内容大量涉及了非研发部门的制度问题，比如为销售设置奖金机制，在实施起来会很有难度，需要公司层面的配合；从另外一个角度看，收益也是明显的。

笔者除了做过研发管理之外，还曾经任外企中国公司的部门经理和副总经理，同时管理过市场/销售/支持等非研发部门。本文的案例虽然是引自别的公司，但在理顺自己管理的部门的时候都有尝试使用，取得了显著效果。在这个过程中逐渐悟到如果不能在整个公司层面理顺关系，妄谈敏捷开发几乎是不可能的。

读者可能注意到本文所使用的图形中框的底色不同，其实自下而上它们被分为团队/客户（棕色）-计划实践（蓝色）-跟踪实践（紫色）-收益（绿色）-目标（金色）几个层次，但缺少“配套制度”这类研发外的生物，“持续集成”“MoSCoW”这些生物也没有位置。

未来本系列（也或许是其他系列）中将将包含一篇或几篇“敏捷成熟度模型”的文章，会将它们纳入其中。这个成熟度模型不是为了评估使用，而是为了弄清楚自己的团队还有哪些活动没有做，它们的目的和价值是什么，是否由于缺失它们而造成了一些困难，从而判断自己的敏捷开发还可以做哪些改进。