Performance Review 也稱績效考核或年度自我評量

引用至 WIki 譯自英文-績效考核、績效評估，有時縮寫為“ PA”，是一個定期，系統的過程，通過此過程可以記錄和評估員工的工作績效。這是在員工接受工作培訓並安頓下來之後進行的。績效評估是職業發展的一部分，包括對組織內部員工績效的定期審核。績效評估通常由員工的直屬主管進行。
wiki: https://en.wikipedia.org/wiki/Performance_appraisal

Performance Review 關係到薪資、升遷和薪水習習相關!

你怎麼能不重視呢~

一般公司的 Review 大概是，主管搜集 review 對象的資訊，接著再和這個 review 對象私下約談

心朋 Simpany 早期 八九不離十，也是採用這個方式進行~

而看起來沒什麼問題、稀疏平常的 Performance Review 其中潛藏不少問題和需要改善的地方…

• 各方意見可能沒有共識，而且各說各話
• 搜集資訊、意見所需要的時間成本、心智成本高昂
  同事提供意見或資訊所需要心智負擔很大，在 Simpany 使用 Review 問卷 (Google 表單) 的方式搜集資訊
• review 過程並不是十分的透明、公開
• 主管並不會 24 小時盯著每個成員，所以主管沒辦法完全暸解、參與實際的工作情際；只能聽取搜集來的資訊做判斷…

傳統的 Review 方式在結束之後，review 對象可能會在事後有些意見 怨言
對應上述情況，可能的問題為：

• 各方意見可能沒有共識，而且各說各話 → 每個團隊成員的認知不同
• 搜集資訊、意見所需要的時間成本、心智成本高昂 → review (績效考核) 半年、一年進行一次，每個人對過去發生的事情那，可能會記憶錯亂、有誤，而且這些資訊放了半年也早就臭酸、變質了…

Performance Review、績效考核常常因為上述不良因素反而無法達到預期效果，更甚變質成充滿惡意指控。 (誇大 😱)

因為主管的資訊來源可能有偏差、誤解，而讓員工有不好的感受
(試想… 努力了一年、半年卻收到負面資訊真的非常難過 🥲)最常見的例子：
團隊成員對同一個當事人、同一個任務內容的評論可能是…

• 成員 A 描寫當事人的開發速度太慢
• 成員 B 描寫當事人慢工出細活、注意小細節

事實應該為何? 主管該相信誰? 我想真相只能待柯南幫忙查明了 ?!

而且上述的證言，”被害人” 當下也無法解釋、說明實際事由，因為：

• 發生時間已經過太久
• 證人都不在 review 現場，無法深入暸解實際情況
• 這些 不好、負面的描述在 review、考核結束的事後，雙方再進行單方面的解釋其實幫助不大；因為當下誤會、偏見已造成…

而 “人們” 為了解開這些的誤解，往往需要更的時間成本去處理或解開這些誤會
諸如此類的心結，經常造成更不好的結果!

但這種會讓勞資奴雙方成本極高的方式，並不是 Simpany 樂見的結果.

為了改善這樣的情況，團隊做了各種研究與改善
也為了避免美意變成惡意
因此我們決定在工程團隊先試用新的 Review (考核) 方式

Simpany 工程團隊約 6 人；需要填寫自己與隊友的評論、問卷

而且題目內容可能無法滿足每個人、每種職位情況；文章後面會補充說明~

---

接下來將說明 Simpany 新、舊 Review 方式的流程與改善目標

舊有的 Performance Review 做法

• 讓團隊成員各自填寫自己與成員們的 Review 問卷
• 由主管匯整問卷資訊
• 主管與當事人一對一 Review meeting

所有步驟都是私下或一對一進行，雖然有保密的功能，也能 “有話直說”，但也帶來不少隱憂…

Performance Review Highlights：由團隊成員一起編輯的共筆文件，主要用途為說明這個 Review 季度自己有哪些做的好的部份，值得注意的表現

新的、改良之後的 Performance Review (團隊版本) 做法

Team Review / 團隊 Review

kickoff

1. 同舊有做法，並事前告知會採團隊 Review 方式
   調整，給分、評估回覆方式，由原先的 0~10 分，改為：”非常不同意、不同意、普通、同意、非常同意、沒機會觀察” 採用類似光譜的方式做為答案選項 (抽象的題目使用抽象的選項)；經嘗試有效加快問卷的填寫速度
2. 請團隊成員羅列 Performance Review Highlights

ENDGAME

1. 主管匯整問卷資訊
2. review 分為上半場與下半場
   1. 上半場：當事人不參與，團隊成員先進行 Review meeting，並由團隊匯總資訊、交流 “特徵” (註)，其中也能去除敏感用字或情緒語言，讓大家對內容有共識也客觀
   2. 下半場：團隊成員與當事人 Review meeting

• 因為當事人與團隊成員可以清楚針對上述 “特徵” 做描述因此可以針對一些模糊不清、模稜兩可的問題做深入討論
• 確定團隊預期的 “期望”

有關 “特徵”：對每個成員的表現、個性，我偏向不使用、優點、缺點去形容，而使用 “特徵” 去描述；
例如，”動作快” 不一定是優點，也有可能是草率，但也不一定缺點，在產品開發 MVP 的情況下可以透過迭代慢慢調整，所以將 “動作快” 描述為 “特徵”

---

團隊參與 review 的進行，可預期時間成本的增加
雖然預期表定 1 小時內處理完成，但實務上容易超時

雖然花得時間較多，但我們發現「團隊 reivew」可以達到以下幾個好處：

• 減少資訊不穩明與意見傳達時的誤會
• 避免不客觀的描述
• 讓 reviewer 能針對 “特徵” 發表想法、意見

---

團隊 Review 的好處

可以針對一些更模糊不清、模稜兩可的問題、特徵，做深入討論

• 保障每個人的話語權 (可以發言、發表意見)
• 透過討論，讓團隊取得共識
• 即早發現、解決可能的誤會、誤解
• 透過團隊論討論降低評論不明確、意見單向的問題
• 讓不好的特徵有 “具體“ 評論並提出建設性改善方向、建議

團隊 Review 討論每個人的觀點，並將 review 調整成比較客觀以友善的方式提出可能的改善方向、方法

團隊 Review 的壞處

• 初期要花很多時間，填寫問卷、開會 review
• 平時要累積、記錄每個成員的行為資訊，比較方便在團隊 Review 時提出來 (舉證)
• 資深員工自然帶有話事權 (可以決定、主導發展方向)
• 整個會議容易淪為表面工夫

小結

在 Simpany 從傳統的密室 review 改為新的「Team Review」方式來進行 performance review (積效考核)，試圖改善舊有問題…

但是相對也帶來新的問題，能幫老闆在積效考核省不去不少工夫；因為實際上老闆、主管可能根本不認識你這個員工 🫣

實際團隊 Review 的結果、成效，其成員被調整的薪資仍然是黑箱…

但有嘗試仍然是好的~ 只能等著瞧

Ref.

• https://designer.microsoft.com/image-creator
• https://www.psohub.com/blog/how-to-do-an-effective-team-performance-review