在軟件研發(fā)領域，能夠有助于效能提升的方法論和實踐一直在快速發(fā)展。比如，我們熟知的敏捷開發(fā)方法已經(jīng)誕生了二十年，DevOps 也已經(jīng)發(fā)展了十多年，相信很多朋友都已經(jīng)對這些方法有了比較深刻的理解，在行業(yè)中也已經(jīng)有很多企業(yè)對其進行了引入、落地和實踐。

但是，我們經(jīng)常遇到的一種現(xiàn)象是，當一個組織或者團隊在消耗了大量的'變革'時間、花費了大量的人力資源和成本后，卻無法有效回答一些看似非?；镜膯栴}，比如：

• 你們的研發(fā)效能到底怎么樣？可否量化？

• 你們比所在行業(yè)平均水平、比別的公司、比別的團隊更好還是更差？

• 研發(fā)效能的瓶頸點和問題是什么？

• 在采納了敏捷或 DevOps 實踐之后，有沒有效果？有沒有實質(zhì)上的提升？

• 你們下一步應該采取什么樣的行動以繼續(xù)優(yōu)化效能？

這就是為什么我們希望進行研發(fā)效能度量。我認為 研發(fā)效能度量的目標就是讓效能可量化、可分析、可提升，通過數(shù)據(jù)驅動的方式更加理性地評估和改善效能，而不要總是憑直覺感性地說出“我覺得...'。

研發(fā)效能度量的出發(fā)點雖然很好，但是如何正確度量卻是一個挺有難度的技術活兒。尤其是這幾年，在研發(fā)效能實踐被普遍采納、研發(fā)效能平臺逐步被構建起來，很多企業(yè)已經(jīng)擁有了一些研發(fā)基礎數(shù)據(jù)的基礎之上，如何有效地度量，卻成為了困擾著很多企業(yè)和管理者的一大難題。

根據(jù)我的經(jīng)驗，度量這件事情不僅困難，而且稍不留神就可能會跑偏，結果經(jīng)常是非但沒有帶來所預期的、對效能提升的正面引導作用，反而帶來了很多嚴重的副作用，讓企業(yè)在消耗了很多時間和資源的情況下，進行了一場看似轟轟烈烈但卻沒有什么價值的數(shù)字游戲，或是一場看似政治正確但卻讓員工變得更加“內(nèi)卷”的無效運動。

那么我們下面就來看一看，研發(fā)效能度量的難點和常見的反模式。

相信每一個從事研發(fā)效能度量的實踐者或專家都聽說過管理大師彼得·德魯克的名言“沒有度量就無法管理”，這句話出自《管理的實踐》，在被引用了 60 多年后的今天依然適用。德魯克強調(diào)了度量對于管理的價值和作用，如果沒有度量，就會缺乏對某個事物的客觀認知，就不知道組織或團隊所處的位置和問題在哪里，那么就不知道應該如何進行決策，當然也就不知道應該如何進行改進。所以我們需要基于事實的度量指標，為管理提供可靠的效能分析和決策支持。

但是，在軟件研發(fā)領域，為什么說效能度量這件事情比較困難呢？

在 2003 年，軟件開發(fā)領域的大師馬丁·福勒就寫過一篇名為“無法度量生產(chǎn)力”的博客，他認為當時的軟件工業(yè)缺乏一些度量軟件開發(fā)有效性的基本元素的能力。仔細思考下，軟件研發(fā)過程跟生產(chǎn)制造行業(yè)實體產(chǎn)品的制造過程的確有著很大的區(qū)別，那么在度量的問題上就會充斥著一些比較困難的因素。雖然本質(zhì)上都是通過一定的工作來生產(chǎn)（研發(fā)）出所需的產(chǎn)品，但不同于生產(chǎn)制造行業(yè)，軟件研發(fā)過程有其特殊性：

軟件研發(fā)過程是靠業(yè)務、產(chǎn)品和工程師的數(shù)字化協(xié)作來推進的，涉及到業(yè)務、產(chǎn)品、研發(fā)、運維等不同職能，多個團隊多種角色協(xié)作時，任務處理的進度、隊列、依賴、瓶頸可能很難清晰觀察到，其中的風險也容易被各個環(huán)節(jié)掩蓋，以至于很多項目管理軟件中填寫的任務進度百分比只是簡單的粗略估算，可能只有部分參考意義，實際上根本無法保證準確。

