研發績效怎麼考核？2026 研發團隊 OKR、研發 KPI 與工程師績效考核實戰

「研發部一年花掉公司三成費用，但我真的不知道他們做得好不好。」這是許多老闆在年終評估研發績效時的心聲。另一邊，研發主管也很無奈：「我們今年把平台重構完，隔年產品開發速度會快很多，但考核表上只有『準時完成率』，大家寧願接簡單的案子。」

研發績效管理之所以困難，是因為研發工作的價值常常要半年、一年後才看得到，失敗的實驗也可能是必要的學習，而產品成敗又牽涉業務、生產與市場。本文以顧問現場的經驗，說明如何把 OKR、研發 KPI 與工程師績效考核拆開設計、再連動起來，讓研發績效看得見、也不會傷害創新。

研發績效為什麼難衡量？先搞懂三個本質差異

在設計任何研發績效制度之前，老闆和人資需要先接受研發工作與業務、生產工作的三個差異：

• 成果有時間差：業務本月成交就看得到業績，研發今年做的技術預研，可能後年才變成產品營收。若只看當年度成果，會系統性地懲罰長期投資。
• 不確定性高：研發本來就有一部分會失敗。若「失敗」直接等於「績效差」，工程師會只挑有把握的題目，創新自然消失。
• 高度協作：一個產品上市需要機構、電子、韌體、軟體、測試多人合作，個人貢獻很難從團隊成果中切割。

因此，研發績效管理的設計原則是：方向用 OKR 對齊、健康度用 KPI 監控、個人評價用多面向證據與校準。三者有關係，但不能把 OKR 達成率直接換算成考績分數。

OKR 和研發 KPI 有什麼不同？兩者如何分工

OKR（Objectives and Key Results，目標與關鍵結果）源自 Intel 的 Andy Grove，後由 John Doerr 於 1999 年引進 Google，之後被許多科技公司採用。Google 的 re:Work 指南說明，目標應具企圖心、讓人稍感不安；關鍵結果應可衡量、容易以數字評分；並建議每個團隊設 3 到 5 個目標、每個目標約 3 個關鍵結果，以 0 到 1.0 評分，挑戰型 OKR 的理想得分落在 0.6 到 0.7。若某人總是百分之百達成，代表目標不夠有野心。

同一份指南也明確指出，OKR 不等於員工績效評估。這一點正是許多台灣企業導入 OKR 失敗的原因：把 OKR 當成另一種 KPI，達成率直接決定獎金，結果大家只設保證做得到的目標。

研發團隊 OKR 怎麼寫？三個範例與檢核方法

研發 OKR 最常見的錯誤，是把工作項目寫成關鍵結果，例如「完成 A 模組開發」「上線 B 功能」。這些是產出，不是成果。好的關鍵結果應該描述「做完之後，世界有什麼可衡量的改變」。

範例一：硬體產品研發團隊

目標：讓新一代控制器成為客戶最容易導入的產品。

• 關鍵結果 1：客戶從開箱到完成安裝的平均時間，由目前的 4 小時降到 1.5 小時（以 10 家試用客戶實測）。
• 關鍵結果 2：試產良率由 92% 提升至 97%。
• 關鍵結果 3：主要零件中可由兩家以上供應商供貨的比例由 60% 提升到 85%。

範例二：軟體平台團隊

目標：讓產品團隊可以更快、更安全地把功能交到客戶手上。

• 關鍵結果 1：從程式碼提交到部署上線的中位數時間，由 5 天縮短至 1 天。
• 關鍵結果 2：部署後需要立即回滾或緊急修補的比例由 18% 降至 8%。
• 關鍵結果 3：開發人員季度滿意度調查中「建置與部署流程」項目平均分數由 3.1 提升至 4.0（5 分量表）。

範例三：技術預研小組

目標：驗證新材料是否值得導入下一代產品。

• 關鍵結果 1：完成 3 種候選材料的關鍵性能測試，並產出可供決策的比較報告。
• 關鍵結果 2：至少 1 種材料在耐溫測試中達到規格要求的 120%。
• 關鍵結果 3：完成候選材料的成本試算，與現行材料差異控制在 15% 以內，或提出可接受的取捨建議。

預研類 OKR 的成果本身就是「學習」，因此允許以「產出可決策的證據」作為關鍵結果，這也是為什麼 OKR 不能直接和獎金連動的原因：一個誠實回報「這條路走不通」的團隊，替公司省下的可能是上千萬的後續投資。

寫完 OKR 後，可以用以下五個問題自我檢核：

1. 這個目標和公司今年的策略有什麼關係？
2. 關鍵結果是成果還是工作項目？
3. 每個關鍵結果都有基準值與目標值嗎？
4. 季末能不能用數字客觀評分？
5. 如果全部做到 1.0，是不是代表目標設得太保守？

