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

譯者 | 明知山

策劃 | 丁曉昀

人力資源經(jīng)理在評(píng)估軟件工程師的績(jī)效時(shí)，他們常常依賴一套已有的指標(biāo)，相信這些指標(biāo)能夠有意義地評(píng)估工程師的績(jī)效。然而，這些指標(biāo)有時(shí)候并未能全面地展現(xiàn)工程師日常職責(zé)以及他們對(duì)項(xiàng)目的實(shí)際貢獻(xiàn)。

考慮這樣的一種情景：一位工程師對(duì)數(shù)百萬用戶使用的產(chǎn)品的關(guān)鍵組件進(jìn)行了修改。從字面上看，這似乎影響了大量用戶群體，但實(shí)際情況可能完全不同。

事實(shí)上，盡管大多數(shù)績(jī)效評(píng)估指南試圖使用可直接與個(gè)人相關(guān)聯(lián)的指標(biāo)，但在工程師角色和技能的背景下，這些指標(biāo)真正所代表的含義常常缺乏清晰性和可解釋性。

在評(píng)估客戶端工程師的績(jī)效時(shí)，這種不足尤為突出。用于評(píng)估他們績(jī)效的指標(biāo)并不像用于評(píng)估服務(wù)端工程師的指標(biāo)那樣具有充分的可解釋性，因此可能存在評(píng)估差異。

本文將深入探討用于評(píng)估客戶端工程師績(jī)效的指標(biāo)、這些指標(biāo)的含義以及它們無法代表的東西。

我們的目標(biāo)是為開發(fā)全棧軟件的企業(yè)在制定績(jī)效評(píng)估指南時(shí)提供更全面的視角，確保對(duì)工程師的貢獻(xiàn)和影響進(jìn)行更平衡和公正的評(píng)估。

這份文檔涉及什么以及不涉及什么

現(xiàn)如今，大多數(shù)可用的績(jī)效評(píng)估指南都圍繞著幾個(gè)基本要素展開。這些要素雖然在不同組織中表達(dá)方式各異，但其核心本質(zhì)基本一致。

首先，企業(yè)通常是基于工程師的影響或其他與影響相關(guān)的要素來評(píng)估工程師的。評(píng)估從衡量他們的工作和貢獻(xiàn)的漣漪效應(yīng)開始。
其次，作為計(jì)算機(jī)科學(xué)的實(shí)踐者，企業(yè)期望工程師解決復(fù)雜的計(jì)算機(jī)科學(xué)問題，為企業(yè)提供持久的優(yōu)勢(shì)。人們默許地認(rèn)為解決問題的能力是他們的核心。
第三，工程師的職責(zé)隨不同級(jí)別資歷的變化而變化。隨著他們?cè)谄髽I(yè)階梯上升，他們的影響力和領(lǐng)導(dǎo)力會(huì)無縫地融入評(píng)估框架中，成為評(píng)估高層級(jí)成長(zhǎng)的重要標(biāo)志。

雖然大多數(shù)評(píng)估標(biāo)準(zhǔn)也包含基于團(tuán)隊(duì)合作和其他類似屬性的指標(biāo)，但這些通常爭(zhēng)議較少，并且更容易在不同技術(shù)領(lǐng)域的工程師之間進(jìn)行校準(zhǔn)。因此，本文不會(huì)深入探討這些方面，而是著重關(guān)注上述要素。

下面的部分將重點(diǎn)介紹一些我們認(rèn)為可以用來評(píng)估客戶端工程師績(jī)效的指標(biāo)。對(duì)于每一個(gè)指標(biāo)，我們將強(qiáng)調(diào)相關(guān)的工程影響，討論固有的技術(shù)復(fù)雜性，并提供示例來演示如何有效地使用這些參數(shù)來將貢獻(xiàn)置于相關(guān)的上下文中。

采用率/規(guī)模

首先讓我們直面問題。用于衡量客戶端工程師工作成果的指標(biāo)通常圍繞他們所開發(fā)功能的采用率、參與度或留存率。

現(xiàn)在，我們停下來思考一下。一些產(chǎn)品指標(biāo)，如安裝量或日活躍用戶，可能并不總能反映出工程師的才華（或者有時(shí)候也能反映？）。關(guān)鍵在于要跨不同的團(tuán)隊(duì)對(duì)評(píng)估指標(biāo)進(jìn)行精細(xì)的校準(zhǔn)。必須將其與用于后端工程師評(píng)估的其他指標(biāo)結(jié)合起來，這些指標(biāo)可能并不總能反映他們的專業(yè)知識(shí)，它們只是體現(xiàn)了產(chǎn)品的增長(zhǎng)。

