輕量級過程改進之績效管理

2021-06-26 23:18:45 字數 4553 閱讀 1044

績效管理是對團隊成員進行工作評估和激勵的過程,雖然很多時候會由人事部門進行員工的績效管理,但對研發團隊而言,技術人員的績效管理很難把控,所以很多團隊往往對績效管理避而遠之,採用管理層主觀判斷的方法進行績效把控;有些團隊雖然會做一些績效管理,但只是關注於績效考核,而忽略績效背後的工作計畫、評估、激勵以及過程改進。個人認為研發團隊的績效管理是一項很有挑戰性的工作,但難度再大首先還是要理一下思路,尤其作為輕量級過程改進的一環,績效管理的目的並不是說能夠達到很完善的程度,而是先做到60分,然後通過團隊整體能力的提公升再進一步改進績效。本文主要闡述在專案績效管理過程中涉及的主要規程、可能存在的問題、分析這些問題並提出相應的改進措施。

一.績效管理的規程

國內中小型研發團隊往往是從作坊式開發模式中發展而來,通常對績效管理的意識比較淡薄,或者乾脆沒有績效管理的理念和流程,管理層憑自身主觀判斷確定員工的績效結果。當團隊發展到一定規模時,管理層發現靠自己的判斷已經不行了,所以就要搞一下績效管理。這時候的績效管理可以理解為是團隊需要進行過程改進的一種預示,也是本文所要討論的場景和初衷。我們都知道過程改進領域有乙個pdca環(由美國質量管理大師edwards deming基於walter shewhart所提出的模型演變而來,故又名戴明環),個人認為績效管理本身實際上也是乙個pdca環:

過程改進如同專案計畫需要進行階段性規劃和控制,績效管理也是一樣。通常績效管理具有週期性,即以一段時間為限形成上面的pdca環,實際操作過程中以乙個月或乙個季度作為基準的情況較多,最好不要超過乙個季度,否則pdca環的時效性將大打折扣。下文統稱這一週期為績效週期。結合績效管理的pdca環及其週期性,績效管理的規程如下:

1.      制定績效計畫

2.      收集績效資料

3.      評估績效

4.      溝通績效

二.績效管理中的問題

1.      混淆績效管理和績效考核

績效管理和績效考核是兩回事,個人認為績效考核應該是績效管理中的乙個環節,結合上文中的績效管理pdca環,績效考核通常只包括plan和check兩個環節,多為事後進行評估,注重形式和結果,主要是人事部門參與整個流程;而績效管理根據團隊目標設定績效期望值,設定績效指標後,不斷激勵並輔導員工,注重整個管理流程,通常團隊管理者參與整個過程。片面強調績效考核而不關注整體績效管理流程對員工自身的提公升是不利的。

2.      沒有應用pdca環進行績效管理

對過程改進而言,績效管理需要形成完整的改進閉環,在本文中我們提倡的就是pdca環。但很多時候績效管理往往難以形成閉環管理,閉環管理需要制定績效計畫、資料收集和分析、績效評價和績效診斷與輔導這四個環節,績效的自評、他評、溝通和改進措施缺一不可。自評能夠觸動員工自身的管理和提公升意識,他評提公升管理層對員工績效的管理和激勵意識,溝通確保個人和團隊之間達成一致,改進措施是本次閉環的最終產出以及下一次閉環的輸入。沒有進行閉環管理是實施績效管理過程改進的根本問題。

3.      缺少績效診斷和輔導

如果績效管理的結果僅僅是對員工打個分,那肯定是不夠的。有些時候員工甚至對績效結果都不清楚,那如何作出改進呢?所以對績效結果我們需要進行診斷,找出好的地方和不好的地方,對好的地方要保持,對不好的地方要改進。改進的方向和思路通常都需要輔導,因為對普通員工,尤其是新員工而言普遍缺少過程改進的意識和方法,這時候通過溝通進行績效的診斷和輔導就變得非常重要了。

4.      績效激勵措施不完善

