2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

據(jù)江邊望海了解很多互聯(lián)網(wǎng)公司都會執(zhí)行Kpi考核。一線的開發(fā)人員的Kpi工作量化不僅困擾這公司的HR也困擾著開發(fā)人員自己。月底的時候如何通過有效的數(shù)據(jù)分析每個開發(fā)人員的工作內(nèi)容是一個很頭疼的問題。所以，很多開發(fā)人員的Kpi績效考核是直接領(lǐng)導(dǎo)憑借感覺打出來的。

很多網(wǎng)絡(luò)公司每年都會有職位晉升的機(jī)會。但是，開發(fā)人員在準(zhǔn)備填寫晉升表的時候發(fā)現(xiàn)能拿出手的數(shù)據(jù)少之又少。天天在忙，卻忙的沒有結(jié)果。

1.基礎(chǔ)篇

1.1.產(chǎn)品線思路

開發(fā)人員是網(wǎng)絡(luò)公司的基礎(chǔ)資源，類似大廚手中的食材。很多時候都是在相應(yīng)產(chǎn)品經(jīng)理、公司業(yè)務(wù)的需求。每個開發(fā)人員既隸屬于行政劃分的智能部門有隸屬于虛擬劃分的產(chǎn)品線。所以，每個開發(fā)人員至少與一個產(chǎn)品線有關(guān)聯(lián)。

第一步：明確任務(wù)數(shù)：

產(chǎn)品線的工作量就是開發(fā)人員的工作量。比如。某個產(chǎn)品線在迭代的第一個周期，產(chǎn)品經(jīng)理輸出了30個需求。而這30個需求又被項目經(jīng)理（一般由開發(fā)主管擔(dān)任）分解成了90個任務(wù)。假設(shè)這個產(chǎn)品線一共有5個開發(fā)人員。你自己領(lǐng)取的和領(lǐng)導(dǎo)指派給你的任務(wù)是20個。

第二步：明確工時：

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

第三步：明確BUG：

有任務(wù)就肯定會產(chǎn)生BUG。指派給你的20個任務(wù)不可能不出現(xiàn)BUG，如果沒有出現(xiàn)恭喜你，你已經(jīng)成為『任務(wù)君』啦。BUG量越少越能體現(xiàn)任務(wù)執(zhí)行的質(zhì)量。

綜述：任務(wù)數(shù)+工時+BUG是考核開發(fā)人員重點(diǎn)。

PS:很多時候，新入職的開發(fā)人員處理的是前任開發(fā)人員遺留的BUG。這個時候就可以將這個BUG理解成任務(wù)。當(dāng)開發(fā)人員處理這個任務(wù)的時候再出現(xiàn)BUG的時候就需要這個開發(fā)人員產(chǎn)生的BUG啦。也符合上述的考核邏輯。

1.2.技術(shù)點(diǎn)思路

第一步：單元測試

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

第二步：代碼質(zhì)量

提交代碼多的程序猿不一定是一個好的程序猿，但是提交代碼量少的一定不是好的程序猿。他的提交代碼量跟任務(wù)量是有關(guān)聯(lián)的?？梢愿鶕?jù)他一個迭代周期『代碼量/提交次數(shù)』來分析出代碼質(zhì)量。當(dāng)然，這是一個粗略的數(shù)值。最終加上研發(fā)組組長的定期Review可以很好的來衡量他的代碼質(zhì)量。

2.晉級篇

2.1.專利

其實，很多程序猿很苦逼的。有一大部分是在十幾或者幾十人的小的互聯(lián)網(wǎng)公司。說是互聯(lián)網(wǎng)公司，可能就是當(dāng)?shù)氐囊患易鼍W(wǎng)絡(luò)平臺的代理商而已。根本沒有什么研發(fā)能力的，公司層面也只是為了賺錢，并沒有把企業(yè)的軟實力作為一種核心競爭力來打造。不過，對于北上廣的網(wǎng)絡(luò)公司而言，是比較注重專利的申請。

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

2.2.發(fā)布文章

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

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

轉(zhuǎn)載于:https://my.oschina.net/jiangbianwanghai/blog/480023

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。