透過人類衡量開發人員生產力

衡量開發人員生產力是一項艱難的挑戰。專注於開發週期時間和產出的傳統指標有限,而且沒有明顯的答案可以轉向其他地方。質化指標提供一種強大的方式,可以使用從開發人員本身衍生的資料來衡量和了解開發人員生產力。組織應優先使用人類的資料,而非系統的資料來衡量開發人員生產力。

2024 年 3 月 19 日


Photo of Abi Noda

Abi Noda 是 DX 的創辦人兼執行長,專注於協助組織衡量和改善開發人員生產力。作為一名程式設計師和研究員,Abi 定期發布有關開發人員體驗的內容和研究。在 DX 之前,Abi 是 Pull Panda 的創辦人兼執行長,該公司於 2019 年被 GitHub 收購。

Photo of Tim Cochran

Tim Cochran 是 Amazon 軟體建置體驗 (ASBX) 團隊的負責人。他之前是 Thoughtworks 的技術總監。

Tim 擁有超過 20 年與規模化企業和大型企業合作的經驗。他提供技術策略建議,並進行正確的技術投資,以實現數位轉型目標。他是開發人員體驗的直言不諱的倡導者,並熱衷於使用資料驅動的方法來改善它。


此刻,某處正有一位技術主管對董事們說:「我們需要一種方法來衡量工程團隊的生產力。」一個工作小組召集起來探討潛在的解決方案,幾週後,建議實施下列指標:提前時間、部署頻率和每位工程師建立的拉取請求數量。

不久後,資深工程主管開會檢視他們新建立的儀表板。問題和疑慮立刻出現。一位主管說:「我們的提前時間是兩天,根據那些基準,這是『表現不佳』——但實際上真的有問題嗎?」另一位主管說:「看到我們有些團隊的部署頻率低於其他團隊,這不足為奇。但我不知道這是否表示有改善的機會。」

如果你對這個故事很熟悉,別擔心——大多數人都很熟悉,包括世界上一些最大的科技公司。當像 DORA 這樣的指標無法提供主管們所希望的見解時,量測計畫失敗是很常見的。

不過,有一個更好的方法。一種專注於從開發人員本身擷取見解的方法,而不是僅依賴速度和產出的基本衡量標準。我們幫助許多組織跳躍到這種以人為本的方法。我們親眼見證了它大幅提升了對開發人員生產力的理解。

我們在這裡指的是定性衡量。在本文中,我們提供了一份入門指南,說明這種方法,它源自我們在協助許多組織進行這趟旅程的經驗。我們從定性指標的定義以及如何倡導它們開始。接著,我們提供有關如何擷取、追蹤和利用這些資料的實用指南。

如今,在財政緊縮和 AI 等轉型技術的背景下,開發人員生產力已成為企業的一項重大考量。此外,隨著企業將目光投向敏捷和 DevOps 轉型之外,開發人員體驗和平台工程也越來越受到關注。所有這些考量都有個共通點,就是依賴衡量來協助指導決策和追蹤進度。而定性衡量是關鍵。

註:當我們說「開發人員生產力」時,我們指的是開發人員能夠順利完成工作,而不是開發人員的個人表現。有些組織發現「開發人員生產力」是一個有問題的術語,因為開發人員可能會誤解其含義。我們建議組織使用「開發人員體驗」一詞,對開發人員來說,這具有更正面的含義。

什麼是質化指標?

我們將定性指標定義為由人類提供的數據組成的測量。這是一個實用的定義——我們尚未在社會科學中找到單一的定義,而我們所見過的備用定義存在我們稍後在本節中討論的缺陷。

圖 1:定性指標是從人類衍生的測量

「指標」一詞的定義是明確的。然而,「定性」一詞沒有權威的定義,正如 2019 年期刊論文 定性研究中的定性是什麼 中所述

定性研究有很多定義,但如果我們尋找一個定義來解決其「定性」的獨特特徵,那麼社會科學廣泛領域的文獻資料就很少了。這篇文章背後的主要原因在於悖論,直截了當地說,研究人員表現得好像他們知道它是什麼,但他們無法制定一個連貫的定義。

