一個令人震驚的事實是連生產率這種常見度量數據都沒有一個簡單的定義。連我們日常經常用到的公式：生產率=工作產品/工作量（工作產品可以是代碼行，功能點，也可以是任何可以計數的東西，比如文檔頁數）都是錯誤的。
如果你正常嘗試使用生產率做度量，那麼至少應該先分爲下面兩種度量數據。
注意下面的例子爲了便於理解使用的是代碼行，但實際上這兩個概念是IFPUG（國際功能點用戶組）對功能點計數時做的分類。
應用類數據 Application Type
下面這段對話將產生一個應用類度量數據：
A：“這個軟件有多少代碼行？”
B：“等我數一下……10000行”。
A：“多少人天開發出來的？”
B：“大約100人天吧”
A：“那麼生產率=10000行/100人天=100行/人天”
這種生產率是按一個應用（Application這個詞彙的來歷）的靜態規模度量產生的生產率，過一段時間會發生戲劇性的變化：
三個月後……
B：“我們又修改了一些代碼，增加了一些代碼，但是也刪除了一些代碼”
A：“哦？”
B：“多投入了100人天，不過現在還是10000行。”
A：“那麼現在的總生產率是：10000行/200人天=50行/人天；如果只算二期麼……0，我也幫不了你了”
B：“好吧……二期算是白忙一場”
開發類數據 Development Type
A：“這個軟件有多少代碼行？”
B：“一共有兩期……等我數一下……第一期100人天開發了10000行……第二期也是100人天，增加2500行，刪除2500行，修改5000行”。
A：“那麼一期生產率=10000行/100人天=100行/人天”
B：“二期呢？”
A：“二期生產率=（增加2500+刪除2500+修改5000）/100人天=10000行/100人天=100行/人天”
B：“yeah!“
A：”不過，也有的體系說二期生產率=（增加2500+刪除2500/2+修改5000）/100人天=8750行/100人天=87.5行/人天
B：”啊？“
A：”等下……還有體系說二期生產率=（增加2500+刪除2500/4+修改5000/2）/100人天=……這個，你自己算吧。“
B：”好吧，總算比白忙一場好。“
如何使用？
場景一：計劃與績效考覈=開發類數據
由於增刪改都要花費工作量，所以用開發類數據做計劃和考覈更加公平一些。
不過，一般採用功能點更加合理一些，比如在重構中極有可能刪除大段的代碼（我們曾經在15分鐘左右把4000行代碼重構爲55行，功能不變），而實際上應用的變化並不大。如果用這種外界（客戶，高層）難以感受到的“變化”來做度量元，很難得到認同。
三種體系（增刪改權值相同，或/2，或/2/4）選擇哪個好呢？
我也不知道，因爲這三種體系都有人在用。我的建議是：
1. 如果剛剛開始做度量
隨便選擇一個方法就好了，但是請記錄下原始數據。
也就是說，要記住有多少新增，多少刪除，多少修改。
2. 數據積累比較多了
請按三種方法都計算一次，然後對比一下計算結果和實際工作量的相關係數（相關係數日後會科普一下，Excel表裏變有這個函數CORREL(B1:G1,B2:G2），相關係數越高表明用這種方法做估算更接近事實。
度量分析沒有“理論上哪個最好”，只有數據本人才有發言權。
或者說，度量分析的本質就是消除各種理論的主觀性、片面性、理想化，把發言權留給數據本身。所以自己做數據分析是免不了的事情。
場景二：需求變更控制
不過，不論有多少理由，一個軟件只修改、刪除功能而不增加功能，都不是一個正常的事情。
過多修改功能表明需求分析最初做的不好，而刪除功能則表明做了過多的無用功能。
爲了約束團隊，防止他們把“改軟件”當作工作，需要定期監控兩者的比值：應用類/開發類，如果這個數據不斷下降，表明大家都在修改之前的功能，很久沒有大量增加功能了。
在小而美的產品研發中，修改功能可能是一個常態，但這不能作爲開始可以不深入思考“最佳功能”的理由。
在項目開發尤其是外包項目中，只修改而不增加功能是一個災難，因爲客戶多數時候不會爲修改功能付費，他們認爲這是因爲乙方未能深入分析需求造成的。
場景三：編碼有效性
也就是用多少代碼能實現多少功能的問題，編碼有效性越高，則所需代碼越少。（日後有詳細文章描述）
當然，這裏的“功能”指國際標準功能點度量出來的功能，而不是我們平時所說的“個人理解不同規模也不同”的那種直覺功能。
在這種場景中，應該使用：編碼有效性=總代碼行/總功能點數=總代碼行/應用類功能點數。
比如在之前那個例子中，第二期代碼行可能還是10000行，但是如果功能點增加了，那麼編碼有效性實際上增高了。
完整示例
下面是一個功能點、代碼行、編碼有效性、應用類、開發類數據的完整應用場景。
A：“這個軟件有多少代碼行和功能點？”
B：“一共有兩期……等我數一下……第一期100人天開發了10000行，200功能點……第二期也是100人天，增加2500行，刪除2500行，修改5000行；增加50功能點，刪除20功能點，修改30功能點”。
A：“那麼一期代碼行生產率=10000行/100人天=100行/人天，功能點生產率=200功能點/100人天=2功能點/人天”
B：“二期呢？”
A：“二期生產率=（增加2500+刪除2500+修改5000）/100人天=10000行/100人天=100行/人天，功能點生產率=（增50+刪20+改30）功能點/100人天=100功能點/100人天=1功能點/人天”（暫時只用第一種增刪改權值算法）
B：“哪期項目做得快呢？“
A：“從代碼行看，一樣；從功能點看，一期項目快一倍。”
B：“以哪個爲準好呢？”
A：“功能點好，比較容易給客戶和領導交代”
B：“二期真爛。”
A：“也未必，你們的編碼有效率提升了。”
B：“怎麼講？”
A：“二期完成後（不是二期開發本身），整個產品還是10000行，功能點卻增加爲300，你們現在的代碼效率已經達到10000/300=33行/功能點了（越低越好，一期是10000/200=50）”
B：“生產率降低，編碼有效性提高……怎麼做整體評價呢？”
A：“生產率提高是終極目標，不過編碼有效性的提升有利於未來的生產率和質量的提升。所以，現在總體評價是生產率下降了，未來要看你們以後是否能真正發揮編碼有效率的優勢了。”
怎麼樣？如果是我，如果能寫一個由數字組成的項目報告，我纔不會寫一大堆模棱兩可的文字呢。