[[441855]]

最近兩年軟件研發效能很熱，這也促使我去年發起了 全球軟件質量&效能大會（QECon） 但凡某件事太熱，就很容易走火入魔，更多人被帶入誤區 ，有點像當初Agile、DevOps一樣，把所有好東西都往自己籃中 裝 ，想包羅萬象、想一網打盡 …… 其實，許多優秀的實踐早已存在，不管 Agile / DevOps 在與不在。當初IBM RUP也想一統天下，如今安在？

整整20年過去了，多少Scrum敏捷教練前赴后繼，但Scrum敏捷開發模式在國內實施的效果如何？其實，效果一般。根據 去年  和 今年  的調查數據，至今天真正實施Scrum敏捷開發模式的組織只有28%左右，這其中估計還有一些是偽敏捷。

在軟件研發效能沒走火入魔之前，我覺得有必要和大家談一談  軟件研發效能的底層邏輯 ，撥開云霧，看清軟件研發效能的本質，澄清軟件研發效能的是是非非，有利于提升軟件研發效能，有利于軟件研發團隊做好明年或未來的研發計劃。

之前寫了 軟件測試的底層邏輯 和  軟件質量管理的底層邏輯 ， 今天所寫的 軟件研發效能的底層邏輯 ，就作為底層邏輯三部曲的最后一篇，算是2021年的收官之作，可能會比較犀利些，不妥之言，望多多包涵。歡迎留言參與討論。

1. 究竟什么是研發效能？

維基百科給效能（efficacy）的定義是：事物產生功效的能力，常用于通識教育、醫學和藥理學，可以忽略。然后 看百度百科的定義，基本靠譜： 效能是指有效的、集體的效應 ，即人們在有目的、有組織的活動中所表現出來的 效率和效果 ，它 反映了所開展活動目標選擇的正確性及其實現的程度 。

普華永道給出“ 組織效能關注組織效率、競爭力和員工貢獻度 ”，谷歌（Google）的GSM（Goals-Signals-Metrics）框架，關注 目標的達成 ，并轉化為 研發效能五個核心元素：代碼質量、工程師注意力、智力復雜性、速度與速率、滿意度。

其實在我之前寫的 一篇文章 已討論過，但還是要在這里澄清一下，這也是我們后面討論的基礎。概念不同，相互爭辯就沒有意義。 研發效能（R&D  Effectiveness ）是指研發團隊 對業務有實際價值的 產出 ，如果需要加上限制，可以說 效能 是 單位時間內 研發團隊對業務有實際價值的 人均產出， 而 效率 關注速度、生產力，而缺乏關注目標選擇的正確性、輸出價值 。

如果考慮到商業環境變化比較快，還需要考慮研發是否有能力適應環境的變化、是否能與時俱進，保持穩定的、有價值的交付，即我們經常所說的可持續性發展或進步。這和研發效能有關系，但其實是另一個問題，只是影響研發效能的一個重要因素。

研發效能強調效率和效果、正確性、競爭力以及對企業效益的貢獻，我們非常關注研發效能，也就毋庸置疑。

2. 研發效能如何落地？

這就需要討論研發效能的底層邏輯，那么底層邏輯是什么呢？

回到前面的定義，就是要有更高的產出，且產出的價值越高越好，在保證目標正確的情況下產出的速度、效率越快越好；可以通過內建質量（如降低復雜度、提升代碼質量）、讓員工保持高度的注意力等不斷提升效率......這樣我們就可以歸納出 研發效能的底層邏輯 就是：做正確的事 ，然后正確地做事，再追求速度 。但這三層邏輯 都依賴于人，人是決定的因素。所以 研發效能的底層邏輯第一條 是 選對人、好好培養人。

基于這樣的邏輯，研發效能的落地可分為四個層次：

1. 選對人、好好培養人，如審視公司的招聘流程、培訓和績效考核制度；

2. 做正確的事，如澄清業務戰略，明確問題、業務需求和用戶需求；

3. 正確地做事 ：如確定/選擇正確的開發模式，制定有效的組織結構和流程；

4. 追求速度 /效率 ，如不斷提高研發人員的技能，開發/購買 研發平臺，搭建DevOps工具鏈，實現高度的自動化（包括構建、部署、測試、運維）。

