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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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