如果你用谷歌搜索“mearsuring software developer productivity”，那么你會(huì)發(fā)現(xiàn)出來(lái)的全都是一些廢話(huà)，一點(diǎn)用處都沒(méi)有的廢話(huà)?！狽ick Hodges，《Measuring Developer Productivity》

所以現(xiàn)在你知道了吧，原來(lái)我們并沒(méi)有辦法來(lái)衡量程序員的工作效率。

老實(shí)說(shuō)，我們現(xiàn)在還沒(méi)有明確的方法可以衡量程序員以及整個(gè)團(tuán)隊(duì)的生產(chǎn)力。我們可以確定誰(shuí)可以依賴(lài)，誰(shuí)比較努力，但卻無(wú)法證明這些猜想，也沒(méi)有量化的方法。

我們的代碼寫(xiě)得多，所以我們的生產(chǎn)力更高

既然開(kāi)發(fā)人員的工作就是寫(xiě)代碼。那么，何不通過(guò)衡量代碼的多少來(lái)衡量其生產(chǎn)力呢——看看他們寫(xiě)了多少行代碼？

但是，不同編程語(yǔ)言之間的代碼行數(shù)是沒(méi)辦法比較的，即使使用的是相同的編程語(yǔ)言，在不同的框架下的程序員之間的生產(chǎn)效率，光看代碼寫(xiě)了多少也是無(wú)從裁定的。

更根本的問(wèn)題是，通過(guò)衡量所寫(xiě)的代碼行數(shù)來(lái)斷定生產(chǎn)力其實(shí)沒(méi)有意義的。很多軟件開(kāi)發(fā)中的最重要部分還包含思考和學(xué)習(xí)——不僅僅是寫(xiě)代碼。

最優(yōu)秀的程序員會(huì)將大量的時(shí)間用于了解和解決疑難雜癥，或幫助他人解決難題，而不是寫(xiě)代碼。他們會(huì)想方設(shè)法簡(jiǎn)化代碼，避免重復(fù)。他們會(huì)通過(guò)實(shí)驗(yàn)、建立原型等方式迭代代碼，替換原先舊的代碼，以獲得最佳的解決方案。

所以，光從代碼數(shù)量上看，還真看不出程序員的生產(chǎn)力水平來(lái)。

我們錢(qián)賺得多，所以我們的生產(chǎn)力更高

我們也可以通過(guò)財(cái)務(wù)上面的盈利能力來(lái)衡量每個(gè)團(tuán)隊(duì)的產(chǎn)出，或者其他的業(yè)務(wù)措施，如有多少用戶(hù)正在使用系統(tǒng)——如果開(kāi)發(fā)人員能為企業(yè)賺更多的錢(qián)（或節(jié)省更多的錢(qián)），那么是不是他們的生產(chǎn)力更高呢？

利用財(cái)政措施似乎在執(zhí)行層面上是一個(gè)不錯(cuò)的主意，但是卻有太多的商業(yè)因素是不受開(kāi)發(fā)團(tuán)隊(duì)控制的。有些開(kāi)發(fā)團(tuán)隊(duì)很垃圾，但他們的產(chǎn)品就是成功了；而有些團(tuán)隊(duì)兢兢業(yè)業(yè)卻還是只收獲了失敗的果實(shí)。注重節(jié)約成本的理念很有可能會(huì)導(dǎo)致許多管理者裁人，企圖“少花錢(qián)多辦事”，而不是投資于真正的生產(chǎn)力提高。

看來(lái)此路不通，我們需要尋找其他更有有意義的生產(chǎn)力指標(biāo)。

我們的開(kāi)發(fā)速度快，所以我們的生產(chǎn)力更高

衡量開(kāi)發(fā)速度——敏捷速度——看起來(lái)更像是另一種從團(tuán)隊(duì)層面來(lái)衡量生產(chǎn)力的方式。畢竟，軟件開(kāi)發(fā)的重點(diǎn)是提供可工作的軟件。如果你的團(tuán)隊(duì)能更快地拿出產(chǎn)品，自然是更好。

但是，速度（一個(gè)團(tuán)隊(duì)在一段時(shí)間內(nèi)能完成的工作）與其說(shuō)是衡量生產(chǎn)力的，還不如更精確點(diǎn)說(shuō)，是用來(lái)衡量預(yù)見(jiàn)性的：用來(lái)衡量一個(gè)團(tuán)隊(duì)能承受多少的工作。

