最大化開發人員效率

高效率環境中的一天

開發人員

• 查看團隊專案管理工具，然後參加站立會議，明確了解她必須處理的工作。
• 注意到開發環境已自動更新，其中包含與開發和生產相符的程式庫，且 CI/CD 管線為綠色。
• 拉取最新程式碼，進行增量式程式碼變更，透過部署到本地環境和執行單元測試快速驗證。
• 她的功能依賴於另一個團隊的商業功能。她能夠透過開發人員入口網站找到文件和 API 規格。她仍然有一些疑問，因此她跳到團隊的 Slack 房間，並迅速從另一位提供支援的開發人員那裡獲得一些幫助。
• 專注於她的任務幾個小時，沒有任何中斷。
• 休息一下，喝咖啡、散步、與同事打乒乓球。
• 提交程式碼變更，然後通過多項自動化檢查，再部署到生產環境。在生產環境中逐步向使用者釋出變更，同時監控業務和運作指標。

開發人員能夠在一天內取得增量進度，並快樂地回家。

低效率環境中的一天

開發人員

• 開始處理當天生產環境中問題的許多警示。
• 查看多個記錄和監控系統以找到錯誤報告，因為系統之間沒有彙總記錄。
• 透過電話與運作人員合作，並確定警示為誤報。
• 必須等待架構、安全性與治理小組回應她先前完成的功能。
• 一天被許多會議打斷，其中許多是狀態會議
• 注意到先前的功能已獲得審查人員的核准，她將其移到另一個分支，啟動一個冗長的夜間 E2E 測試套件，該套件幾乎總是紅色的，由一個孤立的 QA 團隊管理。
• 依賴於另一個團隊的 API，但她找不到目前的說明文件。因此，她改為與另一個團隊的專案經理交談，試圖取得查詢。尋找答案的單據需要幾天時間，因此這會阻礙她的目前任務。

我們可以繼續討論下去。但最終開發人員沒有取得太多成就，感到沮喪且缺乏動力

開發人員效率

什麼是有效率？身為開發人員，就是為你的客戶提供最大的價值。能夠以最好的方式將你的精力和創新運用在公司的目標上。有效率的環境能輕鬆地將實用、高品質的軟體投入生產；並加以操作，讓開發人員不必處理不必要的複雜性、輕率的變動或漫長的延誤，讓他們能專注於增加價值的任務。

在說明低效率環境的範例中，所有事情都比預期花費更久的時間。身為開發人員，你的日常工作充滿了無止盡的阻礙和官僚作風。這不只一件事，而是許多事。這就像被千刀萬剮而死。生產力會慢慢地被小低效率所摧毀，而這些低效率會產生複合效應。低效率的感覺會蔓延到整個組織，不只工程部門。工程師最後會感到無助；他們沒有生產力。更糟的是他們接受了這種工作方式，這種工作方式變成定義開發方式的可接受常規。開發人員會體驗到一種習得無助。

然而在提供高度有效率環境的組織中，會有一種動能感；所有事情都很容易且有效率，而且開發人員會遇到很少的阻力。他們花更多時間在創造價值上。這種沒有阻力的環境，以及透過培養持續改善的渴望和能力來支持它的文化，是公司在進行數位轉型時最難創造出來的東西。

組織會尋找方法來衡量開發人員的生產力。常見的反模式是查看程式碼行數、功能輸出，或過度專注於找出表現不佳的開發人員。最好將對話轉向專注於組織如何提供有效率的工程環境。有生產力會激勵開發人員。沒有阻力，他們就有時間進行創意思考並發揮所長。根據我的經驗，如果組織沒有做到這一點，那麼最好的工程師就會離開。當許多偉大的創新數位公司都在尋找優秀的技術人才時，沒有理由讓開發人員在低效率的環境中工作。

我們來看一個優化開發人員效率的公司範例。

案例研究：Spotify