我們聽過的另一個備用定義是,定性指標測量品質,而定量指標測量數量。我們發現這個定義有兩個問題:首先,「定性指標」一詞包含了指標一詞,這意味著輸出是一個數量(即測量)。其次,品質通常通過轉換為數值和分數的序數尺度來測量——這再次與定義相矛盾。

我們聽到的另一個論點是,情緒分析的輸出是定量的,因為分析結果是數字。雖然我們同意情緒分析產生的數據是定量的,但根據我們的原始定義,這仍然是一個定性的指標(即定性產生的數量),除非有人認為「定性指標」完全是一個矛盾修辭。

除了定義質化指標的問題外,我們也遇到了有問題的口語。一個例子是「軟性指標」這個詞。我們告誡不要使用這個詞,因為它有害且錯誤地暗示從人類收集的資料比從系統收集的「硬性指標」較弱。我們也不鼓勵使用「主觀指標」這個詞,因為它誤解了從人類收集的資料可以是客觀或主觀的事實,正如我們在下一節中所討論的。

質化指標:從人類衍生的測量
類型定義範例
態度指標對特定主題的主觀感受、意見或態度。在 1 到 10 的範圍內,您對您的 IDE 有多滿意?
行為指標與個人工作經驗有關的客觀事實或事件。您需要多長時間才能將變更部署到生產環境?

我們將在本文稍後提供有關如何收集和使用這些測量的指南,但首先我們將提供一個實例來說明這種方法的實踐

Peloton 是一家美國科技公司,其開發人員生產力測量策略圍繞質化指標。為了收集質化指標,他們的組織由產品運營組織的一部分技術支援與開發人員體驗團隊領導,執行半年一度的開發人員體驗調查。

技術學習和見解負責人 Thansha Sadacharam 解釋說:「我非常堅信,而且我想我們許多工程師也真正欣賞這一點,工程師不是機器人,他們是人類。僅僅查看基本數字並不能說明整個故事。因此,對我們來說,擁有一項有助於我們了解整個開發人員體驗的全面調查非常重要。」

每項調查都會發送給大約一半的開發人員的隨機樣本。透過這種方法,個別開發人員每年只需要參與一次調查,將填寫調查所花的總時間減到最少,同時仍提供具有統計意義的代表性資料結果集。技術支援與開發人員體驗團隊還負責分析調查結果並與組織中的領導人分享。

有關 Peloton 的開發人員體驗調查的更多資訊,請收聽與 Thansha Sadacharam 的這段訪談

倡導質化指標

高階主管通常對質化指標的可靠性或有用性持懷疑態度。即使像 Google 這樣高度科學的組織也必須克服這些偏見。工程領導傾向於系統指標,因為他們習慣於使用遙測資料來檢查系統。然而,我們不能依賴這種相同的方法來衡量人。

避免將質化指標和量化指標對立起來。

我們看到一些組織陷入內部的「指標之爭」,這並非明智的運用時間或精力。我們建議倡導者避免將定性指標與定量指標視為非此即彼的對立面。較好的做法是主張它們是互補的工具,正如我們在本文結尾所述。

我們發現反對定性資料的根本原因是誤解,我們將在下方說明。在本文後續,我們將概述自我報告資料的獨特優點,例如它能夠衡量無形資產並呈現關鍵脈絡。

誤解:質化資料僅為主觀

傳統的工作場所調查通常著重於員工的主觀意見和感受。因此,許多工程主管直覺地認為調查只能從開發人員收集主觀資料。

正如我們在以下章節所述,調查也可以擷取關於事實或事件的客觀資訊。Google 的 DevOps 研究與評估 (DORA) 計畫是一個絕佳的具體範例。

客觀調查問題的一些範例

  • 從提交程式碼到程式碼成功執行於生產環境需要多長時間?
  • 你的組織多久會將程式碼部署到生產環境或釋出給最終使用者?

誤解:質化資料不可靠