有時管理者會制定一些 KPI 來度量團隊績效，但 就像那句名言所說：你度量什么，就會得到什么。其實這句話只說了上半句，而下半句是：只是不一定是用你所期待的方式得到。 所謂上有政策、下有對策，由于軟件工作切分的隨意性，也許把一個需求拆成多個小需求，一行代碼拆成多行來寫，那些度量產(chǎn)能或者吞吐量的 KPI 指標也許就被用非預期的方式達成了。

隨著企業(yè)中敏捷研發(fā)模式的持續(xù)推進，我們很難再像傳統(tǒng)項目管理模式一樣清晰界定軟件研發(fā)的各個階段，很多情況下不同需求所對應的開發(fā) / 測試 / 部署工作都是并行的，產(chǎn)品也是不斷迭代、持續(xù)演進的，這也對準確度量造成了一定困難。

另外，現(xiàn)代信息工作的特點就是經(jīng)常容易被各種不斷到來的干擾打斷。這些干擾可能來自外部事件（例如，一個同事問你一個問題、來自微信上的消息通知），也可能是自我的打斷（例如，在兩個不同的系統(tǒng)之間來回切換才能完成一項任務）。

最近，一項針對 IT 專業(yè)人士的觀察研究發(fā)現(xiàn)，有些人在專注工作幾分鐘后就會被打斷。這種高度并行、頻繁被打斷的場景往往無法被度量出來，我們也許看到每個人都在很飽滿地忙于各種任務，但其實這種工作流的中斷對于效能的影響是非常巨大的。這就是所謂的“忙忙碌碌一整天，好像啥也沒做成”，相信很多人都有這種經(jīng)歷。

以上描述了一些研發(fā)效能度量的難點，但是“難不難”和“做不做”是兩回事情。正是因為我們迫切地需要效能度量，需要對于研發(fā)過程進行客觀、量化的分析和認知，所以我們?nèi)匀灰y而上，找到解決這一難題的法門。

很多企業(yè)都已經(jīng)在效能度量的方向上進行了諸多嘗試，那么我們在介紹成功經(jīng)驗之前，先來看看一些失敗的案例，這樣才能對這個領域有更加深刻的認知。

正所謂“成功大都相似，失敗各有不同'。

研發(fā)效能的度量其實也不算是個新鮮的話題了，隨著業(yè)界各大公司日益發(fā)展壯大，很多都已經(jīng)擁有幾百、幾千甚至上萬人的研發(fā)隊伍，研發(fā)效能的基礎數(shù)據(jù)都積累了很多。

但我們經(jīng)常看到一些所謂的“反模式”在不斷上演，雖然從公司角度花了很大的力氣去做度量，但從其理念、出發(fā)點到具體實踐、指標選擇、推廣運營上似乎都存在一些問題、限制和弊端，以至于獲得的成效不大甚至是造成負面影響，最終連累公司整體業(yè)績。

下面我們就一起來看看這些反模式：

在有些企業(yè)，管理者的初心的確是想有效提升組織的研發(fā)效能，但是其管理理念還停留在往前推數(shù)十年的兩場技術革命之前，那種適合于管理重復的體力勞動工作者的模式上。當時的生產(chǎn)環(huán)境是重復的、可知的、確定性的，通常是物理活動，這與當前軟件開發(fā)這種創(chuàng)造性的、未知的、不確定性很高的知識工作完全不同。那么，度量的方式肯定也截然不同。

如果按照傳統(tǒng)的、針對體力勞動者的度量思路，會通過考察單位時間內(nèi)的工作產(chǎn)出來衡量生產(chǎn)率。那么對于軟件開發(fā)人員來說，是不是就可以通過度量每天編寫的代碼行數(shù)來實現(xiàn)呢？代碼行這是一種簡單的、易于獲取的指標，而且符合傳統(tǒng)的度量思路，在實際工作中我們經(jīng)?？吹接泄芾碚邥褂?。比如度量單位時間內(nèi)不同工程師的新增代碼行，以此來衡量每個人工作是否努力、工作是否飽滿、產(chǎn)出是否合理，更有甚者，還會進行團隊內(nèi)代碼行倒排名來作為獎懲措施。

