當測量變成目標：從窗戶稅到 Pull Request 數

前言

我在某次工作中，曾經自己寫了小工具，用來統計我（以及其他團員）本季貢獻了多少 Pull Request、留下多少 Review Comments、解掉了多少 Tickets，想要藉此向主管證明我的產出與貢獻。

主管看了我的報告後，淡淡地說績效評估不只看產出而已，還會看影響力，以及你帶來了什麼樣的價值。當時我有點生氣，覺得自己明明做了這麼多，卻沒有得到應有的獎勵。

我當時有點生氣，就問主管：「你的意思是說，我都偷懶不產出是可以的嗎？」主管當時沒有正面回答這個問題。而我理所當然沒有拿到理想的績效。

過了幾年，我終於理解主管的話，甚至感謝他並沒有直接誇獎我的產出。當測量變成了目的，就會失去測量的意義。

把指標玩壞的故事

1696 年，英國開始向房子的窗戶課稅。窗戶越多，稅越重。通常窗戶多的就是有錢人家，方便稅務官在街上數，不用進屋。

為了減少稅率，全國的窗戶一扇一扇被砌磚封起來，新建的房子甚至不開窗戶了。在當時的英國流行傳染病，沒有窗戶導致房子通風不佳，人們更容易罹患傳染病。

古埃及人在尼羅河旁蓋了專門的尼羅河水位計，用每年氾濫的高度來設定當年的稅率。水位高度是絕對造不了假的自然指標，然而規避並沒有因此消失。

既然無法改變稅率，農民就去少報耕地面積、賄賂量地的書吏、在上繳的穀物裡塞石頭湊重量。國家於是又得派人全程盯著收割、輸送穀物。稅率高的情況下邊際效益遞減，農民也就自然不想提高產量。

1902 年越南河內，為了滅絕老鼠政府公告可以用一條鼠尾換賞金。結果出現只割尾巴後放生的老鼠，甚至出現專門養老鼠的人。鼠患沒有解決反而更嚴重。

當測量變成目標，他就不再是一個好的測量了

為什麼代理指標如此迷人？

測量指標是一件極為重要的事，在軟體開發中有一個詞叫做「可觀測性（Observability）」。讓數字可見是軟體開發很重要的一環，有了數字我們才知道該如何改進、修正錯誤。

• 資料庫連線數暴增：可能是某段 SQL 沒有寫好導致 slow query 佔滿了連線數
• CPU 占用過高：可能是資料量太大導致計算量直線上升
• API 回應時間顯著增加：可能是依賴的第三方服務出現故障

測量是幫助我們找到問題並改善產品的重要手段之一。問題在於，很多公司上層對測量指標帶來的影響一知半解，沒有理解到一旦開始測量指標，讓數字變得好看就會變成目的之一。自古以來都是如此。

用 Pull Request 數、解決的 Bug 數、LLM Token 數、程式碼行數來評估開發者的產出，開發者就會為了讓數字變好看而作出對應的行為，例如故意把系統寫爛一點、把一個 Pull Request 可以解決的功能拆成 10 個、專門寫一個自動化工具讓 AI 不斷生出無意義的程式碼。當測量變成目標，它就不再是一個好的測量了。

更幽微的影響甚至會體現在日常開發。若用這些代理指標來評估績效，代表著不鼓勵團隊內互相幫助，因為幫助其他同事代表犧牲了自己的 Pull Request 數，也沒有動機讓產品變得更好。

重要的指標難以測量

真正重要的指標是難以測量的。因為績效通常都要與數字綁定，拿不出數字等於你無法說明你帶來的影響。

開發者的產出難以量化，為了方便就用 Pull Request 數、LLM Token 數、Bug 數這些顯而易見的代理指標。產出好像提升了，工程團隊變得更忙了，但產品似乎沒有變得更好。

鳳凰專案裡的一句話讓我印象深刻——重要的是結果，而非工作量。重點是為了什麼而測量，而非測量什麼。

是啊，我們是為了什麼而測量呢？代理指標太方便了，一不小心我們就會把真正重要的事情擱置一旁。

對於團隊的生產力來說，什麼是重要的事呢？其實在 Google 的 Project Aristotle 中可以略知一二。

這是 Google 從約 2012 年開始，2015 年公開的內部研究，分析了旗下上百個團隊，想找出什麼讓團隊有生產力。他們發現團隊成員是誰遠不如團隊如何互動重要，具體來說有下列這幾個因素，重要性排名如下：

1. 心理安全性：成員敢於冒險、示弱、承認錯誤而不怕被羞辱或報復
2. 可靠性：準時交付、達到品質標準
3. 角色期待：角色、目標、計畫明確
4. 意義：工作對個人有意義
5. 影響力：相信工作有實質貢獻

這五個因素難以量化，以心理安全性來說他可能體現在：

• 我是否能輕鬆在 Slack 發問而不必擔心被罵
• 我是否可以向資深的開發者提問並獲取我需要的一切資訊
• 在剛上工的一個禮拜，我是否清楚知道接下來要做的事有哪些

這些指標難以測量，卻是影響團隊產出相當重要的因素，他們都是數字無法告訴你的事。既然它難以測量，也就難以被發現。

在某次會議中，我和上層討論估時的目的與期待效果。

會議中，我發現雙方對估時的目的有相當大的落差。

我認為估時主要是為了對齊需求，確保雙方在實作上的認知統一，不應該當作團隊的產出指標，上層則認為估時是為了讓他們評估開發者是否進步、安排後續時程、了解團隊產出的指標。當估時制度導入時，團隊感受到的是壓力與承諾，如果給出較長的估時，上層會質疑為什麼要那麼久；如果給出較短的估時卻沒達標，上層會斥責為什麼沒有遵守估時。

團隊不敢貿然估時，害怕一旦估時就是給出上線時程，也不敢積極對齊需求，因為害怕需求認知不同導致重新開發。明明只是想要理解團隊的產出而已，為什麼反而越變越糟？

當測量變成目標，它就不再是一個好的測量了。

結論

身為開發者，指標帶來的好處是毋庸置疑的。然而當測量變成目標，它就不再是一個好的測量了。尤其身為上位者，通常你就是定義指標的那個人，制定指標的人與負責達到指標的人不同，容易遇到權責不平衡的問題。

測量是個強大的工具，知道他的極限在哪裡，才有辦法善用它。除了數字本身，數字外那些難以量化的事情，或許才是我們更值得追求的事。