软件研发绩效管理的第一性原理 | IDCF

共 3632字，需浏览 8分钟

· 2021-01-11

来源：Scrum中文网
作者：李洁（Jerry Li），CSP，CSM，Scrum中文网资深敏捷顾问和培训师，敏捷教练

我的上一篇文章《软件研发管理中需要破除的三大绩效管理理念》发表后，得到了不少小伙伴的赞同，大家希望能进一步给出一些问题解决方案。比如有一位ID为“飘游乱码”的小伙伴留言：“问题有了，有建议的解决方案没？谢谢！”

由于绩效管理是个比较大的话题，所以我将其分为一个个专题来进行探讨。在本文中，我想先讨论一下自己对软件研发绩效管理的第一性原理的理解。因为做绩效管理，首先搞清楚绩效管理的目标和原则。只有搞清楚了绩效管理的目标和原则，才能知道什么是对的，才能知道目前的绩效管理存在什么问题和应该如何改进。

下一篇文章，或许我会讨论在软件研发组织中该如何设置绩效目标。

一、在很多组织中，软件绩效管理“三观不正”

我亲自在多家公司工作过，也接触过很多公司，亲眼目睹了许多软件绩效管理的“三观不正”现象。特别是以下两种现象：

1.1 绩效管理，完全以考核人为目的

在某些公司，绩效管理完全围绕着绩效考核来实施。每年、半年、季度，甚至是月度，这些公司的管理者们都要对员工设置绩效目标，并在周期结束时进行绩效评估或考核。

然而，在软件研发中，个人绩效目标很难准确合理地预先设置；所以，在绩效考核时，管理者往往也并不是真的完全基于一开始确定的绩效目标来进行考核，而是对自己认为表现好的员工，挖空心思去加分，而对于自己不满意的员工，则挖空心思去减分。

于是，“绩效管理”就完成蜕化成了“考核员工”——依赖于绩效考核，把员工区分成三六九等，给与差异化对待——对于管理者认为表现好的人，升职、加薪和多发奖金，而对于管理者认为表现不好的人，则借机将其淘汰。

这种情况下，“绩效管理”已经完全异化为上位者手中的大棒、鞭笞员工的皮鞭，甚至是打击异己的利器。

这样做，失去了绩效管理的初衷，并让组织变得“官文化”盛行。

1.2 崇拜“神器”

很多公司都很崇拜某种绩效管理“神器”，绩效管理完全围绕着“神器”来实施。

曾经非常流行KPI，所有的岗位都要有KPI——彷佛没有KPI的公司就是游击队，绩效管理完全围绕着KPI来进行。后来，出现了一篇非常著名的抨击KPI的文章，名字我就不说了，大家可以自行百度一下。于是乎，一夜之间，这件“神器”就变成了“过街老鼠”。

一个神器破灭了，怎么办？没关系，还会出现新的“神器”！你看，新的“神器”不是又出现了——OKR。

于是又有无数的公司又捧起了OKR这个绩效管理“神器”——所有的岗位和工作都要制定OKR目标。还有不少知名人士发文著作，说明O该怎么定义、KRs该怎么定义、OKR该怎么跟……彷佛企业只要参透了OKR的秘密，彷佛企业只要推行了OKR，就能够立马打通任督二脉，从此飞上了天。

然而，不可避免的是，有人发出了质疑的声音：“OKR与KPI到底有什么区别？难道传统的KPI就不分析目标和关键成果物吗？难道传统的KPI就不跟踪目标和关键成果物的实现情况吗……”——“这个问题说不清楚，别讨论这个问题！你只要相信OKR就行了！总之OKR就是好……”

不在提高交付效率和质量上下功夫，只会简单粗暴地压榨员工加班和拼命，却幻想着依赖一两件绩效管理“神器”就能实现高绩效，这不是缘木求鱼吗？

我不反对企业运用KPI或OKR，但是我反对企业无脑地、不加思索地、盲目地崇拜和滥用“神器”。

如果不花功夫做好基本的软件研发管理，而只是机械地推行和使用绩效管理工具，非但不能帮助软件组织提效，反而会导致形式主义的泛滥。

二、解决软件研发绩效管理问题，要回归第一性原理

“刻舟求剑”的故事大家都学过：战国时，楚国有个人坐船渡江。船到江心，楚人把随身的宝剑掉进了江中。为了把宝剑找回来，他马上掏出一把小刀，在船舷上刻上个记号，并且对大家说：“这是宝剑落水的地方，所以我要刻上一个记号。”船靠岸后，那楚人立即在船上刻有记号的地方下水，去捞取掉落的宝剑。结果当然是捞不到。