但是我認為，無論如何，代碼行都不會是一個好的度量指標。比爾·蓋茨曾經(jīng)說：“用代碼行數(shù)來衡量軟件的生產(chǎn)力 ，就像用飛機的重量來衡量飛機的生產(chǎn)進度一樣?！?/strong> 雖然代碼行很容易度量，但卻有很大的問題，因為代碼越多不一定就越好。在這個度量的導向下，工程師可能傾向于提交大量重復、冗余的代碼來“湊指標”，讓數(shù)據(jù)變得很好看，但這對企業(yè)沒有任何價值。

在許多情況下，只要能滿足客戶的需求，實際上代碼越少越好。但我們同樣不能度量實現(xiàn)同一個業(yè)務邏輯，誰的代碼寫的最少，因為這樣的代碼可能大量使用復雜語法和表達式來精簡行數(shù)，只有作者一個人能看得懂，不利于代碼傳承和經(jīng)驗共享。

當然，這里只是舉了一個例子，還有很多看起來很簡單、容易度量的指標，比如下面即將講到的工時和資源利用率等，這些指標都很容易會讓度量跑偏。我們應該做的是提供給管理者更多的管理抓手，從正確的度量理念和方向上入手，選取符合數(shù)字化時代特征的度量指標集，這在后文中會展開描述。

互聯(lián)網(wǎng)大廠一直自帶上熱搜的體質(zhì)，而互聯(lián)網(wǎng)圈流行已久的“996'向來是內(nèi)卷的代名詞。大家肯定還記得，2020 年網(wǎng)絡上對于“996'有著深度的討論，“996'話題似乎與互聯(lián)網(wǎng)大廠有著某種深度綁定，某些話題確實也是從大廠內(nèi)部發(fā)源的。比如：阿里的馬云老師說，能 996 是一種巨大的福氣，很多公司、很多人想 996 都沒有機會；京東的東哥說，混日子的不是我兄弟；字節(jié)跳動、快手一段時間以來都在采用“大小周'的工作制度。

隨著內(nèi)卷的不斷加劇，很多人學會了“表演型”加班。 當加班文化盛行，身處其中的每個員工都容易被裹挾其中，即便沒有工作安排，也寧愿下班后留在公司繼續(xù)“磨洋工”。而過度加班會降低工作效率，讓員工患上嚴重的“拖延癥”。

也有理性聲音指出，把提高員工效率寄托在延長工作時間上，本就是管理上的“懶政”。阿里某 P8 同學曾經(jīng)發(fā)帖說，“當一個管理者的智慧無法衡量一支團隊的產(chǎn)出的時候，他就會把'工時’當做最后的救命稻草，死死抱住——這是他唯一聽得懂的東西了。”

以上這些討論其實都在圍繞一個主題，就是工程師的資源利用率。比如上下班打卡、填寫工時（有的公司稱為報工）等，都是非常典型和常見的管理手段。所謂的“996'更多強調(diào)的是工作時長，但在內(nèi)卷和“表演型”加班的氛圍里，這種工作時間的延長其實根本無法轉化為實際有效的產(chǎn)能。我們經(jīng)?？吹降那闆r是，研發(fā)似乎忙得熱火朝天，但是業(yè)務仍然抱怨做得太慢，根本不買賬。即使大家真的都在忙，也會導致更多的衍生問題。比如資源利用率的飽和會導致上下游協(xié)作時的大量排隊和等待，這種局部的過度優(yōu)化會導致全局的效率劣化，對企業(yè)來講得不償失。

另外，長期強調(diào)超高的資源利用率，有把員工當成“資源”而不是“工程師”的傾向，員工長期在這種壓力下會產(chǎn)生疲憊、幸福感下降。有研究表明，這不僅會影響代碼編寫過程的生產(chǎn)力，還會影響結果代碼的質(zhì)量。

