實話說，即使到現在我們的管理層還沒有明確的方法可以衡量程式設計師以及整個團隊的生產力。我可以確定誰可以依賴，誰比較努力，但卻無法證明這些猜想，也沒有量化的方法。難道計算程式碼的多少？這肯定是個笑話。

　　我們的程式碼寫得多，所以我們的生產力更高

　　曾想，既然開發人員的工作就是寫程式碼。那麼，何不通過衡量程式碼的多少來衡量其生產力呢——看看他們寫了多少行程式碼？

　　但是，不同程式語言之間的程式碼行數是沒辦法比較的，即使使用的是相同的程式語言，在不同的框架下的程式設計師之間的生產效率，光看程式碼寫了多少也是無從裁定的。

　　更根本的問題是，通過衡量所寫的程式碼行數來斷定生產力其實沒有意義的。很多軟體開發中的最重要部分還包含思考和學習——不僅僅是寫程式碼。

　　最優秀的程式設計師會將大量的時間用於瞭解和解決疑難雜症，或幫助他人解決難題，而不是寫程式碼。他們會想方設法簡化程式碼，避免重複。他們會通過實驗、建立原型等方式迭代程式碼，替換原先舊的程式碼，以獲得最佳的解決方案。

　　所以，光從程式碼數量上看，還真看不出程式設計師的生產力水平來。

　　我們錢賺得多，所以我們的生產力更高

　　我們也可以通過財務上面的盈利能力來衡量每個團隊的產出，或者其他的業務措施，如有多少使用者正在使用系統——如果開發人員能為企業賺更多的錢（或節省更多的錢），那麼是不是他們的生產力更高呢？

　　利用財政措施似乎在執行層面上是一個不錯的主意，但是卻有太多的商業因素是不受開發團隊控制的。有些開發團隊很垃圾，但他們的產品就是成功了；而有些團隊兢兢業業卻還是隻收穫了失敗的果實。注重節約成本的理念很有可能會導致許多管理者裁人，企圖“少花錢多辦事”，而不是投資於真正的生產力提高。

　　看來此路不通，我們需要尋找其他更有有意義的生產力指標。

　　我們的開發速度快，所以我們的生產力更高

　　衡量開發速度——敏捷速度——看起來更像是另一種從團隊層面來衡量生產力的方式。畢竟，軟體開發的重點是提供可工作的軟體。如果你的團隊能更快地拿出產品，自然是更好。

　　但是，速度（一個團隊在一段時間內能完成的工作）與其說是衡量生產力的，還不如更精確點說，是用來衡量預見性的：用來衡量一個團隊能承受多少的工作。

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

　　保持忙碌的狀態就對了

　　在扣丁參加Android培訓認識的經理曾這樣說道，與其試圖衡量生產力，還不如“保持忙碌的狀態就對了。只要我們不斷地挖掘問題，就一定可以找到瓶頸，解決掉這些難題。”

　　在這種情況下，我們會衡量——並優化——迴圈時間。

　　團隊可以使用看板去監控——並限制——正在進行的工作，並確定瓶頸，使用價值流圖可以瞭解需要優化的步驟、排序、延誤和資訊流。總之一切為了儘快地交貨和釋出。

　　但是我們還是不能將交貨速度等同於生產力。這是因為只優化交付本身的迴圈時間/速度很有可能會導致更大的長期性問題，要知道這種方式實質上是在鼓勵人們只顧眼前，從而偷工減料，揹負技術債務。

　　我們的軟體更好，所以我們的生產力更高

　　眾所周知，軟體中出現bug和錯誤會導致成本顯著提高：不僅開發返工成本高了，維護和支援的成本也高了。而最最重要的是，差的軟體可能會造成客戶的流失，甚至是生意的失敗。

　　要想衡量你正在寫的軟體是好是壞也很容易：缺陷密度、缺陷逃逸率，以及利用SonarQube之類的工具對程式碼庫進行靜態分析。

　　我們知道如何編寫好的軟體。但是軟體質量是否真的足以定義生產力？

　　開發人員——衡量和改進IT效能

　　開發團隊試著綜合上述一些因素來衡量生產力：交付速度和質量。

　　但開發人員並不限於建立和提供程式碼——相反還需要著眼於為端到端提供IT服務的效能指標：交付吞吐量和服務質量。

　　所以這不只是軟體更快、更好的問題，而是需要提供更好更快的服務，在速度和功能之間選擇平衡，衡量並提高生產效率和質量。

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

　　衡量成效，而不是產量

　　不要再試圖去衡量單個開發人員的生產力了。

　　這純粹是在浪費時間。

　　每個人心中都有一杆秤。 對於表現優秀的——鼓勵他們繼續朝著正確的方向前進，再接再厲。對於那些努力上進的——給予他們幫助。對於那些不適合的——可以請出去了。

　　衡量和提高團隊或組織級別的生產力將會讓你收穫更加有意義的回報。

　　當涉及到生產力時：

　　1.衡量關鍵因素——能對團隊和組織起重要作用的因素。

　　2.設定的指標應該是起積極作用的——可以推動學習和改進，而不是造成團隊或個人之間關於產量的惡性競爭。