如何對開發團隊的人員進行績效管理？

01-04

如何量化考核團隊中各個程序員每月的開發工作以及完成的質量？如果僅以開發任務的工作人日進行量化，如遇當月有長假期或當月任務量少時，又當如何應對？

按照我知乎的套路，先實名反對所有高票答案（雖然一直在變），這個問題下面的答案，簡直感覺在過家家。

講真，那些用代碼數、bug數什麼的當指標的，你們真的覺得每個bug都是一樣的？至少乘個優先順序啊（雖然也不對），而且代碼和bug這麼靈活的東西，可以做的文章太多了，比如微信掃碼功能掛了，開1個bug也就可以描述了啊

其實我經歷的各廠，包括我自己帶的團隊的時候，考核方式基本都是披著KPI皮的OKR。

說道OKR這個東西，其實挺詭異的，說白了就是管理者把制定量化指標和衡量的工作也下放，比如說我說今年研發效率提升50%，看上去特別的可度量，但是實際統計口徑最後是我自己出的。換句話說，在OKR考核下，我要做的事其實是「吹個牛逼讓老闆覺得牛逼，並且最後證明我做到了（並不一定實際做到）」。目前來看，因為研發過程的極度複雜性，還沒有找到更好的做法，這比統計代碼量、bug密度之類的鬼東西靠譜太多了。

當然作為這個問題的答案，只說到要用OKR的話，基本等於啥都沒說。後面說正經的，量化這件事，考核研發人員的指標，總體方向其實非常明確，一是產出，二是質量。

研發人員的產出的認知，又有幾個流派，比方說有的leader認為研發的產出是業務結果，業務結果衡量的主要標準就是規模和收入，按照普遍認知的邏輯，UV啦、PV啦、轉化率、在線時長什麼的都是可以視為業務結果的考核，雖然目前行業對這個業務數據的認知比較粗糙，但是基本也可以湊合用了，這個流派優點是結果比較容易考核，更重要的是它和投資人/公司高管的認識是一致的，所以這麼定KPI/OKR可以確保管理責任最小，缺點就是商業邏輯其實本身就很複雜，一個業務結果涉及的太多了，容易產生大牛選了坑的業務，或者小白跟著坐車的事，而且大部分公司研發人員都沒什麼自己選業務的機會。另一個流派是認為研發的產出是產品，這就比較麻煩了，以產品產出來考核，重點是產品的實現難度，這又是一個幾乎沒法量化的東西，所以這個流派，往往產出這塊的判斷也是憑藉主觀感受。這個流派與前一種其實無分對錯，都是比較主流的思考方式，我個人傾向於一，但也不認為二有問題。至於認為研發的產出是代碼，數行數或者字元數的leader，我只能呵呵了。

質量這塊，量化難度太大，但也不是完全沒法量化，它有一部分是可以量化的，在我看來，質量可以分成三部分：

代碼質量：代碼本身的質量決定了對後續開發的友好程度
研發質量：研發階段產生的bug
運維質量：產品上線以後的故障情況和資源消耗情況

其中，第一類，我認為沒法量化，我的做法是不考核，只作為努力提高的方向和主觀考核依據，因為它產生的成本可以通過自己後續的努力重構來彌補，原則上應該誰挖的坑誰填（這樣還是會有問題，可能導致"透支"，即坑越挖越大最後人跑了留下個爛攤子，但我沒找到更好的辦法了，攤手）。第二類，很難用bug數量來衡量研發質量，所以這塊我比較傾向於用紅線的形式來考核：冒煙bug、build break、低級bug和regression做記錄，其它bug視為正常研發中的溝通。第三類我認為是可以量化的，通過線上伺服器消耗、故障恢復時長等來做考核，這種考核的優點同樣是投資人和老闆看得見，不需要擔心指定的KPI偏離了大方向。

總之呢，技術管理這事其實挺複雜的，現在這個發展階段，很多問題都沒答案，我覺得我能給的最重要的建議是「不要瞎搞」，寧肯全用主觀評價，也不要引入錯誤的量化指標。

我覺得量化管理是做不到的，更多的是「set expectation」和「manage expectation」，然後通過「calibration」是做到更大範圍內的公平公正。

