谷歌工程生產力團隊擁有約 2000 名工程師，致力於提升開發者工具和流程效益。團隊內還有一支專注於研究工程生產力的小組，他們關注的不僅僅是「怎麼做」，更多的是「為什麼做」，「什麼時候做」，「做多少」。

這是一個混合方法團隊，既進行定量研究，也進行定性研究。團隊中大約一半是工程師，另一半是用戶體驗研究員，他們來自行為經濟學家、社會心理學家、產業組織心理學家甚至公共衛生領域。

Jaspan 指出，社會科學背景為團隊提供了必要的背景。日誌分析通常是工程生產力研究的一個常見起點，但它只呈現了部分信息。她在播客中表示：「它告訴你開發者做了什麼，但未告訴你其動機和感受。它沒有評估行為的優劣，也沒有揭示改進空間。它只給了你一個數字，但你不能解釋這個數字。除非你擁有更多定性的世界觀，你了解行為以及這些行為隨時間的變化，取決於你如何改變背景。」

因此，大約五年前，生產力研究團隊首次聘請了第一位用戶體驗研究員，以協助設計更好的調查問卷。通過將用戶體驗研究員與工程師配對，他們優化了問題的內容、時間和方式。例如，這種配對使得體驗抽樣成為可能，將調查問卷融入開發者的構建過程中。工程師提供實踐經驗和技術解決方案，支持用戶體驗研究。

Green 表示：「直接接觸那些在領域內非常深入且處於領域頂尖水平的專家，是行為研究方法中非常有力的補充。領域專業知識、來自工程領域的可擴展性和技術技能結合多樣化的行為研究方法，以及對偏見、工作方式和調查回應或訪談注意事項的理解，這些社會科學家們共同為谷歌的用戶體驗研究提供了一種或許獨特的方式。」用戶體驗研究員們揭示了非響應偏見，而工程師們則發現了上游問題，因為事情看起來不太對勁。

開發者生產力是整個組織的目標

這個團隊的首要客戶是為整個組織構建開發工具的第一方開發團隊。目標是幫助他們改進基礎設施工具、流程和最佳實踐。

「例如，當他們想要了解如何提高開發者生產力時，我們的數據和研究是他們尋找答案的地方之一，」Green 說道。

生產力研究團隊還與運營、房地產和工作空間、公司工程等團隊合作，這些團隊為所有谷歌員工創建工具，而不僅僅是工程師，以及其他可能影響整體開發者體驗的團隊。當然，開發者生產力的體驗也可能惠及其他非技術團隊，前提是要進行跨公司的溝通。

「因此，當你關注工程生產力時，你實際上是關注了谷歌的一大部分人口，因此對我們的發現有廣泛的興趣，」Green 表示。

谷歌的工程生產力團隊還充當著不同開發團隊之間的橋樑。正如 Jaspan 所說：「公司非常大，人們在做不同類型的開發工作。構建工具的人可能不知道正在進行的所有不同類型的工作。」

所有這些都為 Green 所說的「形成良好數據的遊樂場」提供了條件，配合具有實際問題經驗的工程師。

速度、便利和質量推動生產力

那麼，如果你擁有谷歌的工程預算，你會衡量什麼呢？

隨著平台工程的興起和跨組織工具的整合，追蹤技術開發者體驗變得更加容易。然而，技術對人類用戶的影響以及圍繞這種體驗的人員和流程仍然具有挑戰性。沒有單一的度量可以完全捕捉到這一點。

Jaspan 表示，開發者生產力研究團隊堅持一個理念：沒有單一的指標可以衡量開發者生產力。從這裡開始，她解釋道，團隊通過三個交叉的維度進行三角定位：

• 速度
• 便利
• 質量

例如，Green 曾經以半開玩笑的方式提出，為了說明一個觀點，最快提高生產力的方法可能是取消代碼審查。當然，大家都抵制這個想法，因為雖然這樣可以提高發布的速度和便利性，但會降低質量。而團隊的研究已經證明，代碼質量可以提高開發者的生產力。

在速度方面，他們確實會測量日誌，但他們還會測量工程師對自己速度的感知，以及進行日記研究和訪談。Jaspan 說：「這既包括使用多種測量方法，也要確保它們彼此之間是相互驗證的。」

綜合方法研究驗證數據

為了更深入地研究谷歌的軟體開發行為，團隊進行了跨工具日誌研究，從多個開發者工具中提取了日誌。他們還進行了日記研究，在這個研究中，工程師每隔幾分鐘就寫下他們在做什麼。他們將這兩種方法進行比較，以便在數據日誌方面建立信心。由於每個工程師的工作和感知都不同，可能會出現類似「蘋果和橙子」的情況，因此他們應用了稱為「多評判者可靠性」的方法來計算這兩個研究之間的一致性。