所以，我們不要過度關注資源效率類指標，還需要考慮流動效率類指標，比如從產(chǎn)品或團隊視角下的需求交付周期、流動速率、流動效率等，后文會展開說明。順便說一句，在我寫下本文時（即 2021 年 8 月），許多互聯(lián)網(wǎng)大廠都紛紛取消了“大小周”的工作制度，也許行業(yè)已經(jīng)更深刻認識到，追求資源效率有其弊端，效能的全面提升才是解決效率問題的良藥。

成熟度模型在軟件行業(yè)的發(fā)展中由來已久，很多企業(yè)都通過了 CMMi 成熟度評估，甚至在敏捷、DevOps 領域也有人照方抓藥，試圖通過這種模式來評估和衡量軟件過程，通過研發(fā)活動的標準化和一致性來提升軟件研發(fā)的效率和質(zhì)量。我在這里先講一個案例。

有一家大型跨國公司，曾經(jīng)是某領域絕對的市場領導者，市值一度達到 2500 億美元。這家公司的高管們非常開明，意識到敏捷軟件開發(fā)對于他們適應快速變化的市場極為重要。于是，高層對大規(guī)模敏捷轉型給予了極大的支持，從上而下，投入巨大。難得的是，基層開發(fā)人員對任何敏捷實踐也都沒有異議，而且自我感覺良好。他們定義了公司級別期望發(fā)生的敏捷活動和行為，并與當時的最佳 Scrum 實踐進行對比，以成熟度的形式進行度量評估。

在具體操作過程中，他們把期望發(fā)生的敏捷活動分成 9 個維度，分別是迭代、迭代中的測試、用戶故事、產(chǎn)品負責人、產(chǎn)品待辦列表、估算、燃盡圖、中斷和打擾、團隊。然后對每個維度給出一系列評估細則。比如，對于迭代維度，他們的評估內(nèi)容是：

當團隊對迭代進行承諾時，需要知道迭代的長度，以便按更好的節(jié)奏交付價值。

評估方式（不加總）：

• 迭代長度 4~6 周，得 2 分

• 迭代長度 4 周之內(nèi)，得 4 分

• 過去三個迭代，迭代長度穩(wěn)定在 1 個月，得 5 分

• 過去三個迭代，迭代長度穩(wěn)定在 4 周，得 6 分

• 過去三個迭代，迭代長度穩(wěn)定在 3 周，得 8 分

• 過去三個迭代，迭代長度穩(wěn)定在 2 周之內(nèi)，得 10 分

以此類推，每個維度都有詳細的評估內(nèi)容，最終可以得到一張敏捷成熟度的雷達圖，如下圖所示。

這個模型一度被行業(yè)廣泛引用，并且作為敏捷開發(fā)方法可以在大規(guī)模企業(yè)落地的證據(jù)之一。也許你已經(jīng)猜到了，這個模型就叫做 Nokia Scrum Test。我們當然不能簡單粗暴地把這家公司手機業(yè)務的衰落直接歸結為敏捷度量方式的無效，但從客觀的角度來看，我們依然能發(fā)現(xiàn)其中隱含的問題。

按照這個模型，管理層看到這些團隊的敏捷成熟度一直在提升，已經(jīng)實現(xiàn)了理論上的敏捷性。但是實際上敏捷轉型并未成功，業(yè)務結果也證明了這一點。在《Transforming Nokia》一書中，描述了一些當時的實際情況：

• 企業(yè)級的敏捷工具沒有被開發(fā)人員真正接受，他們更喜歡簡單的以開發(fā)為中心的工具

• 很多開發(fā)人員在迭代末尾，工作已經(jīng)完成后，后補一個用戶故事

• 把敏捷工具變成了文檔記錄工具，而不是流動和反饋機制

• 看起來所有正確的敏捷活動都在發(fā)生，但開發(fā)者飽受構建和部署的折磨

• 由于 Symbian60 操作系統(tǒng)的規(guī)模和架構，增加新功能很困難

• 在構建和部署軟件時，下游的分離和低效意味著進展非常緩慢

• 技術債務積重難返， 2010 年 Symbian60 系統(tǒng)構建異常緩慢，要花整整 48 小時

反思這個案例，我們可以總結為：這種狹隘的、以活動為導向的敏捷觀是其轉型失敗的根本原因之一。 研發(fā)效能應該度量結果而不僅是過程，端到端價值流的局部優(yōu)化對結果的改進效果很小，因為可能根本就沒有解決效能瓶頸。

