欧盟的软件工程专家Jeppe Hedaa在2018年出版了一本新书，书名是——Nucleon: The missing formula that measures your IT department’s performance”。我翻译为——核子公式：被忽略的IT部门绩效度量工具。
无论中外，“绩效”都是大多数职场人绕不过去的心结。越是所谓的大公司、大组织，越是有强烈的绩效文化。每每到了年底、季度末，人们魂牵梦绕、牵肠挂肚的事情就是自己的KPI（或PBC）了。
2019年的年初，阿里的某个程序员在与其领导在网上撕逼——主要就是因为绩效。他一语道破了“中国式”绩效考核的要点——领导是否喜欢你。
员工都是关心自己个人的绩效，其终极目的还是关心到手的“奖金”。作为高层，关心的还是团队的整体绩效，其终极目的是为了支持企业的整体战略。
对于绩效这个问题，最核心的就是公平、公正——能够反映真实、客观的信息。这个绩效是否真的能够摆脱“人”的因素，可以科学地计算得出呢？
Hedaa先生的逻辑起点应该是与“桥水基金”的老板Dalio先生一样。认为团队本身就像是一个机器（machine）；团队的“绩效”就像是机器“功率”一样，是能够计算（度量）出来的。
在物理学中，有一个度量指标那就是“功率”，计量单位是“瓦特”，其含义，就是在单位时间内做功的多少。 我们常说的“马力”，其实也是功率的一种（1马力=735瓦特）。人类进行到工业时代，常用这个指标来度量机器做功的数量。
我们每家的冰箱都贴着的能效标签，主要显示的就是这个指标。
我们的IT研发团队，是否也能像冰箱一样，被计算和贴上“绩效”标签呢？Hedaa先生，就研发了“核子公式”——用来计算出团队的绩效。
绩效与功率，有很多类似的地方。都是表示某种物质“产出数量”的多少。功率是有计量单位，但是目前，绩效是没有计量单位的。
从霍金开始，科普的文章是最忌讳出现数学公式。但是，为了说明白这个计算公式，我还要列出，如下图—— 大家仔细看下去，还是比较好理解的。
根据这个公式可以总结为两个原则：
1、优秀的人才可以提升团队绩效；
2、组织能力差以及高复杂的IT环境会降低绩效。
人的因素
长期以来，包括看遇见的未来，软件工程都是一个“劳动密集型”的行业。团队主要绩效的因素还是“人”。
核子公式是将市场上软件工程人员分为了10个等级，绩效最高的是10级，最低的是1级。见下图——各级人员的绩效曲线，上一级的人员绩效数值几乎是下一级的2倍。10级人员的绩效是100，几乎是9级（绩效值=57）的2倍。5级代表的是市场里的平均水平人员，其绩效值=5，10级人员是他的20倍。
10级人员是市场上的稀有物种，在正态分布中，只占有1%。9级人员也只占比3%左右。
这个数据是怎么来的，我们按下不表。与我们平常的“直觉”还是比较相近的吧。即优秀的人才还是很难得的。 Hedaa先生提出了一个人力成本的考虑思路——不管关注人员的“薪资成本”，而是要考虑人员的“产出成本”。即：交付单位产出物的成本。
Hedda先生的文章里是没有提及“功能点”(FP)——只是用了“单位产出物”的概念。这个概念与功能点的思路是一致的：将软件划分为可以度量的基础单位。
Hedaa先生的数据来源于在丹麦市场，在这里，10级人员每小时可以为组织赚1300克朗（DKK），而产出成本只有13克朗/单位产出物。5级的人员的成本是160克朗/单位产出物，而只能够每小时赚800克朗。而1级人员，每单位的成本是700克朗。 我们算一下：1级人员的单位产出成本几乎是10级的54倍。
说道在这里，我们就都能理解为什么华为公司会给优秀毕业生开出200万的年薪了吧。
曾经的IT企业家史玉柱先生，也曾经表达过——用高薪雇高级人才，是企业最省钱的策略。
组织因素
绩效再好的人才也是要在组织里工作的，恶劣的组织因素会降低团队的整体绩效。核子公式总结了4方面的因素：
1、团队规模；
2、官僚政治；
3、决策人距离；
4、溢出效应。
团队规模。先说结论,大团队的绩效与小团队相比较，至少要差48%。Hedaa先生，分析统计了564个大小相当的项目（10万行代码）。分为两组，实验组是5人以下的小团队；对照组是超过20的团队。大团队平均是提前6天完成项目，但是成本是小团队的7.3倍。
官僚政治。权力斗争、文字游戏、超级复杂的审批流程，会降低将近团队20%的潜在绩效。我们很多中国人都看过美剧《权力的游戏》，会发现——其实老外们也非常善于政治斗争。我看过很多国外的管理书籍，这个Bureaucracy（官僚）词是反复出现。
Hedaa先生表示：任何组织都需要行政人员，但是这个“支持团队”一旦形成规模，有了自己的流程，所谓的“走上正轨”。往往也意味着事情开始变坏。团队失去动力，生产率也开始降低。
我在某个银行IT团队做咨询项目，他们管理PMO的老总就曾说过：我们应该是服务于开发团队的，而不是给他们添麻烦的。
Hedaa先生给出几条建议来优化官僚政治的负面影响：
• 自治（自组织）：团队自我管理，自己来定义流程、责任、权力等等；
• 端到端的知识：团队有开发产品的全部知识——万事不求人；
• 沟通环境：团队尽可能在同一个物理空间里办公；
• 专注：团队成员专注做一个项目，一次只做一件事情，分心会降低效率。
决策人距离。首先，什么是决策人？即最终决定产品（包括：功能、界面布局）是否符合验收要求的人。在中国，就是那批经常说出“这不是我想要的”的家伙们。Hedaa先生称之为：Idea-owner，Business-owner。
开发团队应该与他们“近距离”的工作，否则会降低至少32%的绩效。
我自己的工作经验，以及咨询的项目，团队总是在抱怨——“等待客户确认”的时间太长了。这部分时间，在建筑行业的术语是“窝工”，Hedaa先生称之为“黑洞”。即在某些关键环节，必须要经过“决策人”的认可才能进入下一步，如果他们的“距离远”，反馈会不及时，造成的结果就是——开发团队大家会无所事事的等待。
这段时间，很影响士气。且不计数团队的工作量“人天”。
在项目开始的产品需求、设计阶段，尤其是需要“决策人”的“近距离”参与。他们也许不能全职投入，但是在有需要的时候能够及时反馈。
溢出效应（Spillover）。这一点，用中国话来讲就是：近朱者赤近墨者黑。
所有的人都会受到队友的影响，有可能是潜能绩效发挥3倍（遇到神队友）；也有可能是发挥1/3（遇到猪队友）。
无论中外，传统的人才金字塔模型，都是一个10级的人才带领一群绩效低的人员工作。
Hedaa先生的研究是，将多个高绩效的人才集合在一起，反而总体绩效会更好。一个10级的人员，会提升另一个10级人员的绩效。他们在这个团队的绩效之和，会高于独自在两个团队的绩效之和。
而将一个10级人员与一群5级人员放在一个团队，5级的绩效会提升，但是10级的会降低。
这一点在欧洲也许可以，但是在中国呢？
有正面的例子——例如《亮剑》里李云龙与赵刚。
也有反面的例子，我曾经的一个团队，云集多位来自美国、中国台湾等地区的所谓牛人，结果却是内耗不断。这个反例，也许正是说明了“高工资、牛背景”不意味着“高绩效”。个人的绩效如何度量？Hedaa先生在文章中，也没有提及。这还是一个管理难题。
复杂因素
这个复杂因素，其实本质上也是与组织有关系的，核子公式总结为4个方面：
1、文化；
2、方法成熟度；
3、遗产；
4、架构。
文化：Hedaa先生，给出就具体的数字——恶劣的团队文化至少会降低17%的团队绩效。
我们都知道“文化”很重要，但是这个因素也很难进行量化表达。国外的专家一直在致力于此，也发明了一些评估与度量的方法，例如：HBS Culture Profile（哈佛商学院文化画像）以及Vega Factors Total Motivation (TOMO)。
这两个方法，我简单查了一下，网上的资料很少。只有感慨：国外人什么都要进行量化，我们的路还很长。
可以总结一点：文化校准（cultural alignment）可以促进积极的企业文化，而积极的企业文化可以提升绩效。
这个“文化校准”如何度量呢？——度量员工的个人目标与部门目标重合度。这点也是整体绩效的重要度量指标，这个指标反映企业的“员工敬业度”与“客户导向”水平。
核子公式将考查组织文化中的6个指标：
• 玩（play）：你工作是否有趣？是否想玩一样？
• 目的：你的工作是否有意义（meaningful）？
• 潜能：这些工作是否帮助你实现人生目标？
• 情绪压力：工作给你带来了情绪压力？
• 经济压力：你的工作是否就是为了赚钱？
• 惯性：你就是为了工作而工作——没有更好的原因？
方法成熟度：在方法层面，影响团队绩效的主要有三个点：敏捷、实际经验、团队一致性。如果团队不敏捷也没有经验，其绩效至少会降低51%。
无论中外，一旦软件系统出了问题——满足不了业务团队的需求，IT团队往往都是替罪羊。这点就使得IT团队往往很“保守”，也因此，“方法”这个领域一般都是很僵硬的。
总体而言，在一个整体团队里，方法应该是一致的。如果做不到，至少在一个小团队里，要保持一致。
遗产：指的是IT遗产，即“老”的遗留系统。如果开发团队维护的系统对于公司而言已没有战略价值，会降低其绩效的18%。
对于企业而言，已有系统，并不是都是麻烦。业务就是在这些老系统上发展壮大的，但是这些系统很可能已经是“得不偿失”了。即维护的成本高于获得的收益。
遗留系统即会消耗团队的维护工作量，也会占有新系统的预算。
架构：架构层面的评估、度量由几个方面组成——产品API的质量，可重复使用的程度,未来保障的程度。恶劣的架构至少降低团队12%的绩效。
企业架构是所有IT从业人员最重要的工作基础。如果企业的架构部门出了问题，所有的项目都会受到影响。
好的架构应该是“易用”、“易选择”；接口的需求应该是简单易懂；鼓励重复使用已有的代码。要尽量避免开发所谓的“专用接口”。
对架构进行评估不能是（类似于CMMI）仅仅度量企业的文档和流程，而是要去度量架构加快生产的速度，满足未来挑战的程度。
小结
以上，我把这个“核子公式”简单介绍完了，如果把每一个指标都录入数据，就能够计算出团队的绩效数据——就像是给冰箱上贴出了能效指标一样。
Hedaa先生也说：进行绩效评估，不能跟着感觉走（gut feelings）；要尽量反映事实。
以往我们只是知道要提升绩效。但是不知道哪里要提升？如何提升？
而现在有了这个公式后，有了具体的绩效数据，我们可以想想：这个数字意味着什么？有多重要？哪些更重要领域可以得到提升？怎么去提升？（版权归北京软件造价评估联盟所有）