但不要被誤導(dǎo)了。這些指標(biāo)所展示的規(guī)模當(dāng)中存在著巨大的與之相關(guān)的工程挑戰(zhàn)。克服這些挑戰(zhàn)應(yīng)該成為他們績(jī)效評(píng)估的標(biāo)準(zhǔn)，而不僅僅是增長(zhǎng)或華麗的數(shù)字本身。

產(chǎn)品指標(biāo)

它代表什么

它不代表什么

示例

安裝量

[每日|每月] 活躍用戶

第[7|30]天留存率

龐大的應(yīng)用程序安裝量或使用量通常意味著一些事情：

它表明了產(chǎn)品經(jīng)過精心設(shè)計(jì)的實(shí)現(xiàn)，特別是在 Web 和 Android 平臺(tái)上。在這些平臺(tái)上兼容各種底層 API 和瀏覽器版本的復(fù)雜迷宮本身就是一個(gè)值得贊揚(yáng)的成就。

它標(biāo)志著產(chǎn)品能夠在各種地理位置之間有效運(yùn)行，每個(gè)地區(qū)都有其獨(dú)特的互聯(lián)網(wǎng)連接、隱私/法律規(guī)定和手機(jī)制造商。

它表明產(chǎn)品更好地適配了 Android 硬件的碎片化，以及存在于 Apple 平臺(tái)上的多種形態(tài)因素（如 MacOS、tvOS、watchOS 等）。

它體現(xiàn)了工程師解決不常見設(shè)備和瀏覽器上的微妙 bug 的能力。

它強(qiáng)調(diào)了工程師在保護(hù)生態(tài)系統(tǒng)健康方面所起到的關(guān)鍵作用，特別是對(duì)于那些真正無處不在的應(yīng)用程序(十億安裝量)以及可能造成系統(tǒng)范圍災(zāi)難的應(yīng)用程序來說。

與普遍看法相反，十億次安裝并不能有效地衡量客戶端工程師在構(gòu)建新興產(chǎn)品方面的能力。

用更輕松的語氣來說，這就像構(gòu)建一個(gè)每秒提供 50 萬個(gè)查詢的后端 API。雖然令人印象深刻，但并不是工程師能力的唯一標(biāo)志，也不是產(chǎn)品整體活力和增長(zhǎng)軌跡的明確衡量指標(biāo)。

如果缺乏可靠的質(zhì)量指標(biāo)的支持（下文有詳述），那么安裝量指標(biāo)就有點(diǎn)像一個(gè)沒有披風(fēng)的超級(jí)英雄。當(dāng)然，它看起來很華麗，可能會(huì)給你帶來一些街頭信譽(yù)，但這還不足以真正拯救世界。單獨(dú)來看，它主要只是炫耀產(chǎn)品增長(zhǎng)，缺乏真正展示影響力的深度。所以，我們不要讓它在沒有全副武裝的情況下投入戰(zhàn)斗，好嗎？

Mitra改進(jìn)了我們的文本編輯器，使其能夠在小眾 Android 廠商設(shè)備上運(yùn)行，為我們1億DAU的產(chǎn)品擴(kuò)大了1%的用戶群。

Akira在 Web 標(biāo)準(zhǔn)上的貢獻(xiàn)促進(jìn)了我們從 2K 用戶的私人預(yù)覽向跨瀏覽器 1 百萬用戶公共預(yù)覽的轉(zhuǎn)變。

Mireya使用 C 實(shí)現(xiàn)了核心的移動(dòng)功能，使我們能夠在推出 Android 后僅兩個(gè)月就推出 iOS 應(yīng)用，增加了 1 百萬日活躍用戶。

Ila對(duì) Apple 平臺(tái) API 的深入了解使我們能夠在 WWDC 發(fā)布后兩周內(nèi)向 10 萬用戶推出 Apple Silicon 版本的應(yīng)用。

由于 Laya 解決了影響數(shù)千名沒有模擬功能的 Android 用戶的 bug，我們?cè)?span id="gg8g4gg" class="candidate-entity-word" data-gid="6734470534952988427">印度的客戶滿意度評(píng)分提高了 3% 。

Amal對(duì)本地存儲(chǔ)的優(yōu)化是讓高級(jí)用戶在連續(xù)30天內(nèi)高度參與產(chǎn)品而不會(huì)耗盡磁盤空間的關(guān)鍵。

應(yīng)用程序健康狀態(tài)和穩(wěn)定性

產(chǎn)品指標(biāo)

它代表什么

它不代表什么

示例

程序崩潰

程序崩潰的減少（或超過 99% 無崩潰）意味著：