這里雖然比 “大象裝進冰箱” 多了一項，但還好，大家還是比較容易記得住，容易實施。比我 最近批評的一本書《軟件開發的201個原則》要好得多，正如網友說，原則太多，就沒有原則。打開書，其中有些原則真不像話，如：

• 原則4 高質量軟件是可以實現的 （我們早就知道，但現在不想，代價太高）

• 原則8  與客戶/用戶溝通 （哪個團隊不去和客戶/用戶溝通？一個動作不適合原則，原則要有明確的態度，告訴我們要做什么、不做什么，如必須 和客戶/用戶溝通 面對面溝通、 每天和客戶/用戶保持溝通 ）

• 原則34 軟件文檔都要有索引 （不一定，今天有全文搜索功能，或者 畫一個思維導圖，只要有關鍵字，但不是索引）

• 原則44 確定子集 

• ......

3. 研發效能底層邏輯第1層：解決人的問題

僅僅寫人是決定的因素，大家印象還不深刻，甚至還不同意這點 ，我還不得不說：需求是人挖掘出來的，設計也是人做的，代碼也是人寫的，測試也是人干的..... 流程也是人制定的、還需要人去執行，工具也需要人去開發和使用，總監 、經理也都是人 ......此時你該認可：研發效能底層邏輯第1層是解決人的問題，對吧？

昨天聽一個線上討論研發效能的直播節目， 有兩點很深刻 ：

• 聽眾急著要度量指標，想了解如何度量效能；

• 一位嘉賓說，有的公司把員工不當人看、當成工具。

第1點留到后面去討論，首先討論第2點： 把員工不當人看、當成工具 ，要求員工聽話，遵守流程、遵守工作紀律，員工只會干活，缺乏思考，沒有創新、發展的空間。其次，招聘流程過于粗暴簡單、 入職培訓 缺失、績效考核唯KPI指標 ..... 等等 ，沒有把 “招對人” 、“培養人” 放在第一位。

要招對人，這點可以學學亞馬遜，之前文章  亞馬遜QA/測試工程師面試究竟考察應聘者哪些能力？ 有詳細介紹 ， 招一個人要經過5～6個環節 （不算多） ，其中有一個環節比較特別，就是 設置Bar raiser。 Bar raisers是一群在各個崗位都是精英的評估人，對應聘者錄用與否擁有表決權，保證亞馬遜能招聘到優秀人才。國內公司流行誰用人，誰最后面試、誰最后決定，這很容易讓一些不合格的人進入公司/團隊，因為用人部門一般是缺人才招人，常常會因為任務急著有人去干，就放松標準、降低要求，讓不合格的人進入自己的團隊。甚至有些團隊Lead怕比自己更厲害的人進來搶走自己的位置，招進的人的水平都會比他/她低。

良好的組織文化的培養、人員技能的培養 （包括人才規劃、培訓體系建立、課程設置，雖然70%是在工作中學） 等等 要緊抓不放，時刻不松懈，微軟的愿景之一： 幫助員工發揮最大潛能， 微軟有一套很好的勝任力建設和評估體系， 見下面 插圖 ，之前在某人才培養峰會上，我曾詳細介紹過。由于篇幅所限，以后有機會再談。

4. 研發效能底層邏輯第2層： 做正確的事

做正確的事，即方向正確，做的事有價值，相當于在 000…000 前面加上1，加更多個0，是下面第3層、第4層去實現的，但沒有這個1，做得再快、再持續改進，依舊是0。同時，做了正確的事，就減少了返工，也提高了效率、降低了成本。

基于對軟件研發的正確理解，需求是源頭，是研發的輸入， “需求定義得是否正確” 顯得非常重要 。開發的需求對客戶的價值越高，開發效能就越高，這也符合我們平時特別強調 需求的優先級 ，按優先級來規劃我們版本發布計劃。只是這里的 優先級 不取決于 單個業務人員是否強勢或催得是否急、 也不取決于 哪個客戶叫得兇不兇， 而是取決于 解決客戶/用戶的問題是否到位、是否值得優先解決。如果研發團隊獨立，需求來自業務部門或客戶，而且沒有回旋的余地，在這層邏輯， 研發效 能 就取決于架構設計的質量、代碼的質量，那意味著做出正確的架構設計、寫出正確的代碼，即我們常常強調的 內建質量 （Built-in quality）。

