如何做好績效考核 淺析考核原則落實

部門搞績效考核，兩個多月了，各種動腦，到現在才算有了些眉目，但還是不覺得有多理想，要想辦法不斷完善。

　　部門裡有各種崗位，項目經理，研發經理，需求分析人員，客服人員，程式員，測試員，所有這些人放在一起搞績效，真有些為難啊。主要困難是，很難弄出個标準來，讓這些不同崗位的成員的績效成績有可比性。這也是讓我覺得非常為難的地方。現在真是非常羨慕那些成員都做相同工作的部門，做績效非常簡單吧，如銷售部門，隻看銷售業績，績效成績有非常大的可比性。

　　不管多麼困難，現在還是搞出了一個績效考核體系，成果如何恐怕還需要時間驗證。在設計這個績效考核方式時，我引進了一些原則，總結總結。

　　原則一，體系化。

　　要不就不要做績效考核，如果要做，就得有個完善績效體系，否則，輕則績效成績沒有任何作用，重則，可能讓人覺得不公平，引起軍心浮動。

　　要建立體系，就需要先考慮許多内容。

　　首先，績效的目的是什麼。然後圍繞這個目的去做體系的建立。

　　其次，績效成績出來後，如何獎優，如何罰劣。

　　再次，要計算成績，有什麼資料支撐，如果資料不夠，是不是要重構管理流程，引進管理軟體以支援績效考核。

　　另外，這些資料是如何獲得的，如何保證資料的合理性，如何保證績效成績的可比性等。

　　原則二，公開。

　　所有加分、減分的原因，計算方式，最終的成果等，一切公開。讓所有成員都明白，自己或别人因為做對了什麼獲得加分，因為做錯了什麼而被減分。特别是對一些非成果性的考核，如工作态度，團隊精神等，公開這種加減分的原則，并且每一次加分的具體理由，尤其來得重要。希望通過這種公開的非常明确的标準以及不斷增長的案例，使大家對部門的價值取向有越來越深刻的了解。如果不公開，對考核者來說，可能顯得更容易些，但是對被考核者來說，可能總不容易進步，因為不知道自己究竟哪裡做得不足。

　　當然，因為公開，就容易讓有心者鑽了空子，但是這是可以不斷完善的，被鑽空子鑽多了，自然就越來越健壯。制度與軟體一樣，需要不斷改進。

　　原則三，強調團隊精神。

　　由于大大小小的項目很多，每個成員都可能分屬于不同的項目，一段時間在在這個項目，另一段時間在做那個項目，甚至可能同一時間手頭有多個項目在同時進行。

　　在績效考核時，會對每個項目的總成績進行評估，如果項目總成績差了，那麼會影響到參與到這個項目的所有人員。

　　甚至，全部門也有個績效總成績評估，如果部門的成績不好，那麼，所有人績效都會受影響。

　　原則四，有時候需要互相制衡。

　　我們對研發人員，一般會以工作量的标準工時作為考核标準，但這個标準工時怎麼定呢?當然不能由開發者自己說了算。這裡就有個項目經理與開發者談判的過程，對于開發者來說，任務的标準工時定得越長越好，對于項目經理來說，這個标準工時定得越少越好(消耗了多少标準工時是對項目經理考核的重要名額)，這時候，項目經理與研發人員雙方之間就有一個制衡關系，通過這個制衡關系，可以保證這個标準工時不會偏差太遠，可能有些任務偏高，有些認為偏低，但是時間長了以後，會趨向于一個比較合理的值的。

　　原則五，不做強競争性的考核。

　　我們部門裡面，我更強調互相協作，團隊精神比什麼都來得重要。然而，如果沒有競争，通過宣傳、鼓動，在一段時間内可能有些會有效果，但是絕不是長久之計。是以，我的原則是，有競争，但不是強競争。

　　有這麼個曆史故事。說是某王讓匠人做弓箭與铠甲，做成後讓做弓箭的匠人用自己做的箭射做铠甲的匠人做的铠甲，如果射穿，就處死做铠甲的人，如果射不穿，就處死做弓箭的人。這樣子搞，品質肯定能上去的。铠甲匠人與弓箭匠人之間就是強競争，超強競争，這兩種匠人之間的關系可想而知，完全是你死我活的敵我關系。

　　在設計績效方式時，我們盡量避免這種競争方式。

　　舉例，程式員與測試員之間，如果測試員沒發現程式員一個bug，就加1分，同時給程式員減1分，這就構成了強競争的關系。時間久了，這兩種崗位之間的人會弄成烏眼雞的，關系一定會很糟糕，協作精神很難養成。我們強調，測試員與程式員是同一條船上的人，他們共同對軟體品質負責，如果有品質問題，程式員與測試員負連帶責任。