效能度量顯然很重要，企業(yè)迫切希望效能提升的愿望也可以理解，但千萬不要把指標設置為 KPI 用于績效考核，因為 把度量與績效掛鉤就一定會產(chǎn)生“造數(shù)據(jù)”的數(shù)字游戲。這時，使用效能度量非但起不到正面效果，還會對公司和團隊造成傷害。

有個著名的定律稱為古德哈特定律，其內(nèi)容是：當某個度量變成了目標，它便不再是一個好的度量。有朋友也將其戲稱為“好心人”定律，效能度量的出發(fā)點是好的，但當它演變成了與績效考核掛鉤的 KPI，大家都有追求自己切身利益的動機，那么各種有創(chuàng)造性的、為了提升指標而進行的不優(yōu)雅的短視行為就會紛紛上演，度量走偏就在所難免了。

其實從理論上講，所有的度量都可以被操縱，而數(shù)字游戲式的度量會分散員工的注意力并耗費大量時間。把度量指標設置為 KPI 進行考核，只是激勵員工針對度量指標本身進行優(yōu)化，這通常比他們在度量之前所做的工作效率要更低。因此，試圖把度量武器化為績效考核，不僅是一種浪費，而且往往適得其反，特別是當薪資與度量的KPI掛鉤的時候。

那么，如果不把效能度量與績效考核掛鉤，那怎樣才能使用度量提高研發(fā)效能呢？答案是：把度量作為一種目標管理方法、一種效能提升的參考工具，促進團隊明確效能目標、分析效能問題，指導團隊針對性優(yōu)化，從而最終獲得效能提升。比如，對線上缺陷密度的度量和分析，可以讓團隊了解產(chǎn)品的質(zhì)量走向和問題的根因，有助于持續(xù)優(yōu)化交付質(zhì)量；對需求交付周期的度量和分析，可以讓團隊了解產(chǎn)品端到端交付效率和細化每個階段的耗時占比，可以針對性的采取干預措施，讓團隊獲得有效的提升。

我們對于度量指標的理解，有時存在一定的片面性，比如認為某個效率類指標的提升就代表了研發(fā)效能的提升。需求交付周期是常見的效能度量北極星指標，在行業(yè)實踐中引用的比較多。但是，如果一個組織或團隊僅僅認為交付快了、周期短了就代表效能提升了，其實這就是一種片面的追求了。

記得之前也有專家說過：如果你不能度量一個事物的所有方面，就無法管理或者發(fā)展它。研發(fā)效能的提升不僅是有“效率”這一個方面，還有很關鍵的另外一個部分是“有效性”。軟件研發(fā)過程中最大的浪費，是構建沒有人在乎的東西。我們所謂的效能提升，一定是要從業(yè)務目標出發(fā)的，構建的功能、質(zhì)量是需要達到期望要求的，在此基礎之上當然效率越高越好、成本越低越好，所以我們說的效能實際上綜合考慮了關于產(chǎn)出和投入的多個要素。

回到需求交付周期這個指標的例子，追求這個指標的優(yōu)化當然很重要，但是需要在功能有效，吞吐量和質(zhì)量穩(wěn)定、安全合規(guī)的基礎之上才有價值，片面地使用局部過程性指標對于研發(fā)效能提升的效果有限，而跳出來看到全局的研發(fā)體系和結構才是關鍵。

研發(fā)效能度量的過程實際上是要把數(shù)據(jù)轉化為信息，然后將信息轉化為知識，這樣就可以讓用戶自主消費數(shù)據(jù)，進行分析和洞察。在企業(yè)進行研發(fā)效能度量的初始階段，可能會存在各種各樣的研發(fā)工具產(chǎn)生出來的原始效能數(shù)據(jù)，但缺少對其進行分析和加工成信息的自動化工具。所以很常見的是，用戶從系統(tǒng)中導出數(shù)據(jù)到 Excel 表格，然后進行各種篩選、關聯(lián)、透視和加工，最終形成度量報表。