但是，我們又不得不考慮人員加入或離開(kāi)等對(duì)速度的影響因素。而且，有一點(diǎn)你得清楚，速度只能只能用于衡量已知團(tuán)隊(duì)——由于很多因素的不同，速度并不能用于不同團(tuán)隊(duì)之間的比較。

保持忙碌的狀態(tài)就對(duì)了

一個(gè)我認(rèn)識(shí)的經(jīng)理曾這樣說(shuō)道，與其試圖衡量生產(chǎn)力，還不如

“保持忙碌的狀態(tài)就對(duì)了。只要我們不斷地挖掘問(wèn)題，就一定可以找到瓶頸，解決掉這些難題?！?/p>

在這種情況下，我們會(huì)衡量——并優(yōu)化——循環(huán)時(shí)間。

團(tuán)隊(duì)可以使用看板去監(jiān)控——并限制——正在進(jìn)行的工作，并確定瓶頸，使用價(jià)值流圖可以了解需要優(yōu)化的步驟、排序、延誤和信息流。總之一切為了盡快地交貨和發(fā)布。

但是我們還是不能將交貨速度等同于生產(chǎn)力。這是因?yàn)橹粌?yōu)化交付本身的循環(huán)時(shí)間/速度很有可能會(huì)導(dǎo)致更大的長(zhǎng)期性問(wèn)題，要知道這種方式實(shí)質(zhì)上是在鼓勵(lì)人們只顧眼前，從而偷工減料，背負(fù)技術(shù)債務(wù)。

我們的軟件更好，所以我們的生產(chǎn)力更高

眾所周知，軟件中出現(xiàn)bug和錯(cuò)誤會(huì)導(dǎo)致成本顯著提高：不僅開(kāi)發(fā)返工成本高了，維護(hù)和支持的成本也高了。而最最重要的是，差的軟件可能會(huì)造成客戶(hù)的流失，甚至是生意的失敗。

要想衡量你正在寫(xiě)的軟件是好是壞也很容易：缺陷密度、缺陷逃逸率，以及利用SonarQube之類(lèi)的工具對(duì)代碼庫(kù)進(jìn)行靜態(tài)分析。

我們知道如何編寫(xiě)好的軟件。但是軟件質(zhì)量是否真的足以定義生產(chǎn)力？

開(kāi)發(fā)人員——衡量和改進(jìn)IT性能

開(kāi)發(fā)團(tuán)隊(duì)試著綜合上述一些因素來(lái)衡量生產(chǎn)力：交付速度和質(zhì)量。

但開(kāi)發(fā)人員并不限于創(chuàng)建和提供代碼——相反還需要著眼于為端到端提供IT服務(wù)的性能指標(biāo)：交付吞吐量和服務(wù)質(zhì)量。

所以這不只是軟件更快、更好的問(wèn)題，而是需要提供更好更快的服務(wù)，在速度和功能之間選擇平衡，衡量并提高生產(chǎn)效率和質(zhì)量。

還有一點(diǎn)，最近有研究表明，企業(yè)要想成功：不僅生產(chǎn)力要提高，更重要的是要提高市場(chǎng)份額和盈利能力。

衡量成效，而不是產(chǎn)量

不要再試圖去衡量單個(gè)開(kāi)發(fā)人員的生產(chǎn)力了。

這純粹是在浪費(fèi)時(shí)間。

每個(gè)人心中都有一桿秤。 對(duì)于表現(xiàn)優(yōu)秀的——鼓勵(lì)他們繼續(xù)朝著正確的方向前進(jìn)，再接再厲。對(duì)于那些努力上進(jìn)的——給予他們幫助。對(duì)于那些不適合的——可以請(qǐng)出去了。

衡量和提高團(tuán)隊(duì)或組織級(jí)別的生產(chǎn)力將會(huì)讓你收獲更加有意義的回報(bào)。

所以當(dāng)涉及到生產(chǎn)力時(shí)：

1.衡量關(guān)鍵因素——能對(duì)團(tuán)隊(duì)和組織起重要作用的因素。

2.設(shè)置的指標(biāo)應(yīng)該是起積極作用的——可以推動(dòng)學(xué)習(xí)和改進(jìn)，而不是造成團(tuán)隊(duì)或個(gè)人之間關(guān)于產(chǎn)量的惡性競(jìng)爭(zhēng)。