Home | 簡體中文 | 繁體中文 | 雜文 | 打賞(Donations) | 雲棲社區 | OSChina 博客 | Facebook | Linkedin | 知乎專欄 | Github | Search | About

10.5. 軟件行業績效管理

10.5.1. 什麼是績效管理

績效管理是管理者保證員工的工作活動和結果與組織目標保持一致的一種手段和過程。它是通過識別、衡量和傳達有關員工工作績效狀況和水平的信息,並作出相應指引來使組織的目標得以實現。 我們聽到更多的是“績效考核”:績效考核是績效管理的基礎和手段,也是績效管理的必經階段。沒有經過績效考核階段是不可能到達績效管理階段的。

10.5.2. 為什麼績效管理

達成目標:績效考核本質上是一種過程管理,而不是僅僅對結果的考核。它是將中長期的目標分解成年度、季度、月度指標,不斷督促員工實現、完成的過程,有效的績效考核能幫助企業達成目標。

挖掘問題:績效考核是一個不斷制訂計劃、執行、檢查、處理的PDCA循環過程,體現在整個績效管理環節,包括績效目標設定、績效要求達成、績效實施修正、績效面談、績效改進、再製定目標的循環,這也是一個不斷的發現問題、改進問題的過程。

分配利益:與利益不掛鉤的考核是沒有意義的,員工的工資一般都會為兩個部分:固定工資和績效工資。績效工資的分配與員工的績效考核得分息息相關,所以一說起考核,員工的第一反應往往是績效工資的發放。

促進成長:績效考核的最終目的並不是單純地進行利益分配,而是促進企業與員工的共同成長。通過考核發現問題、改進問題,找到差距進行提升,最後達到雙贏。 績效考核的應用重點在薪酬和績效的結合上。薪酬與績效在人力資源管理中,是兩個密不可分的環節。在設定薪酬時,一般已將薪酬分解為固定工資和績效工資,績效工資正是通過績效予以體現,而對員工進行績效考核也必須要表現在薪酬上,否則績效和薪酬都失去了激勵的作用。

人員激勵:通過績效考核,把員工聘用、職務升降、培訓發展、勞動薪酬相結合,使得企業激勵機制得到充分運用,有利於企業的健康發展;同時對員工本人,也便于建立不斷自我激勵的心理模式。

10.5.3. 績效管理的分類

績效管理可分為兩大類,一類是激勵型績效管理,側重於激發員工的工作積極性,比較適用於成長期的企業;另一類是管控型績效管理,側重於規範員工的工作行為,比較適用於成熟期的企業。 但無論採用哪一種考核方式,其核心都應有利於提升企業的整體績效,而不應在指標的得分上斤斤計較

10.5.4. 績效管理面臨的問題

績效管理是人力資源管理的一項核心職能,對於人力資源管理來說是非常重要的。然而新型產業績效管理面臨一些列問題,傳統的績效考核手段並不適用,隨着績效管理工作的實施,發現難以推廣,各種阻力重重,很多問題對於人力資源部門一籌莫展。很多企業採用生拿硬套方法,使用傳統方法考核技術人員,這樣僅僅是對於公司做了交代(我們已經實施了績效管理),但這樣績效管理無法長久,最後不了了之。

  1. 軟件開發無法量化

  2. 程序員水平問題

  3. 怎麼考核腦力工作者

  4. 變化總比計劃快,指標分解被打亂

技術人員的績效管理已經超出人力資源部門能力範圍,需要多部門的不斷深入,方能有效地支持企業的整個運營。

KPI之所以廣受歡迎,就是因為“你選擇衡量什麼,你就得到什麼”。問題在於,有許多種KPI指標任你選擇,選到適合自己的真不太容易。領導層如果選了錯誤的KPI,就意味着員工會執行錯誤的指令,後果顯然很嚴重。

站在員工的角度,KPI無非就是:

  1. 在指定的時間段內,我要完成哪些任務;

  2. 這些任務,我分別要完成到什麼程度;

  3. 根據完成了哪些、各自完成的程度來拿錢。

說得再簡單一點就是,完成了KPI拿錢拿獎勵,完不成愛幹嘛幹嘛。提前完成再貢獻,就顯得沒有意義。

KPI從最大程度上提高了效率,卻也是一把雙刃劍。

其一,有些事情值得去做,但在存在一定風險,且無法測量,也因此無法制訂KPI。沒有寫進激勵機制,那創新就顯得困難了些。

其二,沒有人對最項目的終結果負責,每個人只對自己經手的過程負責。

長此以往,KPI 讓那些充滿報復與野心的員工激情消耗殆盡。

