原标题：年底了，怎么为客户端工程师“卷”绩效？

作者 | Ashwin Raghav Mohan Ganesh, Harsha Vardhan Mudumba Venkata

译者 | 明知山

策划 | Tina

人力资源经理在评估软件工程师的绩效时，他们常常依赖一套已有的指标，相信这些指标能够有意义地评估工程师的绩效。然而，这些指标有时候并未能全面地展现工程师日常职责以及他们对项目的实际贡献。

考虑这样的一种情景：一位工程师对数百万用户使用的产品的关键组件进行了修改。从字面上看，这似乎影响了大量用户群体，但实际情况可能完全不同。

事实上，尽管大多数绩效评估指南试图使用可直接与个人相关联的指标，但在工程师角色和技能的背景下，这些指标真正所代表的含义常常缺乏清晰性和可解释性。

在评估客户端工程师的绩效时，这种不足尤为突出。用于评估他们绩效的指标并不像用于评估服务端工程师的指标那样具有充分的可解释性，因此可能存在评估差异。

本文将深入探讨用于评估客户端工程师绩效的指标、这些指标的含义以及它们无法代表的东西。

我们的目标是为开发全栈软件的企业在制定绩效评估指南时提供更全面的视角，确保对工程师的贡献和影响进行更平衡和公正的评估。

这份文档涉及什么以及不涉及什么

现如今，大多数可用的绩效评估指南都围绕着几个基本要素展开。这些要素虽然在不同组织中表达方式各异，但其核心本质基本一致。

• 首先，企业通常是基于工程师的影响或其他与影响相关的要素来评估工程师的。评估从衡量他们的工作和贡献的涟漪效应开始。
• 其次，作为计算机科学的实践者，企业期望工程师解决复杂的计算机科学问题，为企业提供持久的优势。人们默许地认为解决问题的能力是他们的核心。
• 第三，工程师的职责随不同级别资历的变化而变化。随着他们在企业阶梯上升，他们的影响力和领导力会无缝地融入评估框架中，成为评估高层级成长的重要标志。虽然大多数评估标准也包含基于团队合作和其他类似属性的指标，但这些通常争议较少，并且更容易在不同技术领域的工程师之间进行校准。因此，本文不会深入探讨这些方面，而是着重关注上述要素。

下面的部分将重点介绍一些我们认为可以用来评估客户端工程师绩效的指标。对于每一个指标，我们将强调相关的工程影响，讨论固有的技术复杂性，并提供示例来演示如何有效地使用这些参数来将贡献置于相关的上下文中。

采用率 / 规模

首先让我们直面问题。用于衡量客户端工程师工作成果的指标通常围绕他们所开发功能的采用率、参与度或留存率。

现在，我们停下来思考一下。一些产品指标，如安装量或日活跃用户，可能并不总能反映出工程师的才华（或者有时候也能反映？）。关键在于要跨不同的团队对评估指标进行精细的校准。必须将其与用于后端工程师评估的其他指标结合起来，这些指标可能并不总能反映他们的专业知识，它们只是体现了产品的增长。

但不要被误导了。这些指标所展示的规模当中存在着巨大的与之相关的工程挑战。克服这些挑战应该成为他们绩效评估的标准，而不仅仅是增长或华丽的数字本身。

应用程序健康状态和稳定性

产品卓越

客户端应用程序是大多数在线应用的主要接触点。虽然这部分涵盖了产品的卓越性，但其目的是强调快速发布、可访问性、及时的错误解决和整体客户满意度之间的直接联系。

结 论

有那么一段时间，与一些后端工程师相比，客户端工程师被认为不是那么专业。后端工程师经常回避客户端工程工作，因为客户端工程被视为一种次要、更容易的软件工程形式，其重点是表面的东西，而非正确性和软件质量。尽管随着无服务器应用程序和 SaaS 后端的兴起，这种观点在过去五年里发生了显著变化，但残余仍然存在。

即使这些观点正在得到纠正，作为管理者，我们需要确保我们的个人偏见不会影响我们的决策，尤其是当我们的决策深刻影响客户端工程师的职业生涯和福祉时。本文讨论的指标旨在为确保企业更加公平对待客户端工程师提供一个基本的出发点。

英文原文：

https://www.infoq.com/articles/client-side-engineering-metrics/

百度 8500 万挖不来“AI 教父”；淘天年薪百万起步抢全球顶尖人才，上不封顶；王慧文病休后首次动作：AI 投资｜Q资讯

优秀开发者能编码到70岁！Linus Torvalds：Linux是个能留住人的社区，许多顶级Linux内核维护者即将步入60岁

上云还是下云：章文嵩博士解读真正的云原生 Kafka 十倍降本方案！

互联网大厂“组团”宕机，都怪降本增“笑”？