如何對程序員績效考核？

01-05

因為自己是php的，所以尤其想聽聽php程序員管理的經驗。

我干過這事兒，來拋磚引玉吧。

不是我想做，是當時的公司有這制度，財年結束前要和部門裡的每個人面談一次，填一摞表格。

我們程序員都知道這工作不是工廠里拿計件工資的工人，比如今天你做八個工時，組裝了五十台收音機，質檢發現兩台次品，為了質量管理的需要，你今天的績效是四十八台收音機，如果每台收音機你掙五塊錢，那麼你今天掙了5*48=240元。如果你一個季度生產率排名考前，公司考慮給你每台加五毛錢。如此這般。

但程序員的真正績效是他的competence，這不是一個容易量化的概念。competence可以是創造性的解決技術或業務問題，可以是緊張項目開發中爆發的個人效率，可以是長期和別的部門對接時候的影響力，可以是永遠不成為bottleneck的自我管理能力，可以是因為個人實力帶給項目團隊的確定性，可以是在需要的時候提供某個特別具體的技術方案或者理念與實踐，可以是在危機的時候願意投入自己時間到非自己領域的團隊精神，可以是寫出的東西對開源社區的貢獻以及因此給公司帶來的無形效益，可以是帶領新人大大加速他們的融入，也可以是一串充滿靈感的優質代碼 ...

籠統得說，就是用自己的技術和經驗搞定事情的那種能力。

編程太複雜了，一個人可以貢獻的方面太多了，如果用傳統的績效考核制度，就很容易給團隊套上緊箍咒，制度不合適，不充分反映工作性質，就會產生副作用，制度和人，人和人之間就會產生桎梏，分散團隊注意力，破壞團隊和諧。做考核的人要小心翼翼，把一個人放進一個預設好的框框里，實際上這種工作一點意義也沒有。

為什麼有些公司要自尋煩惱？也許因為老闆是從傳統行業過來的，不熟悉IT團隊的工作方式，下面的人也不敢告訴他。也許是因為公司需要這種政治，刻意給人一點壓力，給管理層事做。也許因為HR覺得這是薪酬體系的必要部分。

無論處於哪種原因，這種考核方式通常既不提升團隊和個人的生產力，只會動員起很多人，一起浪費很多時間；實際也不影響最終的薪酬審核，對每個個人的意義並不產生實質影響，一方面因為各種政治與非政治的考慮，評審總是會偏向中庸的路線，不能過分打擊稍後進的，也不能對先進的獎勵得太過分，尤其是加薪，大多數公司的職場就是這麼回事，每種制度看上去條條框框，執行到關鍵步驟，都是霧裡看花。

我後來的思路變化了，表格照樣填，但實質策略變了。

第一是要想保持團隊士氣，不因為死板的績效考核讓自己和團隊里的人陷入難堪的境地，我提高了招聘的標準。實際團隊的成員水平是有層次的，初中高都應該有，有一段時間因為項目的關係，也招過不太滿意的人，雖然是極少數，但還是覺得這個成本太大，找一個不像樣的進來跟自己扯淡然後利用制度來開掉他，不如找一個標準高的，然後狠狠獎勵他。我見過這樣的公司，招聘放水，不對全局負責，看重短期性價比，結果成為中層的一塊心病，把他們推向管理的下限，做過面試官的都知道，在程序員這個行業，平庸的人數都數不過來，標準稍微一降的結果，是任何績效考核都應付不過來的。

這樣一來，每半年或一年的考核，我的注意力就只需要放在可否激勵，如何激勵，激勵多少，以及如何和HR爭取預算這些更積極的問題上來了，同事們也配合。

所以與其招進來爛人用績效制度制約之，不如招聘時確保進來的都至少是當職的人，有競爭力的人對所有制度都是比較友好的，對管理也是。以激勵為目的的考核，誰不歡迎呢？