Spotify 對他們的工程師進行使用者研究，以更了解開發人員的效率。透過這項研究，他們發現了兩個關鍵發現

1. 內部工具的零碎化。Spotify 的內部基礎架構和工具是以小型孤立的「孤島」方式建置，導致工程師必須進行情境切換和認知負擔。
2. 可發現性差。Spotify 沒有集中放置技術資訊的中心位置。由於資訊散佈在各處，工程師甚至不知道從何處開始尋找資訊。

Spotify 的開發人員體驗團隊將這些問題描述為負面飛輪；一個惡性循環，開發人員會遇到太多未知數，迫使他們做出許多孤立的決策，進而加劇分散和重複工作，最終侵蝕產品的端到端交付時間。

圖 1：Spotify 的負面飛輪

為了減輕這些複雜性，他們開發了 Backstage，一個具有外掛架構的開放原始碼開發人員入口網站，可協助將所有基礎架構產品集中顯示在一個地方，提供一致的開發人員體驗，並作為工程師尋找所需資訊的起點。

如何開始？

我在高效率環境中所描述的，就是感覺在一家完全擁抱 DevOps 文化、持續交付和產品思維的公司工作。非常明智的是，大多數公司都在努力實現這種環境。他們已閱讀 加速 和 DevOps 報告狀態。他們知道他們努力建立的是哪種類型的組織。這四個關鍵指標（前置時間、部署頻率、MTTR 和變更失敗率）是 DevOps 績效的絕佳衡量標準。

檢視 DevOps 衡量標準的一種方法是將它們視為 落後指標。它們是有用的衡量標準，可了解您的現況，並指出何時需要進行工作以找出公司應採取哪些具體措施才能改善。理想情況下，我們希望找出更具可操作性的低階成效領先指標。這與高階指標有關。它會逐級上升。這也應與其他研究來源結合，例如開發人員滿意度調查。

有大量的良好建議、實務、工具和流程，您應該用來改進。很難知道該怎麼做。我的研究顯示，有許多關鍵的開發人員回饋迴路。我建議專注於最佳化這些迴路，讓它們快速且簡單。衡量回饋迴路的長度、限制和產生的結果。當引入新的工具和技術時，這些指標可以清楚顯示開發人員成效的改善程度，或至少不會變差。

回饋迴路

我已識別出的關鍵迴路為

這些指標是根據我觀察到的可能性而制定的。並非每家公司都需要每個回饋迴路都處於高效率區間，但它們提供了具體目標來指導決策制定。工程組織應在其特定環境中進行研究，以找出哪些週期和指標對技術策略很重要。

了解哪些技術已應用於最佳化回饋迴路以及公司為此所採取的歷程很有用。這些案例研究可以提供許多想法，供您在自己的組織中應用。

圖 2：功能開發期間的回饋迴路

上方的圖表顯示了開發人員在開發期間如何使用回饋迴路的簡化表示。您會看到開發人員在過程中多個點驗證其工作是否符合規格和預期標準。需要注意的主要觀察結果是

• 如果回饋迴路較短，開發人員會更常執行它們。
• 如果回饋迴路被視為對開發人員有價值，而非純粹的官僚負擔，開發人員會更常執行並採取行動。
• 越早、越頻繁地取得驗證，可以減少後續的返工。
• 結果易於解讀的回饋迴路，可以減少來回溝通和認知負擔。

當組織無法達成這些結果時，問題會迅速加劇。開發人員會浪費大量精力。體現在等待、搜尋或嘗試了解結果所花費的時間中。這些累積起來，會導致產品開發出現重大延誤，這將表現為四個關鍵指標（特別是部署頻率和前置時間）的分數較低。

介紹微回饋迴路

