人力资源经理在评估软件工程师的绩效时，他们常常依赖一套已有的指标，相信这些指标能够有意义地评估工程师的绩效。然而，这些指标有时候并未能全面地展现工程师日常职责以及他们对项目的实际贡献。
考虑这样的一种情景：一位工程师对数百万用户使用的产品的关键组件进行了修改。从字面上看，这似乎影响了大量用户群体，但实际情况可能完全不同。
事实上，尽管大多数绩效评估指南试图使用可直接与个人相关联的指标，但在工程师角色和技能的背景下，这些指标真正所代表的含义常常缺乏清晰性和可解释性。
在评估客户端工程师的绩效时，这种不足尤为突出。用于评估他们绩效的指标并不像用于评估服务端工程师的指标那样具有充分的可解释性，因此可能存在评估差异。
本文将深入探讨用于评估客户端工程师绩效的指标、这些指标的含义以及它们无法代表的东西。
我们的目标是为开发全栈软件的企业在制定绩效评估指南时提供更全面的视角，确保对工程师的贡献和影响进行更平衡和公正的评估。
这份文档涉及什么以及不涉及什么
现如今，大多数可用的绩效评估指南都围绕着几个基本要素展开。这些要素虽然在不同组织中表达方式各异，但其核心本质基本一致。
首先，企业通常是基于工程师的影响或其他与影响相关的要素来评估工程师的。评估从衡量他们的工作和贡献的涟漪效应开始。
其次，作为计算机科学的实践者，企业期望工程师解决复杂的计算机科学问题，为企业提供持久的优势。人们默许地认为解决问题的能力是他们的核心。
第三，工程师的职责随不同级别资历的变化而变化。随着他们在企业阶梯上升，他们的影响力和领导力会无缝地融入评估框架中，成为评估高层级成长的重要标志。
虽然大多数评估标准也包含基于团队合作和其他类似属性的指标，但这些通常争议较少，并且更容易在不同技术领域的工程师之间进行校准。因此，本文不会深入探讨这些方面，而是着重关注上述要素。
下面的部分将重点介绍一些我们认为可以用来评估客户端工程师绩效的指标。对于每一个指标，我们将强调相关的工程影响，讨论固有的技术复杂性，并提供示例来演示如何有效地使用这些参数来将贡献置于相关的上下文中。
采用率/规模
首先让我们直面问题。用于衡量客户端工程师工作成果的指标通常围绕他们所开发功能的采用率、参与度或留存率。
现在，我们停下来思考一下。一些产品指标，如安装量或日活跃用户，可能并不总能反映出工程师的才华（或者有时候也能反映？）。关键在于要跨不同的团队对评估指标进行精细的校准。必须将其与用于后端工程师评估的其他指标结合起来，这些指标可能并不总能反映他们的专业知识，它们只是体现了产品的增长。
但不要被误导了。这些指标所展示的规模当中存在着巨大的与之相关的工程挑战。克服这些挑战应该成为他们绩效评估的标准，而不仅仅是增长或华丽的数字本身。
产品指标 | 它代表什么 | 它不代表什么 | 示例 |
| 庞大的应用程序安装量或使用量通常意味着一些事情：
- 它表明了产品经过精心设计的实现，特别是在 Web 和 Android 平台上。在这些平台上兼容各种底层 API 和浏览器版本的复杂迷宫本身就是一个值得赞扬的成就。
- 它标志着产品能够在各种地理位置之间有效运行，每个地区都有其独特的互联网连接、隐私/法律规定和手机制造商。
- 它表明产品更好地适配了 Android 硬件的碎片化，以及存在于 Apple 平台上的多种形态因素（如 MacOS、tvOS、watchOS 等）。
- 它体现了工程师解决不常见设备和浏览器上的微妙 bug 的能力。
- 它强调了工程师在保护生态系统健康方面所起到的关键作用，特别是对于那些真正无处不在的应用程序(十亿安装量)以及可能造成系统范围灾难的应用程序来说。
| - 与普遍看法相反，十亿次安装并不能有效地衡量客户端工程师在构建新兴产品方面的能力。
- 用更轻松的语气来说，这就像构建一个每秒提供 50 万个查询的后端 API。虽然令人印象深刻，但并不是工程师能力的唯一标志，也不是产品整体活力和增长轨迹的明确衡量指标。
- 如果缺乏可靠的质量指标的支持（下文有详述），那么安装量指标就有点像一个没有披风的超级英雄。当然，它看起来很华丽，可能会给你带来一些街头信誉，但这还不足以真正拯救世界。单独来看，它主要只是炫耀产品增长，缺乏真正展示影响力的深度。所以，我们不要让它在没有全副武装的情况下投入战斗，好吗？
| - Mitra改进了我们的文本编辑器，使其能够在小众 Android 厂商设备上运行，为我们1亿DAU的产品扩大了1%的用户群。
- Akira在 Web 标准上的贡献促进了我们从 2K 用户的私人预览向跨浏览器 1 百万用户公共预览的转变。
- Mireya使用 C++ 实现了核心的移动功能，使我们能够在推出 Android 后仅两个月就推出 iOS 应用，增加了 1 百万日活跃用户。
- Ila对 Apple 平台 API 的深入了解使我们能够在 WWDC 发布后两周内向 10 万用户推出 Apple Silicon 版本的应用。
- 由于 Laya 解决了影响数千名没有模拟功能的 Android 用户的 bug，我们在印度的客户满意度评分提高了 3% 。
- Amal对本地存储的优化是让高级用户在连续30天内高度参与产品而不会耗尽磁盘空间的关键。
|
应用程序健康状态和稳定性
产品指标 | 它代表什么 | 它不代表什么 | 示例 |
程序崩溃 | 程序崩溃的减少（或超过 99% 无崩溃）意味着：
- 展示了工程师有远见和严谨的工程能力，他们提供了出色的客户端软件，相比后端，客户端软件更加难以回滚。
- 遵循了 Web、Apple 和 Android 平台不断变化的最佳实践。
- 能够构建在不同计算环境中无缝运行的软件，这对于 Android 来说尤为重要。这突显了团队的技术多样性和对各种计算环境的深入理解，确保了所有平台上的最佳功能和用户体验。
| 应用程序不发生崩溃也可能是因为它本身就很简单。这些指标需要与产品支持的流程和功能数量一起进行校准。
| Maya将支持 4 种不同身份验证登录流程的崩溃率从每天 1 万次降低到了不到 1 千次。 |
| - 大多数生产级应用程序都具有复杂的启动路径，不仅涉及业务逻辑的初始化，还有一系列复杂的依赖项。快速启动对于留住用户来说至关重要。对P95冷启动的任何实质性改进都需要细致的分析、建立假设和严格的实验。
- 具有合理内存占用的应用程序表明采用了工程最佳实践，例如高效加载实体和重用对象。这在拥有大量低端设备的Android平台上尤为重要。
- 与 Web 工程相比，原生移动开发的一个痛点是相对较长的编译时间。能够显著缩短编译时间的努力将在开发者生产力方面产生多重效应。这可以通过缓存构建工件、优化依赖关系（消除无关依赖项）和使用库动态链接等方法来实现。
|
| - Alice在过去的6个月里将iOS冷启动的P95降低了25%。Alice通过仔细分析启动路径和延迟加载初始屏幕不需要的库实现了这一点。
- Yu重写了视图模型缓存。这提高了内存利用率，并在过去6个月内减少了15%的OOM崩溃。
|
热修复 | 适度数量的热修复通常意味着：
- 稳定、高水准的发布，能够经受住用户需求和技术挑战的考验，展示出对交付卓越、可靠软件解决方案的承诺。
- 深思熟虑的实验标志，突显了对功能测试和实现的战略性方法，进一步增强了软件的韧性和以用户为中心的设计。
|
| Kriti设计了一个在客户端允许我们在后端远程配置客户端参数而无需重新发布应用程序的实验框架，并且不违反应用商店的政策。我们平均每个季度的热修复数量已从 6 个降至少于 2 个。
|
后端错误 (4XX) (以及其他后端指标) | 后端错误率的降低可能意味着：
- 客户端实现的更正，减少了错误的 RPC。这表明系统通信和协调得到了改善。
- 提高了客户端的可配置性，允许在启动后进行参数调整，确保更好的性能和对项目需求和问题的响应。
|
| Indra经历了一个辛苦的过程来理解是什么情况导致客户端发送错误参数并在后端触发了 400 错误。这使我们值班时的误报率降低了30%以上。 |
产品卓越
客户端应用程序是大多数在线应用的主要接触点。虽然这部分涵盖了产品的卓越性，但其目的是强调快速发布、可访问性、及时的错误解决和整体客户满意度之间的直接联系。
指标 | 它代表什么 | 它不代表什么 |
外部问题修复 | 尽管这可能被视为一种虚荣指标，但对于面临用户报告问题的开源客户端应用程序来说，它通常具有重大意义。这个指标强调了处理和解决这些问题的重要性，有助于维护和提升项目在开源社区中的可靠性和声誉。 | - 对于习惯宣告大规模 Bug 被消除的团队，这个指标失去了效力。如果大量 Bug 经常被一笔勾销而不加以解决，那么它就不能作为可靠的绩效和改进衡量指标。
|
发布次数 | 频繁的发布意味着：
- 持续的 Bug 修复和改进，体现了改善产品并确保其可靠性和有效性的承诺。
- 提高了发布能力，克服了历史上的挑战，并展示了改进的更有效率的发布流程。
- 努力与生态系统的其他部分保持同步，包括依赖项和平台更新，确保产品保持最新、安全，并与生态系统的其他元素兼容。
| - 大量的发布也可能源于不稳定性，说明需要进行频繁更新来解决持续出现的问题，并确保产品安预期运行。
- 这一观点强调了在产品稳定性与发布频率之间取得平衡的重要性，避免对团队和最终用户造成过重的负担。
|
NPS/CSAT | 尽管客户满意度调查具有通用性，但通常会受到客户端应用程序的影响。应用程序是用户与服务之间的第一个、最具体且频繁的互动。
- 相反，出色的应用体验可以弥补服务特性、性能和价格方面的不足，给客户留下积极而持久的印象，有助于培养忠诚度和满意度。
|
|
可访问性/可用性指标 | - 努力打造一款无障碍、包容的产品，供听力、视力、行动能力或语言障碍人士使用。
|
|
结论
有那么一段时间，与一些后端工程师相比，客户端工程师被认为不是那么专业。后端工程师经常回避客户端工程工作，因为客户端工程被视为一种次要、更容易的软件工程形式，其重点是表面的东西，而非正确性和软件质量。尽管随着无服务器应用程序和 SaaS 后端的兴起，这种观点在过去五年里发生了显著变化，但残余仍然存在。
即使这些观点正在得到纠正，作为管理者，我们需要确保我们的个人偏见不会影响我们的决策，尤其是当我们的决策深刻影响客户端工程师的职业生涯和福祉时。本文讨论的指标旨在为确保企业更加公平对待客户端工程师提供一个基本的出发点。
原文链接：
https://www.infoq.com/articles/client-side-engineering-metrics/
评论