第二是強調個體責任，減少項目調度，盡量讓每個程序員有一塊自己的領域，是某一個業務或者技術部分的專家，比如A做mobile端的開發，就會盡量讓他把mobile app做過癮了為止，沒有特殊情況，不輕易他隨機調到別的部分。如果每個人的中長期權責是清楚的，那麼績效考核也會是清楚的，每個人能說出自己工作的縱向成果，比如A前六個月對mobile app完成了關鍵性的重構，使用了更新更快的技術，核心代碼的效率有了大幅提升，用戶體驗有明顯改善。這些東西他不說你也知道，因為分工的明確，你自己也很好跟蹤，peer之間也對對方幹了什麼取得了什麼成果十分清楚，這樣就為考核系統的透明化提供了基礎，透明意味著公平與效率。

從管理的角度，每個同事的工作成效都有長期的跟蹤，其中涉及的難度大小都可以比較公正地評判，如果誰一個階段的效率沒有其他人高，你就可以把他所負責的部分的具體情況考慮進去，這能幫你作出更好的評價。更值得考慮的，是你可以把注意力放在每個人的具體成長上，很多時候橫向比較本來就是沒什麼意義的。考核周期臨近的時候，填不填表格，你心裡都是有數的。

也許最重要的，是每個人都從專註的工作中學到了東西，對自己的部分有更大的責任感，並且他們知道，這些在公司的考核系統里，都是可見的。在需要的時候，他們應該為承擔更大的責任，作好了準備。

而你真正要做的，只是盡量為他們向公司爭取激勵就可以了。

如果用代碼量來衡量工作量的話，弊遠大於利，員工位增加代碼量不顧質量，廢代碼非常多，可以說慘不忍睹。

在極端情況下，

——譬如敏捷開發理論下過了磨合期的團隊——

可以把一個需求拆成N多個足夠細節的模塊，並且分別提供每個模塊的標準工時。

按標準工時計算績效即可。

然而大部分情況下，是達不到這種情景的。

而按代碼量來計算，特別不靠譜！特別不靠譜！特別不靠譜！

我的經驗中主要是這麼幾個方面：

1. 質量。這裡的質量指交付物契合需求的程度或按需求交付的準確程度，具體來說就是從理解需求開始到最後產出的交付物過程中的溝通、理解、設計、實現、驗證的總體質量，這個質量可以最後以「Bug密度」這一度量項衡量，對於一般的程序員來說主要是代碼質量。

2. 溝通和團隊協作。和項目團隊各個角色之間的溝通以及協作意願和能力。軟體開發基於個體能力但絕不止於個體能力，尤其是現在複雜的功能軟體，都需要通過多角色合作分工完成，這裡個體關注項目和團隊整體目標的大局觀和價值觀是很重要的項目成功保障。

大的方面就是這兩個。

不邀自來~~

績效考核與工資掛鉤，大家對工資沒有不關心得吧~了解了公司對績效考核的方式才能更知道自己的力該往哪裡使，活該怎麼干，但是關於績效考核不同的公司不同的考核方式，招聘方怎麼說比咱程序員們說的更有指向性，聽經驗豐富的前輩講更可靠。

在這種疑惑的時候找一個經驗豐富的前輩跟你聊聊應該會讓你對自己的未來和發展方向明晰很多。針對這一系列的困惑，我們請來了曾在 Google 美國總部負責廣告產品的創新和研發的王曄老師，給我們帶來一場乾貨 Live 分享《從矽谷技術人日常看程序員職場進階之路》。王老師是「吆喝科技」創始人，StuQ Live 特邀講師，清華大學電子工程系碩士，耶魯大學計算機科學博士，前 Google Growth Hacker 業務增長負責人。擁有豐富的從業經驗，一定能解開你的困惑！在本次Live上王老師將會解答以下這幾方面的問題，但不止於這幾方面。

和你談談

矽谷技術人員日常工作是怎樣的？
技術人員到底是什麼角色？
技術人員的考核標準
技術人員的考核方法
技術人員怎樣要求升職加薪？
技術人員的主人公精神體現在哪裡？
技術人發展路線
技術管理
向上管理和平級管理

王老師的Live將於6月13日，晚 20:00-21:30 （是的，現在已進入倒計時）開講，想要聽前輩談談，給現在困惑的自己一些幫助的小夥伴們趕緊來吧~

關注微信公眾號「StuQ直播課」和掃描海報下方二維碼就能進入直播課頁面啦~萌萌噠王老師在等你哦~

