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

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

 

“内向型”绩效及其导向

进度：“各阶段按时完成率”会导致分析和设计人员草草结束工作，而将大量不确定工作推给开发人员。

笔者给一家银行做咨询的时候其独立测试团队就多次提到开发组会擅自延长开发工期，而不可推迟的交付点会将测试工期大大压缩。

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

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

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

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

 

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

产品研发型

进度：

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

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

质量：

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

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

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

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

成本：

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

需求：

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

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

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