1

我們為什麼應該

度量工程生產力

這個問題才是工程效能要解決的問題：

「隨著組織規模的線性增長，溝通成本也會呈二次曲線增長。」

增加人員對於擴大您的業務範圍是必要的，但是溝通管理成本不會隨著您增加人員而線性增長。不過，還有另一種方法來解決我們的規模化問題：我們可以讓每個人的工作效率更高。如果我們能增加透過提高組織中單個工程師的工作效率，我們就可以擴大業務，而不會相應地增加溝通開銷。

然而，提升生產力也有成本。所以，我們的目標不只是要提升軟體工程生產力，而且是要有效地做到這一點。

在谷歌，我們透過建立一個致力於瞭解工程生產力的研究人員團隊來解決這些權衡問題。

我們的研究團隊包括來自軟體工程研究領域的人和通才軟體工程師，同時，還包括來自不同領域的社會科學家，包括認知心理學和行為經濟學者。他們的加入讓我們不僅可以研究工程師生產的軟體工件，還可以瞭解軟體開發的人的方面，包括個人動機、激勵結構和管理複雜任務的策略。

該團隊的目標是採用資料驅動的方法來衡量和提高工程生產力。

2

第一步：研究

這值得度量麼？

在我們決定如何衡量工程師的生產力之前，我們需要知道指標什麼時候值得衡量。

測量本身的成本就很高：它需要人們測量過程，分析結果，並將其傳播給公司的其他部門。

此外，測量過程本身可能很繁重，並會減慢工程組織的其餘部分。

即使進度不慢，跟蹤進度也可能會改變工程師的行為，可能會以掩蓋潛在問題的方式改變。我們需要聰明地衡量和估計；雖然我們不想猜測，但我們不應該浪費時間和資源進行不必要的衡量。

在谷歌，我們提出了一系列問題來幫助團隊從一開始就確定是否值得衡量生產率。

我們首先要求人們以具體問題的形式描述他們想要衡量的東西；我們發現，人們越具體地提出這個問題，他們就越有可能從這個過程中獲益。當可讀性團隊找到我們時，問題很簡單：一名工程師經歷可讀性過程的成本是否值得他們可能為公司帶來的好處？

然後，我們請他們考慮他們的問題的以下幾個方面：

• 您期望的結果是什麼？為什麼？

• 如果資料支援您的預期結果，將採取什麼行動？

我們之所以這樣問，是因為如果不採取行動，那麼衡量就沒有意義了。

請注意，如果已經有計劃要這麼變更，而如果我們沒有此結果，則操作實際上可能是“維持現狀”。

• 如果我們得到否定的結果，會不會採取適當的行動？

我們問這個問題是因為：在很多情況下，我們發現，即便最後得到了否定性結果，也不會改變行動決定。即：無論結果如何，都要這麼做。

如果是這樣的話，可能就不值得衡量了。我們發現：決策者對知道結果很感興趣，但但，無論結果如何，他們也不會改弦易轍。

• 誰將決定對結果採取行動，他們將在什麼時候採取行動？

我們要求這樣做是為了確保請求測量的人是被授權採取行動(或直接代表他們這樣做)的人。

最終，度量軟體過程的目標是幫助人們做出業務決策。重要的是要了解這個人是誰，包括什麼形式的資料能讓他們信服。

透過提出這些問題，我們發現在許多情況下，度量本身根本就不值得…

這沒什麼大不了的！有很多很好的理由不去衡量工具或過程對生產力的影響。

下面是我們看到的一些不必去做度量的場景：

• 您現在負擔不起更改流程/工具的費用
• 任何結果很快都會因其他因素而失效。
• 結果將僅用作虛榮心度量，以支援您無論如何都要做的事情
• 唯一可用的指標不夠精確，無法衡量問題，並且可能會被其他因素混淆

當您成功地度量軟體過程時，您並不是要證明假設是正確的還是不正確的；成功意味著向涉眾提供他們做出決策所需的資料。

如果涉眾不使用資料，那麼這個度量研究專案就是失敗的。

只有在基於結果做出具體決策時，我們才應該度量軟體過程。

對於可讀性團隊來說，需要做出一個明確的決定。如果指標顯示該過程是有益的，他們將公佈結果。如果不是，這一程式將被廢除。最重要的是，可讀性團隊有權做出這一決定。

3

第二步：選擇

透過目標（Goal）

和訊號（Signal）

選擇有意義的指標

在Google，我們使用目標/訊號/指標(GSM)框架來指導指標建立。