什麼是「set expectation」，就是在事情沒有做之前就要先說好事情做成功應該是什麼樣子的，需要付出怎樣的代價。例如說，「未來 3 個月優化用戶註冊流程，使得用戶註冊轉化率提高 10%」。如果一個 E5 的工程師跟經理說，「我能在未來 3 個月提高用戶註冊轉化率 10%，你覺得怎樣？」那麼經理有幾種回應的方法：

1.「這很好，你去做吧，做好了至少 E5 能夠拿一個 meets all expectation。」

2.「這太簡單了，只能算 E4 的工作，你 E5 做出來了也只能拿 meets most expectation。」

3.「這可能比你想像中的要複雜，能做出來的話你升 E6 沒問題，但有一些可能存在的問題你先要想清楚。」

這樣「set expectation」做好了，好處就是雙方不用猜測到底自己做成怎樣然後對方會給什麼結果。然而這樣的事情不是做一次就結束的，因為工作過程中會獲得新的信息，然後這些新的信息會帶來新的抉擇，就如同一個動態規劃執行的過程一樣，所以中間必須不停地「manage expectation」。可能需要溝通的狀況例如：

1.「我們一個月就把轉化率提升了 8%，我們應該把三個月的目標重新設置為 20%。」

2.「我們第一個月只提升了 2%，在研究同類產品的註冊轉化率後我們覺得提升 5% 就封頂了，目標應該調整為 5%。」

如果沒有這個過程，那意味著否認研發過程可以產生新的信息從而影響下一步的抉擇。那就相當於否認通過動態規劃來管理研發過程，那是要使用貪心演算法？（我覺得 KPI 在一定程度上就是貪心演算法，假設一個公司級別的目標能夠不斷拆分成小目標，每一個小目標達到最優組合起來的大目標一定最優。）

接下來的問題就是怎樣保證公平公正。因為每個人會都會想把 expectation 往下調，那怎樣說明你做了你這個級別應該做的工作呢？就只能通過「calibration」來橫向對比了。如果其它在這個級別的人做出來的結果跟你相似，那你做的結果就是沒問題的。這個橫向對比不僅僅可以在不同人之間做，還可以在跨不同時間段做。如果你這半年做出來的結果顯然比上一個半年要差，那就不應該得到同樣的評價。只要全公司跨部門跨團隊做好 calibration，那理論上是公平公正的。

當然，這一切都是主觀的，但至少經過 calibration 後評價反映的是很多人的主觀綜合後的結果，不再是經理一個人的主觀評價。經理在 set expectation 時就不能只考慮自己怎麼想，必須從全公司 calibration 的角度出發來思考。

***

那些在績效管理問題提 OKR 的人，我很想知道你們學的是哪門哪派的 OKR。執行 OKR 的其中一條規則就是不使用 OKR 來做績效，績效交由 peer review 來解決，實際執行方案例如我說那樣。之前在豌豆莢就是這樣執行的，豌豆莢採用的是 Google 的做法所以 Google 應該也是這樣執行的。

在這個問題上，我覺得 @winter 那句話是不是說反了。他說「其實我經歷的各廠，包括我自己帶的團隊的時候，考核方式基本都是披著KPI皮的OKR」。我覺得他真正想表達的意思是，「大家都披著 OKR 的皮，實質上執行的是 KPI」。綜合這個問題下的答案，和其它一些問題下的答案，我覺得中國是不是很多公司都是這樣子，表面上說自己切換到 OKR 了但實際上執行者根本不懂，還是按照 KPI 的方式去執行。

最搞笑的是有些答案提及 OKR 的 Objective 要能量化。OKR 中的 Objective 和 Key Results 分離就是為了讓 Objective 不能量化只能指導方向，然後 Key Results 是否指向正確方向允許爭論。如果 Objective 是「讓用戶更加享受我們的應用」，Key Results 可以是「增加用戶使用時間到 X」或者是「App Store 評分增加到 Y」。但如果你拚命忽悠用戶去 App Store 給你打高分，他們因此而不爽這個應用，那你就是滿足了 Key Results 而違背了 Objective。OKR 存在的意義就是允許允許大家了解 Objective 從而盯著 Key Results 的實現方式，阻止違背 Objective 的行為出現。

想不到現在在中國那麼多人趕 OKR 的潮流啊，但也想不到那麼多人練到走火入魔啊。

補充。剛剛發現 Joel 在 2002 年 7 月有一篇關於績效評定的文章：