研發 KPI 指標庫：交付、品質、創新與團隊健康

OKR 負責突破，研發 KPI 負責確保基本盤穩定。指標不宜多，建議每個團隊挑 4 到 6 個，涵蓋不同面向，避免單一指標被操弄。以下指標庫依常用框架整理，其中軟體交付指標參考 Google DORA 研究計畫所定義的軟體交付績效指標：

DORA 目前將軟體交付績效指標分成兩組：衡量速度的變更前置時間、部署頻率、失敗部署復原時間，以及衡量穩定度的變更失敗率與部署重工率。同時看速度與穩定度，能避免團隊為了衝快而犧牲品質。

另一個值得參考的是 2021 年發表於 ACM Queue 的 SPACE 框架，作者群包含 Nicole Forsgren 等研究者，主張開發者生產力不能用單一指標衡量，應同時考量滿意度與福祉、績效、活動、溝通與協作、效率與流動五個面向。對老闆而言，這個框架最大的提醒是：程式碼行數、提交次數這類「活動量」指標，只能作為輔助觀察，絕不能單獨拿來評斷工程師。

工程師績效考核怎麼設計？職級期望與評分表

工程師績效考核的核心問題是：「這個人在他的職級上，表現得如何？」因此第一步不是設計評分表，而是先定義職級。沒有職級期望，資深工程師和新進工程師就只能用同一把尺比較，結果往往是誰加班多誰分數高。

步驟一：建立研發職級期望

可以先用三到五個職級描述，例如初階、中階、資深、技術主管，每一級說明在技術能力、問題範圍、影響力、協作與帶人四個面向的期待。例如初階工程師是「在指導下完成明確定義的任務」，資深工程師則是「能獨立拆解模糊問題，並帶動其他成員」。

步驟二：設計多面向評分表

以下是一個工程師績效考核表的權重範例，公司可依產業與團隊特性調整：

• 交付成果（35%）：負責項目的完成度、品質與對團隊 OKR 的貢獻，以具體事例說明。
• 技術能力與品質（25%）：設計品質、問題解決深度、技術文件、程式碼或圖面審查回饋。
• 協作與影響力（20%）：跨部門合作、知識分享、協助他人、參與設計審查的品質。
• 成長與學習（10%）：新技能學習、專業訓練應用、技術預研的貢獻。
• 制度遵循（10%）：研發紀錄完整度、工時填報、資訊安全與保密規範遵守。

其中「研發紀錄完整度」看似瑣碎，卻和公司能否適用研發投資抵減高度相關，詳見同系列研發投資抵減完整解析。

步驟三：蒐集多元證據

考核不能只靠主管印象。建議主管在考核前整理三類證據：專案與 OKR 紀錄、同儕與跨部門回饋、工程師本人的自評與成果說明。每一個高於或低於期望的評分，都應附上具體事例。

校準會議怎麼開？避免研發主管各打各的分數

不同主管對「表現優異」的標準不同，是研發績效考核最常見的不公平來源。校準會議的目的，就是讓主管們用同一把尺。建議流程如下：

1. 主管初評：各研發主管依評分表完成初評，並為每一位人員準備一段簡短的事例說明。
2. 分組校準：研發部門主管與人資主持，各主管輪流說明評分理由，重點討論最高與最低的評分，以及同職級中分數差異大的人員。
3. 交叉檢視：檢查是否有系統性偏差，例如某位主管的部屬普遍偏高、遠端或安靜型人員普遍偏低、近期事件效應過強等。
4. 定案與回饋：確定評等後，由直屬主管與每位工程師進行一對一面談，說明評等理由與下一期發展重點。

若公司對評等分布有參考比例，建議作為校準時的檢視工具，而不是硬性配額，避免小團隊被迫產生不合理的低評等。若員工長期無法達到職級期望，處理上應先有明確的改善計畫、輔導紀錄與合理期間，涉及調職或資遣時更需依勞動法令審慎處理，可參考如何合法資遣不適任員工，個案請諮詢律師。

研發績效指標的 6 個常見陷阱與對策

1. 用工時或加班時數衡量投入：鼓勵低效率與過勞。對策是看成果與品質，工時只用於專案成本分攤與研發費用歸屬。
2. 用程式碼行數或提交次數排名：容易被操弄，還會懲罰精簡設計。對策是活動量指標只用於團隊層級的流程診斷。
3. 只看專案準時率：工程師會在規劃時灌水時程，或只挑簡單題目。對策是搭配目標難度與商業成果一起看。
4. OKR 達成率直接等於考績：大家只設保證做得到的目標。對策是 OKR 與考核分開，考核時看「設定了多有挑戰的目標」與「學到什麼」。
5. 個人化團隊指標：把部署失敗率、客訴率算到個人頭上，造成互相推諉。對策是品質指標以團隊為單位檢討，著重流程改善而非究責。
6. 指標太多：二十個指標等於沒有重點。對策是每個團隊 OKR 不超過 3 到 5 個目標，KPI 控制在 4 到 6 個。