從我的觀察中，你必須掌握基礎知識，也就是開發人員每天會做 10、100 或 200 次的事情。我稱它們為微型回饋迴路。這可能是修正錯誤時執行單元測試。這可能是看到程式碼變更反映在你的本地環境或開發環境中。這可能是更新環境中的資料。如果賦予開發人員權限，他們自然會進行最佳化，但我常常發現微型回饋迴路遭到忽略。這些迴路故意縮短，因此你最後會處理一些非常小的時間增量。

圖 3：微型回饋迴路會複合成份影響較大的回饋迴路。

很難向管理階層解釋為什麼我們必須專注於如此小的問題。為什麼我們必須花時間最佳化編譯階段，將執行時間從兩分鐘縮短到只要 15 秒？這可能是一項繁重的工作，可能需要將系統解耦成獨立的元件。要理解最佳化需要兩天的工作，這比較容易理解。

那兩分鐘可能會快速累積，一天可能超過 100 分鐘。這些短暫的暫停是失去脈絡和焦點的機會。它們對開發人員來說夠長，足以分心、決定開啟電子郵件或去喝杯咖啡，因此現在他們分心且無法專注，有研究指出可能需要長達 23 分鐘才能回到專注狀態並恢復高生產力。我並不是建議工程師不應該偶爾休息和放鬆！但他們應該有意識地這麼做，而不是被環境所迫。

實際上，開發人員會用有用的事情填補這些不活動的時刻來彌補。他們可能有兩個正在進行的工作，並在它們之間切換。他們可能會透過批次處理變更來降低編譯頻率。根據我的研究，這兩者都會導致程式碼整合和開發時間延遲。

最佳化到什麼程度？什麼時候才夠？想像一下，現在我們已將變更縮短到 15 秒，但我們認為可以縮短到三秒。這值得投資嗎？這取決於進行變更的難度以及它將帶來的影響。如果你能開發出一個工具或功能，可以加速 10 個團隊，那麼這可能是值得的。這正是平台思維發揮作用的地方，而不是針對個別團隊進行最佳化。

分散式系統是一項特別的挑戰。將系統拆分為不同的可部署單元（通常是微服務）有很多正當理由。然而，分散式系統也讓許多事情變得困難（請參閱微服務先決條件），包括開發人員的效率。團隊有時可能會針對團隊自主性或執行時間效能進行最佳化，但他們犧牲了開發人員的效率，因為他們沒有投資於維護快速的回饋迴路。這是我的公司遇到的非常常見的情況。

組織效率

高效能的組織已設計其工程組織以最佳化效率和回饋迴路。隨著時間推移，領導階層會創造一種文化，讓開發人員能夠對這些回饋迴路進行逐步改善。

它始於領導階層承認技術（以及消除開發團隊的摩擦）對業務至關重要。這以多種方式表現出來。

技術領導者持續衡量和重新審查效率。高效能的組織已建立一個架構，透過追蹤四個關鍵指標和對其背景很重要的其他資料點，來做出資料驅動的決策。這種文化始於執行層，並傳達給組織的其餘部分。

除了指標之外，他們還建立一個開放論壇，以傾聽每天在環境中工作的個別貢獻者。開發人員將知道他們面臨的問題，並將有許多關於如何解決這些問題的想法。

根據這些資訊，工程經理可以決定投資的優先順序。大型問題可能需要相應的大型現代化計畫來解決不良的開發人員體驗。但通常更重要的是賦予團隊進行持續改進的能力。

一個關鍵原則是擁抱開發人員體驗。通常會看到一個團隊的工作計畫專注於此。開發人員體驗意味著應使用與最終使用者產品開發相同的方法來建構技術功能，並應用相同的研究、優先順序、基於成果的思考和消費者回饋機制。

為了激勵開發人員，高效能的組織會特許經營；這表示開發人員應該有能力改善他們的日常生活。他們有一個政策，讓團隊進行逐步技術改進並管理技術負債。開發人員和產品管理之間應該有健康的資料支持討論。高效能的組織還提供開發人員創新的能力；當他們的團隊有明確的目標和對瓶頸的明確概念時，開發人員可以有創意的解決問題。這些組織還創造了讓最佳想法「浮出檯面」的方法，然後加倍投入，使用資料來評估什麼是最好的。