展示了工程師有遠(yuǎn)見和嚴(yán)謹(jǐn)?shù)墓こ棠芰Γ麄兲峁┝顺錾目蛻舳塑浖?，相比后端，客戶端軟件更加難以回滾。

遵循了 Web、Apple 和 Android 平臺(tái)不斷變化的最佳實(shí)踐。

能夠構(gòu)建在不同計(jì)算環(huán)境中無縫運(yùn)行的軟件，這對(duì)于 Android 來說尤為重要。這突顯了團(tuán)隊(duì)的技術(shù)多樣性和對(duì)各種計(jì)算環(huán)境的深入理解，確保了所有平臺(tái)上的最佳功能和用戶體驗(yàn)。

應(yīng)用程序不發(fā)生崩潰也可能是因?yàn)樗旧砭秃芎?jiǎn)單。這些指標(biāo)需要與產(chǎn)品支持的流程和功能數(shù)量一起進(jìn)行校準(zhǔn)。

Maya將支持 4 種不同身份驗(yàn)證登錄流程的崩潰率從每天 1 萬次降低到了不到 1 千次。

啟動(dòng)延遲

應(yīng)用程序大小

內(nèi)存占用

構(gòu)建時(shí)間

大多數(shù)生產(chǎn)級(jí)應(yīng)用程序都具有復(fù)雜的啟動(dòng)路徑，不僅涉及業(yè)務(wù)邏輯的初始化，還有一系列復(fù)雜的依賴項(xiàng)?？焖賳?dòng)對(duì)于留住用戶來說至關(guān)重要。對(duì)P95冷啟動(dòng)的任何實(shí)質(zhì)性改進(jìn)都需要細(xì)致的分析、建立假設(shè)和嚴(yán)格的實(shí)驗(yàn)。

具有合理內(nèi)存占用的應(yīng)用程序表明采用了工程最佳實(shí)踐，例如高效加載實(shí)體和重用對(duì)象。這在擁有大量低端設(shè)備的Android平臺(tái)上尤為重要。

與 Web 工程相比，原生移動(dòng)開發(fā)的一個(gè)痛點(diǎn)是相對(duì)較長(zhǎng)的編譯時(shí)間。能夠顯著縮短編譯時(shí)間的努力將在開發(fā)者生產(chǎn)力方面產(chǎn)生多重效應(yīng)。這可以通過緩存構(gòu)建工件、優(yōu)化依賴關(guān)系（消除無關(guān)依賴項(xiàng)）和使用庫動(dòng)態(tài)鏈接等方法來實(shí)現(xiàn)。

Alice在過去的6個(gè)月里將iOS冷啟動(dòng)的P95降低了25%。Alice通過仔細(xì)分析啟動(dòng)路徑和延遲加載初始屏幕不需要的庫實(shí)現(xiàn)了這一點(diǎn)。

Yu重寫了視圖模型緩存。這提高了內(nèi)存利用率，并在過去6個(gè)月內(nèi)減少了15%的OOM崩潰。

熱修復(fù)

適度數(shù)量的熱修復(fù)通常意味著：

穩(wěn)定、高水準(zhǔn)的發(fā)布，能夠經(jīng)受住用戶需求和技術(shù)挑戰(zhàn)的考驗(yàn)，展示出對(duì)交付卓越、可靠軟件解決方案的承諾。

深思熟慮的實(shí)驗(yàn)標(biāo)志，突顯了對(duì)功能測(cè)試和實(shí)現(xiàn)的戰(zhàn)略性方法，進(jìn)一步增強(qiáng)了軟件的韌性和以用戶為中心的設(shè)計(jì)。

Kriti設(shè)計(jì)了一個(gè)在客戶端允許我們?cè)诤蠖诉h(yuǎn)程配置客戶端參數(shù)而無需重新發(fā)布應(yīng)用程序的實(shí)驗(yàn)框架，并且不違反應(yīng)用商店的政策。我們平均每個(gè)季度的熱修復(fù)數(shù)量已從 6 個(gè)降至少于 2 個(gè)。

后端錯(cuò)誤 (4XX) (以及其他后端指標(biāo))

后端錯(cuò)誤率的降低可能意味著：

客戶端實(shí)現(xiàn)的更正，減少了錯(cuò)誤的 RPC。這表明系統(tǒng)通信和協(xié)調(diào)得到了改善。

提高了客戶端的可配置性，允許在啟動(dòng)后進(jìn)行參數(shù)調(diào)整，確保更好的性能和對(duì)項(xiàng)目需求和問題的響應(yīng)。

Indra經(jīng)歷了一個(gè)辛苦的過程來理解是什么情況導(dǎo)致客戶端發(fā)送錯(cuò)誤參數(shù)并在后端觸發(fā)了 400 錯(cuò)誤。這使我們值班時(shí)的誤報(bào)率降低了30%以上。