「我們假設在外面有一些真實情況，如果我們不坐在開發者旁邊，可能無法直接觀察到，」Green 說道，「因此，我們將這兩個數據源結合起來，問：這兩種視角是否在告訴我們同一個世界的信息？」

數據日誌研究可以大規模被動進行，無需干擾工程師，而日記研究一次只能由最多 50 名工程師進行，並且可能會變得令人討厭。

「一旦我們找到了足夠的證據表明這兩個數據源提供了相同的信息，我們就可以更加倚重可擴展的方法，」他解釋道。

技術債務與工程滿意度調查

自 2018 年以來，谷歌另一個強大的測量工具是每季度進行的工程滿意度調查，每次向大約三分之一的工程人員發送。Green 承認，最初高管們對這種測量有些猶豫，因為這只是「人們的意見」。在 2020 年的疫情封鎖期間，這項調查首次顯示出生產率的增長，隨後在下一個季度出現了大幅下降，因為居家隔離常常會讓人們感到孤單。

已經證明，技術債務會對開發者的士氣產生負面影響，並減緩開發速度，因此不奇怪，早期的調查中就包含了兩個關於技術債務對生產力影響的問題：

• 你遇到的技術債務的根本原因是什麼？
• 什麼措施適合修復這些技術債務？

多年來，Jaspan 和 Green 的團隊對這些回答進行了整合，最終確定了可能妨礙工程生產力的 10 個技術債務類別：

• 需要遷移或正在進行遷移。
• 項目和 / 或 API 的文檔難以找到，缺失或不完整。
• 測試質量或覆蓋率較差。
• 代碼質量設計不佳。
• 未刪除已死亡和 / 或被放棄的代碼。
• 代碼庫質量降低，未跟上變化的標準。
• 團隊缺乏必要的專業知識。
• 依賴關係不穩定，變化迅速，或觸發回滾。
• 遷移執行不佳或被放棄，可能導致維護兩個版本。
• 需要更新、遷移或維護髮布流程。

工程師可以選擇任何一個或多個選項。產生的數據揭示了不同受眾（如機器學習工程師與後端工程師）需要不同的技術債務干預措施。他們還根據組織線對數據進行切割，以顯示和比較在克服技術債務方面的進展。

關於這個技術債務問題的論文承認，基於調查的度量是滯後指標，只有當技術債務嚴重到足以妨礙工程師時，才會顯現出真正的問題。然而，在探索了 117 個度量指標之後，谷歌團隊仍然沒有找到並預測技術債務將在何時妨礙生產力。

他們還添加了四個問題，了解團隊如何管理債務，以尋求持續改進。

隨著這項調查對整個組織變得越來越重要，工程副總裁開始提出自己的問題。這在一段時間內是有幫助的，但隨後調查必須被重新精簡。現在，每個季度由不同的用戶體驗研究員負責調查，得到不同工程師的支持，同時伴隨著團隊的反饋。Green 承認，這項調查仍然相當「龐大」。

無論你的組織規模（和預算）如何，都鼓勵你投資於自動化和可測量的、觀察性和經驗性的研究，以了解你的開發者體驗以及它支持或妨礙的生產力。

請記住，隨著團隊和代碼的變化，度量指標也會發生變化。正如 Jaspan 所說：「我們知道沒有一個單一的度量可以衡量開發者生產力，因此我們嘗試使用所有這些不同的研究方法來觀察：它們是否都一致？它們是否在告訴我們發生了相同的事情？還是它們不一致？如果是這種情況，我們需要深入挖掘發生了什麼。」

作者簡介：

Jennifer Riggins 是一個文化與科技故事敘述者、記者、作家，以及活動和播客主持人，她致力於分享文化與技術交匯的故事，並解釋我們正在構建的技術所帶來的影響。自 2003 年以來，她一直從事寫作工作，目前居住在倫敦。

原文連結：

https://thenewstack.io/how-google-unlocks-and-measures-developer-productivity/#circle=on

京東闢謠「劉姓商人涉嫌違法被抓」；比特大陸全員工資暫停發放；一周可居家辦公3 天，去哪兒靈活辦公制度出爐｜Q資訊

主力開發已經 68 歲了！「老齡化」嚴重的 Postgres 開源社區呼喚「年輕一代」

無服務計算，廠商究竟在打什麼算盤

放棄 React 改用 Web 組件，微軟這次重構讓開發者不解：沒有任何意義