績效考核需要體系化

申請免費試用、咨詢電話：400-8352-114

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

       部門里有各種崗位，項目經(jīng)理，研發(fā)經(jīng)理，需求分析人員，客服人員，程序員，測試員，所有這些人放在一起搞績效，真有些為難啊。主要困難是，很難弄出個標準來，讓這些不同崗位的成員的績效成績有可比性。這也是讓我覺得非常為難的地方?，F(xiàn)在真是非常羨慕那些成員都做相同工作的部門，做績效非常簡單吧，如銷售部門，只看銷售業(yè)績，績效成績有非常大的可比性。

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

       原則一，體系化。

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

       要建立體系，就需要先考慮許多內(nèi)容。

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

       其次，績效成績出來后，如何獎優(yōu)，如何罰劣。

       再次，要計算成績，有什么數(shù)據(jù)支撐，如果數(shù)據(jù)不夠，是不是要重構管理流程，引進管理軟件以支持績效考核。

       另外，這些數(shù)據(jù)是如何獲得的，如何保證數(shù)據(jù)的合理性，如何保證績效成績的可比性等。

       原則二，公開。

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

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

       原則三，強調團隊精神。

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

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

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

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

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

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

       我們部門里面，我更強調相互協(xié)作，團隊精神比什么都來得重要。然而，如果沒有競爭，通過宣傳、鼓動，在一段時間內(nèi)可能有些會有效果，但是絕不是長久之計。因此，我的原則是，有競爭，但不是強競爭。

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

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

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