如何對程式員績效考核？

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

回複內容：

如果用代碼量來衡量工作量的話，弊遠大於利，員工位增加代碼量不顧品質，廢代碼非常多，可以說慘不忍睹。我幹過這事兒，來拋磚引玉吧。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

而你真正要做的，只是盡量為他們向公司爭取激勵就可以了。在極端情況下，
——譬如敏捷開發理論下過了磨合期的團隊——
可以把一個需求拆成N多個足夠細節的模組，並且分別提供每個模組的標準工時。
按標準工時計算績效即可。

然而大部分情況下，是達不到這種情景的。
而按代碼量來計算，特別不靠譜！特別不靠譜！特別不靠譜！把程式員提交的代碼十天(甚至一個月)左右隨機抽查一次看看品質，然後看看他每個月大致提交的代碼總量。然後綜合評定。

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

非常牛逼的方法！！

當然了，程式員要是勞累命那就沒辦法了，我六點左右開睡，現在就醒了。因為我忍不住要起來修改我們宿舍另兩貨寫的代碼……績效考核的先決條件是工作可測量。
從這個角度講，有兩種方式可以綜合使用：
1.代碼量。每天下班進行工作提交時，統計今日修改，新增的程式碼數，業界基本水平大約是200行。

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

其實，我覺得BOSS的焦慮在於無法“可視化”的觀察項目的進度，這個任務可以通過使用MantisBT，合理設定裡程碑來實現。當BOSS看到裡程碑相關的任務完成度不斷上升的時候，他的焦慮感就會顯著降低了。
代碼量可以作為基礎績效
但合格的代碼必須要有一份KPI指標：有效解決問題、儘可能節省資源、易懂。代碼量和trac中完成任務情況，這是量化的部分，只有這些是不夠的。我的經驗，還需補充兩個非量化指標：1，上遊（產品經理或業務部門）評分，有利於擺正供需關係；2，同事互評，提高團隊意識。