http://www.joelonsoftware.com/news/20020715.html

值得一讀。

－－－－－－－－－－－－

我覺得任何量化的標準的準確度其實還不如主觀評價的準確度。如果一個 team leader review 所有的 code change，參與關鍵問題的討論、解決和驗證，自己也負擔少量開發工作。他對 team 成員的評估應該是準確的，或者說至少不輸給任何量化指標。

量化指標的缺點很明顯：

需要成員做很多 paper/bookkeeping work —— 填寫各種表格和多餘的 bug metadata。
鼓勵管理人員脫離實際的產品開發。
容易造假。
經過上面三條，重視量化標準的 team 會形成很不健康的氛圍。成員之間互相猜忌貶低，管理者閉目塞聽。

根據 @黨宇航的評論，在主觀評價的基礎上進行多人評價的權重參考也是個不錯的方法。不過需要的工具我覺得目前並不 ready for mass use。可能也就 Google 有這種工具吧。但是被統計應該是 reviewer 的主觀評價，而不是簡單的 comment number, defect number 這種數據。但是這種統計模型如何設計恐怕又是個費力氣的活。

根據 @卞成的回答，我對主觀評價加權有了新的看法。我對 team leader 主觀評價的重視不變，但是這種評價的結果是剔除非常不稱職的人，而不是做相對比較（用 @卞成的比喻，不要考慮手和腳誰的功勞大，檢查只是為了發現病灶）。所以對加權工具的效果我有了更多的懷疑。

對於研發人員的管理中的還是定量和定性結合的方面進行。

首先對於研發人員的績效不適合完全定量化的管理，研發工作是腦力勞動，受影響的因素太多，單一的指標往往很難衡量。包括我們說的開發的代碼生產率，缺陷密度；測試的測試生產率，缺陷泄露率等，可以有很多指標，但是一旦完全嚴格量化考核，聰明得開發人員都會找到各種方法來規避指標體系本身的漏洞。而且很多單一指標本身又存在問題，別如代碼生產率，大量的複製重複代碼本身就違反我們的復用原則，生產率太高反而是壞事情。

其次又不能完全不量化，因為只有量化才容易進一步認識我們每個人各自的工作效率。才談得上不斷的持續改進。否則可能陷入老覺得差不多了，沒什麼好提高的思維中。如果要量化，其實任何一個崗位都包括兩個方面的量化以體現高效，一個是生產率，一個是質量。如果對開發則是代碼生產率和缺陷密度，對於測試則是測試執行效率和現場故障密度等。需要根據不同的崗位指定不同的指標，並且反覆驗證指標是合理的。切記指標不要太多，2-3個關鍵指標足夠。

最後，我一直把工作態度和責任心列入績效範疇，績效包括了工作能力（生產率，質量），工作態度和思維能力三方面的內容。工作態度和責任心，思維能力這些可能更加難以量化，但是對於研發人員考核卻很重要。開發團隊強調的是自我主動，自我管理，完全強過程下得規範和約束往往並不能發揮團隊最大效率。

最後如同大公司對各個部門績效考核一樣，各個部門績效考核都優的情況下往往公司整體績效並該不是最優。因此一定要避免這種情況，要講團隊，項目總體目標績效落實到個人，才可能使團隊中每個人為達到項目整體目標績效而努力。

對於研發人員績效考核，可以參考我博客上關於研發主基二元考核的文章。

量化管理只能適用於競爭激烈而合作少的場合，比如勞動密集型的手工製造。

對研發團隊進行細緻的量化管理，既不現實，也無必要。

研發團隊靠的是成員之間互相配合，更多是合作關係，並非競爭關係；量化管理強行抹煞了合作關係，刻意強化競爭關係。須知整體並非部分之和，研發團隊是不可拆分的－－你能把一個人的不同器官拆開，討論手的貢獻大還是腳的貢獻大嗎？真的討論出一個結果來，又有什麼意義？手和腳如果能分家了，這還是一個人嗎？同樣，如果程序員、策劃真的能夠單獨考核，他們為啥還要呆在團隊裡面，為啥不去獨自創造價值？那，團隊還是團隊嗎？