在承諾、衡量和授權之後，就是擴展。

在某個組織規模下，需要透過規模經濟創造效率。組織透過應用平台思維來執行此操作，也就是建立一個特別專注於提升效益的內部平台。他們投資於建立技術能力的工程團隊，以提升開發人員的效益。他們將其他開發團隊視為消費者，而他們提供的服務則像產品一樣處理。這些團隊有技術產品經理和與他們對消費團隊的影響力相關的成功指標。例如，專注於可觀察性的平台能力團隊會建立監控、記錄、警示和追蹤能力，讓團隊可以輕鬆監控其服務的正常運作，並除錯產品中的問題。

治理的需求仍然是優先事項。然而，這不應被視為一個負面的詞彙，因為它在高效率組織中的應用方式非常不同。他們從集中式流程轉向輕量級方法。這與設定和傳達護欄有關，然後輕推團隊朝正確的方向前進，而不是採用冗長的核准流程方法。當治理透過以下方式實施時，它可以在效益中扮演關鍵角色：

• 明確的工程目標
• 指定團隊和服務彼此溝通的方式
• 鼓勵有用的同儕審查
• 將最佳實務融入平台能力中
• 透過架構適能函數自動化控制

基本上，有效的組織會縮短治理回饋迴路。我將在未來的文章中進一步說明這一點。

案例研究：Etsy

Etsy 是 DevOps 運動的先驅之一。其領導人致力於將開發人員效益融入其文化中，並相信快速行動既是一種技術策略，也是一種業務策略。他們積極衡量自己快速且安全地將有價值的產品投入生產的能力，並會調整其技術投資以修復任何阻礙或緩慢因素。

Etsy 的關鍵指標之一是前置時間，其會在辦公室中即時衡量、監控和顯示。當前置時間超過某個關鍵閾值時，發布工程團隊將努力將其降低到合理的水平。其技術長 Mike Fisher 談到 Etsy 工程師「無所畏懼」地快速前進，並擁有嘗試新事物的安全網。

快速部署軟體僅是其中一部分。要真正發揮效用，軟體必須對消費者有價值。Etsy 採取資料驅動的方式，讓每個功能都有可衡量的 KPI，來達成此目標。

程式碼變更會經過一連串檢查，讓開發人員確信變更符合 Etsy 在效能、可用性、故障率等方面的 SLA。變更上線後，Etsy 的實驗平台就能擷取使用者行為指標。團隊會使用這些指標來反覆運算產品，針對相關 KPI 和使用者滿意度進行最佳化。如果最後證明變更沒有價值，就會將其清除，進而避免技術負債。

Etsy 目前有一項優先處理開發人員體驗的計畫，它有四個主要支柱

此政策代表 Etsy 領導階層對其開發人員的真正承諾。他們會持續追蹤包括 4 個主要指標在內的指標，並每月對開發人員進行調查，以擷取淨推薦值 (NPS)，來驗證其效能。

結論

本文開頭提到開發人員效能的重要性，以及其對開發人員快樂感和生產力的影響。我專注於開發人員希望達成的成果，而不仅仅是工具和技術。在進一步探討這個檢驗時，我們會看到開發人員在開發產品時經常使用的一系列回饋迴路。

我也談到微型回饋迴路中的低效率如何累積，進而影響四個主要指標和產品開發速度等較大的指標。並強調開發人員體驗作為一個原則的重要性，以及平台思維如何協助最大化效率和效能。

在接下來的系列文章中，將透過案例研究更深入探討開發人員效能和個別回饋迴路。這些文章將提供具體細節，說明組織如何達成這些數字和產生的成果。除了描述能讓這些最佳化在當地和全球層級發揮作用的組織架構和流程。

下一篇文章將從最小的微型回饋迴路開始。