調查的一項挑戰在於,擁有各種背景的人撰寫調查問題時並未接受過特別訓練。因此,許多工作場所調查並未達到產生可靠或有效衡量標準所需的最低標準。然而,設計良好的調查會產生準確且可靠的資料(我們將在本文後續提供如何執行的指南)。

有些組織擔心人們可能會在調查中說謊。這可能會發生在對於資料如何使用感到恐懼的情況下。根據我們的經驗,當調查被部署為一種工具以協助了解和改善影響開發人員的瓶頸時,受訪者沒有誘因說謊或玩弄系統。

儘管調查資料並非總是 100% 準確,但我們常提醒主管,系統指標也常常不完美。例如,許多組織嘗試使用從其管線彙總的資料來衡量 CI 建置時間,但最後發現需要付出大量精力來清理資料(例如,排除背景工作、考量平行工作)才能產生準確的結果。

兩種質化指標

有兩種主要的定性指標類型

  1. 態度指標擷取針對特定主題的主觀感受、意見或態度。態度衡量標準的一個範例是針對問題「在 1 到 10 的範圍內,你對你的 IDE 有多滿意?」所擷取的數值。
  2. 行為指標擷取與個人工作經驗相關的客觀事實或事件。行為衡量標準的一個範例是針對問題「你部署變更至生產環境需要多長時間?」所擷取的數量。

我們發現,大多數技術從業人員在思考質化指標時,會忽略行為衡量。儘管在軟體研究中盛行質化行為衡量,例如前面提到的 Google 的 DORA 計畫。

DORA 公布年度基準,用於衡量變更前置時間、部署頻率和變更失敗率等指標。許多人不知道的是,DORA 的基準是使用質化方法,並透過以下調查項目擷取

前置時間

對於您處理的主要應用程式或服務,變更前置時間為何(亦即,從提交程式碼到程式碼成功在生產環境中執行需要多長時間)?

超過六個月

一到六個月

一週到一個月

一天到一週

少於一天

少於一小時

部署頻率

對於您處理的主要應用程式或服務,您的組織多久會將程式碼部署到生產環境或釋出給最終使用者?

少於每六個月一次

介於每個月一次到每六個月一次

介於每週一次到每個月一次

介於每天一次到每週一次

介於每小時一次到每天一次

依需求(每天多次部署)

變更失敗率

對於您處理的主要應用程式或服務,變更到生產環境或釋出給使用者的比例是多少會導致服務品質下降(例如,導致服務損壞或服務中斷),並隨後需要補救(例如,需要熱修補程式、回滾、前瞻修正、修補程式)?

0–15%

16–30%

31–45%

46–60%

61–75%

76–100%

復原時間

對於您處理的主要應用程式或服務,當發生服務事件或影響使用者的缺陷時(例如,非計畫性中斷、服務損壞),通常需要多長時間才能復原服務?

超過六個月

一到六個月

一週到一個月

一天到一週

少於一天

少於一小時

我們發現,能夠同時收集態度和行為資料是質化測量的強大優點。

例如,行為資料可能會顯示您的釋出流程快速且有效率。但是,只有態度資料才能告訴您它是否順利且輕鬆,這對開發人員的倦怠和留任具有重要的影響。

使用非技術類比:想像你感到不適並去看醫生。醫生量了你的血壓、體溫、心率,然後說:「嗯,看起來你沒事。你沒有任何問題。」你會嚇一跳!你會說:「等等,我告訴你,我感覺哪裡怪怪的。」

質化指標的優點

質化指標的一個論點是,它們避免讓開發人員承受管理層「被衡量」的感覺。雖然我們發現這是真的,特別是與從開發人員的 Git 或 Jira 數據中得出的指標相比時,但它並未解決質化方法可以提供的最重要的客觀優勢。

在衡量開發人員生產力方面,質化指標有三個主要優點

質化指標可讓您測量其他無法測量的項目