為了提高效率，出發點可以理解，但是更應該著眼於如何幫助成員合作，幫助成員溝通(大部分人並不擅長溝通)，鼓勵成員溝通。就我所見到的絕大部分情況，成員不做事或者進展緩慢並不是因為壓力不夠，也不是因為沒有激勵，也不是因為想偷懶；而是因為缺少溝通，工作上確實遇到障礙了。只要幫他們掃清障礙，他們就會很開心的繼續前進。

如果你是一個HR, 那麼量化管理是一個免不了的任務，就隨隨便便走走形式吧，不要當真。如果你是團隊負責人，就把精力更多花在溝通上，比花在考核上效果要好得多。

另外，也同意bluepy的看法，量化指標是可以的，但是不要用來做考核。量化指標是用來衡量整個項目狀況的，好比體檢時候的指標，看到指標異常就可以引起警惕，去看看到底有沒有問題了。

張誠陽同學提問的進度報表，時間周期之類的，是另外一個很複雜的問題了，這裡只簡單的說說。

進度上通常分為幾個里程碑。但是每個裡程碑的要求，一定是對項目整體的評估，而不是分解後工作任務的累積；須知整體並非部分之和，並不是分解下來的工作湊到一起就成了完整的項目了；這中間有大量的集成整合的工作，評估一定要評估集成之後的整體項目。關於整體項目，很容易弄出很多量化指標，只要記著"整體並非部分之和"這一點就行了，那種累加出來的指標是靠不住的。

績考是手段，不是目的，有時候我們總是無意間以為形式就是工作。

首先要問*你的*績考的目的是什麼？

如果大家都說不清楚這個問題，那績考是多餘的，績考很好也可能保不住你的團隊和公司。

績考是為公司的願景，目標，戰略，戰術掛鉤的，不應該有統一做法。績考結果影響工資，獎金，升遷等等，也是為前面4者服務的。

如果你的團隊的使命就是幫公司做項目掙錢給其它團隊孵化產品的，那團隊的績考就是圍繞項目交付和收錢進行的。

然後關鍵點來了，也是最亂的點，對個人如何考核？我支持的方式是

1）把大團隊割成10人以內的小團隊，下屬也在10人內。這樣上司對每個下屬都是了解的，由他觀察評價。如果公司非要量化，當它是檯面的東西好了。

2）目標是集中精力找出最優秀的2個人，給他們他們想要的，例如大幅加薪。找出最差勁的1人，必要時請他離開。其它人給正常的待遇。

3）讓每個人都清楚團隊目標，2-7-1原則，讓每個人都有機會公布他的工作成果。例如各種review場合。

在管理崗位的人，工作要點是think ahead，不在管不在理，在帶。績考是出不了業績的。

Just my 2 cents.

研發團隊的績效肯定要做，但不適合用一些量化的數據來衡量。比如寫了多少行代碼，完成了多少功能，解決了多少bug之類的，這種考核方式是行不通的。

我們的做法是和整個公司的業績掛鉤，研發人員也會享受一定的銷售業績的提成。這樣做有兩個好處：1. 通過這種方式來強調大家的利益是共同的，就避免了工作上的推諉。2. 也避免了干多干少都一樣的情況。有利於調動大家的積極性。

當然人和人之間肯定有不同，這種不同會體現在工資，獎金和提成的比例上。這個需要團隊的管理者來把握，做好公平。做到這一點，對於小團隊來講，不需要量化的數據，應該是很清楚的。

我們團隊人數比較少，可以做這樣的激勵方式。人再多，就沒有經驗了。:)

宋老師的答案還是最專業的。

對於研發的考核，我只提問題，看官們自行思考。

什麼是量化考核？

量化一般有哪些緯度？

績效管理與管理的關係是什麼？

考核應該誰負責？

各位人力資源管理者，員工關係崗的指標怎麼定的？培訓崗的指標怎麼定的？績效崗的指標怎麼定的。

這些崗位和研發崗位是否有相似性？

能答對一半，既會有答案。

同意卞成的看法。

TED里有一個Dan Pink的演講the surprising science of motivation. 講的是為什麼傳統的績效管理+金錢激勵在現在的創造性工作中起不到理想的作用，甚至常常起到反作用。他還有一本書Drive，Amazon上可以買到電子版。

做了這麼些年的考核工作，提出自己的一些淺薄的看法，還請各位大拿拍磚：

