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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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