敏捷开发绩效管理之四：为团队设立外部绩效目标（目标管理，外向型绩效）...

梦里梦外; 2023-08-17 15:52 111阅读 0赞

这是敏捷开发绩效管理的第四篇。（[之一][Link 1]，[之二][Link 2]，[之三][Link 3]，[之四][Link 4]，[之五][Link 5]，[之六][Link 6]，[之七][Link 7]）

最近在看德鲁克的书，发现其中很明确地写着“企业的绩效只存在于外部，而企业内部只有成本”的概念和说法，下面结合敏捷开发团队的绩效考核展开谈谈。

敏捷开发有很多“外向型”思维，比如：关注客户价值，认为可交付的产品才是真正能表征工作进展的因素等等，但尚未直接与目标管理接轨。外向性思维可以防止部门间壁垒或踢皮球，而转而共同讨论对外交付价值，从下面的对比可以看出这点。

--------------------

# “内向型”绩效及其导向 #

进度：“各阶段按时完成率”会导致分析和设计人员草草结束工作，而将大量不确定工作推给开发人员；开发人员则如法炮制，把延期踢给测试人员。

质量：“千行代码缺陷率”会导致开发人员在很多“是否是缺陷”问题上与测试人员争执不下，另外一些次要的如使用不便、不直观等问题则被长期搁置。

成本：“与计划相比的人员超支率”会导致项目经理很不愿意接受变更，即使是那些显然能给客户带来巨大价值的。

功能：“需求规格中需求的完成比例”会导致开发组思维局限于当年编写需求规格时期的认识，而不能在整个漫长的开发过程中不断精化需求。

此外还有一些更可怕的数据，比如“每月生产的代码行数”“每月生产的功能点或故事点数”（这个很有迷惑性）“每月修改的缺陷数”等，都是不恰当的绩效。德鲁克“企业内部只有成本”的理念指出，无论是文档，代码，可运行软件乃至最终产品，若尚未被销售，都只是成本的一部分。

多数采用内向型绩效的公司和团队，其绩效结果都不好。究其原因，单个部门/工种/个人各自追求自己的绩效，并不会导致整个项目外部绩效的提升（这称为“合成谬误”）。

某些内向型绩效甚至是互斥的，处于零和状态。比如测试团队人均发现的缺陷数（测试团队的绩效）与开发人员人均缺陷数（是开发团队的负绩效）并存，则**两个团队无论如何都无法同时提升绩效**，导致他们永远无法像一个团队一样互相帮助。若你的公司有这样的绩效，则研发人员与测试人员打架就不用奇怪了。

其他多数内向性绩效，都存在潜在的互斥关系。比如前面提到的个阶段按时完成率即内部存在互斥，而“需求规格中需求的完成比例”必与“客户需求响应率”互斥。

# 外向型绩效 #

下面是一些潜在的**“外向型”绩效**，由于之前提过不同企业乃至产品的外向型绩效差别很大，请灵活运用。

**产品研发型**

**进度：**

“与竞争对手相比同档产品的上市日期比较”适合消费电子类产品。

“响应分销商需求的时间”适合渠道比较强势的情况。

这些外向型绩效应该作用在整个团队上，换言之不管哪个环节导致了进度差，都一起得到底的绩效。从而促使整个团队一起思考如何提升绩效。

需求和设计人员为了能让开发人员提前开工，可以采取分段写需求和设计的方法，把最影响架构又最不会发生变化的部分先写出来，让开发人员提前开工干活；而开发人员也可能会采取同样的策略，阶段式地发布产品，让测试人员可以提前测试，防止最后缺陷太多导致产品延期；而需求和设计人员又回过头来用开发的进度和测试的缺陷率，来判断产品应该消减功能换取上市时间，还是增加更多功能以换取竞争力。

可见**一个为外部目标奋斗的团队，会很容易地团结起来，共同思考提升绩效的最佳策略。**

**质量：**

“每月待处理质量问题数”咨询过的一家ERP公司的实际数据（但他们尚未用这个数据考核），此数据一般符合瑞利分布，因此可预测未来的质量问题数量。

“每月终端用户投诉数”适合消费电子、网络游戏等与客户比较紧密的行业。