開發團隊的項目需要進行分類，分為成熟的項目和孵化的項目，成熟的項目比如市場上已經有參照物的項目基本可以算為成熟的項目，你可以通過別人的市場表現來要求開發團隊的輸出結果；孵化的項目比如當年的微信，其實那時候全球也有可參照的項目，比如line，但是在國內市場還沒有競爭對手，這時候對待這些項目的態度就不能和成熟項目的一樣。

對成熟項目的考核，應該是投資銀行的態度，不可能看你長期能長成啥樣，重點還是看你短期內的產出，能不能達到「華爾街」的要求，這時候就需要利用BSC也好、杜邦財務分析也好、KPI也好（這些方法大家都很熟，就不再贅述）進行考核，也就是要量化考核，這種項目沒法量化就沒法管理。說什麼放權、開發是一種藝術不可量化，都是扯，項目搞得再漂亮，沒有市場，沒有流量都是狗屁。所以對於成熟的項目，一考到底。

孵化的項目，就不能再是「華爾街之狼」的態度了，這時候對待他應該向天使投資對待創業項目一樣，既然看好它的前景，那麼就要給他資源和錢，讓它去沖，充分信任開發團隊，這時候要求開發團隊要能畫餅，要能許一個美好的未來，這樣老闆也好平衡別的團隊，當然，天使投資對創業項目也是有一個時間要求的，到期還不能達到預期的效果可能就要廢掉啦，不然別的團隊估計不同意，因為你用他們項目辛辛苦苦賺來的錢養這麼一個二愣子，大家肯定也會有意見。但是確實不能用考核那一套來要求他，因為考核結果肯定很差，新的項目很難一下子有非常漂亮的業績指標的。

通過項目所創造的價值（孵化項目由公司來確定整體的價值）及完成情況來確定Bonus，貢獻度決定bonus poor的大小，完成情況決定團隊可拿到的比例。

以上的都只是團隊，對於個人呢，團隊bonus確定後，就是如何分配到個人了。

個人考核分兩方面：

1、量化指標：項目裡面能量化的一定要量化，暫時不能量化的指標不建議強行量化，強扭的瓜不甜。

2、暫時不能量化的指標（我也信奉工作指標一定都能量化）融入到員工360度反饋（是的，是反饋，不是評價）：通過問卷調查（或者系統）收集周邊評價意見。Quora上有Google的僱員就說Google的員工每年做兩次，考核由兩方面組成partially self-assessment and partially peer assessment。

具體詳見：Google: Do Google"s performance reviews do more harm than good?

以上兩個方面將是幫助team leader進行bonus分配的有效依據。

　　企業實施績效管理的過程中，要注意以下六大步驟：

　　1. 明確推動制定績效管理解決方案的需求

　　制定績效管理計劃的目的是為了什麼?制定計劃是為了改善表現不盡人意的組織的績效嗎?

　　2. 根據一致的標準評估員工

　　如果您評估員工的標準在變化，您將不能建立評估員工表現的統一標準。而如果沒有這種標準，就無法衡量進展。

　　3. 讓員工清楚了解自己的表現是否與公司戰略相符

　　為您的績效管理架構創造一個開放的交流平台。若您的企業擁有內網，則可在內網首頁探討計劃的進展及戰略。如果您的員工不能使用電腦進行在線探討，則可考慮通過直郵來通知大家計劃的最新進展。同時，還需安排時間與員工溝通，告知其他們的個人努力是如何幫助公司實現如增加銷售或提高客戶服務等目標的。

　　4. 為員工提供職業發展機會

　　一旦戰略制定，即要確保業務與戰略的一致性，並開始與員工在企業目標上進行交流。當知道公司的整體戰略及其個人參與部分時，員工情緒會提高，將非常樂於學習如何專業的提高自己的水平。為您的員工描繪一幅藍圖，讓他們清楚知道公司管理者的職責和責任，並通過提供發展機會建立員工的自信。

　　5. 鼓勵員工往有助於實現企業目標的方向表現

　　培訓可為員工傳授所需的技能，但並不會改變行為表現。當一個組織的領導對績效管理架構表示出信任並親自進行實施時，員工的表現也會隨之改變。

　　6. 找出差距並長期監控

　　找出企業培訓與指導的方法，建立員工的責任心。改變往往使人們極為不安，您可通過使管理者也投入到部門的發展中，來減輕員工的此種不安。讓您的管理者成為平和的指導者，而非嚴肅的訓練者。當表現差距擴大時，可視之為建立強大團隊的機會，不要因為員工的某些缺點而進行懲罰。

