不只看數(shù)字：軟件開發(fā)企業(yè)如何評估客戶端工程師績效（軟件開發(fā)人員績效考核辦法）
作者：Ashwin Raghav Mohan Ganesh, Harsha Vardhan Mudumba Venkata
譯者 | 明知山
策劃 | 丁曉昀
人力資源經(jīng)理在評估軟件工程師的績效時，他們常常依賴一套已有的指標(biāo)，相信這些指標(biāo)能夠有意義地評估工程師的績效。然而，這些指標(biāo)有時候并未能全面地展現(xiàn)工程師日常職責(zé)以及他們對項目的實際貢獻。
考慮這樣的一種情景：一位工程師對數(shù)百萬用戶使用的產(chǎn)品的關(guān)鍵組件進行了修改。從字面上看，這似乎影響了大量用戶群體，但實際情況可能完全不同。
事實上，盡管大多數(shù)績效評估指南試圖使用可直接與個人相關(guān)聯(lián)的指標(biāo)，但在工程師角色和技能的背景下，這些指標(biāo)真正所代表的含義常常缺乏清晰性和可解釋性。
在評估客戶端工程師的績效時，這種不足尤為突出。用于評估他們績效的指標(biāo)并不像用于評估服務(wù)端工程師的指標(biāo)那樣具有充分的可解釋性，因此可能存在評估差異。
本文將深入探討用于評估客戶端工程師績效的指標(biāo)、這些指標(biāo)的含義以及它們無法代表的東西。
我們的目標(biāo)是為開發(fā)全棧軟件的企業(yè)在制定績效評估指南時提供更全面的視角，確保對工程師的貢獻和影響進行更平衡和公正的評估。
這份文檔涉及什么以及不涉及什么
現(xiàn)如今，大多數(shù)可用的績效評估指南都圍繞著幾個基本要素展開。這些要素雖然在不同組織中表達(dá)方式各異，但其核心本質(zhì)基本一致。
- 首先，企業(yè)通常是基于工程師的影響或其他與影響相關(guān)的要素來評估工程師的。評估從衡量他們的工作和貢獻的漣漪效應(yīng)開始。
- 其次，作為計算機科學(xué)的實踐者，企業(yè)期望工程師解決復(fù)雜的計算機科學(xué)問題，為企業(yè)提供持久的優(yōu)勢。人們默許地認(rèn)為解決問題的能力是他們的核心。
- 第三，工程師的職責(zé)隨不同級別資歷的變化而變化。隨著他們在企業(yè)階梯上升，他們的影響力和領(lǐng)導(dǎo)力會無縫地融入評估框架中，成為評估高層級成長的重要標(biāo)志。
雖然大多數(shù)評估標(biāo)準(zhǔn)也包含基于團隊合作和其他類似屬性的指標(biāo)，但這些通常爭議較少，并且更容易在不同技術(shù)領(lǐng)域的工程師之間進行校準(zhǔn)。因此，本文不會深入探討這些方面，而是著重關(guān)注上述要素。
下面的部分將重點介紹一些我們認(rèn)為可以用來評估客戶端工程師績效的指標(biāo)。對于每一個指標(biāo)，我們將強調(diào)相關(guān)的工程影響，討論固有的技術(shù)復(fù)雜性，并提供示例來演示如何有效地使用這些參數(shù)來將貢獻置于相關(guān)的上下文中。
采用率/規(guī)模
首先讓我們直面問題。用于衡量客戶端工程師工作成果的指標(biāo)通常圍繞他們所開發(fā)功能的采用率、參與度或留存率。
現(xiàn)在，我們停下來思考一下。一些產(chǎn)品指標(biāo)，如安裝量或日活躍用戶，可能并不總能反映出工程師的才華（或者有時候也能反映？）。關(guān)鍵在于要跨不同的團隊對評估指標(biāo)進行精細(xì)的校準(zhǔn)。必須將其與用于后端工程師評估的其他指標(biāo)結(jié)合起來，這些指標(biāo)可能并不總能反映他們的專業(yè)知識，它們只是體現(xiàn)了產(chǎn)品的增長。
但不要被誤導(dǎo)了。這些指標(biāo)所展示的規(guī)模當(dāng)中存在著巨大的與之相關(guān)的工程挑戰(zhàn)?？朔@些挑戰(zhàn)應(yīng)該成為他們績效評估的標(biāo)準(zhǔn)，而不僅僅是增長或華麗的數(shù)字本身。
|
產(chǎn)品指標(biāo) | 它代表什么 | 它不代表什么 | 示例 |
| 龐大的應(yīng)用程序安裝量或使用量通常意味著一些事情：
|
|
|
應(yīng)用程序健康狀態(tài)和穩(wěn)定性
|
產(chǎn)品指標(biāo) | 它代表什么 | 它不代表什么 | 示例 |
程序崩潰 | 程序崩潰的減少（或超過 99% 無崩潰）意味著：
|
應(yīng)用程序不發(fā)生崩潰也可能是因為它本身就很簡單。這些指標(biāo)需要與產(chǎn)品支持的流程和功能數(shù)量一起進行校準(zhǔn)。 | Maya將支持 4 種不同身份驗證登錄流程的崩潰率從每天 1 萬次降低到了不到 1 千次。 |
|
|
| |
熱修復(fù) | 適度數(shù)量的熱修復(fù)通常意味著：
|
Kriti設(shè)計了一個在客戶端允許我們在后端遠(yuǎn)程配置客戶端參數(shù)而無需重新發(fā)布應(yīng)用程序的實驗框架，并且不違反應(yīng)用商店的政策。我們平均每個季度的熱修復(fù)數(shù)量已從 6 個降至少于 2 個。 | |
后端錯誤 (4XX) (以及其他后端指標(biāo)) | 后端錯誤率的降低可能意味著：
|
Indra經(jīng)歷了一個辛苦的過程來理解是什么情況導(dǎo)致客戶端發(fā)送錯誤參數(shù)并在后端觸發(fā)了 400 錯誤。這使我們值班時的誤報率降低了30%以上。 |
產(chǎn)品卓越
客戶端應(yīng)用程序是大多數(shù)在線應(yīng)用的主要接觸點。雖然這部分涵蓋了產(chǎn)品的卓越性，但其目的是強調(diào)快速發(fā)布、可訪問性、及時的錯誤解決和整體客戶滿意度之間的直接聯(lián)系。
|
指標(biāo) | 它代表什么 | 它不代表什么 |
外部問題修復(fù) | 盡管這可能被視為一種虛榮指標(biāo)，但對于面臨用戶報告問題的開源客戶端應(yīng)用程序來說，它通常具有重大意義。這個指標(biāo)強調(diào)了處理和解決這些問題的重要性，有助于維護和提升項目在開源社區(qū)中的可靠性和聲譽。 |
|
發(fā)布次數(shù) | 頻繁的發(fā)布意味著：
|
|
NPS/CSAT | 盡管客戶滿意度調(diào)查具有通用性，但通常會受到客戶端應(yīng)用程序的影響。應(yīng)用程序是用戶與服務(wù)之間的第一個、最具體且頻繁的互動。
|
|
可訪問性/可用性指標(biāo) |
|
結(jié)論
有那么一段時間，與一些后端工程師相比，客戶端工程師被認(rèn)為不是那么專業(yè)。后端工程師經(jīng)?；乇芸蛻舳斯こ坦ぷ鳎驗榭蛻舳斯こ瘫灰暈橐环N次要、更容易的軟件工程形式，其重點是表面的東西，而非正確性和軟件質(zhì)量。盡管隨著無服務(wù)器應(yīng)用程序和 SaaS 后端的興起，這種觀點在過去五年里發(fā)生了顯著變化，但殘余仍然存在。
即使這些觀點正在得到糾正，作為管理者，我們需要確保我們的個人偏見不會影響我們的決策，尤其是當(dāng)我們的決策深刻影響客戶端工程師的職業(yè)生涯和福祉時。本文討論的指標(biāo)旨在為確保企業(yè)更加公平對待客戶端工程師提供一個基本的出發(fā)點。
本文轉(zhuǎn)載來源：
