讀完這章你要能回答：績效管理和績效考核差在哪？我怎麼建立持續的目標對齊與回饋循環？

績效管理不只是打分，而是持續的目標對齊和回饋循環。

績效管理的本質#

績效管理的目的不是為了分出優劣，而是為了幫助每個人成長，同時確保團隊目標的達成。

劉建國在《技術管理實戰 36 講》中指出常見的誤區：

績效管理 ≠ 績效考核#

績效管理的完整循環#

flowchart TD
    A[🎯 目標設定] --> B[📊 持續跟進]
    B --> C[💬 回饋輔導]
    C --> D[📝 績效評估]
    D --> E[🏆 結果應用]
    E --> A

    A -.- A1["開始：設定 SMART 目標"]
    B -.- B1["過程：定期檢查進度"]
    C -.- C1["過程：即時回饋與指導"]
    D -.- D1["結束：評估與校準"]
    E -.- E1["後續：薪酬、晉升、發展"]

目標設定#

OKR vs KPI#

喬新亮在《CTO 成長復盤》中比較了兩種方法：

對於技術團隊，可以用 OKR 設定技術創新和改進目標，用 KPI 追蹤日常運維和交付指標。兩者可以結合使用。

好的目標的特徵（SMART）#

• Specific（具體的）：清楚定義要達成什麼
• Measurable（可衡量的）：有明確的指標
• Achievable（可達成的）：有挑戰但可實現
• Relevant（相關的）：與團隊/公司目標對齊
• Time-bound（有時限的）：有明確的完成時間

目標對齊#

flowchart TD
    A[🏢 公司戰略目標] --> B[👥 部門/團隊目標]
    B --> C[👤 個人目標]

    C -.->|支撐| B
    B -.->|支撐| A

    style A fill:#e1f5fe
    style B fill:#fff3e0
    style C fill:#e8f5e9

每一層的目標都應該支撐上一層的目標

持續回饋#

很多管理者只在年度考核時才給回饋，導致員工錯過了改進的機會，問題積累到無法挽回。

回饋的時機#

即時回饋：

• 做得好的時候，當場肯定
• 做得不好的時候，及時指出
• 不要等到績效考核時才說

定期回饋：

• 每週的週會或站會
• 每月的 1:1 溝通
• 每季度的階段回顧

有效回饋的方法#

朱贇推薦的回饋框架：

SBI 模型（Situation-Behavior-Impact）

Situation（情境）：
「在上週的技術評審會上...」

Behavior（行為）：
「你提出了三個架構上的潛在風險...」

Impact（影響）：
「這幫助團隊提前發現了問題，避免了上線後的故障」

回饋要針對行為，不要針對人。說「這個程式碼寫得有問題」而不是「你怎麼這麼粗心」。

4A 回饋模型：給的人與收的人都有紀律#

SBI 教的是「怎麼把回饋說清楚」，但回饋是雙向的——收回饋的人也需要紀律。4A 模型把兩端都規範起來：

「Accept or discard」很關鍵：收回饋者沒有義務照單全收，但有義務認真聽。這讓人敢給回饋，也讓收的人不必被迫服從。

做 360 度回饋時，把問題收斂成 Start / Stop / Continue（該開始做什麼、該停止什麼、該繼續什麼），而且具名——匿名回饋容易流於發洩，具名才有當責。

開採衝突：mining conflict / farming for dissent#

健康的回饋文化，需要主動「開採」藏在表面和諧底下的衝突：

• Mining conflict（挖掘衝突）：當會議一片祥和時，主動把不同意見挖出來，而不是讓它埋在檯面下（呼應五大障礙的「害怕衝突」）。
• Farming for dissent（種出異見）：重大決策前主動徵詢反對意見，因為多數人不會主動唱反調。

負面回饋的藝術#

給負面回饋是管理者最難但最重要的技能之一：

1. 私下進行：不要在公開場合批評
2. 及時給出：不要積累到爆發
3. 具體明確：指出具體問題，不要泛泛而談
4. 關注改進：重點是如何做得更好，而不是追責
5. 給予支援：表達你願意幫助他改進

績效評估#

評估維度#

劉建國建議的評估維度：

避免評估偏差#

常見的評估偏差：

• 近因效應：只記得最近的表現
• 光環效應：一個優點掩蓋其他問題
• 相似偏好：喜歡和自己相似的人
• 對比效應：過度受其他人的影響

應對方法：

• 平時做好記錄，評估時有據可查
• 使用統一的評估標準
• 引入多方評估（360 度回饋）
• 評估前校準，確保標準一致

績效校準會議#