像前置時間和部署量這樣的系統指標可以記錄我們管道或票務系統中發生的事情。但開發人員的工作還有許多其他方面需要了解才能提高生產力:例如,開發人員是否能夠保持工作流程或輕鬆瀏覽其程式碼庫。質化指標讓你能夠衡量這些難以或無法衡量的無形資產。

技術債務就是一個有趣的例子。在 Google,一項識別技術債務指標的研究包括對 117 個被提議為潛在指標的指標進行分析。讓 Google 研究人員失望的是,沒有發現任何單一指標或指標組合是有效的指標(有關 Google 如何衡量技術債務的更多資訊,請收聽此訪談)。

雖然可能存在尚未發現的技術債務客觀指標,但可以假設這是不可能的,因為技術債務的評估依賴於系統或程式碼庫的當前狀態與其想像的理想狀態之間的比較。換句話說,人類的判斷是必要的。

質化指標提供跨團隊和系統的遺漏可見性

來自票務系統和管道的指標讓我們可以看到開發人員所做的一些工作。但僅憑這些數據無法讓我們了解全部情況。開發人員做了很多工作,這些工作沒有記錄在票證或建置中:例如,設計關鍵功能、塑造專案的方向或幫助隊友加入專案。

僅透過我們系統中的數據,不可能了解所有這些活動。即使我們理論上可以透過系統收集所有數據,透過儀器記錄指標仍有其他挑戰。

一個例子是難以在不同的團隊工作流程中標準化指標。例如,如果你試圖衡量任務從開始到完成需要多長時間,你可能會嘗試從票務工具中獲取這些數據。但個別團隊通常有不同的工作流程,這使得產生準確的指標變得困難。相比之下,直接詢問開發人員任務通常需要多長時間會簡單得多。

另一個常見的挑戰是跨系統可見性。例如,小型新創公司可以使用問題追蹤器(例如 Jira)來衡量復原時間 (TTR)。然而,大型組織可能需要整合和跨屬性資料,才能跨規劃系統和部署管道獲得端對端系統可見性。這可能需要一年的時間,而從開發人員那裡擷取這些資料可以快速提供基準。

質化指標提供量化資料的背景

身為技術人員,很容易過度專注於量化測量。畢竟,它們看起來乾淨又清晰。然而,如果沒有更豐富的資料,就有可能無法說出完整的故事,這可能會導致我們專注於錯誤的事情。

程式碼檢閱就是一個例子:典型的最佳化是嘗試加速程式碼檢閱。這似乎很合乎邏輯,因為等待程式碼檢閱可能會浪費時間或造成不必要的內容切換。我們可以衡量完成檢閱所需的時間,並激勵團隊改善它。但這種方法可能會導致負面行為:審閱者草率地完成審閱,或開發人員找不到適當的專家來執行審閱。

程式碼檢閱存在一個重要的目的:確保交付高品質的軟體。如果我們進行更全面的分析(專注於流程的結果,而不仅仅是速度),我們會發現程式碼檢閱的最佳化必須確保良好的程式碼品質、降低安全風險、建立團隊成員之間的共用知識,以及確保我們的同事不會陷入等待的困境。定性測量可以幫助我們評估是否達到了這些結果。

另一個例子是開發人員入職流程。軟體開發是一種團隊活動。因此,如果我們只衡量個別產出指標,例如新開發人員提交的頻率或首次提交的時間,我們就會錯過重要的結果,例如我們是否充分利用開發人員提出的想法、他們是否敢於提出問題,以及他們是否與跨職能同儕合作。

如何擷取質化指標

許多技術從業人員沒有意識到撰寫良好的調查問題和設計良好的調查工具有多麼困難。事實上,有許多與此相關的研究領域,例如心理測量學和產業心理學。在可能的情況下,在此方面引入或建立專業知識非常重要。

以下是撰寫調查以避免我們看到組織犯下的最常見錯誤的一些好規則

  • 調查項目需要仔細措辭,每個問題都應該只詢問一件事。
  • 如果你想比較調查之間的結果,請小心更改問題的措辭,以免測量到不同的東西。
  • 如果你更改任何措辭,你必須進行嚴格的統計檢定。