在這個過程中，經(jīng)常存在大量的人工干預行為。那么，在數(shù)據(jù)分析和加工過程中，就很容易有意或無意地引入一些數(shù)據(jù)集合的篩選或“異常數(shù)據(jù)”排除的行為。有時甚至是僅僅為了讓數(shù)據(jù)變得好看、達標而做出一些看似合理但頗有欺騙性的報表來。我曾經(jīng)接觸過一家通過了 CMMi 四級的企業(yè)，會周期性統(tǒng)計研發(fā)效能報表。有一次，在查看報表中的數(shù)據(jù)時，我發(fā)現(xiàn)某個團隊的單元測試覆蓋率一直在 83%~85% 之間浮動，非常地規(guī)律。當我仔細詢問這個數(shù)據(jù)的時候，相關人員相互對視一笑，跟我說：“這些數(shù)據(jù)其實都是手工采集、人工上報的，其實很難保證準確性?！比绻軘?shù)據(jù)都是這種方式被手工統(tǒng)計出來、一層層地上報上去，對企業(yè)來講其實是非常有害的，不但無法發(fā)現(xiàn)現(xiàn)存的實際問題，還會把管理和技術決策引導到錯誤的方向上去。

我在建設服務于全集團數(shù)萬研發(fā)的研發(fā)效能度量平臺時，其中一個 最基本的要求就是度量數(shù)據(jù)的公信力。 也就是說，只有在我們這個平臺上自動采集、匯聚、計算出來的數(shù)據(jù)，才是被集團官方認可的，這些數(shù)據(jù)才可以被用來進行管理和技術決策。我認為這才是一個研發(fā)效能度量產(chǎn)品或平臺的立足之本。有了這樣一個有公信力的平臺之后，那些手工處理的 Excel 表格、人工做圖的 PPT 膠片，就會慢慢淡出大家的視野。

研發(fā)效能的度量不是免費的，為了做到準確、有效的度量，各種成本加在一起是很高的。比如我們經(jīng)常會去度量團隊的需求交付周期及其在設計、開發(fā)、測試、部署等每個階段的時間消耗和占比。這樣一個看似簡單的度量需求，其實背后要做很多事情。

比如團隊的研發(fā)流程要定義清晰、每個階段的完成的定義（DoD）要足夠明確、研發(fā)管理工具的配置要合理，以及最重要的是，團隊中每個人的操作過程要規(guī)范并及時。比如某個需求其實已經(jīng)部署到預發(fā)環(huán)境了，但在看板系統(tǒng)中的狀態(tài)還停留在“開發(fā)中”，原因可能是開發(fā)人員提交代碼、測試人員進行驗證后，并沒有及時同步看板工具中的需求狀態(tài)。在實際研發(fā)過程中，這是很常見的現(xiàn)象，以至于統(tǒng)計發(fā)現(xiàn)很多需求的交付周期都是 0 天，因為這些需求都是在開發(fā)完成之后，開發(fā)人員補錄的需求，然后從看板第一個階段列直接拖動到最后一列，這樣統(tǒng)計出來的數(shù)據(jù)就會有極大地失真。當然，我們應該更多使用自動化的手段來同步狀態(tài)，比如開發(fā)提交、提測、部署等行為會自動觸發(fā)對應需求狀態(tài)的流轉，但這也需要工具平臺開發(fā)出對應的能力，實際上也需要成本的投入。

既然度量有這么高的成本，那我們還需要做么？我的答案是，當收益大于成本的情況下，度量就是值得做的。度量指標應該少而精，每個指標都要追求其投資回報比。但是一些企業(yè)仍然傾向于定義大量的度量指標以彰顯其專業(yè)性，有的甚至達到了成百上千個指標。這樣的做法除了給企業(yè)帶來巨大的成本，好像很難體現(xiàn)出應有的價值。

在度量指標的選擇上，我們經(jīng)常提到一個詞叫做“北極星指標”，也被稱為是首要關鍵指標（One Metric That Matters）。北極星是天空北部的一顆亮星，離北天極很近，幾乎正對著地軸，從地球北半球上看，它的位置幾乎不變，所以古代人們經(jīng)常依靠它來辨別方向。在度量領域，我們可以根據(jù)當前企業(yè)的上下文，在不同領域選取少量的北極星指標來指導我們改進的方向，從目標出發(fā)驅動改進，從宏觀下鉆、定位到微觀問題后再引入更多的過程性指標進行輔助分析。

