1. 如何量化考核軟體開發人員績效
你好,
「目標管理」更適合軟體開發人員。
但些方法最好從上至下全員使用
1、目標項(即當月或是階段性的工作項目、或是要點)
2、目標項的達成准標(以量化標准作為結點,避免方向性的准標如「進一步提高等」)
3、目標在執行過程中所遇到的問題點
4、針對第3項問題點所採取的應對措施(目的進行檢驗,和糾偏)
5、提交成果主要的衡量標准
6、衡向配合部門
以上6項樓主可以進行一個列表,進行橫排~進行目標設定,階段性進行總結。
根據目標完成成度進行考核。
因為軟體開發人員的工作性質比較特殊,考核方案要與所擔當的項目結合起來才能很好的推動,如果太過形式化,執行力和效果都不會很好。
希望回答對您有幫助.
2. 如何有效量化考核指標
績效考核的目的是為了激勵員工,能達到「激勵」這個目的就可以了,沒必要對所有的崗位都定量到底,給一些定性指標也是不影響「激勵」這個最終目的的,而且可以給員工一個更加寬松的環境,有助於處理好企業文化和員工關系。
而且,確實有一些工作是不適合定量的,比如產品開發,這種工作周期又長,風險又大,可能研究了幾年,還是有很大的失敗可能——通常一個項目能有60%的成功率就頂頂不錯了,如果是定量考核的話,那對開發人員無疑是非常不公平的,他付出了長期的工作,卻得不到絲毫承認,而且他的工作也並非完全沒有成果,也許這個項目是失敗了,但由此積累下來的技術卻可能用在別的地方。像這些崗位,定量指標雖然更簡單方便易見成果。
定量考核要慎用,最好是和定性考核摻雜著來,根據不同的崗位、時期、公司所處階段等,可以以不同的考核方法為主,比如,同樣對於生產員工來說,在公司處於擴張期、追求規模時,可以量化考核其生產效率為主;在公司處於穩定期、追求產品質量與創新時,則以定性考核期工作能力等為主。
最後我想說自己很認同鏢哥的說法,所以基本借用了他的話,嘿嘿,不好意思了,膘哥。
3. IT部門的KPI應該怎麼制定
kpi指標設計的重點一是要體現信息化部門的價值,二是要保障系統安全有效運行。kpi要確定可以量化的關鍵值。也可採用監控系統,定期輸出報表。
考查指標,例:
it項目完成率、it服務滿意度、it網路故障時長、it信息安全事故次數 等。
4. IT項目績效考核方法
靠考核解決這個問題不太可能. 要改變的是公司的薪酬制度, 提高基本工資(崗位工資), 降低項目提成的比例. 當然薪酬總額要測算好, 不能比改之前低.
5. 關鍵績效指標法的IT服務的關鍵績效指標法
關鍵績效指標法將成為考核IT服務績效的一個重要因素。關鍵績效指標法包括與業務需求結合的度量,數據中心的監測和能力規劃等等指標。
IT服務的關鍵績效指標法指標與常見的監測指標之間的差異是企業領導的參與。任何一個企業都可以部署一些監控工具來跟蹤分配給虛擬機的資源或伺服器的帶寬利用率等。這些分散的技術因素對IT技術人員有幫助,但對企業的實際應用價值並不大。企業應該了解關鍵績效指標法,利用關鍵績效指標法來管理和解決問題。
雖然ITIL有一套通用的性能建議關鍵績效指標法設置,但它沒有一套可以通用於所有項目的需求關鍵績效指標。IT的關鍵績效指標法關鍵績效指標通常分為三大類:服務交付力關鍵績效指標法、服務關鍵績效指標法或性能的效率關鍵績效指標法和靈活性關鍵績效指標法(應對服務的變化)。企業的IT服務提供商也應該使用服務可用性的關鍵績效指標法指標。 服務吞吐量關鍵績效指標法體現在用戶對應用程序或系統的使用或需求。通常是指事務的數量或計算工作的措施。·響應時間關鍵績效指標法
響應時間的關鍵績效指標法指標包括需要完成事務的時間長短。響應時間關鍵績效指標法包括多種基礎設施元素,如伺服器、網路和存儲。它與服務級別協議有緊密的關系(SLA)。· 資源利用率關鍵績效指標法
舉個例子,物理或虛擬機的資源與被分配資源總量的比值就是一種利用率關鍵績效指標法。如果一個虛擬機分配了10G的內存關鍵績效指標法,而它使用了10G的內存關鍵績效指標法,利用率便是100%關鍵績效指標法。·正常運行時間關鍵績效指標法
正常運行時間關鍵績效指標法是衡量應用或系統正常運行時間的百分比指標關鍵績效指標法。群集技術關鍵績效指標法,自動恢復伺服器關鍵績效指標法和網路故障轉移關鍵績效指標法都有助於正常運行時間的指標關鍵績效指標法。企業可以利用這些指標來計算其定製服務關鍵績效指標法。例如,如果設備的吞吐量關鍵績效指標法和正常運行時間關鍵績效指標法的指標高而響應時間的指標低關鍵績效指標法,無論資源利用率的高低,服務分數都不會受到很大影響。但如果資源利用率和響應時間增加而吞吐量或者運行時間下降,則會嚴重影響服務關鍵績效指標法分數。 ·工作效率還是性能關鍵績效指標法?這個派生關鍵績效指標法的指標將工作量的分配資源關鍵績效指標法和利用資源關鍵績效指標法拿來做比較。這個指標可以看出工作量對資源需求的大小,是浪費資源、資源不足還是剛剛好。·系統效率和性能關鍵績效指標法
系統效率關鍵績效指標法是以伺服器的分配資源與可用資源對比的一個指標關鍵績效指標法,讓伺服器能達到最佳的性能負載。從這個指標可以看出伺服器是存在資源浪費還是資源超載關鍵績效指標法。工作負載關鍵績效指標法和系統的指標關鍵績效指標法通常是通過數據中心匯總數據後計算出來的平均值。IT團隊通過快速測量工作期間的狀態,再比較它以前的狀態來為新技術項目的投資提供必要的數據關鍵績效指標法。例如得到一個較低的關鍵績效指標法數據,就表明可能需要升級負載均衡或其他技術項目關鍵績效指標法。 ·服務請求回應的關鍵績效指標法
服務請求回應關鍵績效指標法是指在可接受的時間內回應通過呼叫或者其他方式的服務關鍵績效指標法請求,並成功解決的事件數量關鍵績效指標法。·服務處理時間TTR關鍵績效指標法
TTR關鍵績效指標法是衡量需要解決關鍵績效指標法服務請求的時間。例如當收到一個新虛擬機的請求時,評估的時間,方案的確定,批准到提供一個新的虛擬機這一整套流程的時間關鍵績效指標法;或者收到要進行資源關鍵績效指標法分配更改的請求,所需要的性能檢測時間關鍵績效指標法。伴隨著IT服務請求的數量增加,TTR關鍵績效指標法會相應的下降。可以看出TTR關鍵績效指標法是靈活的,能夠應對變化的工作量和用戶需求。如果服務請求和TTR關鍵績效指標法的數量同時增加,則表明IT服務存在明顯的服務敏捷性短板關鍵績效指標法。 IT服務提供商或其他提供受SLA(Service-Level Agreement 服務等級協議)約束的IT服務組織,都可以採用SLA 關鍵績效指標法,這是一個涉及范圍廣泛的指標。·服務請求處理率KPI
這個關鍵績效指標法指標是度量在一個可接受的時間對服務請求提供可用服務或者幫助的百分比關鍵績效指標法。·正常運行時間關鍵績效指標法
正常運行時間關鍵績效指標法指標體現在一個計費周期內關鍵績效指標法服務的可用性上。在周期內,也許不可避免有一定量的關鍵績效指標法服務中斷,但這個中斷時間可以衡量SLA的履約能力和關鍵績效指標法經營業績。·平均故障間隔時間(MTBF)/平均修復時間(MTTR)關鍵績效指標法
MTBF和MTTR是指故障頻率關鍵績效指標法和修復故障關鍵績效指標法所需要時間的兩個指標。
·服務請求數量的關鍵績效指標法
這個關鍵績效指標法指標是投訴或服務請求的數量。它的增加表明某些系統或平台存在問題。收集所有的關鍵績效指標法數據,整合並制定關鍵績效指標法結果提供給業務主管,它是SLA問題的一個重要早期關鍵績效指標法預警。根據這個關鍵績效指標法提供的關鍵績效指標法基礎數據可以為業務目標改善服務。 一個也許最重要但被忽視的方面——關鍵績效指標法是與業務緊密相關的。無論會計、市場營銷、銷售等等行業,IT服務都可以管理關鍵績效指標法和提供符合行業所需的關鍵績效指標法應用系統和工具的關鍵績效指標法統計報告。但並不是每一個關鍵績效指標法指標都必不可少或可以作為測量目標。從公司到公司,甚至從項目到項目,這些關鍵績效指標法指標的作用並不相同。選擇IT的關鍵績效指標法指標首先要了解這些指標的作用。專注於關鍵績效指標法服務的業務將關注在不同負載條件下的事務或吞吐量相關的測量和活動關鍵績效指標法指標。相反,企業關注控製成本的關鍵績效指標法指標,包括計算資源的可用性指標、利用率和系統功耗。因此,隨著時間推移,根據不同區域選擇可測量並建立閾值的機制,實現與監控管理工具測量和選擇不同關鍵績效指標法指標是一個成熟IT服務的關鍵。
6. 核心IT能力評價指標甄選基本原則有哪些
(1)科學性原則
評價指標體系是理論與實際結合的產物,它必須是對客觀實際的抽象描述,企業核心IT能力涉及的因素很多,如何對其進行高度的抽象、概括,如何在抽象、概括中抓住最重要、最本質、最有代表性的東西,是設計評價體系的關鍵和難點。對客觀實際抽象描述越清楚、越簡練、越符合實際,其科學性也就越強。另外,評價的內容也要有科學的規定,每個指標的概念要科學、確切,要有精確的內涵和外延,從而滿足科學性要求。
(2)系統性原則
企業核心IT能力評價是涉及到戰略、業務流程、組織結構和文化、信息系統等要素的復雜結構系統,是所有要素組合效應的綜合反映,具有很強的系統整體性,因此在評價指標體系設置過程中,這種系統特殊性應該得到充分的反映,採取系統設計、系統評估的原則,考慮各種因素的相關性、整體性和目標性,才能全面、客觀地做出合理地評價。
(3)動態和靜態相結合的原則
企業核心IT能力具有明顯的動態性,只從靜態角度來考慮是不全面的,不能反映企業核心IT能力的發展規律。因此,評價企業核心IT能力還必須從發展變化的角度來考察,在內部因素與外部因素相互作用的運動中,揭示企業核心IT能力的運動規律,這要求在設置評價指標體系時,要有反映當前企業核心IT能力狀態的靜態指標,也要包括反映企業核心IT能力變化趨勢的動態指標。
(4)獨立性原則
企業核心IT能力評價指標要能反映出企業核心IT能力所具有的系統性,這就要求評價要素功能齊全,但是評價要素多了,指標獨立性差,相互兼容、重疊,突出不了主要矛盾,同時也給實際評價操作帶來困難,因此各個評價指標之間應該盡量避免顯見的包容關系,對隱含的相關關系在處理方法上應盡量將之弱化、消除。
(5)定性與定量相結合的原則
企業核心IT能力是一個多維的復合系統,不僅包括容易量化的因素,也涉及到許多難以量化的要素,但是其又是衡量企業核心IT能力的重要指標,必不可少,因此在指標體系的選擇和運用中,即要包括定性評價要素,也要包括定量評價要素。在評價分析時,將定性指標進行量化處理並以近似值加以反映。
(6)可操作性原則
各評價指標應該概念確切,含義清楚,信息集中,數據資料易於採集,計算范圍明確,計算方法簡便、明確、易於操作。
(7)可比性原則
運用評價指標體系進行比較分析時,常要作橫向、縱向的排序分析,為了使評價結果可比,選取的指標具有普遍的適用性,指標所包含的空間范圍、時間范圍、計算口徑、計算方法等盡量一致。
7. 如何准確估算IT項目管理的工作量
IT項目開發過程中,在面對一個業務功能時首先做的是從需求中設計表結構,然後為表結構定義各種各樣的關聯,定義完關聯後基本上在大腦內形成界面的大致樣子,然後就開始寫代碼。
從上面的過程中,可以知道IT項目管理工作量估算大致分成下面的兩個步驟:
1. 數據結構設計階段
2. 根據數據結構編寫代碼階段
接下來分析下每個估算步驟所用到的知識。
1. 在數據結構設計階段所使用的知識分為以下幾個部分
1) 資料庫設計知識
2) 業務知識
2. 在根據數據結構編寫代碼階段所使用的知識分為以下幾個部分
1) 資料庫操作知識
2) 後台編程語言知識
3) 前台編程語言知識
4) 業務知識
通過以上的分析可以看到,在第一個階段所需知識單一,更多的源自於經驗。由於所使用知識比少,當需求產生變化時,為變化所花費的時間也比較少。因此可以得出一個簡單的結論,當某一個步驟所需知識比較單一時,對該步驟的變更和編碼所需時間都比較少。
8. IT員工的考核標准
IT員工的考核
績效考核是企業績效管理體系的重要組成部分,目的是為了改進部門或員工的工作績效,考核與計劃密切相關,既可針對個人,也可針對部門或項目團隊,故有「個考」與「團考」之分。在企業的管理實務中,績效考核是公認的人力資源管理難點之一,做得好有正向作用,否則會有副作用。 中國金融大典
企業一般都根據戰略規劃,擬定每年的工作計劃,再將年度計劃分解成各部門的年度計劃。大多數情況下,業務部門的計劃定量居多,而職能管理部門的計劃以定性為主,所以較難定量地衡量工作績效。因此,成本中心性質的職能管理部門的績效考核較難做,IT部門尤其難。
眾所周知,企業長期目標需要通過每年的計劃逐年實現,信息化工作也一樣——年初定計劃、年底再考核,如果發現結果有偏差,只能來年再改善,所以考核不能光在年底做,在年度計劃執行中也要做,以便及時發現問題與偏差,進行調整或改進,以保障年度目標的實現。我認為,CIO重視結果固然沒錯,但也要重視控制過程式的考核,不管這種考核是月度考、季度考還是半年考。針對IT部門的考核體系如何建立,應權衡各方因素綜合考慮,因為考核與其他管理行為一樣,是有管理成本的。
以往,我在IT部門基本實行的是以項目管理為主線、專業IT管理為輔線的內部管理體系。年初,我將公司下達的全年信息化工作計劃分解到各項目,實行項目經理負責制;其他事務則以日常管理為主,年終考核以「團考」為主、「個考」為輔。平時自然會論月或論季定期檢查、半年做個小結,根據運作情況,對相關部門或人員「敲敲邊鼓」,必要時再適當調整計劃,但並沒有做嚴格意義上的年中考核。
今年,IT部門根據公司新規劃的需要設立了專業二級部門後,每個二級部門的定位、每個專業崗位的職責更清晰了。IT部門的工作任務就直接分解下達到各二級部門了,而公司級與跨二級部門的項目仍然實行項目制,所以試行年中考核的機會比較成熟。
其實,我之所以說IT部門的考核難做,主要是有不少難題需要解決,還要考慮如何方便操作、不至於耗費太多管理成本。比如:
考核對象
「團考」針對的是整個IT部門,還是僅僅針對二級部門;項目考不考;跨年度運作的大項目如何考:「個考」考哪些人。
考核組織與分工
由誰來考?總裁還是分管副總裁,抑或是人力資源總監牽頭的考核班子,或是IT部門管理層自己考核下屬員工。
考核內容和項目
除了計劃、任務完成情況外,是否還要對內部管理、團隊協作、員工成長及內部客戶滿意度等進行測量:「團考」與「個考」內容能一樣嗎;不同專業性質的二級部門或員工的考核內容能一樣嗎?
考核指標及評價標准
制定哪些KPI;要區分不同崗位嗎;每個KPI的評價標准如何定;如何將定性指標量化;各個指標的權重如何分配:「團考」和「個考」如何關聯。
考核方式和周期
是用表格測評,還是訪談;測評表、調查表的內容、分值如何制定;訪談提綱要統一嗎;選哪些訪談對象;被考核對象是否要先小結與自評;測評要幾個緯度;年中考核與年終考核如何區分與關聯。
考核結果及應用
考核結果如何反饋、誰來反饋;考核結果不理想,是否要調整任務或崗位;要不要和獎勵直接掛鉤;年中考核的改進建議,年終考核如何檢查。
我相信這一系列難題,專業的HR管理咨詢公司都可以提供一整套所謂解決方案,來幫助CIO解決。問題是,你「玩」得起嗎?企業願意投入咨詢費用嗎?咨詢項目做完後,能保證有效的知識轉移嗎?企業的HR部門今後能夠就此操作實施嗎?咨詢方案年年都可以照搬嗎?
今年,公司決定在我們的IT部門試行年中考核後,人力部與我們共同商討提出了比較切實可行的方案,最後由領導牽頭、兩個職能管理部門共同組成的考核組,用了並不太長的時間就完成了本次考核。這個考核方案得到了大多數員工的理解與贊同,認真參與,內部客戶也很認真對待。通過測評、內部調查、溝通和訪談等過程,人力部增進了對IT部門總體情況的了解。我也打算根據發現的一些問題,適當調整管理策略,比如授權、匯報關系、任務分工與目標界定等。此次年中考核也為年終考核打下了基礎,能夠確保IT部門全年工作計劃的全面完成。
我認為,在整個考核過程中,CIO應與人力資源部門一起根據企業的發展需要、管理水平和條件,持續地改進績效考核工作,完善IT部門的績效管理體系,以激勵員工取得更好的績效。
9. kpi如何跟it項目結合
研發崗位,首先是程序員,參考了一些文檔,暫且定義如下:崗位職責:1完成項目經理安排的開發任務;2按照詳細設計文檔編碼;3對所負責的開發模塊進行單元測試並通過;4修改測試部門反饋的缺陷;5對使用公司或部門產品/框架提出反饋意見;6定期完成工作周報,向項目經理匯報。序號 指標名稱 定義 計算公式及考核方法1 完成代碼數量 完成的代碼行數 工具統計所得的代碼行數×難度系數(難1.2,中1,易0.8)2 工作態度 是否遲到早退、工作是否認真積極 定性指標3 整體bug數量 所負責的模塊所產生的bug數量 Bug數量×嚴重程度系數4 修復缺陷引起其他缺陷的數量 修復bug後再次產生的bug數量 Bug數量×嚴重程度系數5 計劃時間與實際完成時間的偏差 項目經理計劃的完成時間與實際完成時間之間的偏差 (實際完成天數-計劃完成天數)/計劃完成天數6 提出建議和意見 對項目組或部門的實際情況在管理、技術上提出有益的建議和意見的條數