漢捷咨詢 孫豪亮

?

杜經理是某高科技企業軟件部的技術主管，小張和小謝都是杜經理下屬的骨干員工。小張工作態度積極主動，交代下來的開發任務都能很快地完成，同時經常主動晚上加班定位問題、解決問題，為了讓版本順利通過，有時候甚至加班到凌晨才回去。工作態度、主動性都很不錯，雖然代碼問題比較多，但問題解決的也很快。小謝則與小張明顯不一樣，在完成開發任務時，小張一天完成的工作，小謝一般要花兩到三天的時間，但小謝的工作質量較高，遺留的問題不多，因此加班也不多，相對小張來說相對清閑一些。

到了季度考核的時候，杜經理例行給小張、小謝進行考核，根據平時的工作態度、表現和工作結果，杜經理對小張非常滿意，每天都非常的忙碌，好員工類型，因此給了小張A，對于小謝，因為小謝加班不多，相對小張緊張解決問題，小謝在看資料、寫文檔、檢查和調試代碼，沒有小張那么緊張，因此給了小謝C。小謝找到杜經理申訴，杜經理直接告訴他：小謝啊，你要學學小張，你看他多么積極，經常的加班，你們的工作結果都差不多，態度就很關鍵了。

半年后，小謝離開了公司，小張接手了小謝的工作。但是讓杜經理奇怪的是，原來小謝那相對輕松的工作節奏，到了小張這里，仍然是非常緊張，小張仍然一如既往地加班、改問題。杜經理于是找到小張以及其他同事座談，終于了解了事情的緣由。小張工作速度的確是快，但是小張拿到工作任務稍微思考一下就開始編碼，為了盡快交付，小張不怎么考慮代碼架構，甚至為了快有時會直接不管架構修改代碼，同時代碼基本沒有注釋，大函數特別多，有好幾個超過1000的大函數，異常處理也很少。因為需求分析和設計不足，很多復雜的場景一開始都沒有考慮，一測試BUG就都跑了出來，因此小張需要花費大量的時間去定位和修改BUG，而且后期還有不少的遺留問題。而小謝接到工作任務后，會認真的分析需求，并進行詳細的設計，特別是異常/復雜場景的考慮，在編程方面，代碼架構清晰，可擴展性好，代碼嚴格遵守公司的編程規范，注釋、異常處理、定位信息充足，即使出現問題，小謝也可以輕松的定位故障。因此小謝才會在測試期間表現得相對輕松。

想到這里，杜經理非常的后悔。為何當初沒有了解這些情況而錯誤的給了小謝不公平的考評結果。其實在企業里面，這種現象也是層出不窮。救火隊員通常都能給領導不錯的印象，獲得不錯的考評，而那些默默的把防火工作做的很出色的，因為在關鍵節點沒有表現，沒有露臉的機會。其實所有的人都知道防火重于救火，把防火工作做的出色的才是優秀的程序員，是軟件開發的最可靠的保證。但是現實的考核結果卻倡導了錯誤的導向，救火員反而獲得了更多的表揚和成功。這也導致了很多的程序員，自覺不自覺地會在代碼中挖坑，以圖在關鍵時刻挺身而出表現一把，從而獲得領導的賞識。

也有企業認識到了這一點，只是在實際考核的時候還是會把考核結果偏向救火隊員，畢竟救火隊員的表現擺在那里。那么我們的員工評價機制到底哪里出了問題？如何扭轉救火比防火更吃香的問題？

根因其實還是對員工的績效評價機制不健全，首先是績效考核的標準不明確，甚至缺失，績效考核主要是靠管理者的主觀印象；其次是缺乏有效的績效輔導和績效面談，只是簡單的把結果說明。更關鍵的，無論是管理者還是員工，都把這當成了一個額外的復雜的任務，而不是把它當成了達成公司和個人目標的重要工具。這個問題的解決，不是單純的績效考核機制能夠解決，建立科學完善的績效管理機制勢在必行。績效考核只是績效管理的一個環節。

績效管理是管理者和員工雙方就目標及如何達到目標形成共識，并促成員工成功地達到目標的管理方法。績效管理是一個完整的管理過程，包括四個過程：制定績效計劃、績效輔導、績效考核與反饋、結果運用。

要想有效規避這個問題，筆者認為首先需要系統建立績效管理機制，重點加強四個方面的工作：一是要轉變觀念，對于管理者，績效管理既是達成業務目標的有效工具，也應該是員工達成個人目標的重要手段；二是要建立明確的績效目標，每個員工考核周期初期就要制定績效目標。管理者與員工一起溝通確認績效目標，績效目標制定遵循SMART原則。為了防止救火隊員獲得比防火隊員更大的考核優勢，績效目標要充分平衡結果和過程的考核比例分配。三是要加強績效輔導，針對目標，定期對員工進行輔導，同時也需要收集績效數據，用數據來支撐考核結果；四是績效面談很關鍵，把握好績效面談的方式，績效考核結果不僅是員工過去一個考核周期的評價，同時也是員工下一步成長的指向標。