虽然“刻舟求剑”只是一个寓言故事，然而现实中只会僵化地执行某些方法论的人却比比皆是。

要解决软件研发绩效管理问题，绝不是依赖于某一两种方法论或者工具，而是要回归第一性原理，也就是要搞清楚研发绩效管理的核心目标和有效性原理，这样才能建立起正确的“三观”。

三、软件研发绩效管理的第一性原理分析

我个人认为，软件研发绩效管理有三大目标和原则：

尽可能地促进组织交付更多的价值
尽可能地促进端到端协作
尽可能地激发员工的内驱力和促进员工成长

下面，我对这三大目标和原则做一个详细阐述。

3.1 尽可能地促进组织交付更多的价值

进行组织绩效管理，首先必须先搞清楚什么是组织绩效，以及如何衡量组织的绩效产出。

彼得·德鲁克在《21世纪的管理挑战》中谈到：“任何组织的绩效都只能在外部反映出来。……管理的责任是通过协调组织的资源，以在组织外取得成效。”——这段话为组织绩效管理指明了方向。

我们必须明白，组织绩效就是其向外交付的价值；组织的绩效只能通过其向外交付的价值量来衡量。对于任何组织，无论这是一个企业，还是一个大学或者机构，都是如此。

软件研发组织的绩效，也只能通过其交付的价值量来衡量。尽可能地交付更多的价值，就是整个软件研发组织的绩效目标。

所以，软件研发绩效管理的首要目标和原则只能是：尽可能地促进组织交付更多的价值。

那么具体如何衡量一个软件组织的绩效？

可以从以下三个方面来衡量软件组织的绩效：

价值的生产和交付周期：即从需求提出到得到满足的端到端时间，也就是通常所说的“前置时间”。
价值交付量：即一段时间内交付了多少价值，这里的价值通常表现为能满足客户需要的功能特性和实现的业务价值。敏捷开发中，往往使用“交付的故事点数”来衡量。
交付质量：即交付的成果物满足内外部客户的程度。通过可以用“缺陷数”、“故障数”、“技术债”之类的指标来衡量。应当注意的是，我们不仅要关注外部质量，还要关注内部质量，否则就会导致未来价值交付效率和交付质量的降低。

3.2 尽可能地促进端到端协作

在软件研发组织中，要交付更多的价值，不是通过某个人的单打独斗或者个人英雄主义来实现的，而是通过整个端到端价值交付过程中的所有人员通力协作来实现的。

所以，软件研发绩效管理的第二大目标和原则是：尽可能地促进端到端协作。

那么该如何衡量端到端的协作呢？

可以通过度量价值流的流动效率来实现，具体做法如下：

假设：如上图所示，从需求提出到发布上线一共经历了6个步骤，每个步骤上有两个两个时间数据：“工作时间”和“停留时间”。我们可以把6个步骤的“工作时间”和“停留时间”加起来，就可以分别得到“总工作时间”和“总停留时间”（即“前置时间”），然后利用“总工作时间”/“总停留时间”，即可得到“流动效率”。图上的“总工作时间”是6小时，而“总停留时间”是7周（可通过“8小时”和“5天/周”，换算为280小时），这样可以计算出“流动效率”约为2.1%。

3.3 尽可能地激发员工的内驱力和促进员工成长

许多企业为了解决协作问题，制定了复杂的工作流程，建立了精细的项目管理系统，希望能够通过流程和工具来解决人际协作问题。但这些做法，结果却往往只会适得其反——让过程变得沉重而低效，在组织中滋生官僚主义。

那么该如何解决协作问题呢？《敏捷软件宣言》中给出了答案：个体和交互胜于流程和工具。

在软件研发组织中，要解决协作问题，应当依赖于每个人的主动性和能力。如果每个人都有足够的能力，并且积极主动地与他人协作，那么人际协作就不会是问题。反之，如果每个人都等走流程和系统来协调工作，那就会浪费无数的时间。而流程和工具定义得再完善，也无法弥补个人的主动性和能力上的缺陷。

所以，软件研发绩效管理的第三大目标和原则是：尽可能地激发员工的内驱力和促进员工成长。

四、运用三大目标和原则，评估您所在组织的绩效管理

个人认为，以上这三大目标和原则，就是软件研发绩效管理的第一性原理。

如果能够将这三点做好，绩效管理必能成为组织发展的一大助力。反之，如果您的组织违反了这三点，必然会在某种程度上成为组织价值交付的障碍。

或许您可以运用这三大目标和原则，去评估当前您所在组织的绩效管理，并找出问题和改进点。

五、您怎么看

您觉得软件研发绩效管理有哪些关键目标和原则？

在您的组织中，采用的绩效管理办法，符合本文提出的三大目标和原则吗？