在調查術語中,「良好的調查」表示「有效且可靠」或「展現良好的心理測量特性」。效度是指調查項目實際測量到你想要測量的構念的程度。信度是指調查項目從你的族群中和隨著時間推移產生一致結果的程度。

我們發現對技術從業人員有幫助的一種思考調查設計的方式:將調查回應流程視為一種發生在人腦中的演算法。

當一個人看到一個調查問題時,會進行一系列的心理步驟才能得出一個回應。以下模型來自開創性的 2012 年書籍,The Psychology of Survey Response

回應流程的組成
組成具體流程
理解

注意問題和說明

表示問題的邏輯形式

識別問題重點(所尋求的資訊)

將關鍵字詞連結到相關概念

檢索

產生檢索策略和提示

檢索具體、通用的記憶

填入遺失的細節

判斷

評估記憶的完整性和相關性

根據可存取性進行推論

整合檢索的材料

根據部分檢索進行估計

回應

將判斷對應到回應類別

編輯回應

分解調查回應流程並檢視每個步驟,有助於我們改善輸入,以產生更準確的調查結果。開發良好的調查項目需要嚴謹的設計、測試和分析,就像設計軟體的流程一樣!

但是良好的調查設計只是執行成功調查的一個面向。其他挑戰包括參與率、資料分析,以及了解如何根據資料採取行動。以下是我們學到的一些最佳實務。

依團隊和角色區隔結果

組織領導者常犯的一個錯誤,就是專注於全公司的結果,而不是按團隊和角色(例如:職務、任期、資歷)細分的資料。如前所述,開發人員體驗高度依賴於情境,且可能因團隊或角色而有極大的不同。只專注於總體結果,可能會忽略影響公司內部小但重要的族群(例如:行動開發人員)的問題。

自由文字評論通常最有價值

我們一直在談論定性的指標,但自由文字評論是極有價值的定性資料形式。除了描述摩擦或工作流程之外,開發人員會有許多改善其開發人員體驗的絕佳點子,自由文字讓我們得以擷取這些點子,並找出後續追蹤的對象。自由文字評論也可以找出調查未涵蓋的領域,這些領域可以在未來納入調查中。

將結果與基準比較

比較分析有助於將資料置於情境中,並有助於推動行動。例如,開發人員對程式碼品質的情緒通常偏負面,這使得難以找出真正的問題或評估其嚴重性。更可採取行動的資料點是:「我們的開發人員對程式碼品質是否其他團隊或組織更沮喪?」情緒分數低於同儕的團隊,以及分數低於產業同儕的組織,可以找出顯著的改善機會。

在適當情況下使用交易調查

交易調查在開發人員工作流程中的特定接觸點或互動期間擷取回饋。例如,平台團隊可以在開發人員於內部開發人員入口網站中建立新服務時,使用交易調查提示開發人員提供回饋。交易調查也可以透過產生更頻繁的回饋和更詳細的見解,來擴充定期調查的資料。

避免調查疲勞

許多組織難以維持調查的高參與率。缺乏後續追蹤可能會讓開發人員覺得重複回應調查沒有價值。因此,領導者和團隊在調查後進行後續追蹤並採取有意義的行動至關重要。雖然每季或半年一次的調查頻率對大多數組織來說是最佳的,但我們看到一些組織成功地進行更頻繁的調查,這些調查整合到常規團隊儀式中,例如回顧。

調查範本

以下是開始進行調查的一組簡單問題。將以下問題載入您偏好的調查工具,或快速開始,複製我們的即用型 Google 表單範本

範本故意設計得簡單,但隨著您的衡量策略成熟,調查通常會變得相當龐大。例如,Shopify 的開發人員調查 長達 20 分鐘,而 Google 的調查 長達 30 分鐘以上。

收集到回應後,使用平均值或頂部方格評分對多選題進行評分。平均分數是透過將每個選項指定為 1 到 5 之間的值並取平均值來計算的。頂部方格分數是透過選擇前兩個最有利選項之一的回應百分比來計算的。

