嘉賓 | 吳駿龍 Wish China QA Director
編輯 | 嚴強
為了提高業務産能，不少網際網路企業都寄托于加人加班和拼工時的“996”工作制。不過，這樣的做法在熱烈的讨論和實踐中已經被證明了不僅收效甚微，而且還會降低員工的積極性，甚至起到反向效果，讓整個研發效能不升反降。是以，近年來不少大中小企業開始紛紛布局研發效能。
企業和團隊剛開始接觸研發效能的時候，或多或少都會産生這些疑問：研發效能具體指的是什麼？研發效能的實踐能夠幫助企業解決哪些問題？曾經大力推行研發效能的企業如今怎麼樣了？研效問題到底解決了嗎？研發效能是否會掉到“搞垮團隊”的怪圈呢？
基于以上這些問題，我們邀請了研發效能專家吳駿龍老師，來分享一下他在研發效能領域的探索。同時吳駿龍老師也是QCon+ 案例研習社【研發效能提升的避坑指南】專題的講師，将帶來「以人為本的研發效能提升最佳實踐」的分享，希望能夠給大家帶來啟發。
以下是對吳俊龍老師的專訪：
InfoQ：你最近在做什麼工作？
我目前在一家跨境電商公司負責國内測試團隊的組建、營運和提效工作。這是一家中小型的網際網路公司，國内主要負責跨境物流，業務有一定的複雜度，但是技術團隊整體規模并不大，是以效能提升是比較重要的工作。我個人主要聚焦于品質提效，即如何又快又好地保證産品的傳遞品質，這也是我的職業生涯的一個長期追求。
不同規模的公司推動品質提效的難點是不一樣的。對于大廠，難點往往在于如何打破組織壁壘，需要平衡各方的利益；而在中小型團隊，難點更多在于基礎設施的不完善，以及團隊資源的問題，需要平衡品質和效率的關系。對于後者，我的團隊目前正在通過資料驅動的方式，實作品質資料的可視化，挖掘效能低下的根因，并推動改進最“痛”的問題。通過半年多的努力，傳遞吞吐量提升了近 2 倍，線上漏測率從 10% 下降到了 3%，基本達到了預期。
InfoQ：你是怎麼對研發效能産生興趣，并走上這條職業道路的呢？
我是做測試開發工作出身的，最早在 eBay 中國，那時研發效能在國内還沒有興起，但是在國外已經不是新鮮事了。我所在的團隊最初叫 QE Infrastructure Team，做自動化工具為主，這些工具平台的閱聽人基本都是測試人員。後來我們開始做測試執行平台，它可以和持續內建流水線結合起來，便于送出代碼後快速得到品質回報，我們也可以通過在流水線中設定各式各樣的品質門禁，友善開發人員管理品質，這樣就和開發人員的工作聯系起來了。之後，我們的工具又內建了釋出平台，可以做制品傳遞和版本管理，這樣又和運維人員的工作聯系起來了。
這些工具的覆寫範圍，基本上就是現在業界所公認的研發效能提升的切入點。你可以對照下面這張圖看一看，這是來自阿裡雲效的一張截圖。後來，我們團隊被改名為 Productivity Team。類似 Productivity 的還有 Efficiency 這些單詞，其實就是我們現在所說的效能的意思。在這方面，确實國外領先很多。
研發效能提升的切入點
有了明确的組織定位，有了完善的工具體系後，我們開始倒逼流程改進，平衡品質和效能的關系，比如：代碼掃描沒有 Blocker Issue 才能合并代碼；Smoke Test 通過才能提測；Full Regression Test 通過才能釋出，除非 Leader 特批；Canary 環境 Smoke Test 通過才能切正式流量，等等。到了這個時間點，我，包括我們整個團隊，都已經不是以最初測試開發的角色去工作了，而是以效能驅動者的身份去賦能每個團隊的日常工作。
之後的幾份工作，我待過阿裡本地生活（餓了麼）這樣的大廠，也在初創公司工作過。除了品質基礎設施建設以外，我也負責容量保障，也帶過業務測試團隊，但是提效這個思維，是我始終貫穿在日常工作中的關注點。看着大家的工作效率提升，是一件既有幸福感又有成就感的事。
InfoQ：在你的研發效能提升的工作曆程中，有遇到過什麼刻骨銘心的困難嗎？有哪些總結沉澱和啟發？
困難是非常多的，我相信每個研發效能的從業人員都有一肚子的苦水。上面提到的利益沖突、基礎設施不完善、團隊認知不夠，甚至是管理層認知不夠，都不是一時半會能解決的事。
從我個人的經曆來說，遇到的最大困難并不在于技術和管理，而是如何拉齊一個組織對研發效能目标的共識。我問一個簡單的問題，你覺得研發效能提升應該得到什麼樣的結果？是你的工作更輕松了，還是你能幹更多活了？對于管理層來說，是團隊不需要加班了？還是産品傳遞更快了？如果在同一家公司的不同群體間有着大相徑庭的答案，那麼衆人就很難形成合力，有的人想輕松，有的人想折騰，這件事自然就難了。
是以，當你準備建設工具和優化流程前，不妨先深度思考，我們在這家企業推動研發效能的目的究竟是什麼，并和你的管理層保持溝通，達成共識，再去影響你的團隊和客戶，這是所有研發效能提升工作的根基。否則，你在工作中一定會遇到各種不了解和各種委屈。
InfoQ：關于研發效能的定義和說法有很多種，從你個人來看，你怎麼了解研發效能呢？它有哪些關鍵的要點？
确實，研發效能的定義很多，而且有些定義非常學院派。比如“研發效能是指使用行為目的和手段方面的正确性與效果方面的有利性，在軟體研發過程中的展現。”這樣晦澀的定義，估計大多數人都看不懂。
我想分享一個我個人比較喜歡的研發效能定義，叫做“順暢、高品質地持續傳遞有效價值的能力”，短短 10 幾個字，但是資訊量很大。我談談我的了解：
順暢：表示價值的流動過程是沒有阻礙的，這對應了流動效率，即制品不能在一個環節上阻塞太久。這是非常重要的一點，阻塞往往意味着某個環節出現了瓶頸，不及時幹預的話會影響到下遊的其它環節。
高品質：提升效率不是以犧牲品質為代價的，兩者是既要也要的關系。
持續傳遞：高頻且小批量地傳遞價值，以便項目的所有幹系人能夠及時獲悉項目進度，識别風險并應對變化。通俗地說，就是“小步快跑”。
有效價值：聚焦于真正對目标使用者有用的産品和功能。
相信你也看到了，上面談到的這些點，最後形成的是一種能力，是以研發效能更多的也是一種長期的能力建設，而不是短期的結果。不是說現在我做的很好就可以，而是要可持續地發展下去。
InfoQ：企業或團隊在度量研發效能的過程中有哪些注意點呢？
我們先要回答一個問題：軟體研發效能究竟能不能度量？
（https://martinfowler.com/bliki/CannotMeasureProductivity.html）
我個人認為研發效能是可以度量的，但是度量是相對的，也就是說，我們不應将重點放在度量結果這個數字上，更不要把度量名額機械地設定為 KPI，而是應該将度量結果作為一種現象，給到我們一個下鑽根因的入口。這是我特别推崇的一種經濟型做法，尤其是在團隊資源有限的情況下。
我可以舉一個例子，我在目前團隊中會使用測試任務前置時間（Test Lead Time，從測試人員接到測試任務，到實際開始測試的時間）作為流動效率的一個度量名額。我們希望大多數測試任務能夠在一周内完成，是以根據測試時長，倒推出前置時間要做到小于 2 天。這個名額本身并不說明問題，它的意義在于，如果前置時間遠遠超過 2 天，我們需要去尋找根因（注意，此時還不能得到測試效率有問題這個結論，不要先入為主給出任何絕對性的結論）。
在尋找根因的過程中，我們還可能需要設定更多的名額來佐證我們的一些猜測。例如，猜測研發人員的提測品質太差，導緻無法及時開始測試，此時就需要納入提測工單打回率這一名額；猜測測試人員的人效不高，無法支撐那麼多測試需求，此時就需要納入測試吞吐量這一名額，等等。還可以結合一些訪談和案例的形式，進一步逼近根因。
是以你看，我們通過度量名額的下鑽，逐漸幫助我們找到了局部效能低下的根因，于是我們就可以采取措施去改進了，改進的結果最終也會展現到度量名額上。我認為，這種将度量名額視為引路人，而不是裁判員的思路，才是更科學的做法。
度量是相對的，還展現在一個重要方面，那就是要避免橫向比較。這也是在不少企業身上所發生的度量誤區，喜歡搞排行榜，去看哪個部門落後了需要改進，這就是将本應相對的度量名額在不同的團隊間絕對化了。再以上面提到的測試任務前置時間為例，在我所負責的中國團隊，我們需要做到 2 天，但是在美國團隊，需求疊代速度較慢，5 天也不影響最終項目的按期傳遞。如果我們機械地以 2 天作為标準去橫向對比中美團隊的效能，就是不合适的。選擇适合團隊目前現狀的度量名額，聚焦于團隊自身的效能提升，也就是“自己和自己比”，是更好的實踐方法。
InfoQ：很多企業或團隊看到别人研發效能提升的方案效果很好，但應用到本公司之後，不僅沒有很好的提高他們的研發效能，甚至讓團隊的研發效能降低了，你認為這種情況的問題是出現在哪裡呢？你有什麼建議呢？
我覺得這恰恰就是研發效能的魅力所在，這個問題的本質在于，研發效能的提升是一項需要高度“與人打交道”的全局性工作，而人是研發工作中最大的變量，難以标準化、難以度量、難以控制，自然也很難有非常具體的普适的效能提升手段。
我們都知道，軟體研發是人類的智力活動，然而，這個幾乎毋庸置疑的論斷卻是許多人共同的思維盲點。我們總是不自覺地認為我們可以依靠計算機解決所有問題。這樣的例子很多，管理者喜愛推銷自動化測試，認為自動化測試能夠替代測試人員的工作，繼而降低人員的工作強度，提升效率。但如果我們隻是盲目地去引入自動化測試技術，不考慮目前團隊人員的技能水準和接受程度，那麼結果很有可能是，在自動化測試上投入的人力成本比手工測試還高，不僅沒提效，還降效了。
我并不否認自動化測試的價值，但在落地時要考慮團隊的實際情況。研發效能提升也是同理，很多時候，我們都在讨論流程要标準化，讨論研效工具要具備普适性，但是這些流程和工具是不是适合我們這個組織，是否對使用者友好呢？這方面的關注和思考還是太少了。
解鈴還須系鈴人，既然軟體研發工作是人類的活動，那麼在此之上的所有效能提升工作，都要顧及人的基本感受和合理需要。是以，對于研發效能建設，我的建議就是四個字：以人為本。轉換到具體工作中，我們可以積極借鑒同行的優秀實踐，但同時更應該去了解這些實踐背後的上下文（目标團隊規模和特點，目标人員技術水準和基礎，公司文化和價值觀，管理者的風格，等等），再結合自己所在團隊的現狀去分析是否适用，或要做出什麼改變，隻有摸透這些背後的邏輯，我們才能真正的将研發效能工具和流程有效落地。
InfoQ：你覺得在未來，進一步提升研發效能，行業有哪些發展趨勢？
我認為研發效能的發展趨勢主要有兩個方向，一個是技術層面，盡可能為“人”多做一些事情，讓“人”少做一點事情，比如低代碼、AI 技術等；另一個是管理層面，将人與人之間的協作方式不斷優化，盡可能沒有阻塞、沒有重複工作。你看，不論怎麼發展，以人為本的實質還是沒變。
我對技術層面的發展相對樂觀。現在的年輕人很少見過使用紙條打孔的程式設計方式吧，它是在 1946 年第一台計算機 ENAC 身上應用的方式。過了不到 10 年，第一種進階程式設計語言 Fortran 就誕生了（是不是第一種有争議）。再看看如今的程式設計語言，國小生都可以輕松上手，這在以往是完全無法想象的。
回到研發效能領域，低代碼甚至無代碼的理念，也就是最近幾年冒出的名詞（雖然這個概念早就有了），現在都已經有了成熟的商業級産品。通過拖拖拽拽，一個不會寫代碼的人也能完成簡單應用的搭建。未來是否能夠拓展到更複雜的應用搭建上是個看點，我們保持關注。
在管理方面，以往我們看到的都是比較籠統的靈活方法和精益管理等等，現在不少企業也開始嘗試看闆方法、需求執行個體化等更細分的實踐，這是好事。對于研發效能這樣正處于發展階段的概念，怕的不是折騰，而是沒人折騰。
InfoQ：最後，和對研發效能感興趣的小夥伴和想要嘗試提升研發效能的管理者們說些什麼吧！
坦白講，在研發效能領域，國内企業總體還是落後的。我們經曆過很長一段時間靠燒錢、人海戰術換取更高的市場占有率，進而達到赢者通吃的歲月，研發效能可以用人、用錢填上。現在發現政策不一樣了，人也沒那麼好招了，再開始節流就比較被動。我個人的感受是，很多公司還處于被迫去推動研發效能提升的階段，不是真正為了提效，而是為了省錢。
微軟現任 CEO 薩提亞·納德拉說過這樣一段話：“There cannot be a more important thing for an engineer, for a product team, than to work on the systems that drive our productivity. So I would, any day of the week, trade off features for our own productivity.”翻譯過來就是“對工程師和産品團隊來說，沒有比建構一個能夠提升研發效能的體系更重要的事了。為了提升研發效能，我願意随時舍棄某些功能的傳遞。”
時代不同了，“大魚吃小魚”已經逐漸成為了曆史，“快魚吃慢魚”才是如今時代的主旋律。我們的管理者應該将研發效能的提升視為關系到公司命運的戰略級目标，這是保持企業競争力的關鍵鑰匙。
對于從事研發效能工作的個人，我也給到三個建議（關鍵詞）：耐心、好學和開放。研發效能提升是不容易的，不要急功近利地試圖一刀切解決所有問題。如果你遇到一家重視研發效能的公司，踏踏實實的多幹幾年，耐心沉澱出屬于自己的方法論，這是你的價值，也是行業的價值。此外，研發效能作為一個熱門領域，知識量是非常大的（當然，也會出現很多偏見），希望你能夠保持學習，尤其是向同行學習，多多思考。最後，我想引用愛因斯坦的一句名言：“要解決我們面對的重要問題，不能停留在當初制造它們的思維層面上。”我們應該抱有開放的心态，嘗試突破自我，用創新思維推動研發效能提升。
衆人拾柴火焰高，希望我們能夠一起努力，為研發效能的發展和革新添磚加瓦。
嘉賓簡介
吳駿龍
Wish China QA Director
前阿裡巴巴本地生活進階測試經理，畢業于中國科學技術大學，碩士學位。在軟體品質體系、服務容量保障、服務穩定性建設、軟體研發效能等領域深耕多年，善于通過創新手段解決品質和效能難題，擁有多項國内外專利。多次受邀于業界各技術大會發表演講，傳播先進理念和方法論。極客時間《容量保障核心技術與實戰》專欄作者，暢銷書《軟體研發效能提升之美》作者。
活動推薦
如何面向新型負載從上而下做好大資料體系更新？5 月 12-14 日，QCon 全球軟體開發大會将落地北京國際會議中心，關注下一代大資料系統架構、分布式資料庫、雲原生資料湖。此外，還有業務架構、Rust、WASM、可觀測、業務安全合規、産品設計、大前端新基建、組織管理等多個熱點專題，與你一起探讨技術新趨勢。現在購票即可享受 8 折特惠，購票立減 1760 元，掃碼立即購票。