Intel和google的OKR是研發人員績效考核的最好辦法呀。

OKR（Objectives and Key Results）全稱是目標與關鍵結果法,自1990年在Intel 誕生以來，特別是1999年由John Doerr 引入到了Oracle、 Google、LinkedIn、Facebook等公司後幫助這些公司從小做到了現在的規模。其實不僅僅是谷歌，包括大量的互聯網公司、IT公司、創意公司如皮克斯動畫，甚至一些基金公司、金融公司都全部或部分採用這個管理系統。

在國內，OKR近來不僅僅在互聯網行業,甚至成為國內各行業的熱門辭彙,作為國內走在前列的OKR培訓及諮詢機構行隆諮詢結合為眾多行業和眾多企業在實施OKR方面的經驗和教訓聯合行動+團隊，推出幫助企業落地OKR管理系統的移動應用：行動+。行動+幫助落地OKR主要體現在以下幾個方面：

1.從目標開始（O）。

OKR中的O就是目標，所以OKR落地的第一步就是建立每個人的目標。行動+的開篇就是讓使用者建立自己的目標。並且目標可以分享到微信朋友圈，或者新浪微博，讓您的所有關係都知道。大家都知道，你的目標知道的人越多，越可能實現。

2.設置實現目標的行動（KRS）。

我們每個人每天多會做一些事情，有的事情可以幫我們直接實現目標，有的事情可以幫助我們間接實現目標，也有的事情根本與我們實現目標沒有關係。行動+的行動必須是能夠直接實現目標的，而且可以動態管理，持續刪除掉不能實現目標的行動。

3.隨時隨地溝通。

應用行動+，leader，下屬和團隊之間可以隨時隨地就工作，目標，經驗教訓做溝通和交流。讓我們隨時隨地進步，隨時隨地成長。

4.及時激勵。

應用行動+,可以隨時為自己的或者同事,團隊的行動,或者目標,進行點贊,送禮物,甚至送紅包.讓我們時時刻刻能感受到受尊重,受矚目;時時刻刻都能感受到做工作給我們帶來的趣味,開心和快樂!

最好的管理就是讓員工具有「主人翁責任感」。微軟在復活之前取消了推行多年的績效考核制度，你以為這是碰巧了？不！績效考核是個大坑，是用來彌補高層領導力不足的問題的。

研發人員的績效考核歷來是企業人力資源管理中的難點問題。由於研發人員的工作與一般的作業人員相比具有複雜性、創造性、周期性等特點，因而傳統的績效考核方法很難滿足對研發人員的考核要求。那麼，企業研發人員的績效考核到底該怎麼做才更具科學性、操作性和實效性呢?

一、確立考核原則

1. 結果考核為主，行為考核為輔的原則

研發人員的工作是高度結果導向型的工作，對研發人員的評價最終往往都要落實到其工作成果上來。在研發人員的考核中，過度關注研發人員的行為而不是結果本身，往往會帶來一系列錯誤的導向，也容易挫傷研發人員的工作積極性。這裡，黑馬周報的OKR模式的（目標+關鍵結果）的考核方法就非常實用。

2. 研發項目考核的市場導向原則

目前來說，國內企業層面的研發主要集中在產品開發上，因此在設定研發考核目標時，必須緊密結合公司研發策略，開發在市場上適銷對路的產品。

3. 個人考核與團隊考核相結合的原則

在研發人員的考核中，把團隊業績作為研發人員績效考核的重要指標，有利於培養研發人員的團隊合作精神，對研發團隊及個人成長均具有重要意義。黑馬周報里個人的目標計劃緊緊和團隊相關聯，每個人的關鍵成果也關乎整個團隊的績效結果。

4. 指標評價方法的科學性原則

在研發成果質量的評價中，引入專業委員會的方式進行，避免主觀性評價偏差過大情況的發生，保證評價的公平、公正。

二、設定三維指標

企業研發人員考核應圍繞三個維度來進行，分別是業績指標、能力指標及行為指標。一般來說，企業的研發人員可以分為項目經理、開發人員及測試人員三類，對於不同類型的研發人員，在指標設計上應該有所差別。下面以研發項目經理的績效指標體系設計為例來說明。

