软件工程师绩效评估的三大误区

2020年4月，McKinsey就“技术转型”给公司带来的影响对500位领导者进行了调查，而结果令人震惊。

从增强IT基础设施到数据扩展和分析，该调查询问了大约10项旨在增加收入或降低成本的技术主导的变革。受访者表示，正是技术人才的变化给公司创造了最大价值。不过，他们同时也表示，人才战略在未来两年内不大可能会变化。这是为何？

其中一个因素可能是，技术人才转型的成功与否，取决于一个有效的绩效衡量标准，而事实上，对大多数组织来说，持续、准确、公平地衡量绩效是一项艰巨的任务。

100 多年来，产业组织心理学家一直在研究衡量工作绩效这一众所周知的困难挑战，甚至为它起了一个名字：标准问题（the criterion problem）。

标准问题的核心是，我们很难找到不被工作之外的因素所污染的绩效衡量标准，但这个标准又能捕捉到工作的全部绩效范围。例如，代码提交的数量就是一个“受污染”的性能指标，因为外部力量会影响它。它也是一个有缺陷的性能指标，因为它忽略了这些代码提交的质量，而这是判断一个工程师能力强弱的重要方面。

然而，虽然没有简单的方案来解决这样一个“百年问题”，特别是像软件工程这样复杂，不断发展的工作，但有一些常见的测量错误是工程领导者可以避免的。

根据最新研究，以下是三个需要避免的错误以及它们的处理方案：

根据现代科学思维，工作绩效是生产力（即任务绩效）、团队合作（即情境绩效）和不良行为——如旷工、摸鱼或失职（即反效果工作行为或合同工作分解结构）的组合。

由于这种固有的复杂性，许多领导者在衡量绩效时会收集全局性的主观评级：例如，净推荐值（NPS）类型的评级，其中主管会评估他们在前三个月试用期后重新雇用新员工的可能性。

通用的、易于收集的指标有时比没有指标更好。尽管如此，使用全局评级的最佳情况是，它提供了对员工组合任务，背景情况和CWB绩效行为的模糊印象，但它也可能使洞察或干预变得困难。最坏的情况是，全局的、主观的评级衡量的是与员工效率完全无关的东西，比如他们与评级者的相似性。

不要只简单地使用一个全局评级，而是将主管评级与团队层面的结果（见下文），人力资源指标（敬业度调查答复和任期），甚至同行评级（例如15Five平台的绩效管理和Ray Dalio的 DotCollector应用程序）相结合。这些综合评级为个人任务、背景情况和CWB绩效行为提供了更可靠的指标。

对于希望获得更客观性能指标的工程组织，领导者通常会把眼光放在少数工程KPI上，如页面加载时间、端点延迟、修复的关键错误数量、正常运行时间和部署交付周期。从表面上看，这些KPI看似是有意义的，因为它们看起来是与工作相关的、可量化的工程师贡献的衡量标准。

但与销售数字一样，个人KPI经常受到员工控制之外的因素的污染，例如团队相互依存、供应商问题或安全威胁。工程KPI在衡量单个工程师的贡献方面也可能存在缺陷，例如他们的协作，沟通和所提供的文档。

与其执着于用KPI来确定个人的产出或行为，不如考虑在团队层面衡量成果，而那必须是有利于组织的集体个人行为的成果，例如增加产品或功能的用户网络推广者“得分”。

假设你已经确定了代表竞争优势的可衡量成果，那么衡量团队层面的成果有时比个人层面的衡量更能奖励和激励行为。如果你选择去衡量团队层面，请确保奖励是“真实”可控的，同时与团队绩效保持一致。

研究还告诉我们，工作绩效不是静态的，而是高度可变的，因此有必要跨时间衡量绩效。但工程管理的现状是定期评审KPI，同时进行年度绩效考核，而不是看即时的KPI或评级，监控个人和团队指标的趋势和变化率，虽然这可能需要更定期的测量和更复杂的数据收集，但我们可以通过观察跨时间的动态影响来获得最可行的信号。

对于资源较少的组织，主管可以定期对其直接下属绩效的趋势和变化进行评级，而不是平均过去六个月的绩效。

说白了，工程师绩效指标没有良方或黄金标准，最好是将指标本企业化，以适应企业工作和业务环境。

找到更准确和公平的评估组织工程绩效的方法可以对员工敬业度、人才保留和公司整体绩效产生重大影响。实施定期评估，为你的工程师确定正确的评估指标可以帮助你充分利用你的组织所拥有的人才。

作者：Dice Guest