[[441855]]

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

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

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

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

1. 究竟什么是研發(fā)效能？

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

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

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

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

研發(fā)效能強調(diào)效率和效果、正確性、競爭力以及對企業(yè)效益的貢獻，我們非常關(guān)注研發(fā)效能，也就毋庸置疑。

2. 研發(fā)效能如何落地？

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

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

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

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

2. 做正確的事，如澄清業(yè)務(wù)戰(zhàn)略，明確問題、業(yè)務(wù)需求和用戶需求；

3. 正確地做事 ：如確定/選擇正確的開發(fā)模式，制定有效的組織結(jié)構(gòu)和流程；

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

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

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

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

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

• 原則44 確定子集 

• ......

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

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

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

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

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

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

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

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

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

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

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

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

• ATDD（驗收測試驅(qū)動開發(fā)） ，通過明確需求的驗收標準，來澄清需求，讓業(yè)務(wù)、產(chǎn)品、研發(fā)、測試等達成共識；

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

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

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

( 亞馬遜 的逆向工作法 )

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

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

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

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

[[441856]]

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

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

（系統(tǒng)工程方法）

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

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

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

• 主干開發(fā)

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

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

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

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

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

• 持續(xù)改進流程，閉環(huán)反饋周期越來越短、越來越準確；

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

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

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