1. 業績指標

項目經理的業績指標主要包括：新產品開發周期、技術評審合格率、項目計劃完成率、項目費用控制、內外部客戶滿意度等，該類別指標主要為客觀性指標。

2. 能力指標

項目經理的能力指標主要包括：業務知識與技能、溝通協調能力、團隊領導與控制能力、指導及幫助下屬的能力、員工管理能力、決策能力等，該類指標主要為主觀性指標，可以採用類似於360o評價的方式進行。

3. 行為指標

項目經理的行為指標主要包括：工作的積極性、主動性、協作精神、團隊意識、工作責任心、服從意識等。

從績效考核的目的來看，如果考核的目的是主要用於加薪、發放獎金、紅利等獎勵，考評指標體系主要為業績指標和行為指標;如果考核目的是為了員工發展，且考核結果將用於教育培訓、能力開發、升遷、調動等人力資源規劃與配置，考核指標體系應包括業績指標、能力指標和行為指標。

三、確立評價主體

研發人員的績效考核方法可以採用員工自我評價、同級(事)評價、上級評價、下屬評價(適用於研發管理人員)相結合的方法進行。

自我評價主要是研發人員自己對過去一段時間業績目標的實現程度進行評估。

同級(事)評價的主要作用是考核員工的團隊協作能力，特別是對於一些需要多人、多部門協作的研發項目來說，這種能力就顯得尤為重要。而對於一些出於保護自己技術優勢地位而不願與人合作的員工來說，這也可以作為一個有力的約束條件。

上級評價可以是直線經理的評價，也可以以項目經理的評價為主，或者是二者的結合。因為對於那些跨部門協作的研發項目來說，直線經理也許不知道自己的員工幹了什麼，工作質量如何。

對於研發項目經理的考核來說，引入下屬評價主要是為了促進項目經理對項目組成員的培養，促進項目經理與成員的溝通，從側面保證項目的順利開展。

研發人員考核四忌

主觀性評價切忌流於形式

主觀性評價要包括行為、態度、成果質量等方面的內容，對於行為態度方面的評價來說，一些研發主管人員出於「面子」的考慮，往往放鬆對這方面的要求，考核結果常常就是「你好我好大家都好」，這種行為一方面挫傷了一些表現優秀員工的積極性，另一方面又助長了團隊內部的不良風氣，對研發團隊的管理是極端不利的。從我們的諮詢實踐來看，做好員工的日常行為考核，完善重要工作落實情況備忘，在考核時做到「用事實說話」是解決上述問題的良好方法。而對於研發成果質量評估，引入專家評估小組是一個不錯的選擇。

切忌績效考核中溝通不充分

績效溝通不暢是造成員工對新方案抵觸的主要原因，許多員工認為引入行為考核是針對自己來的。切忌業績目標過多

過多的業績目標和沒有目標的效果差不多，研究目標管理的專家指出，如果目標超過6～8個，我們只會關心自己認為最重要的2～3個目標。許多企業擔心目標體系太簡單、不夠全面，沒有涵蓋所有的業績要求，就設計了一大堆目標，實際上效果很差。

切忌「自我評估」

評價研發業績時，數量是非常客觀的指標，但是，質量和成本數據往往是十分主觀的。儘管不可能用十分客觀的方式測評質量，但在設計評價過程時可以盡量減少主觀性。一個比較簡單的方法便是儘可能地用外在的數據來評價研發業績的質量。比方說，如果你想估計產品改進的價值，你可以請工程和製造人員來估計，而不是讓研發部門經理來估計他們成績的價值。

績效管理常常被片面理解為績效考核，即如何確定個人的績效，如何提工資和發獎金的問題。實際上績效管理還包含制定績效目標，制定績效計劃，制定配套的制度推動績效等等，當然也包括最後的績效考核，以最終達到績效持續提升的目的。與其對開發團隊進行量化管理，還不如實施OKR 來進行管理。

OKR是企業進行目標管理的一個簡單有效的系統，能夠將目標管理自上而下貫穿到基層。對一個項目來說，設定目標是非常重要的，因為這決定了如何去做，以及能做到何種程度。