研發績效管理的年度節奏：從季度 OKR 到年度考核

制度要有固定節奏，才不會淪為年底一次性的填表。以下是一個可供參考的年度循環：

若研發團隊採用 Scrum，季度 OKR 可以作為 Sprint 規劃時排序待辦項目的依據，相關做法請見敏捷開發指南；產品經理如何把 OKR 轉成產品路線圖，可參考產品經理的工作內容。研發管理的其他主題，則整理在中小企業研發管理總覽。

用管理王系統追蹤研發 OKR 與績效

研發績效制度最怕「設定時很熱鬧，季中沒人看」。管理王是一站式企業 AI 管理系統，以下功能可協助制度持續運轉：

• 專案管理與任務管理：研發專案與里程碑在系統中建立，任務完成情形自動累積，成為里程碑準時率與個人交付成果的客觀紀錄。
• AI 會議記錄：OKR 週會、季度回顧與校準會議的討論重點與決議自動整理，主管考核時可以回顧整季的進展與事例。
• 人事系統與教育訓練：保存工程師的職級、歷次考核結果與訓練紀錄，讓「成長與學習」面向有依據，也方便規劃下一期的訓練需求。
• CEO 戰情室：老闆可在儀表板上查看各專案進度與關鍵數字，掌握研發部門整體狀況，不必等月報。

系統提供紀錄與可視化，評分本身仍需要主管的專業判斷與校準。

研發績效常見問題

研發團隊適合用 OKR 還是 KPI？

兩者都需要，但用途不同。OKR 適合設定每季要突破的方向，例如縮短開發週期或驗證新技術；KPI 適合監控需要長期穩定的交付與品質表現。建議 OKR 不直接與獎金連動，KPI 以團隊層級為主。

OKR 達成率 70% 算好還是不好？

依 Google re:Work 指南，挑戰型 OKR 的理想得分落在 0.6 到 0.7。若團隊總是 100% 達成，往往代表目標設得太保守。但若是「承諾型」目標，例如法規要求的交期，則應以完全達成為標準，設定時要先說清楚屬於哪一種。

工程師績效考核可以用程式碼量或工時嗎？

不建議作為主要依據。SPACE 框架的研究者就指出，開發者生產力無法用單一指標衡量。程式碼量與工時容易被操弄，也無法反映設計品質與協作貢獻，應以成果、品質與影響力的具體事例為主。

技術預研失敗了，研發績效要怎麼評？

先區分「結果失敗」與「執行不佳」。若團隊依計畫完成實驗、及早產出可決策的證據並誠實回報，即使結論是不可行，也應被視為有價值的成果。考核時看的是假設是否清楚、方法是否嚴謹、學習是否轉化為後續決策。

研發績效考核多久做一次比較好？

多數企業採半年或一年一次正式考核，搭配每季 OKR 回顧與每月一對一面談。正式考核的頻率不必太高，但回饋要經常，讓工程師不會到年底才第一次知道主管的評價。

小型研發團隊需要校準會議嗎？

需要，但可以簡化。即使只有兩位研發主管，也應該一起看彼此的評分與理由，確保標準一致；若只有一位主管，可邀請產品或生產主管提供跨部門觀察，降低單一主管的主觀偏差。

結論：研發績效要分層設計，才能兼顧創新與紀律

研發績效管理的關鍵不是找到一個完美指標，而是分層設計：用 OKR 讓團隊聚焦挑戰型目標、用研發 KPI 監控交付與品質健康度、用職級期望與多面向證據進行工程師績效考核，再透過校準會議確保公平。老闆可以從三件事開始：先為研發團隊寫出第一季 OKR、挑選 4 到 6 個團隊層級 KPI、建立研發職級期望。制度跑過兩三個季度後，研發績效就會從「看不懂」變成「看得見、談得清楚」。

讓研發主管學會帶人與設目標：戰國策戰勝學院企業內訓

研發績效制度能否落地，關鍵在研發主管是否會設定目標、給回饋與做校準。戰國策戰勝學院自 2000 年起為企業提供管理培訓，企業內訓課程可依貴公司研發團隊的規模與產業特性，客製化 OKR 設定、績效面談與跨部門協作等主題，讓主管在課堂上直接演練自家團隊的 OKR 與考核表。若需要從制度面重新設計職級、考核與獎酬連動，也可搭配顧問輔導服務，協助規劃與試行。

資料來源：Google re:Work：Set goals with OKRs、What Matters：What is an OKR?、DORA：Software delivery performance metrics、Microsoft Research：The SPACE of Developer Productivity（ACM Queue, 2021）、勞動基準法（全國法規資料庫）