貨物崇拜（Cargo Cults）是一種宗教形式，尤其會出現(xiàn)在一些與世隔絕的落后土著部落之中。當貨物崇拜者看見外來的先進科技物品，便會將之當作神祇般崇拜。第二次世界大戰(zhàn)期間，盟軍為了對戰(zhàn)事提供支援，在太平洋的多個島嶼上設立了空軍基地，以空投的方式向部隊及支援部隊的島民投送了大量的生活用品及軍事設備，從而極大的改善了部隊以及島民的生活，島民也因此看到了人工生產(chǎn)的衣物、罐頭食品以及其他物品。戰(zhàn)爭結束后，這個軍事基地便被廢棄，貨物空投也就自然停止了。此時，島上的居民做了一件非常有意思的事情——他們把自己打扮成空管員、士兵以及水手，使用機場上的指揮棒揮舞著著陸信號，進行地面閱兵演習，試圖讓飛機繼續(xù)投放貨物，貨物崇拜因此而誕生。

這種現(xiàn)象在研發(fā)效能領域時有發(fā)生，盡管貨物崇拜的度量指標制定者們并沒有像島民一樣揮舞著指揮棒，但他們卻大量的復制和粘貼著從網(wǎng)上的各類文章中找來的度量指標，這些指標的定義有其場景和上下文，但他們對這些背景和工作原理并不是很了解。

Google 可以說是國內(nèi)公司膜拜和學習的典范，其在度量工程生產(chǎn)力方面也有明確的“QUANTS”模型，分別是：

• 代碼質(zhì)量（Quality of the code）

• 工程師注意力（Attention from engineers）

• 智力復雜性（Intellectual complexity）

• 速度與速率（Tempo and velocity）

• 滿意度（Satisfaction）

這個指標體系看起來很不錯，但是如果一個組織或團隊的成熟度還比較低，連最基本的需求流轉、敏捷協(xié)作都沒有做好，上來就引入和對標這些對工程能力和工程師文化有一定要求的指標，很可能適得其反，落入貨物崇拜的誤區(qū)。另外，前兩年在網(wǎng)上也有關于高效的工程師每天能寫多少行代碼的討論，據(jù)說 Google 的工程師平均每天能編寫 100-150 行代碼。但如果不管其上下文（技術架構、平臺能力、工程師級別、協(xié)作模式、質(zhì)量標準、統(tǒng)計口徑等），直接使用這個指標來進行對標，一定會搞得工程師苦不堪言。

我們經(jīng)常說：不要因為走得太遠，而忘記了為什么出發(fā)。官僚主義的一個問題是，一旦制定了一項政策，遵循該政策就成了官僚主義的目標，而不管該政策所支持的組織目標是什么。研發(fā)效能度量是為目標服務的，如果一種度量真的很重要，那是因為它必須對決策和行為產(chǎn)生一些可以想象的影響。

比如軟件開發(fā)團隊的經(jīng)理希望通過引入新的持續(xù)集成系統(tǒng)來提高生產(chǎn)力，這就是一個明確的目標，在初期落地執(zhí)行時，可能會采用持續(xù)集成系統(tǒng)注冊用戶數(shù)這個指標來進行度量。但是系統(tǒng)的使用不是目的，而是提升生產(chǎn)力的手段，我們更應該度量的是應用系統(tǒng)后，是否解決了開發(fā)人員對測試快速反饋的需求，質(zhì)量和效率是否得到了有效提升。

在 Google，使用 GSM（目標 / 信號 / 指標）框架來指導目標導向型指標的創(chuàng)建：

• 目標是期望的最終結果。它是根據(jù)從更高層次上理解的內(nèi)容來表達的，不應包含具體的度量方法的參考。

• 信號是目標達成與否的結果。信號本身也可能無法度量。

• 指標是信號的代理。代理的含義是指由于信號本身可能無法量化，因此需要通過指標來代理信號的量化。指標是一定可度量的內(nèi)容。