績效激勵措施不屬於過程改進的內容,但在績效管理實施過程中必不可少。激勵措施可能是物質上的獎勵,也可以是精神和思路上的梳理和鼓勵,無論哪種手段,充分的溝通是確保績效激勵的最根本方式。缺乏激勵會導致過程改進流於形式,導致團隊成員對績效管理的積極性下降和過程改進意識的淡薄。

5.      缺少從團隊的角度管理績效 如果團隊成員較多,通常會進行梯隊式管理模式,即將大團隊分組管理。對於分組後的各小組而言,績效管理應該以小組為單位進行,這裡的小組就相當於乙個團隊,上面提到的各項績效管理規程都可以直接應用。反之,如果在規模較大的團隊中還是執行點對點的績效管理,對於團隊管理和個人績效的提公升都是不現實的。

三.績效管理的過程改進

績效管理的本質是為了提高績效,提高績效當然不能只靠引入一套績效管理流程就想起到立竿見影的效果。但沒有績效管理的理念,不把績效透明出來作為個人和團隊的一項日程工作,績效提公升也就無從談起。同時,績效管理也是個人與團隊管理者之間的一種紐帶,促使個人和團隊之間形成一種溝通機制。績效管理過程改進的切入點包括:

1.      關注團隊級別績效管理

上面提到績效管理中的乙個問題是「缺少從團隊的角度管理績效」,關注團隊績效也就是說我們要站在團隊角度看問題。對研發團隊而言,乙個團隊中包含多種角色,而研發目標通常是乙個進度要求,這個進度要求需要團隊成員協作才能完成。從過程改進的角度看,個人績效的提公升是乙個點,而團隊績效的提公升才是乙個面,點的提公升也是為了面的提公升。

2.      關注績效表現形式

績效管理的過程和結果需要有合適的表現形式,也就是說好的績效管理應該具備統一的、合理的模型。目前主流的如kpi(key performance indicator,關鍵績效指標)、bsc(balancedscore card,平衡計分卡),還有類似google的okr(objectivesand key results,目標和關鍵成果)等都是績效模型。但這些模型也只是一種參考模型,我們需要根據團隊認識和現狀做一下裁剪,本文不對這些模型進行具體展開。

3.      關注績效的確認和溝通 個人認為績效管理的pdca環中最重要的就是績效溝通環節。plan、do和check都是為了最後的action做鋪墊,過程改進的目標和措施也正是通過績效的確認和溝通才能得到明確和推動。當然,績效溝通需要一定的技巧和方法,確保個人和團隊都能從過程改進的角度去看績效管理。

針對上述切入點,我們梳理績效管理過程改進的模式和實踐包括:

1.      團隊目標和計畫同步

績效管理的起點是績效計畫,所以我們第一步就是同步績效週期內的團隊目標和計畫。團隊的計畫一部分如同專案管理中的計畫一樣,需要根據具體的專案進行過濾和透明並形成統一檢視。實際操作中,專案日曆通常是專案級別計畫同步的一項有效實踐。另一部分屬於專案以外的工作計畫需要根據具體團隊的情況進行梳理。

2.      團隊分解和開展團隊績效管理

對大團隊的績效管理首先需要進行小團隊分解,每個小團隊有乙個leader,這些leader負責自己團隊中所有成員的績效管理以及對應的過程改進,同時這些leader的上一層管理者負責這些leader的績效,以此類推。每個小團隊的人數控制在10人以內,建議根據跨職能團隊組建原則進行團隊分解並維護各自的績效計畫和目標。

3.      應用kpi體系

建議在績效管理中引用kpi體系,相對其他績效模型,kpi容易理解和上手,使用也比較廣泛。kpi系統的核心是建立kpi指標庫並確保每個kpi能夠進行量化,通常我們會根據不同的角色設計不同的kpi指標,常見的有:

kpi的特點是量化,但有些工作不一定能做到量化,不能量化的工作可以歸為「重點工作事項」。重點工作事項可以根據具體情況進行設定,例如在本文的上下文中,把過程改進措施作為重點工作事項就是一項最佳實踐。

4.      開展自評和他評

自評和他評兩者缺一不可,自評由個人填寫,他評由團隊leader填寫。自評和他評不是打分,而是對kpi和重點工作事項完成情況的客觀描述。從這些客觀描述中,個人及其直屬上級之間的想法和建議可以得到總結和認識,確保為個人績效溝通以及後續的過程改進提供輸入。

5.      個人績效溝通和改進方案診斷

確保對團隊中每一位成員進行個人績效溝通,這是觸發個人過程改進的最有效時機。個人績效溝通由團隊leader主導,基於但不要侷限於《個人績效表》中的內容。對研發團隊而言,研發人員普遍不善於溝通和表達自己的想法,團隊leader需要有一定溝通技巧讓大家把心裡話說出來,同時能夠結合團隊的整體改進目標和方式以及每一位成員的個人想法為其進行個人過程改進提高思路和指導。關於個人軟體過程(personal software process,psp)和團隊軟體過程(teamsoftware process,tsp)的相關思想和實踐方式可參考過程改進大師watts humphrey的相關著作,這裡不再展開。個人績效溝通的時間不限,個人認為如果能夠和團隊成員進行定期/不定期深入溝通,對於溝通時間上的投入信價比是非常高的。

6.      績效統計和分析 績效管理是為了過程改進,但畢竟還是要有結果的,不然無法體現過程改進的效果,也無法進行激勵。這就需要我們對個人的績效進行打分,打分的方式也不外乎基於100制的乙個分數、或者abcd中的乙個等級,打分的依據參考kpi和重點工作事項的權重進行計算。關於績效打分個人認為不要太量化,從表現形式上後者的效果會比前者好一點,也比較符合過程改進中的等級提公升理念。有了每個績效週期的績效結果,我們就可以基於這些結果進行一定時間範圍(半年或一年)內的績效統計和分析,應用統計分析的工具和方法可以得到個人的績效改進趨勢圖,獎懲措施也可以基於這些資料進行客觀的判斷和執行。

四.績效管理的過程資產

1.      個人績效表

個人績效表主要包括以下要點:

五.小結

績效管理是輕量級過程改進系列團隊管理類的第乙個改進域,也是研發團隊的老大難問題。與傳統行業相比,軟體是「軟」的,開發過程中的不確定性和變異性確實很難通過量化的方式得到績效結果。作為一名技術管理人員,個人也沒有太好的策略和模式進行完善的績效管理,所以本文從過程改進的角度出發,試圖基於個人和團隊過程改進為績效管理提供一些思路,與大家共同**這一話題,有任何好的建議、意見可與我聯絡。

輕量級過程改進之綜述

輕量級過程改進 light weight process improvement,lpi 是一種針對中小型團隊軟體研發過程中普遍存在的重技術輕管理 研發管理缺乏規範 過程改進理念淡薄等現狀和問題而整理的一種 軟體過程改進方法和規範 有眾多輕量級過程改進域組成,主要對中小型團隊持續地改進其軟體過程能力...

輕量級過程改進之綜述

輕量級過程改進 light weight process improvement,lpi 是一種針對中小型團隊軟體研發過程中普遍存在的重技術輕管理 研發管理缺乏規範 過程改進理念淡薄等現狀和問題而整理的一種 軟體過程改進方法和規範 有眾多輕量級過程改進域組成,主要對中小型團隊持續地改進其軟體過程能力...

輕量級過程改進之需求開發

需求開發是指通過對使用者需求進行分析,開發產品需求的過程。需求開發在於把面向使用者的需求轉換為面向研發團隊的需求的過程,回答研發團隊 我們要做什麼樣的產品 的問題。需求開發直接面向研發團隊,是使用者需求傳遞到研發團隊中的必要一環。本文主要闡述在專案需求開發過程中涉及的主要規程 可能存在的問題 分析這...