關於程序員，卓有成效的績效考核方法？

01-04

程序員績效考核是一個老生常談的話題，然而要做好比較難。大致想來，可能有生產力（Productivity)和質量(Quality)兩個方面，那麼因著我們團隊是Scrum模式，對應的指標有：故事數（Story Points)和缺陷數（Bugs)。然而和團隊成員討論下來，似乎這兩個都不是很理想：如果用Bugs來衡量績效的話，勢必會和QA產生很多的爭論。無關績效大家凡事好說，掛鉤到考核往往錙銖必較。另一個是用完成的任務數(Story Point）的話，如何準確衡量是一個問題；另外程序員之間也許會因著任務數的差異而產生矛盾。
但是考核無法避免：一方面為著團隊/個人自我提升，另一方面為著年終評級。
因此請教大家：你們公司是如何考核程序員績效呢？你認為比較好的指標是什麼？
測試

開發人員屬於專業技術組，同時又隸屬某個或多個項目，接受技術和項目雙重考核。

開發人員的直接上級負責組織考核。項目經理對項目目標完成情況進行考核，技術經理對工作態度和能力進行評價，同時有測試和配置管理提供數據支持作為參考。考核一般是績效佔大頭比如80%，工作態度佔20%，工作能力半年或者一年考評一次。

數據支持之一：配置審計數據

配置審計數據包括：開發人員提交的版本是否能編譯通過，版本號、模塊版本標籤、注釋、LOG是否符合規範。同時通過提交版本的統計表能看出來工作量。

從配置審計數據能看出開發人員的工作認真程度，比如一次提交模塊通過率是否很高，一段時間內提交了多少模塊可以看出工作量，模塊有多少行代碼也可以被統計出來。

數據支持之二：測試評估數據

測試評估數據能了解開發人員模塊的提交情況，是否按計劃提交到測試了。可以看到BUG數，BUG是分級的：輕微、一般、嚴重，對BUG引入原因也有統計：環境參數配置導致的BUG、UI/易用性、需求設計不清晰導致的BUG、編碼錯誤、測試理解錯誤等。

如果開發人員嚴重錯誤、編碼錯誤過多，說明開發質量和開發水平需要改進。

這個回答里關於績效考核的部分可以參考： http://www.zhihu.com/question/20045768/answer/13831495

負責對開發人員做績效考核的主管，無論是按KPI定量考評還是定性考評，上面談到的數據支持也是必要的，因為我們不能想當然給開發人員評價優秀或者不合格，需要有說服性的數據。這個對於年終評級或者面談改進建議都是強有力的依據。

建立配置管理和測試團隊，每月提交測試審計報告和測試評估報告，在一個逐漸正規化、人員不斷擴大的團隊里是必要的。如果團隊人數比較少，任務集中目標明確，靠一個有威望的LEADER來做考評也是沒問題的，對團隊有貢獻的留下，拖後腿的走人。誰行誰不行，LEADER最清楚了。

把提交修改的次數計為負面影響吧

前提是公司項目經理需要指定出一套代碼標準和項目進度及需求說明的文檔，分發給對應的程序員！

分幾個方面吧

1、是否按照文檔的要求書寫代碼。如果一個程序員不能很好的按照領導的要求辦事，這樣的程序員能力再強，我想開除也並不可惜！

2、根據個人的能力水平分配不同的開發任務。當然，項目經理是最清楚自己手下人員的個人能力以及能承擔多大的開發任務。有時候項目中遇到事先沒有想像到的困難也是正常的，這個時候對於員工加班是正常的，就看這個程序員是否通過其他途徑或者求助並且能準時的完成任務!

4、個人的解決問題的邏輯思維能力。我帶團隊的時候就遇到過幾個程序員，邏輯思維能力真的很弱很弱，給他提供很多解決問題的思路，就差把答案告訴他的，但是結果一樣，還是拋給我一句話：不會！這樣的早一天走，公司早一天減少損失！

3、個人的學習能力。這點本人覺得非常重要，如果一個程序員沒有很強的學習能力的話，一個團隊就得不到進步，一個團隊得不到進步，結局顯而易見！

個人帶團隊中的一些心得！

謝謝大家的回復。Maggie提到了配置審計數據，測試評估數據；武建亮建議：按設計執行能力，邏輯思維能力，學習能力等等。我想想，我再提供我們項目組更詳細的信息，大家能不能在集思廣益一下，看如何做的更細：

例如配置審計數據：

1，開發人員提交的版本能不能通過，一般來說，我們項目組有一定的流程保證提交的版本能夠通過，所以不通過的情況極少，所以這個數據可能對於每個成員來說都是一樣：都能完成。

2，完成功能數：這和我說的用戶故事數類似，這個可以作為團隊成員設立目標採用：例如每個迭代用戶點書增加 5%,這就是一個目標。有人項目中使用這個的嗎？請問效果如何？

3，代碼行數：使用代碼行數來反映工作量呢，評價莫衷一是。有人說，同樣100行代碼，簡單邏輯和複雜邏輯的代碼，工作量一樣嗎？也比如有的人寫比較長的邏輯判斷，但有人用正則表達式能簡潔的解決問題，又如何判斷優劣？

4，Bug數：我同意陳宇的看法，得出一個事先公布的標準，讓大家慢慢適應。但是我比較擔心這會影響和QA的關係，畢竟我在和團隊成員討論的時候，有人就表示：Bug數如果和自己績效掛鉤的話，以後對於QA提的Bug自己會嚴加審核，以前不管是自己導致的Bug，還是屬於功能優化，大家本著把工作做好、把產品質量提高的態度，都會把它完成，但是如果關係到績效話，就不會那樣包容。另外，也有意見說：按正常情況，一個人做的工作越多，產生的Bug數可能越大，如果用Bug衡量，不是讓大家盡量少做，好比言多必失，那大家就盡量不說話？

請問大家對這項指標的意見呢？有人項目中用Bug數來衡量的嗎，請問效果如何？

參考大家的意見，我有一個想法：

在團隊內部內比較成員績效：

指標成績30%， Scrum Master/Lead 意見30%，團隊成員360度評價 40%.

在團隊外部比較成員績效時（就是幾個開發團隊間要比較成員表現）

完成功能數增長率，用Bug率吧（Bug數/代碼數)。