“每月分销商投诉数”适合渠道比较强势的情况。

“每月论坛缺陷提出数”适合……我在的一家企业使用BBS免费处理缺陷。

用最终用户提出的抱怨作为外部质量目标的策略，不是说大家不用测试了，把缺陷留给用户。而是：**用我们测试了但仍漏给客户让其发现的缺陷，来修订我们对缺陷的认识，修订发现缺陷的方法。**

有很多产品，收到的客户关于易用性的抱怨，远远多于对功能和常规缺陷的抱怨，就应该将“易用性差”作为核心的质量问题，进而作为质量重点。我在下载一款总体评价4星半的Android短信软件时，发现近期的评价很多都是“越来越难用了”“没用的功能越来越多”甚至“更新太频繁了（给了1星）”等等，最近的一些评分平均估计会下降到4星以下。这些抱怨应该当作质量管理的最终考核标准，因为下载者无疑会根据这些评价来决定是否安装软件，而不是看那些“千行缺陷率”“测试人员发现缺陷数”。

**成本：**

“产品实际投入产出”适合很长的战线。

试想如果是手机研发，应该在开发阶段就做好测试、维护、重刷系统等接口，另外应该优化性能以选择低端硬件，否则整个产品极难保障盈利。

而且还会发生若软件做得好（但软件的研发成本要上升），则可以节省一些硬件资源或减免某些专用硬件的情况。这时候若要分别考核软件部门和硬件部门，就很难实现了。

**需求：**

“每月待处理需求数”咨询过的一家ERP公司的实际数据，如果产品试销售过程中此数据很大而且消退很慢（符合瑞利分布），则表明产品与客户的需求不符。估计也能呈现一些易用性方面的因素。

“客户尖叫度（Customer Screaming Rate）”苹果成功的标志性绩效指标，不谈需求，因为他要超越需求。要学习这个很难，但要理解并体现其精神。

“软件与硬件需求匹配度”适合消费电子，比如若硬件与软件研发平行，则最终交付产品中交付的软件和硬件应该匹配，而不能“18个功能中，硬件完成了12个，软件完成了13个，但其中6个不重合（就是说这些功能交付不了）”，这样软硬件部门才会共同配合。

某手机厂商很擅长上一条，他们一年的200个项目中，只有3个延期，就是很好地利用了功能排序-软硬件对齐的方法，牺牲次要功能保证上市时间。

**项目开发型**

产品做的多，项目做的少，不敢多说，请各位补充吧！

--------------------

**为团队设立外部绩效目标的目的，是对齐团队的不同角色、工序、人员的目标，从而互相帮助提升共同的绩效。**

外部目标多数可以被客户、用户或市场明确感知，其提升几乎意味着带来收入的增加。如果想在测试人员发现Bug的时候发奖金但却发现账上没有钱，那就改到客户很少抱怨的时候发吧，那时候账上肯定有钱。

注：这是一篇旧文，因符合本系列的内容，在进行了很大改动后重新编辑发布在这里。

点击下载免费的敏捷开发教材：《[火星人敏捷开发手册][Link 8]》

![0_1311055886783t.gif][]![0_1311055987UN6B.gif][]

转载于:https://www.cnblogs.com/JPAORM/archive/2011/08/23/2510455.html

[Link 1]: http://blog.csdn.net/cheny_com/article/details/6705497
[Link 2]: http://blog.csdn.net/cheny_com/article/details/6705568
[Link 3]: http://blog.csdn.net/cheny_com/article/details/6705821
[Link 4]: http://blog.csdn.net/cheny_com/article/details/6713089
[Link 5]: http://blog.csdn.net/cheny_com/article/details/6721626
[Link 6]: http://blog.csdn.net/cheny_com/article/details/6723708
[Link 7]: http://blog.csdn.net/cheny_com/article/details/6723715
[Link 8]: http://blog.csdn.net/cheny_com/article/details/6616794
[0_1311055886783t.gif]: http://hi.csdn.net/attachment/201107/19/0_1311055886783t.gif
[0_1311055987UN6B.gif]: /images/20230810/d155d2901a7a47ef8de57dbabafbc29e.png