IT軟體公司研發線績效管理經驗

2021-05-04 09:58:13 字數 2097 閱讀 8201

由於工作需要,公司特別邀請到了業界專家鄧超先生來公司交流研發線績效管理相關問題,這裡記錄和鄧超先生交流的一些記錄和自己在平時工作中的理解。

1、

評價員工是否表現優秀和員工獎金的發放採用不同的標準。

員工表現是否優秀工作量不作為直接評價指標,而只作參考指標,主要關注進度指標和質量指標;

獎金的發放則重點考察工作量指標,同時參考其他指標。

我覺得這裡講的員工的表現比較籠統,應該是員工能力、綜合素質的體現,為日後晉級做依據。獎金的發放依據多勞多得視乎沒有什麼異議。

2、

員工是否表現優秀,採用相對該員工崗級的考核方式,所有考核指標都要考慮崗級因素。

3、

當所有人都能達到指標要求,也就是指標體現不出差異時,該指標可不作為直接評價指標,而作為參考指標。

4、

不同崗位的人員不放在一起進行正態分佈;少於

10個人也不進行正態分佈;

這個深有體會,我們部門是全公司最特殊的部門、我們部門有開發、測試、業務、需求、策劃人員,之前的績效考核中要把這些人放在一起來按照統一的標準考核和正態分佈是非常困難,比較不同的人職能不同,參考的標準也不同

5、

不同專案之間的平衡,包括工作量的審核、由專家委員會進行審查,專家委員會成員由部門經理、產品經理、規劃經理構成。

6、

評價等級的劃分,先依據團隊的平均水平劃定及格線.

7、

開發人員考核安排的

1天工作量要求達到

200行**量(包含增加、刪除、修改的**)

我覺得是平均開發時間,這裡的200行**應該不是有效**。

8、

排工作計畫時不告訴員工專家委員會評估的工作量,由員工自行認領工作並排出計畫完成時間,如果員工評估的時間大於專家委員會評估的時間則要求縮短時間或換人,如果員工評估的時間小於專家委員會評估的時間則實際工作完成時間以員工評估的為準,但以專家委員會評估的工作量作為最終考核的工作量,此工作量自始至終都不向員工公布。

這個很好我覺得,這個有點類似敏捷開發方法scrum的sprint planning meet(

一般為一天時間(7小時)。該會議需要制定的任務是:產品owner(業務人員)和團隊成員將自己的功能模組(backlog)分解成小的功能模組,  

決定在即將進行的sprint裡需要完成多少小功能模組,確定好這個product backlog的任務優先順序。另外,該會議還需詳細地討論如何能夠按照需求完成這些小功能模組。制定的這些模組的工作量以小時計算。)因為有時候,專案經理/開發經理或者專家組都好,沒有比員工自己更了解自己開發能力了的,但是如果員工想忽悠領導,故意多報一些時間,不好意思有估算庫做依據,最終確定的時間也會**不離十。即使估算偏差較大,還可以修正估算庫的時間。

9、

參加評審的人員給工作量,但要求

1個小時發現至少

5個缺陷。

10、

對需求人員的考核主要考察需求文件的缺陷率和對提單的答覆工作的滿意度。其中對提單答覆的滿意度由提單人打分。

11、

作為管理人員在過程中要多採用抽查方式進行監督,例如對不同組之間工作量估計的合理性和平衡性(檢查 **行)、功能測試結束時抽查部分功能點運**況等,通過抽查以督促提高薄弱環節的工作質量和合理性。

IT軟體公司研發線績效管理經驗

由於工作需要,公司特別邀請到了業界專家鄧超先生來公司交流研發線績效管理相關問題,這裡記錄和鄧超先生交流的一些記錄和自己在平時工作中的理解。1 評價員工是否表現優秀和員工獎金的發放採用不同的標準。員工表現是否優秀工作量不作為直接評價指標,而只作參考指標,主要關注進度指標和質量指標 獎金的發放則重點考察...

軟體公司績效考核(大家提提建議)

今天看到一篇 軟體公司績效考核 文章 公司正想用,不知道到底好不好,大家談談想法 軟體開發工程師工作質量考核評分標準 序號 標準 說明 評分標準 1 錯誤率 每千行程式20個錯誤以下 包含20個 5 每千行程式21 25個錯誤 4 每千行程式26 30個錯誤 3 每千行程式31 35個錯誤 2 每千...

Atitit 研發管理軟體公司的軟資產列表指南

atitit.研發管理軟體公司的軟資產列表指南 1.isv模型下的軟資產 12.實現層面implet 13.規範spec層 14.法則定律等val層的總結2 soft assets就是 軟資產 指人力資源 human resources 品牌 brand 技術 technology 及知識儲備等資產...