voshk

培训-绩效管理

2016/12/24 Share

完整的系统

构件 :

目标/计划

辅导/教练

评价/检查

回报/反馈

流程

组织目标分解(工作单元职责)

绩效计划

  1. 活动:与员工一起确定绩效目标,发展目标,行动计划
  2. 开始时间

按时完成 个方面表现良好 不用处理 继续循环 而不是要给鼓励之类的

不然会形成暗示,做什么东西就求什么回报

连续几个循环 而不要一个循环

增加沟通成本

角色

高层管理者:目标设定者,主导者,决策者

部门管理者:标准制定者,辅导者,记录者,评估者,建议者(有刻度,是3还是4 选择题 框在筐子里)

心里要有底,知道手底下人每个人几斤几两

事后做决定: 啪一大嘴巴子 怎么不穿毛衣 不吃饭。。

个人: 参与者,被考核者

绩效考核的类型和思想基础

发展历程:

  • 以事为中心(某件事,没有周期而言)

  • 目标管理MBO manegement by object
    以人为本 四个共:

共同目标

信息共享

好坏共同担当

  • 关键绩效指标kpi smart原则 要分的细
  • 平衡记分卡(bsc)
    以总体战略为核心,分层次,分部门不同设置

绩效考核的意义

绩效考核是动作,结果是奖惩依据

考核的必要性:“管理应用” “开发应用”

不仅是针对员工,更重要的是针对管理者

因为:

  • 考核是直线管理者不可推卸的责任,因为员工的绩效就是他自己的绩效
  • 认真组织可哦呵不仅体现了管理者对员工,自身和组织的负责精神,而且反映了管理者自己的工作态度

所以:

  • 各级管理者要作为业绩改善和提高的有效推动者,而不仅仅是员工业绩和能力的评定者!

原则

实用性原则

管理水平,行业精英特别点,适合员工的素质特点

客观公平原则

以客观事实为依据,避免人为因素是绩效评价结果与员工的实际工作绩效有较大的差距,影响绩效评价结果的可信度

公开原则

对评价的标准,程序,方法及时间的选择公开宣布,使员工积极参与到考评中来。
同时考评的记过应该是公开的,有利于员工的横向和纵向的比较,明确自己的位置,自己可以确定今后的努力方向。 (避免小团队私底下讨论)

差别

考核结果要有差别,要有优良中差,要满足正态分布规律

一致性

绩效开个的主体和考核的对象必须对考核的要求和考核的结果达成一致意见,顺利推行的保证

奖惩挂钩激励为主的原则

与奖惩挂钩,才不会流于形式。出发点应该是正面的,激励鼓励为主,而不是处罚为主

动态原则

不是一成不变的,根据考核达成情况以及内外部条件的变化而变化

相对稳定原则

一定时间内必须保持稳定,不应该随便修改,以保证考核的严肃性和权威性

保持考核框架和数据源相对稳定

目标管理法(MBO)

目标为导向,成果为标准

可量化,数据化

例:企业目标/愿景-年度人才引进战略-年度招聘计划-季度-当月-月底入职3个php工程师

关键绩效指标 KPI(key performance Indicator)

总体业绩的一些关键醒指标

SMART

Specific 明确的具体的

Measurebale 可衡量的

Achievable 可达成的

Relevant 与目标相关的

Time-bounded 有达成期限的

例:当月招聘目标-初试人员数量,重点岗位到岗率

平衡计分卡(BSC, The Balance Scorecard)

从财务/客户/内部运营/学习与成长

使命与战略目标:财务,内部流程,顾客,学习与成长

客户投诉:先跪舔(道歉,让他爽)

内部流程:分析原因,给予解决问题的期限

团队:学习与成长

例:

围绕当月招聘计划

财务:招聘成本

客户:招聘渠道/供应商管理

内部运营:招聘入职各类报表

学习成长:招聘工具(面试题库,筛选工具)

小结

  • 人性假设与管理者职能
  • 绩效管理与绩效考核的关系
  • 绩效考核的类型及指标分解

不要考核态度(模棱两可,主观想法

考核行为,要把行为量化成 响应时间

可考核的客观指标(对比的/成长的)

整体趋势要可衡量的

最多5个,3项大于60%

旧的考核指标

  1. 开发进度。(衡量效率以及对进度的把控),占比25%

  2. Bug统计。分为开发阶段Bug数量(成反比)以及线上Bug修复(与数量成正比并结合Bug等级及修复难度),共占比40%。

  3. 代码质量(组内进行Code Review,进行代码质量评审)。占比15%。

  4. 面对紧急任务或突发情况的处理能力(临时插进来的需求等难度或者耗时评估),占比10%。

  5. 对外协调沟通表达能力(主要涉及开发过程中与设计/产品/服务器端小伙伴打交道),占比10%。

新的考核指标

  1. 排期内任务达成率:

    • 衡量效率,对进度的把控 (30%)

      1. 100% - 30%
      2. 95% - 20%
      3. 90% - 10%
      4. <90% - 0
    • 代码质量:bug数(15%), 代码复用性/可扩展性(15%) (什么是bug定义清楚,影响功能正常使用的才是bug,体验/功能优化 不是)

      1. < 10 - 15%
      2. 10 < 20 - 10%
      3. 20 < 30 - 5%
      4. 30 - 0

  1. 跨部门沟通合作

    • 产品数据(页面留存率等数据统计)/用户满意度(投诉率) (20%)
    • 面对紧急任务或突发情况的响应时间(临时插进来的需求等难度或者耗时评估) (10%)
  2. 团队集体行为完成度 (10%)

    • 固定任务(考勤/周报等按时完成)

      1. 全勤/周报/评审会按时参加 10%
      2. 迟到/早退1次,周报/评审会没按时1次 5%
      3. 迟到/早退>1次,周报/评审会没按时>1次 0
    • 自我成长(自我提升):没基础数据,暂时无法提供具体衡量指标