• Goal 是指：目標，即期望的最終結果。它是根據您想要在高層次上理解的內容來表述的，不應該包含對衡量它的具體方法的引用。
• Signal 是指：訊號量，就是你能知道是否你已經達到最終結果的方式。訊號是我們想要測量的東西，但它們本身可能是不可測量的。
• Metric 指標體系，它們是訊號的代理。這是我們實際上可以測量的東西。這可能不是理想的衡量標準，但我們認為它已經足夠接近了。

它可以防止路燈效應。

“在路燈下找鑰匙”，比喻為：假如你只在你能看到的地方找丟失的鑰匙，那麼，你很可能找錯地方了。

對於指標，當我們使用我們可以輕鬆獲得的指標時，就會發生這種情況，無論這些指標是否適合我們的需求，都是可得到且且很容易衡量。

相反，GSM迫使我們思考哪些指標實際上將幫助我們實現目標，而不是簡單地考慮我們現有的指標。

GSM透過鼓勵我們在實際測量結果之前使用原則性方法提出適當的指標集，從而幫助防止指標蔓延和指標偏見。

GSM可以告訴我們哪裡有測量覆蓋範圍，哪些是無法覆蓋的地方。當我們執行GSM流程時，我們列出所有目標，併為每個目標建立訊號。

目標 Goals

目標應該有一組屬性，就像“平衡計分卡”一樣。

訊號 Signals

訊號「Signals」是我們知道我們已經實現目標的方式。並不是所有的訊號都是可以測量的，但在這個階段這是可以接受的。訊號和目標之間不存在1：1的關係。每個進球都應該至少有一個訊號，但他們可能有更多的訊號。一些目標可能也有相同的訊號。

指標 Metrics

指標體系「Metrics」是我們最終決定如何測量訊號的地方。指標體系本身不是訊號；它們是訊號的可測量代理。

因為它是代理人，所以，很可能不是完美的度量項。因此，當我們嘗試對底層訊號進行三角測量時，某些訊號可能具有多個度量。

此外，某些訊號可能沒有任何關聯的指標。因為這個時候訊號可能根本無法測量。例如，度量程式碼質量。

4

第三步：使用資料

驗證指標體系

量化指標很有用，因為它們可以為您提供推進力和規模化。

你可以在很長一段時間內衡量整個公司工程師的經驗，並對結果充滿信心。

然而，它們沒有提供任何背景或敘述。

定量指標無法解釋為什麼工程師選擇使用過時的工具來完成他們的任務，或者為什麼他們採取不尋常的工作流程，或者為什麼他們繞過標準流程。只有定性研究才能提供這些資訊，只有定性研究才能洞察下一步改進過程的步驟。

5

第四步：行動

採取改善行動，並跟蹤其結果

回想一下我們的最初目標：我們想要採取行動，提高生產率。

在對一個主題進行研究之後，谷歌的團隊總是會準備一份建議清單，告訴我們如何才能繼續改進。

我們可能會向工具建議新功能，改善工具的延遲，改進文件，刪除過時的流程，甚至更改工程師的激勵結構。

理想情況下，這些建議是“工具驅動的”：如果工具不支援工程師這樣做，告訴他們改變他們的流程或思維方式是沒有好處的。相反，我們總是認為，如果工程師擁有合適的資料和合適的工具，他們就會做出適當的權衡。

5

結語

• 在衡量生產率之前，不管結果是積極的還是消極的，都要詢問結果是否可行。如果你不能對結果做任何事情，那麼它很可能不值得衡量。
• 使用GSM框架選擇有意義的指標。一個好的度量標準是您試圖測量的訊號的合理代理，並且它可以追溯到您最初的目標。
• 選擇覆蓋生產力所有部分的指標(定量)。透過這樣做，您可以確保您不會以犧牲另一個方面(如程式碼質量)為代價來提高生產率的一個方面(如開發速度)。
• 定性指標也是指標！考慮建立一種調查機制來跟蹤工程師信念的縱向指標。
• 定性指標也應該與定量指標保持一致；如果它們不一致，很可能是不正確的定量指標。
• 旨在建立內置於開發人員工作流程和激勵結構中的建議。儘管有時有必要推薦額外的培訓或文件，但如果將其構建到開發人員的日常習慣中，則更有可能發生更改。

6

每個指標的五大衡量屬性QANTS ：

1. Quality of the code
2. Attention from engineers
3. Intellectual complexity
4. Tempo and velocity
5. Satisfaction

— THE END —

文章轉自，持續交付2.0