務必檢閱可能包含大量資訊的開放式文字回應。如果您收集了大量的評論,ChatGPT 等 LLM 工具可協助萃取核心主題和建議。在完成結果分析後,務必與受訪者分享您的發現,讓他們填寫調查的時間有價值。

在 [插入組織名稱],您作為開發人員或技術貢獻者工作有多容易或困難?

非常困難

有點困難

既不簡單也不困難

有點簡單

非常簡單

對於您處理的主要應用程式或服務,變更前置時間為何(亦即,從提交程式碼到程式碼成功在生產環境中執行需要多長時間)?

超過一個月

一週到一個月

一天到一週

少於一天

少於一小時

您在工作中感到高度生產力的頻率如何?

從未

很少

有時

大部分時間

始終

請評分您對以下陳述的同意或不同意程度

強烈不同意不同意中立同意非常同意
我的團隊遵循開發最佳實務
我有足夠時間進行深入工作。
我對專案中自動化測試涵蓋範圍感到滿意。
我很容易將程式碼部署到生產環境。
我對 CI/CD 工具的品質感到滿意。
我很容易為團隊的程式碼庫做出貢獻。
根據我們的目標,團隊的技術負債數量適當。
根據使用者的意見,持續檢視規格並重新設定優先順序。

請分享任何其他有關如何改善開發人員體驗的意見回饋

[開啟文字輸入區]

同時使用質化和量化指標

定性指標和定量指標是衡量開發人員生產力的互補方法。從調查中得出的定性指標提供生產力的整體觀點,包括主觀和客觀的衡量標準。另一方面,定量指標也提供顯著的優勢

  • 精確度。人類可以告訴你他們的 CI/CD 建置通常是快還是慢(例如,持續時間接近一分鐘或一小時),但他們無法報告精確到毫秒的建置時間。當我們的衡量需要高度精確度時,就需要定量指標。
  • 連續性。通常,組織調查其開發人員的頻率最多每季一次或兩次。為了收集更頻繁或持續的指標,組織必須系統性地收集資料。

最終,透過結合定性和定量指標,即混合方法,組織可以最大程度地了解開發人員的生產力和經驗。那麼,你如何同時使用定性和定量指標?

我們看到組織在使用定性指標建立基準並確定焦點所在時,會獲得成功。然後,再使用定量指標深入探討特定領域。

工程主管發現這種方法很有效,因為定性指標提供整體觀點和背景,讓大家廣泛了解潛在的機會。另一方面,定量指標通常只適用於軟體交付流程中較狹窄的範圍。

出於這個原因,Google 同樣建議其工程主管先查看調查資料,再查看日誌資料。Google 工程研究員 Ciera Jaspan 解釋說:「我們鼓勵主管先查看調查資料,因為如果你只查看日誌資料,它並不能真正告訴你某件事是好還是壞。例如,我們有一個指標追蹤變更的時間,但這個數字本身沒有用。你不知道,這是一件好事嗎?是一件壞事嗎?我們有問題嗎?」。

混合方法讓我們能夠同時利用定性和定量指標的優點,同時全面了解開發人員的生產力

  1. 從定性資料開始,找出你的首要機會
  2. 一旦您知道要改善什麼,請使用定量指標進一步深入探討
  3. 使用定性和定量指標追蹤您的進度

只有結合盡可能多的資料(定性和定量),組織才能開始全面了解開發人員的生產力。

然而,最後重要的是要記住:組織花費大量資金在高素質的人員身上,他們可以觀察並偵測基於記錄的指標無法偵測到的問題。透過深入了解開發人員的想法和意見,組織可以發掘以前被視為不可能的見解。


致謝

感謝 Laura Tacho、Max Kanat-Alexander、Laurent Ploix、Martin Fowler、Bethany Otto、Andrew Cornwall、Carol Costello 和 Vanessa Towers 對本文的回饋。

重大修訂

2024 年 3 月 19 日:發布文章的其餘部分

2024 年 3 月 13 日:發布至優點

2024 年 3 月 12 日:發布至倡導定性指標