作者 | 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 十倍降本方案！
網際網路大廠「組團」宕機，都怪降本增「笑」？