軟件工程師績效評估解釋

在考慮軟件工程師績效評估的不同方法時，一定會想到一個問題：為什麼我們需要使用多種評估模型？ 簡單的答案是，軟件開發是一個複雜的、多方面的過程，通常涉及數十個人在不同的團隊中工作。

高管和利益相關者並不總是對每個開發人員的資格和職責有深入的了解，尤其是在大型組織和團隊中。 這就是為什麼性能評估應該留給技術熟練的專業人員，這些專業人員能夠理解每個軟件工程師的職責、能力、技能組合以及在整個軟件開發過程中的角色。

那麼，進行績效考核的正確方法是什麼？ 答案將取決於許多因素，從組織的規模和目標到工程師績效的更詳細方面。

管理績效評估

管理人員在工程績效評估中發揮著主導作用。 在許多較小的組織中，直接經理可能是唯一進行審查的人。 大公司通常不是這種情況，因為他們的審查過程通常更複雜，並且涉及更多不同角色和部門的人。 較大的組織也傾向於比較小的組織更頻繁地使用同行評審和自我評估。

自 20 世紀下半葉大公司採用績效評估以來，績效評估已經走過了漫長的道路，但績效評估的歷史超出了本文的範圍，支持一些績效評估模型的行為心理學也是如此。 相反，這篇文章側重於流程的實際方面，從管理層的職責開始。

儘管方法可能因組織的規模和類型而異，但一些基本原則適用於大多數（如果不是全部）審查情況。

管理人員需要如何進行績效評估

管理層需要徹底規劃審查過程，並確保參與的每個人都了解自己的責任。

• 審查過程需要提前定義好，讓經理和工程師有足夠的時間參與並提交反饋。 最後一分鐘的反饋可能價值較小，因為它可能會匆忙提交以趕上最後期限。
• 管理層需要將審查過程的目標、目的和價值傳達給工程師和其他利益相關者。 良好的溝通應該消除對流程的疑慮並提高評論的質量。
• 審查模板或表格需要事先商定，並且在設計時應考慮到使用壽命。 理想情況下，它們不應在審查週期之間發生變化，以確保審查結果隨著時間的推移具有可比性。
• 該方法應旨在最大限度地減少偏差並確保高度的一致性。 每個經理和工程師都有自己做某些事情的方式，但一致性可以防止個人及其偏見或偏好過度影響結果。
• 當採用同行評審和自我評估時，管理層需要確保評審過程的完整性。

減輕偏見和處理有問題的評論

由於管理層對審查過程的巨大影響，管理人員需要注意可能破壞過程的潛在偏見和其他問題。 即使計劃階段執行得很好，整個過程設計得當，管理層也可能需要消除某些不受歡迎的做法並確保過程的完整性。

• 在流程的所有階段都需要考慮能力和期望。 粗略地審查每個團隊成員可能會導致經理或同事提交過於正面或負面的評論。 假設同行提交了有問題的評論，因為他們不熟悉某個工程師的具體能力。 在這種情況下，管理層需要進行干預並確保此類審查不會影響總體得分。
• 經理也可以拒絕評論。 假設某位經理與一小部分工程師的工作脫節。 在這種情況下，他們不應該直接審查團隊的績效，因為他們可能缺乏平衡和詳細審查所需的背景和知識。
• 對特定個人或其職責缺乏深入了解的審閱者可能會覺得有必要提交對其表現的審查以選中一個框，從而生成一個沒有太多實質內容並且不會為審查過程增加太多價值的審查。
• 有偏見和片面的評論也會扭曲結果。 如果經理審查違反其意願聘用的團隊成員，或者處理項目的團隊未得到特定經理的認可，則他們的審查可能不客觀。 或者，審閱者可能會“挑選”特定的績效指標，以使個人或團隊看起來更好，因為這符合他們的興趣。

理想情況下，經理和高管能夠以純粹客觀的心態進行審查，但存在偏見。 然而，意識到它們可以減輕它們的影響。

請記住，經理審查軟件工程師的方式可以為經理的績效和專業水平提供有價值的見解。

同行評審

與經理評論相比，同行評論提供了一些優勢，但需要記住一些權衡。

同事往往比經理更有能力評估彼此的表現。 他們對隊友的工作有更多的了解。 他們經常從事相同的項目並與相同的人合作，因此往往對團隊動態和單個工程師的能力有很好的把握。

