工程師實務上面對到的bug，有可能是個人負責部分bug、單一團隊內分工產生的bug或是跨team bug，亦或是前面三者混合在一起的bug。但往往因為團隊分工、個人績效評分方式，只能解決個人部分的bug，無法把其他原因導致的bug有效解決。
當一個指標成為目標，它通常就不再是好指標。
重點不是打造完美 KPI，而是讓「隱瞞問題、推掉責任、快速關issue」不再比「揭露問題、追查到底」更划算。
| KPI 設計 | 容易產生的扭曲 |
|---|---|
| 發現 bug 數 | 拆分小問題、專挑別人的錯 |
| 解決 bug 數 | 優先搶容易關閉的 ticket |
| 結案速度 | 修一半、過早結案 |
| 零事故 | 隱瞞或降低事件等級 |
| 跨 Team 貢獻 | 製造很多表面協作紀錄 |
| QA 通過率 | 減少測試強度，讓報表好看 |
這其實就是 Goodhart’s law：
當一個指標成為目標，它通常就不再是好指標。
比較現實的做法不是把所有價值都 KPI 化，而是分成三層。
一. 團隊KPI只衡量結果
二. 個人績效保留主管判斷
三. 用制度防止最壞行為
第一層 團隊 KPI 只衡量結果
團隊層級可以使用較難造假的指標：
| 團隊指標 | 觀察內容 |
|---|---|
| 端到端成功率 | 使用者最後是否成功完成流程 |
| 問題復發率 | 同類問題是否再次出現 |
| 偵測時間 | 問題發生多久後團隊才知道 |
| 修復時間 | 從確認問題到恢復正常所需時間 |
| Production 趨勢 | 客訴、錯誤率、延遲是否實際下降 |
這些指標用來判斷系統有沒有變好，不直接切成每個人的分數。
第二層 個人績效保留主管判斷
個人貢獻改用少數具體案例，而不是計數：
在什麼情境下，這個人增加了什麼資訊、做了什麼判斷，最後造成什麼可驗證的結果？
例如：
- 找到原本無法重現的觸發條件。
- 將跨 Team 問題追到 root cause。
- 完成修復並加入回歸測試。
- 建立 trace，讓未來事件可被定位。
這仍然包含主觀判斷，但它至少要求主管提出具體證據，而不是只靠印象、關係或聲量。
第三層 用制度防止最壞行為
有些事情不必做成加分 KPI，只要設成不可違反的工作規則：
- 不得因 QA 無法重現就宣稱沒有問題。
- 不得把 bug report 人格化為找碴。
- 問題轉交必須由下一位 Owner 明確接手。
- 跨 Team 問題必須指定 DRI(註1)。
- 沒有 root cause 時，必須留下下一步與更新時間。
- 主動揭露問題不得單獨成為扣分理由。
這些規則不是用來選出誰最優秀，而是防止組織用錯誤方式處理真實資訊。
所以現實可行的制度不是：
而是：
這仍然不可能完全客觀，因為主管是否理解技術貢獻、是否願意維護公平，依然很重要。制度最多只能降低任意解釋的空間，無法取代人的判斷。
因此原句可以改得更符合現實：
主管無法把所有貢獻精確制度化，但可以建立最低規則：讓提出問題不會吃虧、問題不會因跨 Team 消失，並要求績效評價以具體證據說明發現者與解決者的貢獻。
重點不是打造完美 KPI，而是讓「隱瞞問題、推掉責任、快速關issue」不再比「揭露問題、追查到底」更划算。這是很大的制度進步。
補充:
註1:
DRI = Directly Responsible Individual，可翻成「直接負責人」或「單一責任人」。
他的責任不是親自完成所有工作，而是確保整件事：
- 有人持續追查
- 跨 Team 工作有人協調
- 下一步、負責人與期限明確
- 不會因責任轉交而消失
- 最後有驗證結果並正式結案
例如一個聊天軟體的訊息漏失問題：
| 角色 | 責任 |
|---|---|
| 發現者(可能是App RD, QA或使用者) | 提供現象、證據與重現路徑 |
| App Team | 檢查 Client 端 |
| Backend Team | 檢查 Server、Queue 與同步機制 |
| QA | 驗證修復與回歸測試 |
| DRI | 串起以上工作，把問題追到真正解決 |
所以 DRI 不等於「背鍋的人」，也不一定是主管或最會寫那段程式的人。比較準確的理解是：大家可以分工，但 DRI 負責確保事情不會掉在分工的縫隙裡。