請大家多提意見，也許以後也有其他人有類似的問題，希望在這個帖子裡面能夠討論的深入些，這樣有更多的參考價值，歡迎大家幫忙邀請你認識的人作答，非常感謝。

1、首先強調，績效管理是引導、激勵員工共同完成公司目標。一般來說，個人的績效考核包含業績和能力考核兩部分，業績一般佔60%-80%，能力佔20%-40%，根據實際公司導向確定。

2、業績部分。程序員的職責目標是按時按質按量完成開發計劃所分配的任務。所以，考核的指標也應圍繞時間、質量、數量來制定。

數量和時間：軟體開發應強調按開發計劃按時按質完成任務。題主所說的用「任務數」來考核，我建議按開發計劃用計劃完成率來考核會更好，計劃完成率包括要按時間節點和任務數完成，控制開發的進度。另外，說因為任務數差異存在矛盾，這需要跟員工解釋，一般來說，程序員能力的高低已在基本工資上表現了，能力越強，基本工資越高。所以程序員能力強，完成同樣任務所需的時間少，理應承擔更多的任務，除非你們是所有人是一樣的基本工資，那另說，這需要你們將原來所有的人工成本扣除所有人基本工資之和剩下來的做為項目獎金，設置按參加項目的多少、難易程度、承擔的角色、完成的質量等指標制定獎金分配規則，才可以還原不同的人的貢獻價值。
開發質量。以上所說開發質量考核的指標，更多的偏向缺陷BUG。我認為，程序的質量是由可靠性、可讀性、可修改性、可維護性、可繼承性和一致性構成的。BUG是一方面，可以設定範圍，不同嚴重程度和數量的BUG扣多少分。另外，在進行開發準備時，應嚴格制定開發規範，對代碼長度、行數、注釋、格式等做出規範，並且應有專人或小組對以上幾個方面進行評審，評審結果做為績效考核的一部分。

說得不妥之處，歡迎探討。

我沒有什麼經驗不太懂

只說個設想

有個項目評估小組高層啥的對項目大致劃分個等級（主要是根據項目的利潤和價值），這個劃分看經驗了

然後不同的Team 更具項目計算係數a1

Team內，team leader 給個係數，

互評給個係數

都乘起來

另外考慮績效中的bug

我覺得和QA有矛盾是不能避免的，這個還是要經過一段時間磨合，得出一個事先公示的標準，先立下規矩大家慢慢也就適應了，總有bug肯定是不行