伯樂線上導讀： 2003年8月29日，軟體行業大牛Martin Fowler寫過《無法衡量生產效率》。10年後的8月29日，Martin 在其網站首頁以《十年後仍無法衡量生產效率》標題再次推薦了這篇文章，並附言：“軟體行業的巨大挫敗之一，是我們沒有合理建立研究，去思考諸如物件導向程式設計和測試驅動開發之類的開發工具和技術、還有其他更高階的語言是否對我們有益。我們經常看到不當的研究，並且常常很糟糕，是因為它們是基於一個錯誤的衡量方法（比如員工每天所編寫程式碼的行數）。十年前的今天，我的挫敗感促使我寫了《無法衡量生產效率》一文。我認為該文在今天看起來，和十年前沒什麼不同。” （完整譯文見下文。感謝@治不好你我就不是獸醫 的翻譯。如果其他朋友也有不錯的原創或譯文，可以嘗試提交到伯樂線上。）
我們見到過太多關於軟體開發過程、設計實踐以及類似內容充滿激情的討論。它們當中有很多是無法驗證的，因為軟體行業沒有能去衡量代表開發效率的一些基本元素。特別是我們無法合理地衡量生產效率。
當然，生產效率可以通過觀察生產過程的輸入與產出來衡量。所以，要衡量軟體開發的生產效率，你就必須去衡量軟體開發的產出。我們無法衡量生產效率的根源就在於我們無法衡量產出。
並不是說人們沒有嘗試過。最令我氣憤的就是那些用程式碼行數來衡量生產效率的研究。首先，總是存在不同的語言、不同的計數方式、不同的格式化風格造成的問題。即使採用一致的計數標準，衡量相同語言程式碼，且程式碼被自動格式化為統一的風格，程式碼行數仍然無法正確反映產出。
任何優秀的開發者都知道，讓他們去實現一個特定功能所需的程式碼行數可能相差巨大。除此之外，精心設計以及重構過的程式碼都會更短小，因為它消除了冗餘。複製貼上風格的程式會有更多的行數以及更差的設計，因為它充滿冗餘。這很好證明，只要你使用一個支援inline method的重構工具去修改一個程式。只需用這個工具去重構那些普通函式，你就可以輕易讓程式碼行數翻倍。
你可能覺得已經沒人再用程式碼行數了，實際上每個月我都能看到基於程式碼行數的生產效率研究論文，甚至是在類似IEEE Software這樣令人尊敬的期刊上。
也不是說程式碼行數是個完全沒用的衡量，它能很好代表系統規模。我可以很確定一個100 KLOC（KLOC=千程式碼行）的系統比一個10KLOC的系統要大。但是如果我用了一年時間寫了那個100KLOC的系統，而Joe在一年內用10KLOC實現了同樣的系統，這無法說明我更高產。實際上我得到的結論是：我們的生產效率差不多，但我的系統設計得更差。
另一個經常被用來衡量產出的方法是使用功能點（Function Points）。雖然我更同情這種做法，但它並不能令我信服。我聽過很多這樣的故事：同一個系統，不同人統計的功能點數目相差有3倍之多。
即使我們能夠找到一種方式用功能點精確衡量功能，我認為這仍然無助於解決生產效率的衡量問題。可以這麼說，衡量功能點是觀察軟體開發直接產出的方式，但真實產出確是另一回事。假設有一個精確的功能點計算系統，如果我花一年釋出了一個有100個FP（功能點）的系統，同時Joe也用一年釋出了一個50FP的系統，是不是就能說我更高產？我覺得不是。很可能我做的100FP中只有30個對我的客戶來說是真正有用的功能，而Joe開發的功能則全部都是有用的。我會這麼說：雖然我的直接生產效率更高，但Joe的真實生產效率更高。
Jeff Grigg向我指出，還存在影響功能點交付的內因。我的100個功能點可能提供的都是很相似的功能，我之所以花了一年時間，是因為我沒有很好的重用程式碼。Joe的50個功能都是差別相當大的（對他來說可不是個好訊息），所以幾乎沒有重用的可能。儘管需要實現50個相當不同的功能，並且幾乎無法重用程式碼，但Joe真的很棒，他在一年之內就全部完成了。
但這些都忽視了一點：即使是有用的功能也無法真正用來做衡量。假設我有了進步，完成了30個有用的功能點，同時Joe只完成了15個。但有人會發現Joe的15個功能點為我們的客戶增加了1千萬的盈利，但我的工作成果帶來的盈利只有500萬。我仍然認為Joe的真實生產效率要比我高，因為他產出了更多的商業價值。並且我堅信任何真正的軟體生產效率衡量必須基於其所帶來的商業價值。
這種思想也適用於成功率。通常關於軟體專案成功的判斷都是虛假的，因為人們並不理解什麼是失敗。我可以說一個成功的專案就是產生的商業價值大於研發成本的專案。假如Joe和我各參與了5個專案，我的4個專案是成功的，而Joe只有一個專案成功。這是不是就意味著我乾的比Joe好呢？這可不一定。如果我的4個專案每個盈利1百萬，而Joe那個成功專案的收入比他所有的5個專案成本的總和還要多出1千萬，那麼他才是那個應當獲得提拔的人。
有些人會說“如果無法衡量，就無法管理”，這是站不住腳的。商業領域中，人們一直在管理著那些他們無法衡量價值的東西。你如何衡量一個公司裡律師的生產效率？如何衡量市場部門、教育機構？你無法衡量，但你任然需要去管理它們（更多資訊參考Robert Austin）。
如果團隊的生產效率都很難衡量，那麼個人對團隊的貢獻就更難衡量了。通過觀察每個迭代產出特性的多少，你可以對團隊的產出有個大致的概念。這是個很粗糙的感受，但是你可以感覺出團隊的速率是否有所提高，或者大致感覺出兩個團隊的生產效率哪個更高一些。但是個人的貢獻值就很難計算了。可能有的成員職責是實現特性，而有些成員的角色可能是協助者——他們負責幫助他人實現特性。他們的作用是提升整個團隊的生產效率——除非你是這個團隊中的一個開發者，你將很難搞清楚這些人的產出到底是什麼。
如果你覺得這些情況還不夠複雜，在《經濟學人》（sep 13-19,2003）上有一篇關於生產效率趨勢的文章。經濟學家們似乎發現，由於90年代中對計算機產業的投資導致瞭如今商業領域中生產效率的提升。
這其中的重點是——增長是落後於投資的：“對計算機方面的投資並不會自動地推動生產效率提升，公司同時也需要重組他們的商業實踐”。同樣的滯後效應也出現在電力發明之後。
所以商業價值不僅難於衡量，還存在時延。很可能直到團隊構建的軟體釋出多年之後，你才能夠衡量團隊的生產效率。
我可以理解為什麼衡量生產效率如此具有誘惑性。如果可以做到，我們就可以更容易、更客觀地評估軟體。然而錯誤的衡量方式只會使問題惡化。我覺得必須承認：在這一領域，我們仍然很無知。