產(chǎn)品卓越

客戶端應(yīng)用程序是大多數(shù)在線應(yīng)用的主要接觸點(diǎn)。雖然這部分涵蓋了產(chǎn)品的卓越性，但其目的是強(qiáng)調(diào)快速發(fā)布、可訪問性、及時(shí)的錯(cuò)誤解決和整體客戶滿意度之間的直接聯(lián)系。

指標(biāo)

它代表什么

它不代表什么

外部問題修復(fù)

盡管這可能被視為一種虛榮指標(biāo)，但對(duì)于面臨用戶報(bào)告問題的開源客戶端應(yīng)用程序來說，它通常具有重大意義。這個(gè)指標(biāo)強(qiáng)調(diào)了處理和解決這些問題的重要性，有助于維護(hù)和提升項(xiàng)目在開源社區(qū)中的可靠性和聲譽(yù)。

對(duì)于習(xí)慣宣告大規(guī)模 Bug 被消除的團(tuán)隊(duì)，這個(gè)指標(biāo)失去了效力。如果大量 Bug 經(jīng)常被一筆勾銷而不加以解決，那么它就不能作為可靠的績(jī)效和改進(jìn)衡量指標(biāo)。

此外，這個(gè)指標(biāo)基于某種誠(chéng)信假設(shè)。

發(fā)布次數(shù)

頻繁的發(fā)布意味著：

持續(xù)的 Bug 修復(fù)和改進(jìn)，體現(xiàn)了改善產(chǎn)品并確保其可靠性和有效性的承諾。

提高了發(fā)布能力，克服了歷史上的挑戰(zhàn)，并展示了改進(jìn)的更有效率的發(fā)布流程。

努力與生態(tài)系統(tǒng)的其他部分保持同步，包括依賴項(xiàng)和平臺(tái)更新，確保產(chǎn)品保持最新、安全，并與生態(tài)系統(tǒng)的其他元素兼容。

大量的發(fā)布也可能源于不穩(wěn)定性，說明需要進(jìn)行頻繁更新來解決持續(xù)出現(xiàn)的問題，并確保產(chǎn)品安預(yù)期運(yùn)行。

這一觀點(diǎn)強(qiáng)調(diào)了在產(chǎn)品穩(wěn)定性與發(fā)布頻率之間取得平衡的重要性，避免對(duì)團(tuán)隊(duì)和最終用戶造成過重的負(fù)擔(dān)。

NPS/CSAT

盡管客戶滿意度調(diào)查具有通用性，但通常會(huì)受到客戶端應(yīng)用程序的影響。應(yīng)用程序是用戶與服務(wù)之間的第一個(gè)、最具體且頻繁的互動(dòng)。

糟糕的體驗(yàn)可能會(huì)留下深刻的負(fù)面印象，難以抹去。

相反，出色的應(yīng)用體驗(yàn)可以彌補(bǔ)服務(wù)特性、性能和價(jià)格方面的不足，給客戶留下積極而持久的印象，有助于培養(yǎng)忠誠(chéng)度和滿意度。

可訪問性/可用性指標(biāo)

努力打造一款無障礙、包容的產(chǎn)品，供聽力、視力、行動(dòng)能力或語言障礙人士使用。

可用性通常表現(xiàn)為產(chǎn)品支持成本的降低。

結(jié)論

有那么一段時(shí)間，與一些后端工程師相比，客戶端工程師被認(rèn)為不是那么專業(yè)。后端工程師經(jīng)?；乇芸蛻舳斯こ坦ぷ鳎?yàn)榭蛻舳斯こ瘫灰暈橐环N次要、更容易的軟件工程形式，其重點(diǎn)是表面的東西，而非正確性和軟件質(zhì)量。盡管隨著無服務(wù)器應(yīng)用程序和 SaaS 后端的興起，這種觀點(diǎn)在過去五年里發(fā)生了顯著變化，但殘余仍然存在。

即使這些觀點(diǎn)正在得到糾正，作為管理者，我們需要確保我們的個(gè)人偏見不會(huì)影響我們的決策，尤其是當(dāng)我們的決策深刻影響客戶端工程師的職業(yè)生涯和福祉時(shí)。本文討論的指標(biāo)旨在為確保企業(yè)更加公平對(duì)待客戶端工程師提供一個(gè)基本的出發(fā)點(diǎn)。

本文轉(zhuǎn)載來源：

不只看數(shù)字：軟件開發(fā)企業(yè)如何評(píng)估客戶端工程師績(jī)效_研發(fā)效能_InfoQ精選文章