2019獨角獸企業重金招聘Python工程師標準>>>

據江邊望海了解很多互聯網公司都會執行Kpi考核。一線的開發人員的Kpi工作量化不僅困擾這公司的HR也困擾著開發人員自己。月底的時候如何通過有效的數據分析每個開發人員的工作內容是一個很頭疼的問題。所以，很多開發人員的Kpi績效考核是直接領導憑借感覺打出來的。

很多網絡公司每年都會有職位晉升的機會。但是，開發人員在準備填寫晉升表的時候發現能拿出手的數據少之又少。天天在忙，卻忙的沒有結果。

1.基礎篇

1.1.產品線思路

開發人員是網絡公司的基礎資源，類似大廚手中的食材。很多時候都是在相應產品經理、公司業務的需求。每個開發人員既隸屬于行政劃分的智能部門有隸屬于虛擬劃分的產品線。所以，每個開發人員至少與一個產品線有關聯。

第一步：明確任務數：

產品線的工作量就是開發人員的工作量。比如。某個產品線在迭代的第一個周期，產品經理輸出了30個需求。而這30個需求又被項目經理（一般由開發主管擔任）分解成了90個任務。假設這個產品線一共有5個開發人員。你自己領取的和領導指派給你的任務是20個。

第二步：明確工時：

每個任務的處理都需要碼農（開發人員）在下面不停的碼代碼。碼完之后需要把工時記錄下來。很多碼農會質疑，我怎么能清楚的算出我完成任務所花費的時間呢？答案是，一開始肯定不精確，但是隨著你和團隊逐漸在意工時這個參數了，也就以為著這個數值會越來越準。

第三步：明確BUG：

有任務就肯定會產生BUG。指派給你的20個任務不可能不出現BUG，如果沒有出現恭喜你，你已經成為『任務君』啦。BUG量越少越能體現任務執行的質量。

綜述：任務數+工時+BUG是考核開發人員重點。

PS:很多時候，新入職的開發人員處理的是前任開發人員遺留的BUG。這個時候就可以將這個BUG理解成任務。當開發人員處理這個任務的時候再出現BUG的時候就需要這個開發人員產生的BUG啦。也符合上述的考核邏輯。

1.2.技術點思路

第一步：單元測試

很多開發人員沒有寫過單元測試，究其原因是團隊太小，沒有完整的開發流程，看得是結果，中間過程能省的就省了。殊不知，編寫單元測試不僅有利于你理解產品的需求而且方便今后的代碼維護。所以，單元測試編寫的覆蓋率可以作為考慮一個開發人員是否有良好編寫規范的一個重要指標。

第二步：代碼質量

提交代碼多的程序猿不一定是一個好的程序猿，但是提交代碼量少的一定不是好的程序猿。他的提交代碼量跟任務量是有關聯的。可以根據他一個迭代周期『代碼量/提交次數』來分析出代碼質量。當然，這是一個粗略的數值。最終加上研發組組長的定期Review可以很好的來衡量他的代碼質量。

2.晉級篇

2.1.專利

其實，很多程序猿很苦逼的。有一大部分是在十幾或者幾十人的小的互聯網公司。說是互聯網公司，可能就是當地的一家做網絡平臺的代理商而已。根本沒有什么研發能力的，公司層面也只是為了賺錢，并沒有把企業的軟實力作為一種核心競爭力來打造。不過，對于北上廣的網絡公司而言，是比較注重專利的申請。

開發人員跳槽往往最有價值的是工作經驗。但是，這個并不會讓你的職業生涯有質的變化，在這家是開發人員到了那家還是開發人員，可能薪水比那家拿的多了一些。如果有『專利發明人』的頭銜那就不一樣了。第一：他是可量化的；第二：它是開發人員的職業里程碑。開發人員往往只關注如何做事兒，卻很少思考如何做成一件事兒。而專利其實就是開發人員職業上升的一個重要標志。所以，在做好8小時工作外，要思考如何從工作中提取專利技術。這個將來對你做技術管理崗位還是架構師都有非常大的幫助。

2.2.發布文章

一個好的開發人員不僅天天在網上查找資料，也會將自己的開發經驗分享出去。現在很多公司都在使用開源軟件。所以，很多研發團隊都有開源精神。博客是一種非常好的分享方式，但是這并不能讓一個開發人員有更好的成就感。所以，可以選擇一些權威的雜志或者專欄投稿。已經采用這對于你來說是一個非常了不得的成就。兩條路：1.要不堅持寫博客，寫多了整理成書；2.要不就向權威的雜志投稿。

本文出自：http://blog.jiangbianwanghai.com/2016/02/23/how-to-solve-the-problem-of-unable-to-quantify-in-developers-work/

轉載于:https://my.oschina.net/jiangbianwanghai/blog/480023

總結

以上是生活随笔為你收集整理的如何解决开发人员的工作无法量化的问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。