衡量開發人員的工作量一直是讓很多管理者頭疼的問題，開發工作的不易量化讓對於開發人員個體的工作變得難以評估。這時許多管理者為了圖方便，直接只用代碼行數來評估開發人員的工作量，這讓很多開發人員都苦不堪言。
在開發工作中，代碼行數體現的數據最直觀，這點我們不能否認，它一定是一個可以參考的維度。但是如果僅用代碼行數來評估開發人員的工作量，甚至以代碼行數來設定 KPI ，這無疑是非常錯誤的行為，其帶來的後果也是非常嚴重的。
首先這並不是一種非常專業且科學的評估方式，甚至會讓制定該規則的人顯得有些「業餘」。親自有過項目經驗的開發者和技術管理人員應該都知道，一個項目中真正耗費精力的地方是框架搭建、功能需求分解，以及後續的功能測試，真正去寫代碼的時間佔比其實並沒有多少。
其次，如果僅用代碼行數來評估開發工作量的話，團隊所面臨的最大難題便是垃圾代碼的增加。團隊成員為了完成 KPI ，在本就能 20 行寫完的功能上加入各種註釋和無用的函數，甚至直接往項目裡面貼源碼，而不去考慮代碼的耦合性、可讀性、可維護性、重用性等。雖然 KPI 完成了，但開發人員逐漸降低的效率、延誤越來越久的項目、質量越來越低的代碼，團隊在進行著完全沒有必要的內耗，會讓整個項目越來越艱難，和最初的目的背道而馳。
比爾蓋茨曾經總結過這麼一句話，“用代碼行數來衡量編程的進度，就如同用重量來衡量飛機的製造進度”。沒錯的，代碼數量並不等於代碼質量，一味的追求寫了多少行代碼沒有多大本質意義，關鍵在於是不是真的解決了實際問題。而只用代碼行數來評估工作量，無疑是管理方式落後的表現。不客氣的講，這樣的管理者思想仍舊停留在農耕時代，高產出=高價值，這樣的等式在軟件研發領域是不成立的。
那麼，一個合格的管理者到底應該如何科學的評估開發人員的工作量呢？
目前比較常見的方法是基於 WBS（Work Breakdown Structure）的工作量估算，也稱作自下而上法。通常的估算步驟如下：
- 尋找類似的歷史項目，進行項目的類比分析，根據歷史項目的工作量憑經驗估計本項目的總工作量；
- 進行 WBS 分解，力所能及地將整個項目的任務進行分解；
- 參考類似項目的數據，採用類比法或專家法，估計 WBS 中每類活動的工作量；
- 彙總得到項目的總工作量；
- 與第1步的結果進行印證分析，根據分析結果，確定估計結果。
此外，也有 Putnam 模型、 COCOMOⅡ模型、IBM 模型等科學的估算方法，雖然看起來比較複雜，但比「一刀切」式的只看代碼行數的評估方法要有效的多。
始終追求高效開發協作的 Gitee 企業版也在和大家一起探索更科學、合理、公正的工作量評估體系，Gitee 企業版剛上線不久的「統計」模塊將多維度可視化的指標獨立出來，讓管理者更全面、直觀、立體地瞭解項目進度級團隊情況。
「統計」模塊在未來仍將會是 Gitee 企業版的重點，後續我們會對該模塊持續改進，提高大家的效率是我們不變的目標。
閱讀更多 Gitee官方 的文章