OKR 首先是溝通工具:團隊中的每個人都要寫 OKR，所有這些OKR都可以放在協作工具當中，比如 Worktile 。任何員工都可以通過 Worktile 看到每個人在這個團隊中最重要的目標是什麼，團隊的目標是什麼。
OKR是努力的方向和目標:OKR代表你到底要去哪裡，而不是你要去的地方具體在哪裡。
OKR必須可量化（時間數量）。比如銷售時設定銷售目標，如果只是定義成「我們要努力提高銷量」，肯定不是一個好的 OKR，因為無法衡量，好的OKR是「今年的銷量較去年增加50%」。
目標必須一致:制定者和執行者目標一致、團隊和個人的目標一致。首先，制定公司的OKR；其次，每個團隊定自己的 OKR；第三，每個工程師或設計師寫各自的OKR。這三步各自獨立完成，然後對照協調這三者的OKR。OKR跟個人績效沒有關係，因為OKR 系統的結果和每個人並不直接掛鉤。
目標要是有野心的，有一些挑戰的，有些讓你不舒服的。
通過月度會議檢查，時時跟進OKR：在月度會議上需要確定如何去達到目標，是一個幫助達到目標的過程。
通過季度會議檢查，及時調整OKR：互聯網的變化非常快，每季度有一個OKR 的 review，調整的原則是目標（Objectives）不變，只允許調整關鍵成果（Key Results）。

無論是通過實施OKR 或者是其他方法進行績效管理，其實都需要合理藉助工具，Worktile 最近根據研發團隊在工作當中的多種需求整理出了一套詳細的解決方案 - Worktile，可能會對題主有所幫助。

一說量化，首先就涉及到一個問題，開發這項工作到底是藝術創作還是照單加工。如果說是照單加工，勞煩您去看看工廠的加工單，看看工業產品的描述是什麼樣子的。再來說開發工作是不是照單加工。如果說是藝術創作，誰又見過要求相對明確的結果的藝術創作？

對中小IT企業量化考慮這個事情基本屬於胡鬧。

唯一靠譜的就是Leader說了算。事情干不好Leader受罰，事情干好了，怎麼分錢Leader說了算，只是要把分錢的方案抄送給領導，在部分情況下可以考慮抄送參與人員。

作為Leader而而考慮怎麼分錢，無非就是：

1：所負責任務的難易程度

2：質量

3：速度

4：分享精神

5：其他

總之，基本就是人治。這個團隊要達到用人不疑，疑人不用的程度。

但是，對於大型IT企業來說，量化考核就很重要了。說重要不是說大企業的開發工作就確定是藝術創作或者照單加工。而是說，在一個大型企業里，各種利益太多，為了方便管理而不得已不為之。這裡就比較認同 @黨宇航

以上討論不涉及外包業務。

多謝邀請，但是抱歉，量化管理一直是我的弱項。

我曾經試行過但是失敗的量化方式是：

1，工時考核。通過工時和有效代碼行數來對比考核工作量和效率。

2，測試問題數量考核。通過測試提交的問題數量和有效代碼行數來對比考核質量。

失敗原因是有效代碼行數很難科學，測試問題數量也難科學。

供參考。另邀請了幾位管理者，希望有幫助。

強烈不同意目前第一票的kubi的說法。

1，中國研發績效做得好的華為明顯比國內普通科技公司競爭力強。

2，KPI和績效管理從來也是以激勵為主，並不只是考核就完了。

3，研發績效應該研發主管主導，HR為輔，多依靠工具，少依靠外行人。

4，管理不是天生的能力，也是需要學習較長時間的。不能以管理者的失敗（其實多半是不合格的管理者），來推論管理的無用。

要做程序員的績效考核，需要具備幾個先決條件：

1. 獲得大家認可的設計文檔模板和書寫規範

2. 有效的設計文檔Review機制

3. 獲得大家認可的代碼風格和最佳實踐定義

4. 有效的Code Review機制

5. 有效的Bug記錄

以上條件都有了之後，就可以拿到三個值」每頁文檔存在的設計問題數「，」每千行代碼存在的Review問題數量「，」每千行代碼存在的Bug數量「。

這三個值就可以衡量一個程序員在」設計「，」編碼「和」測試「三個階段的綜合表現。

對腦力勞動者進行績效考評沒啥意義。

他們願意干，績效就高；不願意干，績效就低。

還不如對HR的團隊活動工作，進行績效考評。團隊活動質量高，團隊氣氛好，開發工作就能變高效。Google就是這麼做的。