在軟件研發(fā)領(lǐng)域，能夠有助于效能提升的方法論和實(shí)踐一直在快速發(fā)展。比如，我們熟知的敏捷開(kāi)發(fā)方法已經(jīng)誕生了二十年，DevOps 也已經(jīng)發(fā)展了十多年，相信很多朋友都已經(jīng)對(duì)這些方法有了比較深刻的理解，在行業(yè)中也已經(jīng)有很多企業(yè)對(duì)其進(jìn)行了引入、落地和實(shí)踐。
但是，我們經(jīng)常遇到的一種現(xiàn)象是，當(dāng)一個(gè)組織或者團(tuán)隊(duì)在消耗了大量的'變革'時(shí)間、花費(fèi)了大量的人力資源和成本后，卻無(wú)法有效回答一些看似非?；镜膯?wèn)題，比如：
你們的研發(fā)效能到底怎么樣？可否量化？
你們比所在行業(yè)平均水平、比別的公司、比別的團(tuán)隊(duì)更好還是更差？
研發(fā)效能的瓶頸點(diǎn)和問(wèn)題是什么？
在采納了敏捷或 DevOps 實(shí)踐之后，有沒(méi)有效果？有沒(méi)有實(shí)質(zhì)上的提升？
你們下一步應(yīng)該采取什么樣的行動(dòng)以繼續(xù)優(yōu)化效能？
這就是為什么我們希望進(jìn)行研發(fā)效能度量。我認(rèn)為 研發(fā)效能度量的目標(biāo)就是讓效能可量化、可分析、可提升，通過(guò)數(shù)據(jù)驅(qū)動(dòng)的方式更加理性地評(píng)估和改善效能，而不要總是憑直覺(jué)感性地說(shuō)出“我覺(jué)得...'。
研發(fā)效能度量的出發(fā)點(diǎn)雖然很好，但是如何正確度量卻是一個(gè)挺有難度的技術(shù)活兒。尤其是這幾年，在研發(fā)效能實(shí)踐被普遍采納、研發(fā)效能平臺(tái)逐步被構(gòu)建起來(lái)，很多企業(yè)已經(jīng)擁有了一些研發(fā)基礎(chǔ)數(shù)據(jù)的基礎(chǔ)之上，如何有效地度量，卻成為了困擾著很多企業(yè)和管理者的一大難題。
根據(jù)我的經(jīng)驗(yàn)，度量這件事情不僅困難，而且稍不留神就可能會(huì)跑偏，結(jié)果經(jīng)常是非但沒(méi)有帶來(lái)所預(yù)期的、對(duì)效能提升的正面引導(dǎo)作用，反而帶來(lái)了很多嚴(yán)重的副作用，讓企業(yè)在消耗了很多時(shí)間和資源的情況下，進(jìn)行了一場(chǎng)看似轟轟烈烈但卻沒(méi)有什么價(jià)值的數(shù)字游戲，或是一場(chǎng)看似政治正確但卻讓員工變得更加“內(nèi)卷”的無(wú)效運(yùn)動(dòng)。
那么我們下面就來(lái)看一看，研發(fā)效能度量的難點(diǎn)和常見(jiàn)的反模式。
相信每一個(gè)從事研發(fā)效能度量的實(shí)踐者或?qū)＜叶悸?tīng)說(shuō)過(guò)管理大師彼得·德魯克的名言“沒(méi)有度量就無(wú)法管理”，這句話出自《管理的實(shí)踐》，在被引用了 60 多年后的今天依然適用。德魯克強(qiáng)調(diào)了度量對(duì)于管理的價(jià)值和作用，如果沒(méi)有度量，就會(huì)缺乏對(duì)某個(gè)事物的客觀認(rèn)知，就不知道組織或團(tuán)隊(duì)所處的位置和問(wèn)題在哪里，那么就不知道應(yīng)該如何進(jìn)行決策，當(dāng)然也就不知道應(yīng)該如何進(jìn)行改進(jìn)。所以我們需要基于事實(shí)的度量指標(biāo)，為管理提供可靠的效能分析和決策支持。
但是，在軟件研發(fā)領(lǐng)域，為什么說(shuō)效能度量這件事情比較困難呢？
在 2003 年，軟件開(kāi)發(fā)領(lǐng)域的大師馬丁·福勒就寫(xiě)過(guò)一篇名為“無(wú)法度量生產(chǎn)力”的博客，他認(rèn)為當(dāng)時(shí)的軟件工業(yè)缺乏一些度量軟件開(kāi)發(fā)有效性的基本元素的能力。仔細(xì)思考下，軟件研發(fā)過(guò)程跟生產(chǎn)制造行業(yè)實(shí)體產(chǎn)品的制造過(guò)程的確有著很大的區(qū)別，那么在度量的問(wèn)題上就會(huì)充斥著一些比較困難的因素。雖然本質(zhì)上都是通過(guò)一定的工作來(lái)生產(chǎn)（研發(fā)）出所需的產(chǎn)品，但不同于生產(chǎn)制造行業(yè)，軟件研發(fā)過(guò)程有其特殊性：
軟件研發(fā)過(guò)程是靠業(yè)務(wù)、產(chǎn)品和工程師的數(shù)字化協(xié)作來(lái)推進(jìn)的，涉及到業(yè)務(wù)、產(chǎn)品、研發(fā)、運(yùn)維等不同職能，多個(gè)團(tuán)隊(duì)多種角色協(xié)作時(shí)，任務(wù)處理的進(jìn)度、隊(duì)列、依賴、瓶頸可能很難清晰觀察到，其中的風(fēng)險(xiǎn)也容易被各個(gè)環(huán)節(jié)掩蓋，以至于很多項(xiàng)目管理軟件中填寫(xiě)的任務(wù)進(jìn)度百分比只是簡(jiǎn)單的粗略估算，可能只有部分參考意義，實(shí)際上根本無(wú)法保證準(zhǔn)確。
有時(shí)管理者會(huì)制定一些 KPI 來(lái)度量團(tuán)隊(duì)績(jī)效，但 就像那句名言所說(shuō)：你度量什么，就會(huì)得到什么。其實(shí)這句話只說(shuō)了上半句，而下半句是：只是不一定是用你所期待的方式得到。 所謂上有政策、下有對(duì)策，由于軟件工作切分的隨意性，也許把一個(gè)需求拆成多個(gè)小需求，一行代碼拆成多行來(lái)寫(xiě)，那些度量產(chǎn)能或者吞吐量的 KPI 指標(biāo)也許就被用非預(yù)期的方式達(dá)成了。
隨著企業(yè)中敏捷研發(fā)模式的持續(xù)推進(jìn)，我們很難再像傳統(tǒng)項(xiàng)目管理模式一樣清晰界定軟件研發(fā)的各個(gè)階段，很多情況下不同需求所對(duì)應(yīng)的開(kāi)發(fā) / 測(cè)試 / 部署工作都是并行的，產(chǎn)品也是不斷迭代、持續(xù)演進(jìn)的，這也對(duì)準(zhǔn)確度量造成了一定困難。
另外，現(xiàn)代信息工作的特點(diǎn)就是經(jīng)常容易被各種不斷到來(lái)的干擾打斷。這些干擾可能來(lái)自外部事件（例如，一個(gè)同事問(wèn)你一個(gè)問(wèn)題、來(lái)自微信上的消息通知），也可能是自我的打斷（例如，在兩個(gè)不同的系統(tǒng)之間來(lái)回切換才能完成一項(xiàng)任務(wù)）。
最近，一項(xiàng)針對(duì) IT 專業(yè)人士的觀察研究發(fā)現(xiàn)，有些人在專注工作幾分鐘后就會(huì)被打斷。這種高度并行、頻繁被打斷的場(chǎng)景往往無(wú)法被度量出來(lái)，我們也許看到每個(gè)人都在很飽滿地忙于各種任務(wù)，但其實(shí)這種工作流的中斷對(duì)于效能的影響是非常巨大的。這就是所謂的“忙忙碌碌一整天，好像啥也沒(méi)做成”，相信很多人都有這種經(jīng)歷。
以上描述了一些研發(fā)效能度量的難點(diǎn)，但是“難不難”和“做不做”是兩回事情。正是因?yàn)槲覀兤惹械匦枰芏攘浚枰獙?duì)于研發(fā)過(guò)程進(jìn)行客觀、量化的分析和認(rèn)知，所以我們?nèi)匀灰y而上，找到解決這一難題的法門(mén)。
很多企業(yè)都已經(jīng)在效能度量的方向上進(jìn)行了諸多嘗試，那么我們?cè)诮榻B成功經(jīng)驗(yàn)之前，先來(lái)看看一些失敗的案例，這樣才能對(duì)這個(gè)領(lǐng)域有更加深刻的認(rèn)知。
正所謂“成功大都相似，失敗各有不同'。
研發(fā)效能的度量其實(shí)也不算是個(gè)新鮮的話題了，隨著業(yè)界各大公司日益發(fā)展壯大，很多都已經(jīng)擁有幾百、幾千甚至上萬(wàn)人的研發(fā)隊(duì)伍，研發(fā)效能的基礎(chǔ)數(shù)據(jù)都積累了很多。
但我們經(jīng)?？吹揭恍┧^的“反模式”在不斷上演，雖然從公司角度花了很大的力氣去做度量，但從其理念、出發(fā)點(diǎn)到具體實(shí)踐、指標(biāo)選擇、推廣運(yùn)營(yíng)上似乎都存在一些問(wèn)題、限制和弊端，以至于獲得的成效不大甚至是造成負(fù)面影響，最終連累公司整體業(yè)績(jī)。
下面我們就一起來(lái)看看這些反模式：
在有些企業(yè)，管理者的初心的確是想有效提升組織的研發(fā)效能，但是其管理理念還停留在往前推數(shù)十年的兩場(chǎng)技術(shù)革命之前，那種適合于管理重復(fù)的體力勞動(dòng)工作者的模式上。當(dāng)時(shí)的生產(chǎn)環(huán)境是重復(fù)的、可知的、確定性的，通常是物理活動(dòng)，這與當(dāng)前軟件開(kāi)發(fā)這種創(chuàng)造性的、未知的、不確定性很高的知識(shí)工作完全不同。那么，度量的方式肯定也截然不同。
如果按照傳統(tǒng)的、針對(duì)體力勞動(dòng)者的度量思路，會(huì)通過(guò)考察單位時(shí)間內(nèi)的工作產(chǎn)出來(lái)衡量生產(chǎn)率。那么對(duì)于軟件開(kāi)發(fā)人員來(lái)說(shuō)，是不是就可以通過(guò)度量每天編寫(xiě)的代碼行數(shù)來(lái)實(shí)現(xiàn)呢？代碼行這是一種簡(jiǎn)單的、易于獲取的指標(biāo)，而且符合傳統(tǒng)的度量思路，在實(shí)際工作中我們經(jīng)?？吹接泄芾碚邥?huì)使用。比如度量單位時(shí)間內(nèi)不同工程師的新增代碼行，以此來(lái)衡量每個(gè)人工作是否努力、工作是否飽滿、產(chǎn)出是否合理，更有甚者，還會(huì)進(jìn)行團(tuán)隊(duì)內(nèi)代碼行倒排名來(lái)作為獎(jiǎng)懲措施。
但是我認(rèn)為，無(wú)論如何，代碼行都不會(huì)是一個(gè)好的度量指標(biāo)。比爾·蓋茨曾經(jīng)說(shuō)：“用代碼行數(shù)來(lái)衡量軟件的生產(chǎn)力 ，就像用飛機(jī)的重量來(lái)衡量飛機(jī)的生產(chǎn)進(jìn)度一樣?！?/strong> 雖然代碼行很容易度量，但卻有很大的問(wèn)題，因?yàn)榇a越多不一定就越好。在這個(gè)度量的導(dǎo)向下，工程師可能傾向于提交大量重復(fù)、冗余的代碼來(lái)“湊指標(biāo)”，讓數(shù)據(jù)變得很好看，但這對(duì)企業(yè)沒(méi)有任何價(jià)值。
在許多情況下，只要能滿足客戶的需求，實(shí)際上代碼越少越好。但我們同樣不能度量實(shí)現(xiàn)同一個(gè)業(yè)務(wù)邏輯，誰(shuí)的代碼寫(xiě)的最少，因?yàn)檫@樣的代碼可能大量使用復(fù)雜語(yǔ)法和表達(dá)式來(lái)精簡(jiǎn)行數(shù)，只有作者一個(gè)人能看得懂，不利于代碼傳承和經(jīng)驗(yàn)共享。
當(dāng)然，這里只是舉了一個(gè)例子，還有很多看起來(lái)很簡(jiǎn)單、容易度量的指標(biāo)，比如下面即將講到的工時(shí)和資源利用率等，這些指標(biāo)都很容易會(huì)讓度量跑偏。我們應(yīng)該做的是提供給管理者更多的管理抓手，從正確的度量理念和方向上入手，選取符合數(shù)字化時(shí)代特征的度量指標(biāo)集，這在后文中會(huì)展開(kāi)描述。
互聯(lián)網(wǎng)大廠一直自帶上熱搜的體質(zhì)，而互聯(lián)網(wǎng)圈流行已久的“996'向來(lái)是內(nèi)卷的代名詞。大家肯定還記得，2020 年網(wǎng)絡(luò)上對(duì)于“996'有著深度的討論，“996'話題似乎與互聯(lián)網(wǎng)大廠有著某種深度綁定，某些話題確實(shí)也是從大廠內(nèi)部發(fā)源的。比如：阿里的馬云老師說(shuō)，能 996 是一種巨大的福氣，很多公司、很多人想 996 都沒(méi)有機(jī)會(huì)；京東的東哥說(shuō)，混日子的不是我兄弟；字節(jié)跳動(dòng)、快手一段時(shí)間以來(lái)都在采用“大小周'的工作制度。
隨著內(nèi)卷的不斷加劇，很多人學(xué)會(huì)了“表演型”加班。 當(dāng)加班文化盛行，身處其中的每個(gè)員工都容易被裹挾其中，即便沒(méi)有工作安排，也寧愿下班后留在公司繼續(xù)“磨洋工”。而過(guò)度加班會(huì)降低工作效率，讓員工患上嚴(yán)重的“拖延癥”。
也有理性聲音指出，把提高員工效率寄托在延長(zhǎng)工作時(shí)間上，本就是管理上的“懶政”。阿里某 P8 同學(xué)曾經(jīng)發(fā)帖說(shuō)，“當(dāng)一個(gè)管理者的智慧無(wú)法衡量一支團(tuán)隊(duì)的產(chǎn)出的時(shí)候，他就會(huì)把'工時(shí)’當(dāng)做最后的救命稻草，死死抱住——這是他唯一聽(tīng)得懂的東西了?！?/p>
以上這些討論其實(shí)都在圍繞一個(gè)主題，就是工程師的資源利用率。比如上下班打卡、填寫(xiě)工時(shí)（有的公司稱為報(bào)工）等，都是非常典型和常見(jiàn)的管理手段。所謂的“996'更多強(qiáng)調(diào)的是工作時(shí)長(zhǎng)，但在內(nèi)卷和“表演型”加班的氛圍里，這種工作時(shí)間的延長(zhǎng)其實(shí)根本無(wú)法轉(zhuǎn)化為實(shí)際有效的產(chǎn)能。我們經(jīng)常看到的情況是，研發(fā)似乎忙得熱火朝天，但是業(yè)務(wù)仍然抱怨做得太慢，根本不買(mǎi)賬。即使大家真的都在忙，也會(huì)導(dǎo)致更多的衍生問(wèn)題。比如資源利用率的飽和會(huì)導(dǎo)致上下游協(xié)作時(shí)的大量排隊(duì)和等待，這種局部的過(guò)度優(yōu)化會(huì)導(dǎo)致全局的效率劣化，對(duì)企業(yè)來(lái)講得不償失。
另外，長(zhǎng)期強(qiáng)調(diào)超高的資源利用率，有把員工當(dāng)成“資源”而不是“工程師”的傾向，員工長(zhǎng)期在這種壓力下會(huì)產(chǎn)生疲憊、幸福感下降。有研究表明，這不僅會(huì)影響代碼編寫(xiě)過(guò)程的生產(chǎn)力，還會(huì)影響結(jié)果代碼的質(zhì)量。
所以，我們不要過(guò)度關(guān)注資源效率類指標(biāo)，還需要考慮流動(dòng)效率類指標(biāo)，比如從產(chǎn)品或團(tuán)隊(duì)視角下的需求交付周期、流動(dòng)速率、流動(dòng)效率等，后文會(huì)展開(kāi)說(shuō)明。順便說(shuō)一句，在我寫(xiě)下本文時(shí)（即 2021 年 8 月），許多互聯(lián)網(wǎng)大廠都紛紛取消了“大小周”的工作制度，也許行業(yè)已經(jīng)更深刻認(rèn)識(shí)到，追求資源效率有其弊端，效能的全面提升才是解決效率問(wèn)題的良藥。
成熟度模型在軟件行業(yè)的發(fā)展中由來(lái)已久，很多企業(yè)都通過(guò)了 CMMi 成熟度評(píng)估，甚至在敏捷、DevOps 領(lǐng)域也有人照方抓藥，試圖通過(guò)這種模式來(lái)評(píng)估和衡量軟件過(guò)程，通過(guò)研發(fā)活動(dòng)的標(biāo)準(zhǔn)化和一致性來(lái)提升軟件研發(fā)的效率和質(zhì)量。我在這里先講一個(gè)案例。
有一家大型跨國(guó)公司，曾經(jīng)是某領(lǐng)域絕對(duì)的市場(chǎng)領(lǐng)導(dǎo)者，市值一度達(dá)到 2500 億美元。這家公司的高管們非常開(kāi)明，意識(shí)到敏捷軟件開(kāi)發(fā)對(duì)于他們適應(yīng)快速變化的市場(chǎng)極為重要。于是，高層對(duì)大規(guī)模敏捷轉(zhuǎn)型給予了極大的支持，從上而下，投入巨大。難得的是，基層開(kāi)發(fā)人員對(duì)任何敏捷實(shí)踐也都沒(méi)有異議，而且自我感覺(jué)良好。他們定義了公司級(jí)別期望發(fā)生的敏捷活動(dòng)和行為，并與當(dāng)時(shí)的最佳 Scrum 實(shí)踐進(jìn)行對(duì)比，以成熟度的形式進(jìn)行度量評(píng)估。
在具體操作過(guò)程中，他們把期望發(fā)生的敏捷活動(dòng)分成 9 個(gè)維度，分別是迭代、迭代中的測(cè)試、用戶故事、產(chǎn)品負(fù)責(zé)人、產(chǎn)品待辦列表、估算、燃盡圖、中斷和打擾、團(tuán)隊(duì)。然后對(duì)每個(gè)維度給出一系列評(píng)估細(xì)則。比如，對(duì)于迭代維度，他們的評(píng)估內(nèi)容是：
當(dāng)團(tuán)隊(duì)對(duì)迭代進(jìn)行承諾時(shí)，需要知道迭代的長(zhǎng)度，以便按更好的節(jié)奏交付價(jià)值。
評(píng)估方式（不加總）：
迭代長(zhǎng)度 4~6 周，得 2 分
迭代長(zhǎng)度 4 周之內(nèi)，得 4 分
過(guò)去三個(gè)迭代，迭代長(zhǎng)度穩(wěn)定在 1 個(gè)月，得 5 分
過(guò)去三個(gè)迭代，迭代長(zhǎng)度穩(wěn)定在 4 周，得 6 分
過(guò)去三個(gè)迭代，迭代長(zhǎng)度穩(wěn)定在 3 周，得 8 分
過(guò)去三個(gè)迭代，迭代長(zhǎng)度穩(wěn)定在 2 周之內(nèi)，得 10 分
以此類推，每個(gè)維度都有詳細(xì)的評(píng)估內(nèi)容，最終可以得到一張敏捷成熟度的雷達(dá)圖，如下圖所示。
這個(gè)模型一度被行業(yè)廣泛引用，并且作為敏捷開(kāi)發(fā)方法可以在大規(guī)模企業(yè)落地的證據(jù)之一。也許你已經(jīng)猜到了，這個(gè)模型就叫做 Nokia Scrum Test。我們當(dāng)然不能簡(jiǎn)單粗暴地把這家公司手機(jī)業(yè)務(wù)的衰落直接歸結(jié)為敏捷度量方式的無(wú)效，但從客觀的角度來(lái)看，我們依然能發(fā)現(xiàn)其中隱含的問(wèn)題。
按照這個(gè)模型，管理層看到這些團(tuán)隊(duì)的敏捷成熟度一直在提升，已經(jīng)實(shí)現(xiàn)了理論上的敏捷性。但是實(shí)際上敏捷轉(zhuǎn)型并未成功，業(yè)務(wù)結(jié)果也證明了這一點(diǎn)。在《Transforming Nokia》一書(shū)中，描述了一些當(dāng)時(shí)的實(shí)際情況：
企業(yè)級(jí)的敏捷工具沒(méi)有被開(kāi)發(fā)人員真正接受，他們更喜歡簡(jiǎn)單的以開(kāi)發(fā)為中心的工具
很多開(kāi)發(fā)人員在迭代末尾，工作已經(jīng)完成后，后補(bǔ)一個(gè)用戶故事
把敏捷工具變成了文檔記錄工具，而不是流動(dòng)和反饋機(jī)制
看起來(lái)所有正確的敏捷活動(dòng)都在發(fā)生，但開(kāi)發(fā)者飽受構(gòu)建和部署的折磨
由于 Symbian60 操作系統(tǒng)的規(guī)模和架構(gòu)，增加新功能很困難
在構(gòu)建和部署軟件時(shí)，下游的分離和低效意味著進(jìn)展非常緩慢
技術(shù)債務(wù)積重難返， 2010 年 Symbian60 系統(tǒng)構(gòu)建異常緩慢，要花整整 48 小時(shí)
反思這個(gè)案例，我們可以總結(jié)為：這種狹隘的、以活動(dòng)為導(dǎo)向的敏捷觀是其轉(zhuǎn)型失敗的根本原因之一。 研發(fā)效能應(yīng)該度量結(jié)果而不僅是過(guò)程，端到端價(jià)值流的局部?jī)?yōu)化對(duì)結(jié)果的改進(jìn)效果很小，因?yàn)榭赡芨揪蜎](méi)有解決效能瓶頸。
效能度量顯然很重要，企業(yè)迫切希望效能提升的愿望也可以理解，但千萬(wàn)不要把指標(biāo)設(shè)置為 KPI 用于績(jī)效考核，因?yàn)?把度量與績(jī)效掛鉤就一定會(huì)產(chǎn)生“造數(shù)據(jù)”的數(shù)字游戲。這時(shí)，使用效能度量非但起不到正面效果，還會(huì)對(duì)公司和團(tuán)隊(duì)造成傷害。
有個(gè)著名的定律稱為古德哈特定律，其內(nèi)容是：當(dāng)某個(gè)度量變成了目標(biāo)，它便不再是一個(gè)好的度量。有朋友也將其戲稱為“好心人”定律，效能度量的出發(fā)點(diǎn)是好的，但當(dāng)它演變成了與績(jī)效考核掛鉤的 KPI，大家都有追求自己切身利益的動(dòng)機(jī)，那么各種有創(chuàng)造性的、為了提升指標(biāo)而進(jìn)行的不優(yōu)雅的短視行為就會(huì)紛紛上演，度量走偏就在所難免了。
其實(shí)從理論上講，所有的度量都可以被操縱，而數(shù)字游戲式的度量會(huì)分散員工的注意力并耗費(fèi)大量時(shí)間。把度量指標(biāo)設(shè)置為 KPI 進(jìn)行考核，只是激勵(lì)員工針對(duì)度量指標(biāo)本身進(jìn)行優(yōu)化，這通常比他們?cè)诙攘恐八龅墓ぷ餍室?。因此，試圖把度量武器化為績(jī)效考核，不僅是一種浪費(fèi)，而且往往適得其反，特別是當(dāng)薪資與度量的KPI掛鉤的時(shí)候。
那么，如果不把效能度量與績(jī)效考核掛鉤，那怎樣才能使用度量提高研發(fā)效能呢？答案是：把度量作為一種目標(biāo)管理方法、一種效能提升的參考工具，促進(jìn)團(tuán)隊(duì)明確效能目標(biāo)、分析效能問(wèn)題，指導(dǎo)團(tuán)隊(duì)針對(duì)性優(yōu)化，從而最終獲得效能提升。比如，對(duì)線上缺陷密度的度量和分析，可以讓團(tuán)隊(duì)了解產(chǎn)品的質(zhì)量走向和問(wèn)題的根因，有助于持續(xù)優(yōu)化交付質(zhì)量；對(duì)需求交付周期的度量和分析，可以讓團(tuán)隊(duì)了解產(chǎn)品端到端交付效率和細(xì)化每個(gè)階段的耗時(shí)占比，可以針對(duì)性的采取干預(yù)措施，讓團(tuán)隊(duì)獲得有效的提升。
我們對(duì)于度量指標(biāo)的理解，有時(shí)存在一定的片面性，比如認(rèn)為某個(gè)效率類指標(biāo)的提升就代表了研發(fā)效能的提升。需求交付周期是常見(jiàn)的效能度量北極星指標(biāo)，在行業(yè)實(shí)踐中引用的比較多。但是，如果一個(gè)組織或團(tuán)隊(duì)僅僅認(rèn)為交付快了、周期短了就代表效能提升了，其實(shí)這就是一種片面的追求了。
記得之前也有專家說(shuō)過(guò)：如果你不能度量一個(gè)事物的所有方面，就無(wú)法管理或者發(fā)展它。研發(fā)效能的提升不僅是有“效率”這一個(gè)方面，還有很關(guān)鍵的另外一個(gè)部分是“有效性”。軟件研發(fā)過(guò)程中最大的浪費(fèi)，是構(gòu)建沒(méi)有人在乎的東西。我們所謂的效能提升，一定是要從業(yè)務(wù)目標(biāo)出發(fā)的，構(gòu)建的功能、質(zhì)量是需要達(dá)到期望要求的，在此基礎(chǔ)之上當(dāng)然效率越高越好、成本越低越好，所以我們說(shuō)的效能實(shí)際上綜合考慮了關(guān)于產(chǎn)出和投入的多個(gè)要素。
回到需求交付周期這個(gè)指標(biāo)的例子，追求這個(gè)指標(biāo)的優(yōu)化當(dāng)然很重要，但是需要在功能有效，吞吐量和質(zhì)量穩(wěn)定、安全合規(guī)的基礎(chǔ)之上才有價(jià)值，片面地使用局部過(guò)程性指標(biāo)對(duì)于研發(fā)效能提升的效果有限，而跳出來(lái)看到全局的研發(fā)體系和結(jié)構(gòu)才是關(guān)鍵。
研發(fā)效能度量的過(guò)程實(shí)際上是要把數(shù)據(jù)轉(zhuǎn)化為信息，然后將信息轉(zhuǎn)化為知識(shí)，這樣就可以讓用戶自主消費(fèi)數(shù)據(jù)，進(jìn)行分析和洞察。在企業(yè)進(jìn)行研發(fā)效能度量的初始階段，可能會(huì)存在各種各樣的研發(fā)工具產(chǎn)生出來(lái)的原始效能數(shù)據(jù)，但缺少對(duì)其進(jìn)行分析和加工成信息的自動(dòng)化工具。所以很常見(jiàn)的是，用戶從系統(tǒng)中導(dǎo)出數(shù)據(jù)到 Excel 表格，然后進(jìn)行各種篩選、關(guān)聯(lián)、透視和加工，最終形成度量報(bào)表。
在這個(gè)過(guò)程中，經(jīng)常存在大量的人工干預(yù)行為。那么，在數(shù)據(jù)分析和加工過(guò)程中，就很容易有意或無(wú)意地引入一些數(shù)據(jù)集合的篩選或“異常數(shù)據(jù)”排除的行為。有時(shí)甚至是僅僅為了讓數(shù)據(jù)變得好看、達(dá)標(biāo)而做出一些看似合理但頗有欺騙性的報(bào)表來(lái)。我曾經(jīng)接觸過(guò)一家通過(guò)了 CMMi 四級(jí)的企業(yè)，會(huì)周期性統(tǒng)計(jì)研發(fā)效能報(bào)表。有一次，在查看報(bào)表中的數(shù)據(jù)時(shí)，我發(fā)現(xiàn)某個(gè)團(tuán)隊(duì)的單元測(cè)試覆蓋率一直在 83%~85% 之間浮動(dòng)，非常地規(guī)律。當(dāng)我仔細(xì)詢問(wèn)這個(gè)數(shù)據(jù)的時(shí)候，相關(guān)人員相互對(duì)視一笑，跟我說(shuō)：“這些數(shù)據(jù)其實(shí)都是手工采集、人工上報(bào)的，其實(shí)很難保證準(zhǔn)確性。”如果效能數(shù)據(jù)都是這種方式被手工統(tǒng)計(jì)出來(lái)、一層層地上報(bào)上去，對(duì)企業(yè)來(lái)講其實(shí)是非常有害的，不但無(wú)法發(fā)現(xiàn)現(xiàn)存的實(shí)際問(wèn)題，還會(huì)把管理和技術(shù)決策引導(dǎo)到錯(cuò)誤的方向上去。
我在建設(shè)服務(wù)于全集團(tuán)數(shù)萬(wàn)研發(fā)的研發(fā)效能度量平臺(tái)時(shí)，其中一個(gè) 最基本的要求就是度量數(shù)據(jù)的公信力。 也就是說(shuō)，只有在我們這個(gè)平臺(tái)上自動(dòng)采集、匯聚、計(jì)算出來(lái)的數(shù)據(jù)，才是被集團(tuán)官方認(rèn)可的，這些數(shù)據(jù)才可以被用來(lái)進(jìn)行管理和技術(shù)決策。我認(rèn)為這才是一個(gè)研發(fā)效能度量產(chǎn)品或平臺(tái)的立足之本。有了這樣一個(gè)有公信力的平臺(tái)之后，那些手工處理的 Excel 表格、人工做圖的 PPT 膠片，就會(huì)慢慢淡出大家的視野。
研發(fā)效能的度量不是免費(fèi)的，為了做到準(zhǔn)確、有效的度量，各種成本加在一起是很高的。比如我們經(jīng)常會(huì)去度量團(tuán)隊(duì)的需求交付周期及其在設(shè)計(jì)、開(kāi)發(fā)、測(cè)試、部署等每個(gè)階段的時(shí)間消耗和占比。這樣一個(gè)看似簡(jiǎn)單的度量需求，其實(shí)背后要做很多事情。
比如團(tuán)隊(duì)的研發(fā)流程要定義清晰、每個(gè)階段的完成的定義（DoD）要足夠明確、研發(fā)管理工具的配置要合理，以及最重要的是，團(tuán)隊(duì)中每個(gè)人的操作過(guò)程要規(guī)范并及時(shí)。比如某個(gè)需求其實(shí)已經(jīng)部署到預(yù)發(fā)環(huán)境了，但在看板系統(tǒng)中的狀態(tài)還停留在“開(kāi)發(fā)中”，原因可能是開(kāi)發(fā)人員提交代碼、測(cè)試人員進(jìn)行驗(yàn)證后，并沒(méi)有及時(shí)同步看板工具中的需求狀態(tài)。在實(shí)際研發(fā)過(guò)程中，這是很常見(jiàn)的現(xiàn)象，以至于統(tǒng)計(jì)發(fā)現(xiàn)很多需求的交付周期都是 0 天，因?yàn)檫@些需求都是在開(kāi)發(fā)完成之后，開(kāi)發(fā)人員補(bǔ)錄的需求，然后從看板第一個(gè)階段列直接拖動(dòng)到最后一列，這樣統(tǒng)計(jì)出來(lái)的數(shù)據(jù)就會(huì)有極大地失真。當(dāng)然，我們應(yīng)該更多使用自動(dòng)化的手段來(lái)同步狀態(tài)，比如開(kāi)發(fā)提交、提測(cè)、部署等行為會(huì)自動(dòng)觸發(fā)對(duì)應(yīng)需求狀態(tài)的流轉(zhuǎn)，但這也需要工具平臺(tái)開(kāi)發(fā)出對(duì)應(yīng)的能力，實(shí)際上也需要成本的投入。
既然度量有這么高的成本，那我們還需要做么？我的答案是，當(dāng)收益大于成本的情況下，度量就是值得做的。度量指標(biāo)應(yīng)該少而精，每個(gè)指標(biāo)都要追求其投資回報(bào)比。但是一些企業(yè)仍然傾向于定義大量的度量指標(biāo)以彰顯其專業(yè)性，有的甚至達(dá)到了成百上千個(gè)指標(biāo)。這樣的做法除了給企業(yè)帶來(lái)巨大的成本，好像很難體現(xiàn)出應(yīng)有的價(jià)值。
在度量指標(biāo)的選擇上，我們經(jīng)常提到一個(gè)詞叫做“北極星指標(biāo)”，也被稱為是首要關(guān)鍵指標(biāo)（One Metric That Matters）。北極星是天空北部的一顆亮星，離北天極很近，幾乎正對(duì)著地軸，從地球北半球上看，它的位置幾乎不變，所以古代人們經(jīng)常依靠它來(lái)辨別方向。在度量領(lǐng)域，我們可以根據(jù)當(dāng)前企業(yè)的上下文，在不同領(lǐng)域選取少量的北極星指標(biāo)來(lái)指導(dǎo)我們改進(jìn)的方向，從目標(biāo)出發(fā)驅(qū)動(dòng)改進(jìn)，從宏觀下鉆、定位到微觀問(wèn)題后再引入更多的過(guò)程性指標(biāo)進(jìn)行輔助分析。
貨物崇拜（Cargo Cults）是一種宗教形式，尤其會(huì)出現(xiàn)在一些與世隔絕的落后土著部落之中。當(dāng)貨物崇拜者看見(jiàn)外來(lái)的先進(jìn)科技物品，便會(huì)將之當(dāng)作神祇般崇拜。第二次世界大戰(zhàn)期間，盟軍為了對(duì)戰(zhàn)事提供支援，在太平洋的多個(gè)島嶼上設(shè)立了空軍基地，以空投的方式向部隊(duì)及支援部隊(duì)的島民投送了大量的生活用品及軍事設(shè)備，從而極大的改善了部隊(duì)以及島民的生活，島民也因此看到了人工生產(chǎn)的衣物、罐頭食品以及其他物品。戰(zhàn)爭(zhēng)結(jié)束后，這個(gè)軍事基地便被廢棄，貨物空投也就自然停止了。此時(shí)，島上的居民做了一件非常有意思的事情——他們把自己打扮成空管員、士兵以及水手，使用機(jī)場(chǎng)上的指揮棒揮舞著著陸信號(hào)，進(jìn)行地面閱兵演習(xí)，試圖讓飛機(jī)繼續(xù)投放貨物，貨物崇拜因此而誕生。
這種現(xiàn)象在研發(fā)效能領(lǐng)域時(shí)有發(fā)生，盡管貨物崇拜的度量指標(biāo)制定者們并沒(méi)有像島民一樣揮舞著指揮棒，但他們卻大量的復(fù)制和粘貼著從網(wǎng)上的各類文章中找來(lái)的度量指標(biāo)，這些指標(biāo)的定義有其場(chǎng)景和上下文，但他們對(duì)這些背景和工作原理并不是很了解。
Google 可以說(shuō)是國(guó)內(nèi)公司膜拜和學(xué)習(xí)的典范，其在度量工程生產(chǎn)力方面也有明確的“QUANTS”模型，分別是：
代碼質(zhì)量（Quality of the code）
工程師注意力（Attention from engineers）
智力復(fù)雜性（Intellectual complexity）
速度與速率（Tempo and velocity）
滿意度（Satisfaction）
這個(gè)指標(biāo)體系看起來(lái)很不錯(cuò)，但是如果一個(gè)組織或團(tuán)隊(duì)的成熟度還比較低，連最基本的需求流轉(zhuǎn)、敏捷協(xié)作都沒(méi)有做好，上來(lái)就引入和對(duì)標(biāo)這些對(duì)工程能力和工程師文化有一定要求的指標(biāo)，很可能適得其反，落入貨物崇拜的誤區(qū)。另外，前兩年在網(wǎng)上也有關(guān)于高效的工程師每天能寫(xiě)多少行代碼的討論，據(jù)說(shuō) Google 的工程師平均每天能編寫(xiě) 100-150 行代碼。但如果不管其上下文（技術(shù)架構(gòu)、平臺(tái)能力、工程師級(jí)別、協(xié)作模式、質(zhì)量標(biāo)準(zhǔn)、統(tǒng)計(jì)口徑等），直接使用這個(gè)指標(biāo)來(lái)進(jìn)行對(duì)標(biāo)，一定會(huì)搞得工程師苦不堪言。
我們經(jīng)常說(shuō)：不要因?yàn)樽叩锰h(yuǎn)，而忘記了為什么出發(fā)。官僚主義的一個(gè)問(wèn)題是，一旦制定了一項(xiàng)政策，遵循該政策就成了官僚主義的目標(biāo)，而不管該政策所支持的組織目標(biāo)是什么。研發(fā)效能度量是為目標(biāo)服務(wù)的，如果一種度量真的很重要，那是因?yàn)樗仨殞?duì)決策和行為產(chǎn)生一些可以想象的影響。
比如軟件開(kāi)發(fā)團(tuán)隊(duì)的經(jīng)理希望通過(guò)引入新的持續(xù)集成系統(tǒng)來(lái)提高生產(chǎn)力，這就是一個(gè)明確的目標(biāo)，在初期落地執(zhí)行時(shí)，可能會(huì)采用持續(xù)集成系統(tǒng)注冊(cè)用戶數(shù)這個(gè)指標(biāo)來(lái)進(jìn)行度量。但是系統(tǒng)的使用不是目的，而是提升生產(chǎn)力的手段，我們更應(yīng)該度量的是應(yīng)用系統(tǒng)后，是否解決了開(kāi)發(fā)人員對(duì)測(cè)試快速反饋的需求，質(zhì)量和效率是否得到了有效提升。
在 Google，使用 GSM（目標(biāo) / 信號(hào) / 指標(biāo)）框架來(lái)指導(dǎo)目標(biāo)導(dǎo)向型指標(biāo)的創(chuàng)建：
目標(biāo)是期望的最終結(jié)果。它是根據(jù)從更高層次上理解的內(nèi)容來(lái)表達(dá)的，不應(yīng)包含具體的度量方法的參考。
信號(hào)是目標(biāo)達(dá)成與否的結(jié)果。信號(hào)本身也可能無(wú)法度量。
指標(biāo)是信號(hào)的代理。代理的含義是指由于信號(hào)本身可能無(wú)法量化，因此需要通過(guò)指標(biāo)來(lái)代理信號(hào)的量化。指標(biāo)是一定可度量的內(nèi)容。
舉個(gè)例子，比如企業(yè)希望代碼的可讀性提高，這樣可以得到更高質(zhì)量、更一致的代碼，也能促進(jìn)健康的代碼文化，那么按照 GSM 框架：
目標(biāo)：由于可讀性的提高，工程師編寫(xiě)了更高質(zhì)量的代碼
信號(hào)：可讀性過(guò)程對(duì)代碼質(zhì)量有積極的影響
指標(biāo)：可讀性評(píng)審對(duì)代碼質(zhì)量沒(méi)有影響或負(fù)面影響的工程師比例、參與可讀性過(guò)程并改善了其團(tuán)隊(duì)的代碼質(zhì)量的工程師比例
在與國(guó)內(nèi)一些企業(yè)的交流中我發(fā)現(xiàn)，很多公司的研發(fā)效能度量都是主要從管理者的視角出發(fā)的，無(wú)論是工時(shí)、人員飽和度等衡量資源利用率的指標(biāo)，還是需求交付周期、吞吐量等衡量流動(dòng)效率的指標(biāo)，本質(zhì)上都是從管理維度看待研發(fā)效能這件事情。但是在前文中我也提過(guò)，我們不應(yīng)該把員工當(dāng)成一種”資源”，而是要作為”工程師”來(lái)看待。 員工幸福感的下降不僅會(huì)影響代碼編寫(xiě)過(guò)程的生產(chǎn)力，還會(huì)影響結(jié)果代碼的質(zhì)量。
所以我們做研發(fā)效能提升，本質(zhì)上還是要多關(guān)注工程師的感受，他們對(duì)工作環(huán)境、工作模式、工作負(fù)載、研發(fā)基礎(chǔ)設(shè)施、項(xiàng)目協(xié)作、團(tuán)隊(duì)發(fā)展、個(gè)人提升是否感到滿意，是否有阻礙工程師發(fā)揮更大創(chuàng)造性和產(chǎn)生更大生產(chǎn)力的因素存在。工程師個(gè)人效能的有效提升是組織效能提升非常關(guān)鍵的組成部分。就像 Facebook 會(huì)把“不要阻塞開(kāi)發(fā)人員”作為貫穿公司研發(fā)和管理實(shí)踐中的核心原則之一，就是強(qiáng)調(diào)公司流程和實(shí)踐也要從工程師視角來(lái)考慮問(wèn)題。
那么，我們?nèi)绾味攘抗こ處煹臐M意度呢？我們可以選擇 eNPS（Employee Net Promoter Score）來(lái)衡量員工的忠誠(chéng)度，更高的員工忠誠(chéng)度可以讓工程師提供更卓越的服務(wù)，讓客戶滿意，最終助力企業(yè)業(yè)務(wù)的成功。當(dāng)然，我們不僅關(guān)注 eNPS 指標(biāo)的數(shù)值本身，還可以將其與其他人力資源指標(biāo)結(jié)合起來(lái)，這樣就可以知道為什么員工會(huì)給出負(fù)面反饋，這將揭示表象背后的原因，并幫助管理者尋找改進(jìn)的方法。
“成功大都相似，失敗各有不同'。 本文分析了研發(fā)效能度量的難點(diǎn)和常見(jiàn)的“反模式'，希望大家能夠在開(kāi)啟效能度量之旅之前，先辨別清楚方向，避免一開(kāi)始就陷入到沼澤泥潭之中。
研發(fā)效能度量“難不難”和“做不做”是兩回事情，正因?yàn)槠涮N(yùn)含的巨大價(jià)值，我們還是要想辦法去探索和實(shí)踐。在下一篇文章中，我會(huì)具體介紹行業(yè)中有關(guān)的權(quán)威報(bào)告、多個(gè)互聯(lián)網(wǎng)大廠的研發(fā)度量案例，并總結(jié)和提煉出其中隱含的度量設(shè)計(jì)思路和關(guān)鍵原則。敬請(qǐng)期待！
作者介紹：
張樂(lè)，DevOps 與研發(fā)效能資深實(shí)踐者，長(zhǎng)期工作于擁有數(shù)萬(wàn)研發(fā)的互聯(lián)網(wǎng)大廠（百度、京東等），主攻敏捷與 DevOps 實(shí)踐、DevOps 平臺(tái)建設(shè)、研發(fā)效能度量體系設(shè)計(jì)等方向，歷任資深敏捷教練、DevOps 平臺(tái)產(chǎn)品總監(jiān)、研發(fā)效能度量標(biāo)準(zhǔn)化聯(lián)盟負(fù)責(zé)人等崗位。長(zhǎng)期活躍于技術(shù)社區(qū)，目前是 DevOps 起源國(guó)際組織 DevOpsDays 中國(guó)區(qū)核心組織者，同時(shí)也是國(guó)內(nèi)多個(gè)技術(shù)峰會(huì)的聯(lián)席主席、DevOps/ 研發(fā)效能專題出品人、特邀演講嘉賓。EXIN DevOps 全系列國(guó)際認(rèn)證授權(quán)講師、鳳凰項(xiàng)目 DevOps 沙盤(pán)國(guó)際授權(quán)教練。歷任埃森哲、惠普等全球五百?gòu)?qiáng)企業(yè)資深咨詢顧問(wèn)、技術(shù)專家，多年敏捷與 DevOps 轉(zhuǎn)型、工程效率提升和大型項(xiàng)目實(shí)踐經(jīng)驗(yàn)。暢銷書(shū)《獨(dú)角獸項(xiàng)目：數(shù)字化時(shí)代的開(kāi)發(fā)傳奇》譯者。
聯(lián)系客服
