我的上一篇文章《软件研发管理中需要破除的三大绩效管理理念》发表后，得到了不少小伙伴的赞同，大家希望能进一步给出一些问题解决方案。比如：有一位ID为“飘游乱码”的小伙伴留言：“问题有了，有建议的解决方案没？谢谢！”
由于绩效管理是个比较大的话题，我会持续选择一些主题来进行讨论。在本文中，我想先讨论一下自己对软件研发绩效管理的第一性原理理解。
一 在很多组织中，软件绩效管理“三观不正”
我自己亲自在很多家公司工作过，也接触过很多公司，亲眼目睹了许多软件研发绩效管理的“三观不正”现象。特别是以下两种现象：
#1 绩效管理，完全以考核人为目的
在某些公司，绩效管理完全围绕着绩效考核来进行。每年/半年/季度，这些公司的管理者都要对员工设置绩效目标，并在周期结束时进行绩效考核。
然而，在软件研发中，个人绩效目标很难预先设置和合理设置；所以，在绩效考核时，管理者往往也并不是真得完全基于绩效目标来进行考核，而是要对自己认为表现好的员工，挖空心思去加分，而对于自己不满意的员工，则挖空心思去减分。
于是，绩效管理，就变得完全以考核员工为目的——依赖绩效考核这个手段，把人区分出三六九等，给与分别对待——对于管理者认为表现好的人，升职、加薪和多发奖金，而对于管理者认为表现不好的人，则是将其淘汰的机会。
这样做，保证了管理者的权威，同时也让组织变得“官文化”流行。
#2 崇拜“神器”
很多公司都很崇拜绩效管理“神器”。
曾经非常流行KPI，所有的岗位都要有KPI——彷佛没有KPI的公司就是游击队，绩效管理完全围绕着KPI来进行。后来，出现了一篇非常著名的抨击KPI的文章，名字我就不说了，大家可以自行百度一下。于是乎，一夜之间，“神器”变成了“过街老鼠”。
一个神器破灭了，怎么办？没关系，还会出现新的“神器”！你看，新的“神器”不是又出现了——OKR。
于是无数的公司又捧起了OKR这个“神器”——所有的岗位和工作都要制定OKR目标。还有许多知名人士在发文著作，O该怎么定义，KRs该怎么定义，OKR该怎么跟……彷佛企业只要参透了这个秘密，彷佛企业只需要推行了OKR，就能够立马打通任督二脉，从此飞上了天。
然而，不可避免的是，有人质疑：“OKR与KPI到底有什么区别？难道传统的KPI就没有目标和关键成果物吗？难道传统的KPI就不进行目标和关键成果物的跟踪吗？”——“这个问题说不清楚，别讨论这个问题，你只要相信OKR就行了，总之OKR就是好！”……
当然，我并不反对企业合理运用KPI和OKR这两种工具，但是我反对企业无脑地、不加思索地、盲目地崇拜“神器”。一味地依赖和滥用工具，只会导致官僚主义和效率低下。
二 解决软件研发绩效管理问题，要回归第一性原理
“刻舟求剑”的故事大家都学过：战国时，楚国有个人坐船渡江。船到江心，楚人把随身的宝剑掉进了江中。为了把宝剑找回来，他马上掏出一把小刀，在船舷上刻上个记号，并且对大家说：“这是宝剑落水的地方，所以我要刻上一个记号。”船靠岸后，那楚人立即在船上刻有记号的地方下水，去捞取掉落的宝剑。结果当然是捞不到。
虽然“刻舟求剑”只是一个寓言故事，然而只会僵化地执行某些方法论的人却比比皆是。
要解决软件研发绩效管理问题，绝不是依赖于某一两种方法论或者工具，而是要回归第一性原理，也就是要搞清楚研发绩效管理的核心目标和有效性原理，这样才能建立起正确的“三观”。
三 软件研发绩效管理的第一性原理分析
我个人认为，软件研发绩效管理有三大目标和原则：
- 尽可能地促进组织交付更多的价值
- 尽可能地促进端到端协作
- 尽可能地激发员工的内驱力和促进员工成长
下面，我对这三大目标和原则做一个详细讲解。
#1 尽可能地促进组织交付更多的价值
进行组织绩效管理，首先必须先搞清楚什么是组织绩效，以及如何衡量组织的绩效产出。
彼得·德鲁克在《21世纪的管理挑战》中谈到：“任何组织的绩效都只能在外部反映出来。……管理的责任是通过协调组织的资源，以在组织外取得成效。”——这段话为组织绩效管理指明了方向。
我们必须明白，组织绩效就是其向外交付的价值；组织的绩效只能通过其向外交付的价值量来衡量。对于任何组织，无论这是一个企业，还是一个大学或者机构，都是如此。
软件研发组织的绩效，也只能通过其交付的价值量来衡量。尽可能地交付更多的价值，就是整个软件研发组织的绩效目标。
所以，软件研发绩效管理的首要目标和原则只能是：尽可能地促进组织交付更多的价值。
那么具体如何衡量一个软件组织的绩效？
可以从以下三个方面来衡量软件组织的绩效：
- 价值的生产和交付周期：即从需求提出到得到满足的端到端时间，也就是通常所说的“前置时间”。
- 价值交付量：即一段时间内交付了多少价值，这里的价值通常表现为能满足客户需要的功能特性和实现的业务价值。敏捷开发中，往往使用“交付的故事点数”来衡量。
- 交付质量：即交付的成果物满足内外部客户的程度。通过可以用“缺陷数”、“故障数”、“技术债”之类的指标来衡量。应当注意的是，我们不仅要关注外部质量，还要关注内部质量，否则就会导致未来价值交付量和交付质量的降低。
#2 尽可能地促进端到端协作
在软件研发组织中，要交付更多的价值，不是通过某个人的单打独斗或者个人英雄主义来实现的，而是通过整个端到端价值交付过程中的所有人员通力协作来实现的。
所以，软件研发绩效管理的第二大目标和原则是：尽可能地促进端到端协作。
那么该如何衡量端到端的协作呢？
可以通过度量价值流的流动效率来实现，具体做法如下：
假设：如上图所示，从需求提出到发布上线一共经历了6个步骤，每个步骤上有两个两个时间数据：“工作时间”和“停留时间”。我们可以把6个步骤的“工作时间”和“停留时间”加起来，就可以分别得到“总工作时间”和“总停留时间”（即“前置时间”），然后利用“总工作时间”/“总停留时间”，即可得到“流动效率”。图上的“总工作时间”是6小时，而“总停留时间”是7周（可通过“8小时”和“5天/周”，换算为280小时），这样可以计算出“流动效率”约为2.1%。
#3 尽可能地激发员工的内驱力和促进员工成长
许多企业为了解决协作问题，制定了复杂的工作流程，建立了精细的项目管理系统，希望能够通过流程和工具来解决人际协作问题。但这些做法，结果却往往只会适得其反——让过程变得沉重而低效，以及让员工变得官僚。
那么如何才能解决协作问题呢？《敏捷软件宣言》中给出了答案：个体和交互胜于流程和工具。
在软件研发组织中，要解决协作问题，应当依赖于每个人的主动性和能力。如果每个人都有足够的能力，并且积极主动地为他人补位，那么协作就不会是问题。反之，如果每个人都等让着流程和系统来协调，那么就会浪费无数的时间。而流程和工具定义得再完善，也无法弥补个人的主动性和能力上的缺陷。
所以，软件研发绩效管理的第三大目标和原则是：尽可能地激发员工的内驱力和促进员工成长。
四 运用三大目标和原则，评估您所在组织的绩效管理
个人认为以上这三大目标和原则，就是软件研发绩效管理的第一性原理。
如果能够将这三点做好，绩效管理必能成为组织发展的一大助力。反之，如果您的组织违反了这三点，必然会在某种程度上成为组织价值交付的障碍。
您能运用这三大目标和原则，去评估当前您所在组织的绩效管理，并找出问题和改进点。
五 您怎么看
您觉得软件研发绩效管理有哪些关键目标和原则？在您的组织中，采用的绩效管理办法，符合本文提出的三大目标和原则吗？还是说，您的组织中，有更为优越的指导思想？
欢迎在评论区留下您的观点。
本文作者：
李洁（Jerry Li），CSP，CSM，Scrum中文网资深敏捷顾问和培训师，敏捷教练