然而，同行評審也可能受到偏見的影響。 偏見可以表現為積極的，基於友誼，也可以表現為消極的，由個人問題或團隊成員之間的競爭引起。 集體思考也可以影響審查過程，尤其是在緊密結合的團隊中，因為人們可能傾向於為他們的隊友提供掩護。 鑑於這些可能性，需要以減輕偏見的方式設計同行評審模板和問卷，並儘可能關注特定的能力和客觀標準。 團隊成員的結果如何跟踪關鍵績效指標往往比關於個人特徵的主觀問題或其他開放式問題更有價值。

潛在的偏見提出了一個關鍵問題：同行評審應該匿名嗎？

可以提出有效的論據來支持匿名和公開審查，但重要的是要考慮不同的組織方案和團隊規模。 因此，沒有絕對正確或錯誤的答案，儘管大多數組織都喜歡匿名評論。

匿名與公眾反饋

讓我們仔細看看匿名反饋的優勢：

• 匿名可以鼓勵開放性和原創性思維。 如果團隊中的大多數人對某事或某人感到積極，那麼不同的意見可能不受歡迎。 匿名審閱者可以提供不同的觀點，而不會激怒他們的同事。
• 匿名反饋可以包含有價值的信息。 假設專業人士正在為同一個人收集匿名和公開的反饋。 他們很有可能會引用匿名意見來提出他們可能不願意從公開評論中引用的問題。 一些額外的點可能具有很大的價值，特別是如果在團隊其他成員發現問題之前提出問題。 這種預警使管理層和被審查者有機會解決和糾正新發現的缺陷，以免它們升級為更嚴重的問題。
• 維護關係是匿名反饋的另一個重要方面。 人們以不同的方式對負面評論做出反應，因此保持匿名可以保持凝聚力並防止團隊成員之間發生摩擦。
• 如果評論不是強制性的，通常更容易說服人們參與匿名評論。

但是，匿名同行評審也有一些缺點：

• 匿名是雙向的。 它鼓勵坦率的評論，但它可能會促使一些人濫用它，通過不誠實的評論來宣傳他們的議程。 有人可能會利用他們的匿名性來僅僅根據他們的個人喜好來破壞同事。 相反，匿名可用於為不值得他們提交正面評論的人，因為評論者可以選擇保護他們的長期同事和朋友，可能以犧牲其他團隊成員為代價。
• 公眾評論可以發揮更大的作用。 假設一個人從幾十個匿名評論者中收到了幾行負面反饋。 很有可能，這種反饋不會像從可信賴和受尊重的團隊成員那裡獲得相同的反饋那樣有影響力。 當反饋來自親近的人時，員工更有可能認真對待反饋。
• 在某些組織（即小型組織）中，確保匿名性可能具有挑戰性。 每天與他們一起工作的五個人總共收到四條評論的人可能能夠分辨出誰提交了哪條評論。 這可能會導致人們將評論視為匿名的，從而破壞了匿名化的全部意義。
• 雖然讓人們提交公開評論可能更具挑戰性，但評論者更有可能認真對待他們，因為他們知道他們的名字已附上。 因此，他們可以投入更多時間來提供詳細、客觀和平衡的反饋，而不是將審查過程視為一種形式。

自我評估

自我評估——或自我評價——是另一種常用於績效評估的方法。 與其他評論模型一樣，他們可以提出自己的爭議。

員工管理人員通常需要定期進行自我評估，如果目標是使用它們來跟踪進度和隨時間的變化，這是有道理的。 很少有組織要求每月進行評估，但每年、每兩年甚至每季度的自我評估都很常見。 要求工程師定期提供反饋可能是有益的，尤其是在與高度自治的團隊和個人打交道時。 被審查者可以使用這些定期評估來傳達需要解決的潛在問題，解釋他們如何克服特定挑戰，詳細說明他們如何以及為什麼提高績效，並確定阻礙他們提高績效的因素。

減輕自我評估的局限性

不幸的是，自我評估有幾個嚴重的缺點，偏見是最明顯的一個。 有些人可能會誇大他們的表現，拒絕透露他們工作中的不足，或者列出阻礙他們表現的問題。 其他人可能對自己過於挑剔。 在任何一種情況下，結果都可能出現偏差。

組織如何減輕缺點？ 管理人員可以設計自我評估表格和問題，以解決偏見並將其影響降至最低。

• 避免允許過多主觀性的開放式問題。
• 關注有形的結果，而不是主觀的目標和價值觀。
• 對被審查者處理的關鍵責任給予更高的重視。
• 強調關鍵績效指標和可量化的目標。
• 重申組織的核心價值觀並相應地評估績效。

為了讓工程師解決可能未包含在自我評估表中的問題，請提供評論部分。

