在 4 月 20 日舉行的《中國企業軟體研發管理白皮書》釋出會上，DevOps 與研發效能資深技術專家張樂老師做了一場名為《研發效能的升維思考和降維執行》的主題演講，闡述瞭如何系統化思考研發效能的關鍵要素、互動結構及實施路徑，並將其與落地執行有機結合起來。以下為張樂老師的演講內容摘錄。
首先我要支援一下《中國企業軟體研發管理白皮書》，在我看來這是特別好的一個載體。因為我們之前看到很多與研發管理相關的內容都是從國外引入的，比如 DevOps 現狀調查報告等。這次非常開心能夠看到我們本土輸出的研發管理的實踐經驗，為廣大研發效能管理者和從業人員提供參考，這是一次有益的嘗試。
回到正題，今天我分享的話題是「研發效能的升維思考和降維執行」，希望能給大家帶來一些啟發。
研發效能到底怎麼提升？
當我們談論研發效能時，所指代的內容、談論的焦點可能並不完全相同。所以在講研發效能怎麼提升之前，我們首先要回答的是：大家談論的研發效能到底是什麼？我把這個問題拋給了最近很火的 ChatGPT，同時也在行業裡調研了一些軟體工程師。
大家的回答裡羅列了很多有助於研發效能提升的要素，比如目標、流程、方法、技能、知識、工具，還有團隊溝通等。這些內容為我們找到效能提升的突破口提供了一些線索，但相對區域性和片面，並無法直接回答「組織研發效能如何提升」這個綜合性的問題。
所以，我們今天講研發效能的升維思考，首先是要清楚地知道總體目標是什麼，與達到目標相關的要素有哪些，以及這些要素之間的關聯關係是什麼。只有這樣，才能看到問題的本質，有效提升效能。
如下圖所示，我從管理、工程和技術三個關鍵維度出發，對影響研發效能的關鍵要素進行了一些梳理：
第一個是管理維度，強調透過流程、文化和人來幫助組織提效。從效率層面看，首先要關注的一個點與需求相關。行業裡有句話叫「GIGO（Garbage in garbage out）」，如果你的輸入是低質量的，那麼你的輸出也是低質量的。這就要求我們在研發源頭一定要避免開發不靠譜的需求，而例項化需求的實踐能夠幫助我們。
從質量層面看，測試/安全左移、質量門禁、各種應用變更管理等都可以對質量的提升產生促進作用。那這些要素怎麼才能對工程師的體驗產生很好的影響呢？一個行之有效的方法就是標準化和簡化研發流程。比如說有沒有一些在 Code Review 階段就能發現的問題？有沒有在自動掃描階段就能發現的問題？透過流水線能否自動檢出 Bug？而不是所有的變更都要走重量級的審批流程。
第二個是工程維度，也就是透過自動化、一致性的方式來執行研發活動。
從效率層面看，程式碼分支怎麼管？是主幹開發還是分支開發，還是 Git Flow？這些不同的分支模型，都會對研發效率產生很大影響。除此之外，還有自動化構建/測試、環境治理、部署釋出等，也都會對團隊的交付週期和交付效率產生影響。
在質量層面，程式碼評審、單元測試都是工程維度經常需要考慮的實踐。跟大家分享一個資料，近期騰訊釋出了《2022年騰訊研發大資料包告》，裡面提到程式碼評審的參與率是 74.6%，程式碼評審的千行評論數為 15.3 個。也就是說參與程式碼評審的每 1000 行程式碼，就有 15 個評論。這說明程式碼評審這件事是在實實在在地做，而不是表面功夫。
那麼從工程維度看，怎麼最佳化我們研發工程師的開發體驗呢？就是透過自動化流程，減少手工重複的工作，讓大家聚焦在業務程式碼的開發上。
第三個是技術維度，側重於應用和基礎設施架構的設計和實現，以及新技術的應用。
比如雲原生，還有現在非常火的 ChatGPT。很多同學已經開始嘗試讓 ChatGPT 幫助我們細化需求，生成概要設計，或者在區域性做程式碼補全、程式碼重構，以及自動生成一些測試。可以說，智慧化開發、智慧化測試、智慧化運維逐漸走進我們的視野了。
但問題是，這些要素不能單獨存在，因此我們需要一個抓手，將這些要素體系化，才能真正落地到實際中。
研發效能的黃金三角模型
在 2021 年，我提出了「研發效能黃金三角」的框架，將效能實踐、效能平臺和效能度量統一起來。經過這兩年的持續探索和實踐沉澱，我把這個模型升級成了 2.0 版本，在框架裡增加了更多細節描述，比如效能實踐地圖、效能平臺的五個層次、效能度量的五項精進等，目的是讓我們對於研發效能提升的理解具有全域性性和系統性。
總的來說，落地研發效能提升工作，並不是只關注效能實踐、效能平臺、效能度量這三件事就可以了，這還是一種靜態思維。我希望我們去思考要素和要素之間的互動、關聯關係，並讓這些要素形成一個彼此強化、持續最佳化的增強迴路。這個增強迴路能夠把研發效能裡的優秀實踐沉澱到工具平臺上，透過一站式的平臺來承載這些研發實踐，幫助我們做規模化的擴充套件；而效能平臺又會產生大量資料，支撐我們做效能的度量與分析，形成持續改進的閉環。
研發效能的實踐地圖
黃金三角看上去還是比較抽象，所以我在裡面寫了一些落地的條目：比如在效能實踐裡，我們需要關注產品導向的交付正規化，關注敏捷精益協作、持續交付的工程實踐、雲原生的持續交付等。我將這些內容總結歸納成了「研發效能的降維執行——效能實踐地圖」，如下圖所示：
裡面的要點有很多，我著重講一下產品導向的交付正規化。如下圖，我將產品導向與專案導向的交付模式從多個維度進行了對比：
首先，從思維模式來看。世界上很多舉世矚目的工程都有專案管理理論的支撐，比如甘特圖，它是由亨利·勞倫斯·甘特在 1917 年所創，隨後被用於修建當時世界上最大的混凝土結構——胡佛大壩。值得注意的是，甘特圖在當時的使用場景是高確定性的基礎設施工程，重複性工作多，不確定性工作較少。
在類似的場景下，用這種管理正規化足夠了。但是，我們不能指望兩次工業革命之前的正規化到今天的數字化時代依然奏效。現如今，大環境是快速的、迭代的，其顯著特徵是易變性、不確定性、模糊性、複雜性，那麼研發正規化也需要做相應的調整才行。所以現在的研發專案管理，除了專案導向外，也要考慮產品導向。
什麼是產品導向的思維模式呢？就是要承認不確定性，用迭代的思路去解決不確定環境的問題，持續交付業務價值。
去年我翻譯了一本書 Project to product，書名直譯是《從專案到產品》，但最終我認為，《價值流動》這個書名更能體現書中要表達的內容，因為這本書強調我們要考慮價值在企業裡跨越多個部門的流動，要從端到端的視角去看企業全域性的價值交付過程，而不是某個組織、某個部門的區域性過程。
為什麼很多企業有技術債？一定程度上是專案模式導致的。一個專案是有終點的，到截止時間之後，沒有人再願意投入資源。那時工作會指派給一個人，讓他在做新專案的同時再去維護老專案，這就導致大量沒有人願意維護的技術債務變得越來越多。但如果從產品導向來解決這個問題，會容易一些。
其次，從成功標準來看，專案導向是以成本中心的運營模式，以按時、按預算完成專案既定的交付內容來作為成功標準。但是產品導向，是把業務成功作為真正的成功標準，它更聚焦於增量的價值交付。
專案導向是把人安排在工作上，一個人在一年裡可能換了七八個專案，但他很難在每一個專案裡都有積累、跟團隊磨合得很好，也很難產生很高的效能。而產品導向，就是要長期穩定的團隊來負責長期穩定的產品，從而產生長期穩定的價值。另外，這兩種模式在組織與團隊、驅動模式和可見性等方面都有著完全不同的處理方式。
說到可見性，我們不得不提到「西瓜現象」——常被用於描述專案管理中未暴露的問題。西瓜表面是綠色的，裡面的瓤是紅色，就好像我們在專案管理過程中，向上彙報時認為進度一切正常，最後上線前才發現上不了。這是為什麼？因為本質的問題沒有被暴露。因此，產品導向就是要解決這個問題，把可見性暴露出來，透過迭代持續的最佳化，讓過程變得更透明。
除了產品導向的交付正規化外，持續交付也是我們在「效能實踐地圖」中要格外關注的。
雲原生的持續交付實踐
在雲原生時代，我們不禁追問：雲原生的持續交付跟普通的持續交付到底有何種區別？要考慮這個問題，我們先要搞清楚雲原生到底有什麼不同，我認為主要有三個點：
- 可以透過程式碼去管理基礎設施（ IaC，Infrastructure as Code）；
- 微服務和容器化，能夠幫助我們更簡化、更解耦地開發和部署應用；
- 更完善的釋出控制，比如各種灰度策略等。
那麼，接下來的問題是，雲原生的持續交付該怎麼做？概括來說，雲原生的持續交付就是在雲原生的技術底座之上，用 CI/CD 串聯上下游工具鏈和底層的工具平臺，最後做到全流程的自動化。
效能平臺的多視角設計
大家很關注工具，但如果只是把多個工具整合在一起，那只是做了第一步，更高階的方式是貼合具體研發場景實現多視角的設計。
要做好工具平臺的建設，就要從三個視角出發，分別是產品視角、專案/空間視角、應用視角。這三層是一個相互巢狀的關係，越往外層越是產品和業務導向的；越靠內層越是工程和技術導向的。參見下圖：
先看最容易理解的專案視角/空間視角。我們現在進入到任何一個 DevOps 平臺，都會要進入到一個專案/空間中。負責某個產品或某個部分工作的團隊在這裡工作，他們分解需求、寫程式碼、做測試，完成部署釋出。這裡的關鍵點是，各個領域的工具怎麼才能有機整合在一起，高效支撐工程師的工作。這就需要跨領域互聯互通的能力，讓開發、測試、運維之間的研發活動能夠銜接得更絲滑。
不過，只有空間或者專案視角是不夠的。在一個大的專案裡，可能有 1000 個人，500 個服務，幾萬條流水線。這種資訊爆炸會讓團隊成員不容易聚焦在自己關注的工作上。
如果以應用為中心來組織 DevOps 流程，就可以讓工程師聚焦在自己負責的應用上，管控整體流程。這跟雲原生的大思路是一致的，在雲原生之前，開發看的是程式碼，運維看的是機器。但是在雲原生時代，開發和運維看的都是應用。
那麼怎麼從應用視角去提升效率呢？既然雲原生時代以應用為中心，那我們可以採取應用模板的方法。
比如企業裡有 300 個應用，那麼可以透過同一個應用模板把 300 個應用建立出來。這樣做的第一個好處，就是透過應用模板去沉澱雲原生時代的最佳實踐和規範，一鍵化地建立應用，實現研發管理規範性的提升。第二個好處就是效率的提升，極大簡化開發過程和運維過程。
不過還存在一個問題：業務人員更關心業務需求什麼時候被受理、有沒有被開發、能否上線，並不關注細節程式碼。所以有什麼樣的辦法能把這些工作也管理起來呢？思路就是在產品視角里完成：從產品角度透視需求流轉及相關研發活動，確保產品全生命週期得到良好的管理。
這三個視角相互解耦，不同角色可以專注於各自的職責和目標，高效完成自己的工作。它們又相互連線，構成一個有機整體。不同視角中的底層資料是同一份，研發資訊也能夠互聯互通。透過這個有機的整體：
- 在應用視角，我們以應用為中心，實現雲原生的持續交付，對工程師日常工作，尤其是工程類的工作流程進行最佳化。
- 在專案/空間視角，我們以需求（特性）的流動為主線，拉通了交付團隊內各角色的高效敏捷協作，也實現了跨應用的研發協同。
- 在產品視角，我們以產品生命週期管理為目標，實現了複雜業務或產品的跨空間協作。
最終，透過一站式研發效能平臺的多場景、多視角設計，可以支撐研發全鏈路的高效、高質量、可持續的交付。
總的來說，在專案或者空間視角里，我們看到的是每一個產品需求、每個研發團隊的研發過程；在業務視角里，我們看到的是雲原生的持續交付；在產品視角里管理業務需求，我們能夠看到業務需求的流動。三者既分離又相互整合，從而形成一個生態共同體，幫助我們持續最佳化研發過程，這就是多視角的研發效能平臺建設。
效能度量的五項精進
最後我們談一下度量。我之前整理過一個模型，叫「研發效能度量的五項精進」。
- 度量基礎設施建設：包括價值流網路、工件網路、工具網路；
- 度量指標體系：要讓結果指標牽引整體，讓過程指標賦能一線；
- 洞察分析模型：包括分析思路、模型建立、分析方法和分析場景；
- 度量產品建設：從資料、資訊，到知識、智慧，要讓轉化過程自動化；
- 資料驅動的實驗思維：目的是讓研發效能可量化、可分析、可提升。
尤其要注意的是，對單一維度過度解讀是很危險的事情，所以我們需要透過指標組合，比如「北極星指標+群星指標+圍欄指標」，來得到一個比較完整的流量指標體系，從而牽引著效能的提升。
總結和展望
對於研發效能的提升，首先是要升維思考，我強調研發效能不是解決區域性的效率問題，也不是單點的工具或資源問題，而要從全域性化、系統化的角度去尋求解決方案。同時，我們還要降維執行，要下鑽到一線去解決具體的問題，並結合新技術與時俱進。
最近，我們已經看到大模型的技術在行業裡面的探索應用，相信未來我們有機會從各個維度去重塑研發生產力，讓研發過程獲得十倍甚至更高的效能提升。
就讓我們一起擁抱創新，持續探索，共同構建未來。