如何实行开发部门的绩效考核是很多软件公司技术管理负责人的关注点。刘青焱认为开发部门实施绩效考核，一个重要的目的就是践行量化的目标管理，其意义首先在于客观，其次在于衡量结果公正。

记者：开发部门为什么要实行绩效考核？

刘青焱：绩效考核作为管理六要素之一，在有效管理、凝聚团队、提升士气等方面有着不可或缺的作用。可以说，成功的业务离不开成功的产品，成功的产品离不开成功的执行，成功的执行离不开成功的绩效考核。开发部门是生产部门、执行部门，所以有效的实施绩效考核是必不可少的。

绩效考核可以增强沟通。在绩效考核的过程中，有点强制性的迫使管理人员和团队成员进行定期的沟通，这对于增进管理人员和团队成员之间的相互信任、消除误解都有积极的作用。

藉由尊重和沟通，对开发人员进行持续地激励，从而帮助他不断地进步，将他们的潜力发挥到最大。这样，通过有效地实施绩效考核，将绩效考核变为绩效管理和绩效改进，可以有助于保持整个团队的凝聚力，进而保持高生产力以及工作可控性。

记者：对开发人员实行绩效考核有哪些经验体会？

刘青焱： 基本上我遇到的问题也都是些比较典型的问题。比如开发工作很难数字化这个问题。本质的原因是，开发工作是创造性的工作，总是具有不确定性在里面。有句话说得好，每个软件项目都是一个新项目。所以传统软件工程搞了这么多年，其实是废了的。如果不能有效地管理开发人员，软件的质量就是不可管理的。

但是我们又要尽量把目标用一些数字描述出来，因为数字是相对客观公正的。所以我们可以把框架性的目标用数字描述出来，这样沟通起来最清楚，也不容易产生沟通和理解上的偏差。而对于具体的执行过程，则属于数字之外的东西。绩效管理，数字是绩效，数字之外的是管理。

所以，开发工作往往不能过度追求数字。一味追求数字的后果只有一个，那就是绩效被过度重视而管理被过度忽视，从而增加质量失控的风险。

举个例子， 完成一个后台系统模块。这里“一”就是数字，但是其他的部分呢，就完全在此之外了。或者，我们再加上一个，bug数控制在N个以下。但这是无济于事的。因为当你的业务量急速上升的时候，你会发现开发人员甲做的模块可以平滑扩容，很好地支撑起新的业务量；而开发人员乙呢，就可能甚至需要停止业务，花费很大精力去重构。

所以我的观点是，除了钱可以被控制（ 度量），其他东西是不可以被控制（度量）的。也就是说，除了销售人员的quota是真正可以数字化的之外，其他职位的目标都是无法真正数字化的。要量化，但是不能过度追求数字。

同样是上面的例子，我们会发现，即使有量化目标，也无法区分优秀的开发人员和一般的开发人员。一般而言，一个优秀程序员的能力是一般程序员的十倍甚至二十倍还要高，但是他们的薪酬却不会差那么大。其根本原因就是，没有什么绩效考核机制能够准确地识别出这些优秀的人员。因为度量工具永远都不会拥有发现的功能：同样是完成了期望的目标，你无法说甲比乙优秀多少。结果往往是，都是符合期望，于是得分都一样。长此以往，绩效考核也就成了埋没人才的罪魁祸首。

前人说了，千里马常有而伯乐不常有。把千里马当牛用的人，不在少数。因为在僵化的环境中，都是讲求德比才重要。而且往往对德的判断都是管理者的主观臆测。一个德才兼备的人才，在顶级的管理者眼中是德才兼备的，在二流管理者眼中就往往是才胜于德，在末流管理者眼中可能就是无德无才了。

因此，用人先要识人。看一个人有没有才，要从他的实际工作看，而不是只看一个数字化的结果。看一个人有没有德，则更多取决于管理者的胸怀大小了。

所以，要做好绩效管理，就要深刻理解“绩效管理=绩效+管理+管理者”的道理。