360 度評估

360 度反饋流程結合了許多先前討論過的模型，以提供更廣泛的反饋並確定被審核者的優勢和劣勢。 在 360 度系統中，直接績效評估、來自工程師同事（同行）、經理、客戶和其他來源的評估被製成表格，以生成單一結果，並以易於理解的格式呈現給被評估者。

由於這種方法可確保來自多個來源的反饋，並且涵蓋的不僅僅是基本的績效指標和技能，因此它在許多情況下都很有用。 它提供了工程師績效的概覽，使管理層能夠一目了然地獲得有價值的見解。 此外，如果一個組織決定不與每個員工分享每次審查的結果，它可以改為分享 360 度反饋的結果。

這種方法評估基本的團隊技能，並就工程師的表現、行為、溝通和任何其他所需標準提供團隊反饋。 但是，它不適合評估技術技能、特定於單個項目的技能或細粒度的績效指標。 由於它通常涉及許多具有不同背景和參與程度的人，因此 360 度反饋可能過於主觀，無法評估軟件工程師績效的某些方面。

軟件工程師績效評估中包含的內容

為利益相關者創造價值並為他們提供可操作信息的績效評估中應包括哪些內容？ 審查應該是全面的還是集中在短期內要處理的幾個項目上？

答案取決於組織的類型和審查的範圍，儘管有些點應該包含在大多數（如果不是全部）績效審查中。

速度和迭代

開發人員完成任務的速度是任何績效評估的重要指標，就像他們處理迭代軟件開發的方式一樣。 在與處理單個項目的大型團隊、經常從一個項目和客戶跳到另一個項目和客戶的個人以及消防工作打交道時，速度和迭代至關重要。 軟件工程師的落地運行能力可以決定項目的成敗。

代碼質量和代碼審查

雖然速度是一個關鍵指標，但如果價格高昂，它的價值就會降低。 代碼的質量必須是最重要的，並且不應該為了滿足緊迫的期限而妥協。 質量較差的代碼可能會在以後給團隊或組織的其他成員帶來麻煩。

代碼審查確保有人檢查其他人編寫的代碼。 這個過程雖然耗時，但簡單明了，是確保和保持質量的好方法。 持續的代碼審查使組織不必全面審查其開發人員編寫的每一行代碼。 代碼審查員需要是高技能的人，能夠識別需要注意的各種問題和關鍵領域，從設計和功能到樣式和文檔。

內部溝通與責任

溝通不是一項技術技能，但它可以深刻地影響軟件工程師的工作質量。 工程師經常與他們的同行、團隊領導、利益相關者和客戶進行溝通，並且需要表現出高度的責任感和專業精神。

溝通不暢會破壞他們的工作質量，並使小問題升級為更大、更昂貴的問題。 專業和及時的溝通是基礎，應該接受審查。 即使是最令人印象深刻的技術技能也不如承擔責任和有效溝通的需要那麼重要。

招聘、領導和規劃

高級軟件工程師和團隊負責人通常在招聘中發揮關鍵作用，因此審查他們在這些方面的表現也很重要。 如果團隊負責人做出糟糕的招聘決定，就會影響整個團隊，甚至可能影響整個組織。

領導力可能難以衡量和審查，尤其是在團隊成員不願提供負面反饋的情況下。 因此，有必要確保審查過程使他們免受可能因對其上級的不雅審查而受到報復。

計劃是另一個主觀類別。 領導者需要確保充分規劃和執行團隊目標。 然而，他們在這方面的表現取決於其他團隊成員，包括下屬和上級。 錯過目標和截止日期是明顯的危險信號，但審查過程應考慮可能導致它們的一系列因素，例如，管理不善未能及時採取行動使項目重回正軌或缺乏時間或資源趕上最後期限。。

績效評估並不容易——不要讓他們變得更難

每個組織都應創建適合其特定需求的績效評估模型。 僅僅因為谷歌或蘋果正在做某事，並不一定意味著它適用於另一家公司或團隊。

績效評估需要大量計劃和仔細考慮。 有必要在一方面的複雜性和徹底性與另一方面的實用性和有用性之間取得適當的平衡。 小型組織可以進行績效評估，而不會使過程過於繁瑣和困難。 同樣，大型組織應盡最大努力使流程盡可能精簡。

不要忘記審查審查過程本身。 無論是按季度還是按年度進行審核，在進行下一輪審核之前，請先審核最近一輪審核。 過程順利嗎？ 它是否發現了有用的信息？ 找出任何缺點，解決它們，並努力不斷改進審查過程。