10.5.5. 績效管理的誤區

績效管理強調組織目標和個人目標的一致性,強調組織和個人同步成長,形成“多贏”局面;績效管理體現着“以人為本”的思想,在績效管理的各個環節中都需要管理者和員工的共同參與。

在我看來國內企業績效管理歸為,員工考核,很多人認為企業存在的問題是員工工作不積極,沒有責任感。我認為這樣的企業首先應該自我反省。什麼樣的企業文化,產生什麼樣的員工。

10.5.6. 怎樣做績效管理

績效管理應以軟件開發為主綫,貫穿軟件開發過程中,而不是軟件開發以外一項工作。績效管理不能影響正常的軟件開發,不應讓績效管理成為技術人員的負擔。 讓績效管理融入開發工作,成為軟件開發過程中的一個環節。 績效管理應該由技術部門自行實施,人力資源部門協助。與其挖空心思怎麼樣考評員工,不如建立一個積極上進的團隊。所以我們應該以團隊建設為主,而不是考核為主。

實施績效管理是為了更好的實現:達成目標,挖掘問題,分配利益,促進成長,人員激勵。實現上述目標,我們不一定非使用“關鍵績效指標(KPI:Key Performance Indicator)”,還有其他的考核方式。 KPI是在國內應用最廣的,但我覺得也是最不適用於技術人員考核的方法。平衡計分卡(Balance Scorecard, BSC)操作起來太繁瑣。360°評價體系,真的浪費人力成本。 最後一種目標管理MBO(Management by objectives) 我認為優於其他幾項,但仍需要改造,我們只需要借鑒一部分精華即刻。

10.5.6.1. 開發模式

項目管理模式的軟件開發團隊,不理利於創新,會降低員工的積極性,員工沒有參與感,將員工視為工時,一個部件,一個資源,任憑項目經理的調度,使用。員工的想法無法得到重視,僅僅是執行命令。 我更喜歡敏捷開發團隊,我更喜歡全棧開發人員,讓開發人員參與的軟件開發周期的每個環節中,人力資源利用率高,讓開發工作成為有趣的事,從被動接收任務分配,到主動參與其中。

10.5.6.2. 通過代碼提交數量判斷其在團隊中的貢獻

分析年,月,周每個隊員的提交數量判斷其在團隊中的貢獻。這是一個有說服力的數據,無人反對。做的工作多自然提交就會多。

需要注意,同級別比較,不能垮級別比較。貢獻越多,對系統就越瞭解這是成正比的。也就更有機會得到晉陞。

通過本週,本月報表與上周,上月的對比,分析員工工作狀態。

10.5.6.3. 目標與達成

設置目標,確定達成目標的關鍵結果,這部分參考了MBO(Management by objectives)與OKR(Objectives Key Results)。

10.5.6.4. 通過提交日曆查看員工的狀態

提交日曆可以一看出一周,一個月,一年的貢獻。

10.5.6.5. 團隊約束

團隊的約束遠大於規章制度的約束。

10.5.6.6. BUG率

BUG並不能說明什麼,做的越多,BUG反饋就越多,它可以所作選項出現,我更關注的是reopen的次數。而不是隊員的bug數量 很多人錯誤的將bug率計入考評,導致多做多bug, 少做少bug, 不做沒bug。

10.5.6.7. 代碼審查

我不建議專門抽時間做代碼審查,我主張提交後即刻審查,分支合併過程審查。審查可能考核隊員能力,責任心等等

10.5.7. 魚骨圖

我使用魚骨圖做OKR,我認為這樣更清晰。

10.5.8. 雷達圖

考核指標打分制,很多企業將考核項目打分例如1~10分,然後再計算總分,這個打分本身就不合理。 傳統的績效考核採用填表的方式,我認為這種方法應該淘汰了。我更喜歡雷達圖。 通過雷達圖打分,覆蓋區域面積越大能力越強,同時可以一眼看出那方面能力不足。

Figure 10.1. 雷達圖

雷達圖

10.5.9. 全棧開發能力評估

需求,設計,開發,測試,運維。

Figure 10.2. 全棧開發

全棧開發

10.5.10. 總結

綜上所述,我管這種績效考核稱為CO2TRD (高大上,我TM真有才!!! 為什麼這樣組合,CO2不用說了,TRD來自Toyota Racing Development) 即:

  • Contributors (貢獻)

  • Objective (目標達成)

  • Teamwork (團隊合作)

  • Constraints (約束)

  • Defect (缺陷)

  • Review (審查)

記住CO2TRD是Netkiller 發明的:)