在最終確定績效結果前，召開管理者校準會議。每個管理者講述自己團隊的績效分布和典型案例，相互校準標準。

同儕當責勝過制度#

前面談的回饋與校準，大多是「由經理推動」的。但最強的標準維護者，其實不是制度，也不是經理——而是受團隊敬重的同儕。

當紀律由經理一人壟斷時，團隊會學會「只要經理沒看到就沒事」，於是集體沉默、把問題上推。真正讓標準活起來的，是同儕之間「我不會讓你拖累我們」的相互當責。

這呼應五大障礙裡的「規避當責」——經理不該是唯一的紀律來源。

從經理驅動到同儕驅動#

落實同儕當責的三個動作：

1. 公開目標與標準：讓每個人都清楚「達標長什麼樣」，標準才能被共同維護。
2. 輕量進度檢視：高頻、低負擔的同步（站會、看板），讓落差即時被看見。
3. 獎勵轉向集體成果：當獎勵綁在團隊成果上，同儕自然有動機互相當責。

親密悖論：關係越好，越不好意思指出對方的問題——「都是朋友，何必撕破臉」。但真正的尊重，是相信對方承受得起誠實。迴避當責不是體貼，是放任。（呼應 HRT 的尊重原則。）

成就層級與薪資寬幅#

當責與回饋之外，把「貢獻」和「報酬」對應清楚，也是績效體系的一環。

成就層級#

工程師的影響力可以分層描述，幫助對齊期望與晉升：

薪資寬幅（salary band）#

同一層級內保留薪資寬幅，而非一刀切：

• 同層級的人，因經驗、稀缺性、實際貢獻不同，薪資應有合理區間。
• 寬幅讓「在原層級持續精進」也有加薪空間，而不是非得升職才能漲薪。
• 透明的層級與寬幅，能減少「同工不同酬」的猜忌，呼應團隊文化的透明原則。

績效結果的應用#

績效與薪酬#

績效結果通常與以下掛鉤：

• 年度調薪
• 獎金發放
• 股權激勵
• 晉升機會

績效談話#

談話準備：

• 回顧這個週期的工作表現
• 準備具體的例子和數據
• 想好如何回應可能的質疑

談話結構：

1. 先讓員工自評
2. 分享你的評估結果
3. 討論差異和原因
4. 聚焦改進方向
5. 確認下一步行動

處理績效不佳#

對於持續績效不佳的員工：

flowchart TD
    subgraph S1 [第一步：明確告知問題]
        A1[具體指出哪些方面不達標]
        A2[確認對方理解問題]
        A3[設定改進期限 2-3 個月]
    end

    subgraph S2 [第二步：提供支援]
        B1[安排導師或結對]
        B2[給予更多指導和回饋]
        B3[必要時調整工作內容]
    end

    subgraph S3 [第三步：評估改進]
        C1{有明顯進步？}
        C2[繼續觀察]
        C3[考慮換崗或離開]
    end

    S1 --> S2 --> S3
    C1 -->|是| C2
    C1 -->|否| C3

    style S1 fill:#ffebee
    style S2 fill:#fff3e0
    style S3 fill:#e8f5e9

全程保持溝通的透明和尊重

不要因為不好意思而避免處理績效問題。拖延只會讓問題更嚴重，對團隊和個人都不公平。

工程師的績效特殊性#

技術人員的績效評估有其特殊性：

如何量化技術貢獻？#

• 程式碼量：不是好指標，容易被刷
• Bug 數：只反映品質，不反映創造
• 上線功能：需要考慮難度差異
• 技術影響力：難以量化但很重要

更好的評估方式#

1. 專案回顧：回顧具體專案中的貢獻
2. 同行評審：收集合作者的回饋
3. 技術分享：評估知識輸出和影響力
4. 難題解決：記錄處理的複雜問題

本章要點#

1. 管理不只是考核：績效管理是持續的過程，不是一次性事件
2. 目標要對齊：個人目標要支撐團隊和公司目標
3. 回饋要及時：不要等到考核才說，即時回饋才有效
4. 4A 雙向紀律：給的人 Aim-to-assist／Actionable，收的人 Appreciate／Accept-or-discard
5. 同儕當責勝過制度：紀律別只靠經理，公開標準、輕量檢視、獎勵集體成果
6. 小心親密悖論：關係好不該成為迴避當責的藉口
7. 評估要公正：避免偏差，使用統一標準，多方校準
8. 層級與寬幅：用成就層級對齊期望，用薪資寬幅獎勵原地精進
9. 結果要應用：績效結果要與薪酬、晉升掛鉤才有意義
10. 技術有特殊性：不能簡單用程式碼量等指標來衡量工程師