前言

考評牽涉到升職與加薪，所以往往是許多人在職場上的目標，如果從 RD 的角度來看相對單純，就是不斷朝「考評目標」邁進就對了！

但切換到主管視角了之後，開始需要去幫每個成員的貢獻度評分，這件事雖然權力很大，但相對壓力也很大，畢竟我寫下一個簡單的數字之後，可能就影響了明年的升職/加薪人選。

每個主管都期待能夠公平、公正地去幫每個成員評比，無論是適任還是不適任，都能夠被好好篩選出來，然而有些難題如果沒有被克服，很容易導致評分不公平、不公正。

難題

評估標準模糊

未明確定義不同職位的期望，導致解讀方式很多。

不同 level 的職級如果沒有明確定義，很容易在灰色地帶陷入苦惱

比如：我們都清楚「帶人」是 senior 的職務之一，但針對「系統效能調教」，究竟是 junior 還是 senior 的工作範疇？

即便針對不同 level 有了界線，同樣是 junior，年薪 60 到年薪 80 可能都叫 junior，但如果用同樣的標準去評斷，總會有成員被低估或高估。

比如：年薪 60 的 junior 可能只要完成基礎功能開發即可，但這對於年薪 80 的 junior 來說，已經是基本要求了，應給予更進階的期望，否則太容易達標了。

成員表現難以判斷

缺乏足夠的資料來支持評估，或者資料沒有被量化，導致成效變得主觀。

主管底下這麼多人，頂多只記得一些比較大的貢獻，不可能記得每個人這一季做了什麼，如果成員沒有主動提供自己完成過的任務，很容易導致主管在評分的時候，只有想到「有印象」的貢獻，這時就變得不客觀了。

比如：主管特別著重後端，因為 A 成員有做後端效能調教，所以主管記得並給予高分，但 B 成員都在搞前端，主管沒興趣也沒印象，覺得沒在做什麼就給了低分。

主觀評價

主管也是人，可能會因為個人喜好或情感因素，對成員的表現有不同的評價。

會有一部分人誤用了「向上管理」的精神，誤以為只要跟主管麻吉麻吉，就可以在考評中得到較好的評分。而會有這樣的成員，就代表有這樣的主管，誤把感情因素算進去評分中，很容易導致一些「默默做事」的成員被低估了。

策略

設定不同職級的期望

以我們公司的現況為例，會將 RD 分成 1~3 級的 junior，以及 4~6 級的 senior，所以有可能兩位成員的職稱相同，但大家給予的期待是不同的。

明確將每個職級的期待描述清楚，盡可能減少模稜兩可的空間，就能夠很清楚區別，每個成員是否有達成大家對他的期望。

比如：

• junior 1 的期望：
  完成指派的基本工作任務，並在同事幫助下，能夠完成基本 bug 修復、既有功能擴展等任務。
• junior 2 的期望：
  獨立完成一般的工作任務，能夠從頭到尾完成有範例指示的功能模組。
• junior 3 的期望：
  獨立完成複雜的開發任務，能夠給予簡易的系統優化建議，並指導 junior 1 與 junior 2 的 RD。

期望設定可以幫助 RD 明確了解他們在團隊中的角色和責任，並且有助於確保每個人都在適合的職級上工作，這樣的透明性也有助於提供有針對性的培訓和發展，以協助 RD 不斷提升他們的技能和貢獻。

收集資料

蒐集有關成員表現的相關資料和證據，或者由成員自行準備提供，可能包括工作成果、項目完成情況、客戶回饋、團隊合作和自我評估等。

比如：

完成電商系統 phase 1

• 第三方登入功能(100%)，與 A 團隊協作
• 商品展示模組(100%)，並寫成共用元件讓 B 團隊使用
• 購物車模組(90%)，等待設計出 icon 才全部完成

儘量使用量化數據來支持評估。數據可以包括項目的進度報告、錯誤率、工作效能和成就等方面的數據。

比如：

• 完成 Jira bug 卡片數量: 20/25 (priority high/low)
• 提升登入頁面前端顯示速度 20%
• 減少 SonarQube duplicated code 50%

多方參與

尋求多方參與和意見，以確保評估的客觀性。這可以包括徵求同事的(360 度)反饋、參考多個團隊成員的意見，並請其他主管參與評估，特別是當主管可能受到情感影響時。透過多方參與，可以提供更全面的觀點。

結語

考評雖然壓力很大，卻也是一個很好的機會，可以好好檢視每個成員一整季的目標達成情形。

這個階段可能會發現，大部分成員是符合預期，而會有少部分能夠超出預期，少部分可能會無法達成預期。但無論結果如何，總是有了這個結果之後，團隊成員才會更有實際的感覺 - 「我這一季到底做得怎麼樣？」

而有了這樣的感覺之後，要談後續的目標設定，就會相當有動力了！