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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

4. ……


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

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

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

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