做正確的事，傳統領域有好的實踐，也有好的方法，你可能覺得不適合軟件研發，沒問題，軟件研發也有自己好的實踐， 至少我覺得3個實踐比較可行有效 ：

• ATDD（驗收測試驅動開發） ，通過明確需求的驗收標準，來澄清需求，讓業務、產品、研發、測試等達成共識；

• 亞馬遜 的逆向工作法 ，見下面插圖，只有三步，也容易記住、容易實施。

• 研發流程形成閉環，實時做日志分析、及時獲取客戶的反饋，送入下一個迭代的輸入。

這比向你說一套需求工程來得簡單、容易。如果你還做不好，就得好好學習需求工程。

( 亞馬遜 的逆向工作法 )

5. 研發效能底層邏輯第3層： 正確地做事

這就回到剛才說的第1點 “聽眾急著要度量指標，想了解如何度量效能”。

許多公司就像這位聽眾一樣，抓研發效能，首先想到的就是要抓研發效能度量，急著確定度量指標，其次想到的就是建研發效能平臺、搭DevOps工具鏈，忘記了“人是決定的因素”，也忘記了“先要有明確的業務目標”， 度量、工具鏈都是手段，不是目標 。只有搞清楚研發的效能業務目標是什么，然后看要達成這些目標的障礙是什么、問題在哪里，然后去想如何清除 障礙 、解決問題。

正確地做事，如前所說，包括選擇正確的開發模式、制定有效的流程等。不是別人都用Scrum，我也用Scrum，而是分析自己研發（流程）中的主要問題是什么、如何解決這些問題，有沒有現成的框架可以解決這些問題，是需要改進還是需要變革？

[[441856]]

（方法是否正確，此圖可引發你的思考）

正確地做事 ，就是要用系統工程的方法解決問題，有良好的系統性思維、結構化思維，還要經過 “目標設定-問題分析-方案設計-評估指標建立-多個方案評估-選擇最優方案” 等問題分析與解決的基本流程。如果要學習 Guide tot he Systems Engineering Body of Knowledge ，有1100+頁，估計你沒時間。

（系統工程方法）

方法優于工具，工具是方法的固化。我們需先制定良好的方法，然后再開發出易用的、高效的工具。 像Google研發效能在技術上也只有三大招：

• 使用單體代碼倉庫（管理公司的大部分代碼）；

• 使用高效的聲明式定義bazel構建，支持精準測試；

• 主干開發

雖然軟件系統很復雜，但許多時候就是 我們自己 沒有正確做事而造成的。如果是遺留系統，沒有太多的好方法，可以慢慢重構，或老系統不動，重新寫一套新系統。 今后，我們需要每時每刻都應該在想 ：高內聚低耦合，為可靠性而設計/編程、為性能而設計/ 編 程 、為彈性而設計、讓別人看懂代碼比寫代碼更重要... ...  那么正確做事的方法總是有的 。更何況人類有53年的軟件工程經驗與教訓 （雖然人類有健忘癥） 、有成千上萬人的軟件研發工作經驗的積累？許多優秀的實踐可以嘗試， 大部分工作都有優秀實踐參考 ，而不需要每件事都靠自己發明創造，更不需要自己不斷挖坑、不斷填坑。

6.  研發效能底層邏輯第4層： 追求速度/效率

招對了人、培養好了人，差不多就能做正確的事、正確地做事。

如果還不行，就有前面的一些思路、方法供參考。實現了 “做正確的事、正確地做事”，效能已經很高了，當然我們還不滿足，需要不斷地提升研發效能， 這時需要做好下列三件事 ：

• 需要落實研發效能度量，可以參考  只要五步，研發效能度量就能成功落地！

• 持續改進流程，閉環反饋周期越來越短、越來越準確；

• 持續技術創新或引進新技術（如AI技術），完善研發平臺和 DevOps 工具鏈，中間可能包含了“固化，破局，再固化，再破局”的過程。

如果用底層邏輯的語言，可以概括為一句話——  持續反思、持續創新、持續改進，其目標就是更好地確保組織的 一致性，持續地做對事情、正確地做事 ，產生飛輪效應。

這篇文章算是一氣呵成。雖然文章不算長，但我講清楚了研發效能的底層邏輯 （4層） 。