衡量工程生產力#
本章由 Ciera Jaspan 撰寫，Riona Macnamara 編輯。Google 作為一家資料驅動的公司，致力於以客觀數據支持產品與設計決策。然而，衡量軟體工程中「人」的面向充滿挑戰。為此，Google 組建了一支專門研究工程生產力的跨領域團隊，成員涵蓋軟體工程研究者、通才工程師，以及認知心理學和行為經濟學等社會科學專家。
本章以 Google 內部的 readability 流程（可讀性審查流程）為實際案例，完整展示如何從「是否值得衡量」到「選擇指標」再到「採取行動」的完整方法論。
為什麼要衡量工程生產力？#
規模化的困境#
當企業想要擴大業務範圍（例如從搜尋引擎進入企業應用、雲端或行動市場），通常需要擴大工程團隊。然而根據 Brooks 在《人月神話》（The Mythical Man-Month）中的觀察：
- 組織規模線性增長時，溝通成本會二次方增長
- 單純增加人力無法讓業務範圍線性擴展
另一條路：提升個人生產力#
除了增加人力，還有另一種方式——讓每個人更有生產力。若能提升個別工程師的生產力，就能在不增加等比溝通開銷的情況下擴大業務範圍。
Google 的做法是建立一個持續改善循環：
- 了解什麼讓工程師有生產力
- 識別工程流程中的低效之處
- 修正已識別的問題
- 重複以上循環
效率的考量#
改善流程本身也需要人力資源。如果花費 50 個工程師年才能理解並解決生產力瓶頸，卻只提升了相當於 10 個工程師年的生產力，那就不值得。因此目標不僅是改善生產力，更要高效率地改善。
Google 的工程生產力研究團隊#
Google 組建了一支專門的研究團隊，採用資料驅動的方法來衡量與改善工程生產力。團隊的獨特之處在於納入了社會科學家，使團隊不僅能研究工程師產出的軟體產物，還能理解軟體開發中的人性面向：
- 個人動機（personal motivations）
- 激勵結構（incentive structures）
- 管理複雜任務的策略
分類篩選：是否值得衡量？#
衡量本身是昂貴的——需要人力來測量流程、分析結果並向公司傳播。衡量過程可能拖慢工程組織，追蹤進度也可能改變工程師的行為，甚至掩蓋根本問題。Google 設計了一系列篩選問題，幫助團隊判斷是否值得啟動生產力衡量。
四個關鍵問題#
1. 你期望什麼結果？為什麼？#
即使我們想假裝自己是中立的調查者，但實際上我們都有先入為主的觀念。在一開始就承認這點，可以幫助我們處理偏見，防止事後對結果進行合理化解釋。
以 readability 為例：團隊承認他們不確定結果。人們過去確信流程的成本是值得的，但隨著自動格式化工具（autoformatters）和靜態分析工具的出現，沒有人完全確定。越來越多人認為這個流程已淪為一種「入門儀式」（hazing ritual）。
2. 如果數據支持你的預期結果，會採取什麼行動？#
如果不會採取任何行動，那就沒有衡量的意義。注意，「維持現狀」本身也可以是一種行動——前提是如果沒有這個結果，原本計畫會有所改變。
Readability 團隊的回答很直接：如果效益足以證明成本合理，他們會在 FAQ 中連結研究數據，並廣泛宣傳以設定期望。
3. 如果得到負面結果，會採取適當行動嗎？#
這是最常阻止專案進行的問題。研究團隊經常發現，決策者對結果感興趣，但無論結果如何都不會改變決定。如果負面結果不會改變決策，衡量就不值得。
Readability 團隊作出了強有力的承諾：如果分析顯示成本超過效益或效益微不足道，他們會終止整個流程。由於不同程式語言在格式化工具和靜態分析的成熟度不同，評估會按語言逐一進行。
4. 誰來決定根據結果採取行動？何時行動？#
確保請求衡量的人就是有權採取行動的人（或直接代表該決策者）。還需了解什麼形式的資料能說服決策者：
- 有些決策者透過訪談故事產生同理心來做決定
- 有些信賴調查數據
- 有些只信任日誌分析
- 有些能接受複雜的統計分析
如果決策者原則上不相信結果的呈現形式，衡量同樣沒有意義。
Google 的研究者雖然不基於軼事做決策，但會使用結構化訪談（structured interviews）和案例研究（case studies）來深入理解現象，為量化數據提供脈絡。軼事之所以持續存在，是因為它們能提供原始數字無法傳達的情境與敘事。
不值得衡量的常見情境#
以下是 Google 發現不值得衡量的典型情況：
- 目前無力改變流程或工具：可能有時間或財務限制。例如明知換用更快的建置工具能節省大量時間，但轉換期間需要暫停開發，而重要的資金截止日期即將到來
- 結果即將被其他因素推翻：例如在計畫性組織重組前衡量軟體流程，或衡量即將棄用系統的技術債
- 決策者有根深蒂固的觀點：某些利害關係人只相信特定類型的方法，而這些方法不適用於當前問題
- 結果只會作為虛榮指標（vanity metrics）：用來支持本來就要做的事。這是 Google 最常告訴人們不要衡量的原因
- 可用指標不夠精確：指標可能被其他因素混淆。使用不精確的指標（例如程式碼行數）得到的結果將無法解讀
衡量軟體流程的成功不在於證明假設的正確或錯誤，而在於提供利害關係人做決策所需的資料。如果利害關係人不會使用這些資料，專案必定失敗。只有在具體決策會基於結果而做出時，才應該衡量軟體流程。
使用 Goals/Signals/Metrics 框架選擇有意義的指標#
確定值得衡量後，下一步是決定用什麼指標。程式碼行數（LOC）顯然不行——正如 Dijkstra 所言，程式碼行數不應被視為「產出的行數」而應被視為「花費的行數」。
Google 使用 GSM（Goals/Signals/Metrics）框架來指導指標的建立：
| 層級 | 定義 | 說明 |
|---|---|---|
| Goal（目標） | 期望的最終結果 | 以高層次描述想要理解的事物，不包含具體衡量方式 |
| Signal（信號） | 如何知道已達成結果 | 我們希望衡量的事物，但本身可能無法直接衡量 |
| Metric（指標） | 信號的代理量測 | 我們實際能衡量的東西，可能不是完美的衡量，但足夠接近 |
GSM 框架的三大好處#
1. 避免路燈效應（Streetlight Effect）
「路燈效應」源自「在路燈下找鑰匙」的寓言：如果只看得到的地方，可能並非正確的位置。先設定目標，再推導信號與指標，可以避免只用手邊容易取得的指標來衡量。
2. 防止指標蠕變（Metrics Creep）與指標偏差（Metrics Bias）
GSM 鼓勵在實際衡量之前，用有原則的方法事先確定合適的指標集。如果事後結果不符預期，利害關係人可能提議改用其他指標——而因為一開始沒有基於原則選擇，就無法說他們是錯的。GSM 讓利害關係人可以清楚看到指標如何對應到原始目標。
3. 顯示衡量覆蓋範圍
執行 GSM 流程時會列出所有目標並為每個目標建立信號。不是所有信號都能衡量——這沒關係！至少我們已識別出哪些是無法衡量的，並據此評估是否值得建立新指標。
可追溯性#
最重要的是維持可追溯性（traceability）：對於每個指標，都應能追溯到它所代理的信號，以及它試圖衡量的目標。
Goals：設定目標#
目標應以期望的屬性來撰寫，不引用任何指標。目標本身不可衡量，但一套好的目標是所有人在進入信號和指標階段前能達成共識的基礎。
QUANTS：生產力的五個核心面向#
Google 研究團隊發現，人們在衡量時常忘記納入生產力中的所有可能權衡。例如一個團隊可能過度專注於提升速度，而忘了衡量品質。為了對抗這種傾向，團隊將生產力分為五個核心面向，使用助記詞 QUANTS：
| 面向 | 英文 | 關鍵問題 |
|---|---|---|
| Q — 程式碼品質 | Quality of the code | 程式碼品質如何？測試案例是否足以防止迴歸？架構是否能有效降低風險？ |
| U — 工程師注意力 | Attention from engineers | 工程師多常進入心流（flow）狀態？通知干擾多嗎？工具是否鼓勵上下文切換？ |
| A — 智識複雜度 | Intellectual complexity | 完成任務需要多少認知負荷？問題的固有複雜度是什麼？工程師是否需要處理不必要的複雜性？ |
| N — 節奏與速度 | Tempo and velocity | 工程師完成任務的速度？發布速度？在給定時間內完成多少任務？ |
| T — 滿意度 | Satisfaction | 工程師對工具是否滿意？工具是否滿足需求？是否感到倦怠？ |
| S | (包含在上述各項中) |
這五個面向之間存在權衡關係。團隊應在每個面向都考慮目標，確保不會在改善其中一個面向的同時，不經意地拖累其他面向。
Readability 案例的目標設定#
| QUANTS 面向 | 目標 |
|---|---|
| Quality | 工程師因 readability 流程寫出更高品質的程式碼；寫出更一致的程式碼；貢獻於程式碼健康文化 |
| Attention | 無相關目標（並非所有問題都涉及全部五個面向，這是正常的） |
| Intellectual | 工程師透過 readability 流程學習 Google 程式碼庫和最佳編碼實踐；在過程中獲得指導 |
| Tempo | 工程師因 readability 流程更快速、更有效率地完成工作 |
| Satisfaction | 工程師看到 readability 流程的好處，並對參與流程有正面感受 |
Signals：定義信號#
信號是我們得知是否達成目標的方式。信號與目標之間不是一對一的關係：每個目標至少有一個信號，但可能有更多；某些目標也可能共享同一個信號。
以 readability 流程為例的部分信號：
| 目標 | 信號 |
|---|---|
| 工程師寫出更高品質的程式碼 | 獲得 readability 認證的工程師認為自己的程式碼品質高於未獲認證者；readability 流程對程式碼品質有正面影響 |
| 工程師學習程式碼庫與最佳實踐 | 工程師回報從 readability 流程中學到東西 |
| 工程師在流程中獲得指導 | 工程師回報與資深審查者有正面互動 |
| 工程師更快完成任務 | 獲得認證者自認更有生產力；其變更清單的審查速度更快 |
| 工程師對流程有正面感受 | 工程師認為 readability 流程是值得的 |
Metrics：確定指標#
指標是信號的可衡量代理（measurable proxy）。因為是代理，所以可能不是完美的衡量。因此，某些信號可能有多個指標，藉此三角測量底層信號。
指標的限制與處理#
- 人類認知可能有誤：自我評估容易受偏見影響
- 日誌指標可能不完整：未必捕捉到工程師花費時間的全貌，也可能被未知因素混淆
- 某些信號可能無法衡量：例如程式碼品質——學術界提出許多代理指標，但沒有一個真正捕捉到它。在 readability 案例中，團隊決定不使用不良的代理指標做量化衡量，而是讓工程師自評程式碼品質
如果多個指標顯示不同結果，表示其中可能有誤，需要進一步探索。如果結果一致，則對已接近真相更有信心。
Readability 案例的三個資料來源#
最終，readability 的生產力影響評估結合了三種來源的指標：
- Readability 專屬調查（Readability Survey）：在工程師完成流程後進行，獲取即時回饋。可避免回憶偏差（recall bias），但引入近因偏差（recency bias）和抽樣偏差（sampling bias）
- 大規模季度調查（Quarterly Survey）：追蹤非 readability 特定但預期會受其影響的項目
- 開發者工具的細粒度日誌指標（Logs Data）：判斷工程師完成特定任務所需的時間
使用日誌指標來評估個別工程師的表現是有害的。若生產力指標被用於績效評估，工程師會迅速操弄指標（game the metrics），使其失去衡量和改善整體生產力的功能。唯一讓這些衡量有效的方式是放棄衡量個人，轉而衡量整體效果。
完整的 Goals/Signals/Metrics 對照#
以下為 readability 案例的完整對照摘要：
Quality of the code（程式碼品質）
| 目標 | 信號 | 指標 |
|---|---|---|
| 寫出更高品質的程式碼 | 獲認證者自認程式碼品質較高 | 季度調查：對自身程式碼品質感到滿意的工程師比例 |
| readability 流程對品質有正面影響 | Readability 調查：認為審查對品質無影響或有負面影響的工程師比例 | |
| Readability 調查：認為參與流程改善了團隊程式碼品質的工程師比例 | ||
| 寫出更一致的程式碼 | 審查者提供一致的回饋與指引 | Readability 調查：反映審查者意見與標準不一致的工程師比例 |
| 貢獻於程式碼健康文化 | 獲認證者在程式碼審查中定期評論風格與可讀性問題 | Readability 調查：回報定期在審查中評論風格與可讀性的工程師比例 |
Intellectual Complexity（智識複雜度）
| 目標 | 信號 | 指標 |
|---|---|---|
| 學習程式碼庫與最佳實踐 | 工程師回報從流程中學習 | Readability 調查：回報學到四個相關主題的工程師比例 |
| Readability 調查：認為學習或獲得專業知識是流程優勢的工程師比例 | ||
| 在流程中獲得指導 | 與資深審查者有正面互動 | Readability 調查：認為與審查者合作是流程優勢的工程師比例 |
Tempo/Velocity（節奏與速度）
| 目標 | 信號 | 指標 |
|---|---|---|
| 更有生產力 | 獲認證者自認更有生產力 | 季度調查：回報高生產力的工程師比例 |
| 完成流程正面影響速度 | Readability 調查：認為缺乏 readability 降低團隊速度的工程師比例 | |
| 變更清單審查更快 | 日誌：有/無 readability 作者的 CL 中位審查時間 | |
| 變更清單更容易通過審查 | 日誌：有/無 readability 作者的 CL 中位 shepherding 時間 | |
| 變更清單更快完成審查 | 日誌：有/無 readability 作者的 CL 中位提交時間 | |
| 不對速度產生負面影響 | Readability 調查：認為流程負面影響速度的工程師比例 | |
| Readability 調查：認為審查者及時回應的工程師比例 |
Satisfaction（滿意度）
| 目標 | 信號 | 指標 |
|---|---|---|
| 正面感受 | 視為整體正面體驗 | Readability 調查：回報整體正面體驗的工程師比例 |
| 認為流程值得 | Readability 調查：認為流程值得的工程師比例 | |
| Readability 調查：認為審查品質是優勢的工程師比例 | ||
| 不感到挫折 | 不視為令人挫折的流程 | Readability 調查：認為流程不確定、不清楚、緩慢或令人挫折的工程師比例 |
| 季度調查：對自身工程速度感到滿意的工程師比例 |
使用資料驗證指標#
即使遵循 GSM 框架，選定的指標仍可能無法完整呈現全貌，因為它們未能捕捉到預期的信號。Google 使用質性資料來驗證量化指標。
經驗取樣研究的啟示#
Google 曾建立一個衡量工程師中位建置延遲（median build latency）的指標，目標是捕捉工程師的「典型體驗」。團隊接著進行了經驗取樣研究（experience sampling study）——在工程師執行建置後自動發送小型問卷。結果發現，某些情況下工程師回報他們並未啟動建置！原來是自動化工具觸發了建置，工程師並未等待這些結果，因此不算是「典型體驗」。團隊隨後調整指標，排除了此類建置。
Google 的經驗是：當量化指標與質性指標不一致時，通常是量化指標未能捕捉到預期的結果。
量化 vs. 質性指標的互補#
| 面向 | 量化指標 | 質性指標 |
|---|---|---|
| 優勢 | 提供規模與統計力量；可跨公司、長時間衡量 | 提供情境與敘事；解釋工程師為何選擇特定工具或工作流程 |
| 限制 | 不提供脈絡或敘事 | 難以規模化 |
| 適用場景 | 確認整體趨勢與效果 | 理解原因並提出下一步改善建議 |
採取行動與追蹤結果#
研究完成後，Google 的團隊總會準備一份改善建議清單，可能包括：
- 為工具新增功能
- 改善工具延遲
- 改善文件
- 移除過時流程
- 調整工程師的激勵結構
建議應盡可能是工具驅動的（tool driven）。告訴工程師改變流程或思維方式的效果有限；應始終假設只要工程師擁有適當的資料和合適的工具，他們就會做出適當的權衡。
Readability 案例的結果#
研究顯示 readability 流程整體而言是值得的：
- 滿意度：達成 readability 認證的工程師對流程感到滿意，並認為自己從中學到東西
- 速度：日誌顯示他們的程式碼審查更快、提交更快，即使考慮到不再需要那麼多審查者
- 改善空間：工程師也指出了痛點，這些痛點可以讓流程更快或更愉快
語言團隊根據這些建議改善了工具與流程，使其更快速、更透明，讓工程師有更好的體驗。
結論#
Google 發現，配置一支工程生產力專家團隊對軟體工程有廣泛的好處。與其依賴每個團隊各自摸索提升生產力的方法，一個集中化的團隊可以專注於複雜問題的廣泛解決方案。
這類「以人為本」的因素出了名地難以衡量。變更工程流程涉及的許多權衡難以精確衡量，且常有意想不到的後果。因此，這樣的團隊必須保持資料驅動，並致力於消除主觀偏見。
TL;DRs#
- 衡量前先問可行動性：在衡量生產力之前，先確認無論結果是正面或負面，都能據此採取行動。如果無法對結果做任何事，很可能不值得衡量
- 使用 GSM 框架選擇有意義的指標：好的指標是你試圖衡量的信號的合理代理，且可追溯回原始目標
- 用 QUANTS 覆蓋生產力的所有面向：確保不會在改善一個面向（如開發速度）的同時犧牲另一個面向（如程式碼品質）
- 質性指標也是指標：考慮建立調查機制來追蹤工程師信念的縱向指標。質性指標應與量化指標一致；若不一致，通常是量化指標有誤
- 建議應融入開發者工作流程與激勵結構：雖然有時需要建議額外的訓練或文件，但如果改變能融入開發者的日常習慣，變革更可能發生