舉個例子，比如企業(yè)希望代碼的可讀性提高，這樣可以得到更高質(zhì)量、更一致的代碼，也能促進健康的代碼文化，那么按照 GSM 框架：

• 目標：由于可讀性的提高，工程師編寫了更高質(zhì)量的代碼

• 信號：可讀性過程對代碼質(zhì)量有積極的影響

• 指標：可讀性評審對代碼質(zhì)量沒有影響或負面影響的工程師比例、參與可讀性過程并改善了其團隊的代碼質(zhì)量的工程師比例

在與國內(nèi)一些企業(yè)的交流中我發(fā)現(xiàn)，很多公司的研發(fā)效能度量都是主要從管理者的視角出發(fā)的，無論是工時、人員飽和度等衡量資源利用率的指標，還是需求交付周期、吞吐量等衡量流動效率的指標，本質(zhì)上都是從管理維度看待研發(fā)效能這件事情。但是在前文中我也提過，我們不應該把員工當成一種”資源”，而是要作為”工程師”來看待。 員工幸福感的下降不僅會影響代碼編寫過程的生產(chǎn)力，還會影響結果代碼的質(zhì)量。

所以我們做研發(fā)效能提升，本質(zhì)上還是要多關注工程師的感受，他們對工作環(huán)境、工作模式、工作負載、研發(fā)基礎設施、項目協(xié)作、團隊發(fā)展、個人提升是否感到滿意，是否有阻礙工程師發(fā)揮更大創(chuàng)造性和產(chǎn)生更大生產(chǎn)力的因素存在。工程師個人效能的有效提升是組織效能提升非常關鍵的組成部分。就像 Facebook 會把“不要阻塞開發(fā)人員”作為貫穿公司研發(fā)和管理實踐中的核心原則之一，就是強調(diào)公司流程和實踐也要從工程師視角來考慮問題。

那么，我們?nèi)绾味攘抗こ處煹臐M意度呢？我們可以選擇 eNPS（Employee Net Promoter Score）來衡量員工的忠誠度，更高的員工忠誠度可以讓工程師提供更卓越的服務，讓客戶滿意，最終助力企業(yè)業(yè)務的成功。當然，我們不僅關注 eNPS 指標的數(shù)值本身，還可以將其與其他人力資源指標結合起來，這樣就可以知道為什么員工會給出負面反饋，這將揭示表象背后的原因，并幫助管理者尋找改進的方法。

“成功大都相似，失敗各有不同'。 本文分析了研發(fā)效能度量的難點和常見的“反模式'，希望大家能夠在開啟效能度量之旅之前，先辨別清楚方向，避免一開始就陷入到沼澤泥潭之中。

研發(fā)效能度量“難不難”和“做不做”是兩回事情，正因為其蘊含的巨大價值，我們還是要想辦法去探索和實踐。在下一篇文章中，我會具體介紹行業(yè)中有關的權威報告、多個互聯(lián)網(wǎng)大廠的研發(fā)度量案例，并總結和提煉出其中隱含的度量設計思路和關鍵原則。敬請期待！

作者介紹：

張樂，DevOps 與研發(fā)效能資深實踐者，長期工作于擁有數(shù)萬研發(fā)的互聯(lián)網(wǎng)大廠（百度、京東等），主攻敏捷與 DevOps 實踐、DevOps 平臺建設、研發(fā)效能度量體系設計等方向，歷任資深敏捷教練、DevOps 平臺產(chǎn)品總監(jiān)、研發(fā)效能度量標準化聯(lián)盟負責人等崗位。長期活躍于技術社區(qū)，目前是 DevOps 起源國際組織 DevOpsDays 中國區(qū)核心組織者，同時也是國內(nèi)多個技術峰會的聯(lián)席主席、DevOps/ 研發(fā)效能專題出品人、特邀演講嘉賓。EXIN DevOps 全系列國際認證授權講師、鳳凰項目 DevOps 沙盤國際授權教練。歷任埃森哲、惠普等全球五百強企業(yè)資深咨詢顧問、技術專家，多年敏捷與 DevOps 轉型、工程效率提升和大型項目實踐經(jīng)驗。暢銷書《獨角獸項目：數(shù)字化時代的開發(fā)傳奇》譯者。