记者：在俱乐部会员讨论时候，你曾经提到“量化标准还是最重要的”，请问如何很好地制定这个标准呢？

刘青焱：要很好制定出量化的考核标准，最重要的一条是，技术管理者一定要懂技术，要专注技术。唯有如此，才有可能制定出公平且一致的标准，并经充分的沟通，让技术人员信服。然后，技术管理者需要对过程和结果保持开放和透明的评价，必须公正客观，并在团队内部达成充分一致。不然，一个技术管理者很快就会堕落为一个技术官僚，并被顶级的程序员所厌恶。

只有管理者真正理解技术，真正对团队成员了解，相互知根知底，才能制定出一致认同的目标和标准。通常讲，目标设定要让开发人员“跳一跳够得到”。如果不是对他的能力十分清楚，不知道他的兴奋点在什么位置，又怎么能够设定出正确高度的目标呢？高度要很好地量化，首先要知道目标应该设在哪里，然后量一量，知道这个地方的目标的高度是多少。这样才能得到最佳的量化目标。这样得到的量化目标和标准才是可管理的。

何谓可管理的？就是这个设定不会流于形式，或者权谋，而是确确实实能够激励和帮助开发人员不断提高，从而实现整个团队能力和生产力的不断提高。

记者：在大公司和小公司实行绩效考核有什么区别吗？

刘青焱：大公司和小公司的绩效考核与绩效管理区别非常大。

大公司层级复杂，甚至跨地域、跨市场，所以常常采用矩阵式管理结构，层级和汇报关系复杂。所以对于大公司，绩效管理尤为重要。因其沟通成本很高，所以量化要更强，以此减少层间沟通的信息变形。

因而大公司的绩效管理很容易出现过度量化、过度追求数字的问题。因为对于一家庞杂的大公司，唯一的一般等价物就是钱。所以大公司的CFO就时常出任CEO。

两个团队绩效分数相同的人，可能实际能力差距巨大。所以无法再管理细节的CEO最终管的，就是钱。

在此情况下，如果我们过度追求数字，对销售团队是没有错误的，但是对开发团队就是灾难。过度追求数字，质量就会下降，开发人员就会沮丧，出现问题就会互相指责，最终带来的后果就是团队的分崩离析和产品的失败。不要被世界500强的光环所掩盖，它们之中如此失败的案例比比皆是。

所以大公司里，要从组织架构上把追求短期利益的团队（例如销售）和追求长期利益的团队（例如技术研究）划分开，分别实施不同的绩效管理方法，从而在制度上尽力确保公司短期利益和长期利益的平衡。

小公司由于团队人数少，层次简单，等级壁垒小，沟通成本低，所以技术管理者应该多用沟通的方式代替过度量化的数字，应该把目光集中在个人目标和公司目标的一致性上。因为对于小公司而言，应该是每一个人，包括程序员，都十分清楚公司的目标以及方向。每一个人都十分清楚自己的工作对公司的未来有着至关重要的影响。

小公司因为存在更大的生存压力，因而更注重短期目标和一致性目标。小公司资源是更加紧缺的，这也就意味着，小公司不太可能从结构上保障短期和长期的平衡。这就对一个技术管理者提出了很高的要求。因为和销售型团队比较，技术性团队更需要这种平衡。

一支团队要在一家公司里生存，就必须有数字。一个团队要在一家公司里长久生存，就不能过度追求数字。因为只有长久的公司里才能有长久的团队，而短视的公司是不会长久的。在这一点上，一个技术管理者应该做好平衡的艺术。有效地运用绩效管理这一工具，帮助技术管理者做好这种平衡。

无论大小公司，技术管理者都需要秉承一个理念，把技术人员当作管理者来管理。即，充分认识到程序员的工作具有很强的自主性和创造性，传统的管理生产者的方法是不合适的。技术管理者重要的管理目标之一应该是团队成员的长期成长，并通过这种成长实现团队生产力的提高，从而更好地支持业务目标的完成。从这一点上讲，绩效管理，正是团队整体生产力持续提升的重要管理工具。

（本文来自《程序员》杂志2010年4月刊）