这是敏捷开发绩效管理的第四篇。(之一,之二,之三,之四,之五,之六,之七)
最近在看德鲁克的书,发现其中很明确地写着“企业的绩效只存在于外部,而企业内部只有成本”的概念和说法,下面结合敏捷开发团队的绩效考核展开谈谈。
敏捷开发有很多“外向型”思维,比如:关注客户价值,认为可交付的产品才是真正能表征工作进展的因素等等,但尚未直接与目标管理接轨。外向性思维可以防止部门间壁垒或踢皮球,而转而共同讨论对外交付价值,从下面的对比可以看出这点。
“内向型”绩效及其导向
进度:“各阶段按时完成率”会导致分析和设计人员草草结束工作,而将大量不确定工作推给开发人员;开发人员则如法炮制,把延期踢给测试人员。
质量:“千行代码缺陷率”会导致开发人员在很多“是否是缺陷”问题上与测试人员争执不下,另外一些次要的如使用不便、不直观等问题则被长期搁置。
成本:“与计划相比的人员超支率”会导致项目经理很不愿意接受变更,即使是那些显然能给客户带来巨大价值的。
功能:“需求规格中需求的完成比例”会导致开发组思维局限于当年编写需求规格时期的认识,而不能在整个漫长的开发过程中不断精化需求。
此外还有一些更可怕的数据,比如“每月生产的代码行数”“每月生产的功能点或故事点数”(这个很有迷惑性)“每月修改的缺陷数”等,都是不恰当的绩效。德鲁克“企业内部只有成本”的理念指出,无论是文档,代码,可运行软件乃至最终产品,若尚未被销售,都只是成本的一部分。
多数采用内向型绩效的公司和团队,其绩效结果都不好。究其原因,单个部门/工种/个人各自追求自己的绩效,并不会导致整个项目外部绩效的提升(这称为“合成谬误”)。
某些内向型绩效甚至是互斥的,处于零和状态。比如测试团队人均发现的缺陷数(测试团队的绩效)与开发人员人均缺陷数(是开发团队的负绩效)并存,则两个团队无论如何都无法同时提升绩效,导致他们永远无法像一个团队一样互相帮助。若你的公司有这样的绩效,则研发人员与测试人员打架就不用奇怪了。
其他多数内向性绩效,都存在潜在的互斥关系。比如前面提到的个阶段按时完成率即内部存在互斥,而“需求规格中需求的完成比例”必与“客户需求响应率”互斥。
外向型绩效
下面是一些潜在的“外向型”绩效,由于之前提过不同企业乃至产品的外向型绩效差别很大,请灵活运用。
产品研发型
进度:
“与竞争对手相比同档产品的上市日期比较”适合消费电子类产品。
“响应分销商需求的时间”适合渠道比较强势的情况。
这些外向型绩效应该作用在整个团队上,换言之不管哪个环节导致了进度差,都一起得到底的绩效。从而促使整个团队一起思考如何提升绩效。
需求和设计人员为了能让开发人员提前开工,可以采取分段写需求和设计的方法,把最影响架构又最不会发生变化的部分先写出来,让开发人员提前开工干活;而开发人员也可能会采取同样的策略,阶段式地发布产品,让测试人员可以提前测试,防止最后缺陷太多导致产品延期;而需求和设计人员又回过头来用开发的进度和测试的缺陷率,来判断产品应该消减功能换取上市时间,还是增加更多功能以换取竞争力。
可见一个为外部目标奋斗的团队,会很容易地团结起来,共同思考提升绩效的最佳策略。
质量:
“每月待处理质量问题数”咨询过的一家ERP公司的实际数据(但他们尚未用这个数据考核),此数据一般符合瑞利分布,因此可预测未来的质量问题数量。
“每月终端用户投诉数”适合消费电子、网络游戏等与客户比较紧密的行业。
“每月分销商投诉数”适合渠道比较强势的情况。
“每月论坛缺陷提出数”适合……我在的一家企业使用BBS免费处理缺陷。
用最终用户提出的抱怨作为外部质量目标的策略,不是说大家不用测试了,把缺陷留给用户。而是:用我们测试了但仍漏给客户让其发现的缺陷,来修订我们对缺陷的认识,修订发现缺陷的方法。
有很多产品,收到的客户关于易用性的抱怨,远远多于对功能和常规缺陷的抱怨,就应该将“易用性差”作为核心的质量问题,进而作为质量重点。我在下载一款总体评价4星半的Android短信软件时,发现近期的评价很多都是“越来越难用了”“没用的功能越来越多”甚至“更新太频繁了(给了1星)”等等,最近的一些评分平均估计会下降到4星以下。这些抱怨应该当作质量管理的最终考核标准,因为下载者无疑会根据这些评价来决定是否安装软件,而不是看那些“千行缺陷率”“测试人员发现缺陷数”。
成本:
“产品实际投入产出”适合很长的战线。
试想如果是手机研发,应该在开发阶段就做好测试、维护、重刷系统等接口,另外应该优化性能以选择低端硬件,否则整个产品极难保障盈利。
而且还会发生若软件做得好(但软件的研发成本要上升),则可以节省一些硬件资源或减免某些专用硬件的情况。这时候若要分别考核软件部门和硬件部门,就很难实现了。
需求:
“每月待处理需求数”咨询过的一家ERP公司的实际数据,如果产品试销售过程中此数据很大而且消退很慢(符合瑞利分布),则表明产品与客户的需求不符。估计也能呈现一些易用性方面的因素。
“客户尖叫度(Customer Screaming Rate)”苹果成功的标志性绩效指标,不谈需求,因为他要超越需求。要学习这个很难,但要理解并体现其精神。
“软件与硬件需求匹配度”适合消费电子,比如若硬件与软件研发平行,则最终交付产品中交付的软件和硬件应该匹配,而不能“18个功能中,硬件完成了12个,软件完成了13个,但其中6个不重合(就是说这些功能交付不了)”,这样软硬件部门才会共同配合。
某手机厂商很擅长上一条,他们一年的200个项目中,只有3个延期,就是很好地利用了功能排序-软硬件对齐的方法,牺牲次要功能保证上市时间。
项目开发型
产品做的多,项目做的少,不敢多说,请各位补充吧!
为团队设立外部绩效目标的目的,是对齐团队的不同角色、工序、人员的目标,从而互相帮助提升共同的绩效。
外部目标多数可以被客户、用户或市场明确感知,其提升几乎意味着带来收入的增加。如果想在测试人员发现Bug的时候发奖金但却发现账上没有钱,那就改到客户很少抱怨的时候发吧,那时候账上肯定有钱。
注:这是一篇旧文,因符合本系列的内容,在进行了很大改动后重新编辑发布在这里。
点击下载免费的敏捷开发教材:《火星人敏捷开发手册》