作者：Ashwin Raghav Mohan Ganesh, Harsha Vardhan Mudumba Venkata
译者 | 明知山
策划 | 丁晓昀
人力资源经理在评估软件工程师的绩效时，他们常常依赖一套已有的指标，相信这些指标能够有意义地评估工程师的绩效。然而，这些指标有时候并未能全面地展现工程师日常职责以及他们对项目的实际贡献。
考虑这样的一种情景：一位工程师对数百万用户使用的产品的关键组件进行了修改。从字面上看，这似乎影响了大量用户群体，但实际情况可能完全不同。
事实上，尽管大多数绩效评估指南试图使用可直接与个人相关联的指标，但在工程师角色和技能的背景下，这些指标真正所代表的含义常常缺乏清晰性和可解释性。
在评估客户端工程师的绩效时，这种不足尤为突出。用于评估他们绩效的指标并不像用于评估服务端工程师的指标那样具有充分的可解释性，因此可能存在评估差异。
本文将深入探讨用于评估客户端工程师绩效的指标、这些指标的含义以及它们无法代表的东西。
我们的目标是为开发全栈软件的企业在制定绩效评估指南时提供更全面的视角，确保对工程师的贡献和影响进行更平衡和公正的评估。
这份文档涉及什么以及不涉及什么
现如今，大多数可用的绩效评估指南都围绕着几个基本要素展开。这些要素虽然在不同组织中表达方式各异，但其核心本质基本一致。
- 首先，企业通常是基于工程师的影响或其他与影响相关的要素来评估工程师的。评估从衡量他们的工作和贡献的涟漪效应开始。
- 其次，作为计算机科学的实践者，企业期望工程师解决复杂的计算机科学问题，为企业提供持久的优势。人们默许地认为解决问题的能力是他们的核心。
- 第三，工程师的职责随不同级别资历的变化而变化。随着他们在企业阶梯上升，他们的影响力和领导力会无缝地融入评估框架中，成为评估高层级成长的重要标志。
虽然大多数评估标准也包含基于团队合作和其他类似属性的指标，但这些通常争议较少，并且更容易在不同技术领域的工程师之间进行校准。因此，本文不会深入探讨这些方面，而是着重关注上述要素。
下面的部分将重点介绍一些我们认为可以用来评估客户端工程师绩效的指标。对于每一个指标，我们将强调相关的工程影响，讨论固有的技术复杂性，并提供示例来演示如何有效地使用这些参数来将贡献置于相关的上下文中。
采用率/规模
首先让我们直面问题。用于衡量客户端工程师工作成果的指标通常围绕他们所开发功能的采用率、参与度或留存率。
现在，我们停下来思考一下。一些产品指标，如安装量或日活跃用户，可能并不总能反映出工程师的才华（或者有时候也能反映？）。关键在于要跨不同的团队对评估指标进行精细的校准。必须将其与用于后端工程师评估的其他指标结合起来，这些指标可能并不总能反映他们的专业知识，它们只是体现了产品的增长。
但不要被误导了。这些指标所展示的规模当中存在着巨大的与之相关的工程挑战。克服这些挑战应该成为他们绩效评估的标准，而不仅仅是增长或华丽的数字本身。
|
产品指标 | 它代表什么 | 它不代表什么 | 示例 |
| 庞大的应用程序安装量或使用量通常意味着一些事情：
|
|
|
应用程序健康状态和稳定性
|
产品指标 | 它代表什么 | 它不代表什么 | 示例 |
程序崩溃 | 程序崩溃的减少（或超过 99% 无崩溃）意味着：
|
应用程序不发生崩溃也可能是因为它本身就很简单。这些指标需要与产品支持的流程和功能数量一起进行校准。 | Maya将支持 4 种不同身份验证登录流程的崩溃率从每天 1 万次降低到了不到 1 千次。 |
|
|
| |
热修复 | 适度数量的热修复通常意味着：
|
Kriti设计了一个在客户端允许我们在后端远程配置客户端参数而无需重新发布应用程序的实验框架，并且不违反应用商店的政策。我们平均每个季度的热修复数量已从 6 个降至少于 2 个。 | |
后端错误 (4XX) (以及其他后端指标) | 后端错误率的降低可能意味着：
|
Indra经历了一个辛苦的过程来理解是什么情况导致客户端发送错误参数并在后端触发了 400 错误。这使我们值班时的误报率降低了30%以上。 |
产品卓越
客户端应用程序是大多数在线应用的主要接触点。虽然这部分涵盖了产品的卓越性，但其目的是强调快速发布、可访问性、及时的错误解决和整体客户满意度之间的直接联系。
|
指标 | 它代表什么 | 它不代表什么 |
外部问题修复 | 尽管这可能被视为一种虚荣指标，但对于面临用户报告问题的开源客户端应用程序来说，它通常具有重大意义。这个指标强调了处理和解决这些问题的重要性，有助于维护和提升项目在开源社区中的可靠性和声誉。 |
|
发布次数 | 频繁的发布意味着：
|
|
NPS/CSAT | 尽管客户满意度调查具有通用性，但通常会受到客户端应用程序的影响。应用程序是用户与服务之间的第一个、最具体且频繁的互动。
|
|
可访问性/可用性指标 |
|
结论
有那么一段时间，与一些后端工程师相比，客户端工程师被认为不是那么专业。后端工程师经常回避客户端工程工作，因为客户端工程被视为一种次要、更容易的软件工程形式，其重点是表面的东西，而非正确性和软件质量。尽管随着无服务器应用程序和 SaaS 后端的兴起，这种观点在过去五年里发生了显著变化，但残余仍然存在。
即使这些观点正在得到纠正，作为管理者，我们需要确保我们的个人偏见不会影响我们的决策，尤其是当我们的决策深刻影响客户端工程师的职业生涯和福祉时。本文讨论的指标旨在为确保企业更加公平对待客户端工程师提供一个基本的出发点。
本文转载来源：
不只看数字：软件开发企业如何评估客户端工程师绩效_研发效能_InfoQ精选文章
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。