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
- 同舊有做法，並事前告知會採團隊 Review 方式
調整，給分、評估回覆方式，由原先的 0~10 分，改為：”非常不同意、不同意、普通、同意、非常同意、沒機會觀察” 採用類似光譜的方式做為答案選項 (抽象的題目使用抽象的選項)；經嘗試有效加快問卷的填寫速度 - 請團隊成員羅列 Performance Review Highlights
ENDGAME
- 主管匯整問卷資訊
- review 分為上半場與下半場
- 上半場：當事人不參與，團隊成員先進行 Review meeting，並由團隊匯總資訊、交流 “特徵” (註)，其中也能去除敏感用字或情緒語言，讓大家對內容有共識也客觀
- 下半場：團隊成員與當事人 Review meeting
- 因為當事人與團隊成員可以清楚針對上述 “特徵” 做描述因此可以針對一些模糊不清、模稜兩可的問題做深入討論
- 確定團隊預期的 “期望”
有關 “特徵”：對每個成員的表現、個性，我偏向不使用、優點、缺點去形容，而使用 “特徵” 去描述；
例如，”動作快” 不一定是優點，也有可能是草率，但也不一定缺點，在產品開發 MVP 的情況下可以透過迭代慢慢調整，所以將 “動作快” 描述為 “特徵”
團隊參與 review 的進行，可預期時間成本的增加
雖然預期表定 1 小時內處理完成，但實務上容易超時
雖然花得時間較多，但我們發現「團隊 reivew」可以達到以下幾個好處：
- 減少資訊不穩明與意見傳達時的誤會
- 避免不客觀的描述
- 讓 reviewer 能針對 “特徵” 發表想法、意見
團隊 Review 的好處
可以針對一些更模糊不清、模稜兩可的問題、特徵，做深入討論
- 保障每個人的話語權 (可以發言、發表意見)
- 透過討論，讓團隊取得共識
- 即早發現、解決可能的誤會、誤解
- 透過團隊論討論降低評論不明確、意見單向的問題
- 讓不好的特徵有 “具體“ 評論並提出建設性改善方向、建議
團隊 Review 討論每個人的觀點，並將 review 調整成比較客觀以友善的方式提出可能的改善方向、方法
團隊 Review 的壞處
- 初期要花很多時間，填寫問卷、開會 review
- 平時要累積、記錄每個成員的行為資訊，比較方便在團隊 Review 時提出來 (舉證)
- 資深員工自然帶有話事權 (可以決定、主導發展方向)
- 整個會議容易淪為表面工夫
小結
在 Simpany 從傳統的密室 review 改為新的「Team Review」方式來進行 performance review (積效考核)，試圖改善舊有問題…
但是相對也帶來新的問題，能幫老闆在積效考核省不去不少工夫；因為實際上老闆、主管可能根本不認識你這個員工 🫣
實際團隊 Review 的結果、成效，其成員被調整的薪資仍然是黑箱…
但有嘗試仍然是好的~ 只能等著瞧
