核子公式——量化IT团队绩效

　　欧盟的软件工程专家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）；要尽量反映事实。

　　以往我们只是知道要提升绩效。但是不知道哪里要提升？如何提升？

　　而现在有了这个公式后，有了具体的绩效数据，我们可以想想：这个数字意味着什么？有多重要？哪些更重要领域可以得到提升？怎么去提升？（版权归北京软件造价评估联盟所有）