https://stuq.maodou.io/cl/bdqqc7grdXwN5m2Fh (二維碼自動識別)

績效考核的先決條件是工作可測量。
從這個角度講，有兩種方式可以綜合使用：
1.代碼量。每天下班進行工作提交時，統計今日修改，新增的代碼行數，業界基本水平大約是200行。

2.進行任務細化分割和管理。MantisBT可以實現這個功能。開發的整個流程，都可以在mantis上加以體現。分析人員逐級分割任務，並將最終可實現的子任務分割給程序員，程序員可以通過統計其任務完成量來估算其工作量。

其實，我覺得BOSS的焦慮在於無法「可視化」的觀察項目的進度，這個任務可以通過使用MantisBT，合理設置里程碑來實現。當BOSS看到里程碑相關的任務完成度不斷上升的時候，他的焦慮感就會顯著降低了。

Mar27,2017補：

我最近兩年做了一件事情——統計自己的有效工作時間，所謂有效工作時間，就是可以與項目相關聯的時間，不包括事務性工作，以及培訓，中途休息等時間，是一個人一天工作中的最乾的部分。我的2016年度全年有效工作時間大約是89%（計入了加班工時中與項目相關的部分），這個時間是可匯總統計的。雖然有容易造假的缺陷，但是如果能和上面第1條，第2條關聯起來，作為一種工作效率統計指標還是很理想的。我在搜集基礎數據時用到的工具是outlook。redmine中也可以統計各個任務的完成時間，作為一個組織整體的工時記錄和效率測量，redmine可能更佔優勢。我現在非常傾向於用工時來進行效率評價。

把程序員提交的代碼十天(甚至一個月)左右隨機抽查一次看看質量，然後看看他每個月大致提交的代碼總量。然後綜合評定。

而且會在程序員入職時把這種方式告知他們。我在杭州一家公司兼職他們公司就這樣乾的，老闆也是技術出身，偶爾也參與到審查代碼當中來。大家也都很喜歡這種方式，有時一個多星期狀態不好啥也不幹也沒關係。

非常牛逼的方法！！

當然了，程序員要是勞累命那就沒辦法了，我六點左右開睡，現在就醒了。因為我忍不住要起來修改我們宿舍另兩貨寫的代碼……

所完成的技術工作（不一定是純編碼工作）在整個項目中的重要性。
交付情況（包括時間、bug量、可擴展性、代碼質量、業務承載能力等等）
團隊協作，包括是否能夠分享和幫其他人成長
技術積累的深度

說點題外話,你想量化程序猿的工作,他們就離反抗你不遠了.當然也不是沒有公司對程序猿進行量化KPI.

但前提是,SE需求明確,任務細化到位.團隊有足夠的人去分解SE的需求.或者計劃指定規範,對團隊實力有著清楚的認識,所以這個時候你就需要一個TL來做這些事情.而且你們需要一個良好的內部IM溝通工具,或者web交流平台.

其次,資源要夠,例如測試設備充足,伺服器充足等等(不同業務不同需求)

最後,你給的KPI獎勵制度夠誘人,就像打遊戲做任務,只有獎勵夠誘惑,才能吸引人人坑.

____________

以上問下自己做到了嗎?如果做不到,你這個KPI多半也是個擺設.因為上面任何一條都能影響程序猿的產出.

如果你做到了上面這些, 好恭喜你,你們公司非常正規了,如果這個程序猿工作不努力,幹活不認真,產出效率低,那麼問題一定不是處在程序猿身上,而是HR工作有問題.

代碼量考核，這個真的合適么？

代碼質量、進度，團隊考核比較合適吧（任務績效+周邊績效）

【基本工資+日常績效】+項目獎金.........外加利潤共享措施

HR應當盡量少插手，幫助team leader去搞....

代碼量可以作為基礎績效

但合格的代碼必須要有一份KPI指標：有效解決問題、儘可能節省資源、易懂。

代碼量和trac中完成任務情況，這是量化的部分，只有這些是不夠的。我的經驗，還需補充兩個非量化指標：1，上游（產品經理或業務部門）評分，有利於擺正供需關係；2，同事互評，提高團隊意識。