IT部门如何制定“靠谱”的考核策略,听听这些CIO们的一手经验

CIOAge
如何明确IT任职资格标准、制定更合理晋升机制,实现能者多劳多得,同时杜绝慵懒懈怠?管理岗位合技术岗位是否分开?本文一起来听听这些CIO们的一手经验。

团队是体现企业战斗力的最小组织单元,很多情况下,我们张口闭口谈团队协作精神。但是,每个团队成员工作时的状态和心态截然不同,在一个团队中吃“大锅饭”难免有人懈怠,让其他团队成员心生不平。

[[205079]]

如何明确IT任职资格标准、制定更合理晋升机制,实现能者多劳多得,同时杜绝慵懒懈怠?管理岗位合技术岗位是否分开?

@达威股份信息化负责人李旭:晋升可以分开,如果公司不大,都是合在一起的。

@天地华宇CTO杨来旺:我觉得大于100的IT团队就有必要搞清晰的任职资格标准和考核体系了。我正在修订我这边的标准,所以想和大家一起探讨一下。

@湖南旺府投资控股集团CIO曾庆林:团队大了就可以搞,小团队没必要。这个体系建立与维系,需要耗费很多的人力物力,至少要分成三个以上的团队,每个团队达到25人以上才有意义。

@TCL集团CIO高建雄:搞管理的得懂技术,搞技术的得懂管理。

@天地华宇CTO杨来旺:给每个人明确现在能达到什么,通过如何努力能达到更高一个级别,每个级别对应的待遇是什么样的。大家觉得多少IT人员是大团队和小团队的分界线?100? 200?300?

@北京李先生加州牛肉面大王IT主管董健:如果长期看,小团队还是也应该规划的,一个人不可能在一个位置呆一辈子,像我们公司IT部门,最短的都呆了5年以上了,一个萝卜一个坑。

@天地华宇CTO杨来旺:我们现在200多人,所以虽然确实会耗费人力、物力。但是,无论向上,还是向下,能达到公平,公正,公开,透明。很多公司没有把 T和M系列分开,所以为了涨工资,只能先给个经理、高级经理,但是实际上这个人不一定适合管理,甚至下面可能都没有兵。

@北京能源集团多乐港IT负责人梁新刚:我曾在国家电网呆过,总部信通部,直属有信通运维公司负责运维,部门下设安全、建设、运维三个处。另外,国网还有一个运营监控中心,负责数据展示和数据质量。我一直认为这样的架构是完美的,但是一般公司用不起。

@TCL集团CIO高建雄:什么叫公平?按能力?

@达威股份信息化负责人李旭:框架对大多数公司来说太大了,但是普通、优秀、卓越不好区分。

@天地华宇CTO杨来旺:按结果考核,比如我们定了一个项目,如期保质保量完成,这一项就考核通过。赞同 @梁新刚的观点,可能要把握一个度,客观+主观。

@北京能源集团多乐港IT负责人梁新刚:系统建设不会一直有任务,日常运维可以外包,建议把人员重点放在安全和数据分析上。

@TCL集团CIO高建雄:我觉得工资还是要和级别挂钩的,你能力再强,不升个经理级别(或技术经理)的话,你的贡献也达不到经理级别,当然薪水也就不该到经理级别。老实说,一般的内部IT,技术牛与很牛差距不是那么大,真正自己做产品的单说。

@湖南旺府投资控股集团CIO曾庆林:要分管理与技术两条线吧,对于不想管人的,但技术够牛,也是可以拿高薪的。

@映客直播李东林:「Jason Gao: 我觉得工资还是要和级别挂钩的,你能力再强,不升个经理级别(或技术经理)的话,你的贡献也达不到经理级别,当然薪水也就不该到经理级别。」这不适用于技术大牛吧,有一种情况,有人技术很强,但完全不会管理,但是作为技术攻坚,能力突出。

@万合天宜新媒体影视CIO郝英杰:其实设计院的总工比一般的小经理工资高多了。

@北京能源集团多乐港IT负责人梁新刚:内部IT不需要技术太强,要了解公司业务需要什么样的技术。

@大爱城地产信息部高级经理李胜军:管理与技术两条线更合理。

@北京行知探索文化发展集团孙波:这个话题非常好,我最近在听绩效管理的课,也在思考如何给团队加加油。

@万合天宜新媒体影视CIO郝英杰:就是晋升途径的问题,一条是行政线,一条是技术线。

@以纯集团IT部杨样贤:不喜欢管理的技术大牛可以给他另外一些职称,达到经理或副经理的级别,拿这种级别的工资。

@大爱城地产信息部高级经理李胜军:互联网公司可能需要的技术大牛多,需要不断创新技术,一般企业信息化的IT团队对技术大牛的需求不多,多为IT应用。

@映客直播李东林:技术层面可以简单分为三个层次:1、熟练使用现成产品和工具;2、在现有产品和工具的基础上,可通过产品自身的命令或自己写,变成脚本,实现部分自动化或半自动化;3、具备较强的开发能力,可根据需求灵活的实现不同的技术方案。

@湖南旺府投资控股集团CIO曾庆林:我这边就有一个专门做技术研究的,他的工资不按薪资结构体系来。

@TCL集团CIO高建雄:还是要区分内部IT还是产品研发。

@大爱城地产信息部高级经理李胜军:对,内部IT和产品研发区别对待。引入ITIL服务体系和系统,提升IT服务与运维效率,自然人的效率就提升了。

@映客直播李东林:恩,产品研发,这属于贴近业务的,我刚才说的主要还是站在运维和IT这个方面,主要多以提升效率、降低人力、降低错误率的角度出发。另外,关于是否要分技术线和管理线,看公司内部实际情况吧。

有些公司是分的,技术线就是走技术大牛路线,攻坚某一个技术防线,管理线多考察沟通、协调、项目管理、情商等。另外一种是部分,都是技术线,要求技术线的领导任职资格是技术必须强,必须能知道手下日常工作,管理方面不做明细的要求。

@北京能源集团多乐港IT负责人梁新刚:运维也不需要技术太强,因为他工作的面太窄,不需要走大牛路线。真正的大牛肯定不会满足一直从事运维工作,运维要的是安全稳定不出差。

@大爱城地产信息部高级经理李胜军:技术大拿搞研发对路,别的不对路。由技术研发的部门储备技术大牛,IT应用与运维部门更多侧重管理、协调与技术支持,一般管理岗和工程师岗就够了。

@映客直播李东林:每个领域如果研究很深入的话,都可以成为技术大牛,不论是开发、运维、还是IT,主要看你使用的是什么类型的技术,通常能有机会处理一些高并发、大集群、上P级数据,有实操经验,基本在中型公司都能当个小头。

IT跟产品研发不太一样的地方,咱们除了跟机器打交道以外,有大量时间都要跟人打交道,所以对沟通、协调能力要求会比其他技术岗要高。

@四维图新IT总监邓天辉:运维和IT有区别吗?

@映客直播李东林:运维更多是偏业务线上服务,IT更多偏企业内部。

@昆仑保险CTO崔占东:企业内部的IT,一方面是建立新的业务支撑能力;另一方面是保障这个能力的持续、稳定运行。个人感觉两方面都是需要技术高手。

@映客直播李东林:提供一些考核指标做参考。

指标是什么?哪些指标值得关注?指标的优先级?如何设计指标合理并符合公司要求?

  1. 基于业务的指标设定
  2. 指标涵盖的范围:可用性、容量、频率(天、周、月)等
  3. 指标的承担者和检查者
  4. 指标的横向和纵向的回顾对比
  5. 指标的告警值设定
  6. 指标的数据来源
  7. 指标由哪些数据构成(列/字段,例:月份、服务名称、时间类型、响应时间等)

报表是什么?哪些信息应该写入报表?这些信息能否反应指标是否达成?优先级?采集方式是什么?

KPI是什么?

指标与报表的对应关系

面向服务

面向对象:IT架构支持。

  1. 系统类:性能(cpu、内存、IO负载)、状态(服务运行市场、磁盘状态)、故障(故障发生记录、故障处理记录、优化建议)
  2. 网络类
  3. 安全类
  4. 软件类
  5. 数据库
  6. 存储类
  7. 动力类

面向流程

  1. 服务台管理
  2. 事件管理(一线解决率、二线响应时间、三线响应时间、时间平均解决时长)
  3. 故障管理
  4. 请求管理
  5. 访问管理

面向人员

  1. 员工流失率
  2. 服务满意度

面向财务

  1. 成本分析
  2. 预算分析

@万合天宜新媒体影视CIO郝英杰:KPI也有局限性的,现在的大企业开始做模糊KPI了(名词记不住了,就是这个意思)。现在的企业变化太快了,年初的KPI目标年底可能已经都变了。

@映客直播李东林:所有的内容肯定无法做到100%量化和客观,但尽力往这个方向靠,相对来说,评价标准比较明确,数据来源客观,如果对向下的话,员工对考核结果应该不会有太大异议。

@达威股份信息化负责人李旭:你的KIP太复杂了,落不了地,最近我们也在做绩效管理。

@映客直播李东林:这个涉及的范围比较广,根据实际的关注点调整就可以了。基于考核结果,再制定职级体系和晋升通道。每个公司的的关注点不太一样,有些公司重IT的服务意识、态度、效率,有些公司重应用服务的稳定性和可用性,有些比较重数据分析和收集,看实际需要来配置KPI吧。

@天地华宇CTO杨来旺:考核是把双刃剑,用好了避免管理上的漏洞,让团队螺旋式向上成长。用不好可能会影响大家的积极性,抹杀大家创造性。所以,我现在也是加了主观,客观的通过系统数据分析(UV、页面响应等),主观的比如让客服部门给产品经理打分,对于产品上线的功能是否真正满足了客户的需求评分(一般满意、满意、超预期等)。

@北京能源集团多乐港IT负责人梁新刚:绩效考核针对销售非常有效,因为销售业绩是可以明确量化的,针对其他专业,需要慎重使用。IT服务稳定为先,他不干活但是系统运行稳定绩效怎么定?

@万合天宜新媒体影视CIO郝英杰:看一个企业真正在做绩效的关键点在员工面谈阶段(有这个过程就是真的再做绩效,没有就是在扣钱)。绩效考核的办法有很多种,KPI只是其中的一个办法,我更推荐 360度考核。不管用哪种方法都是各有利弊的,如果说公平的话,360是最好的,但是也最费人力物力。

@以纯集团IT部杨样贤:绩效考核关键还是在于执行,对员工来说是否公平很重要。搞得太复杂,执行起来费时费力,不一定会有好效果,抓住几个关键点就行。

@天地华宇CTO杨来旺:可能性质不同,我这边80%是产品和开发人员。对于DBA和运维只考核两点:1、系统可用率(事故时间/总时长);2、任务处理及时性(比如开发提出的请求,24小时是否可以完成)。

@北京行知探索文化发展集团孙波:能定量定性的,用KPI。对于敏捷交付的,不容易定性、定量的用OKR。

责任编辑:未丽燕 来源: 78CIO
相关推荐

2013-09-17 11:07:22

2022-11-22 11:09:52

CIOIT部门

2018-05-08 13:11:39

智能制造

2014-07-29 09:33:17

公司邮箱

2019-10-24 15:23:04

SQL优化数据库

2023-08-24 21:49:54

人工智能高端算法工程师

2019-02-20 13:08:48

CIOIT转型

2013-07-23 09:07:57

BYOD策略步骤

2014-08-19 10:42:59

程序员

2012-10-22 11:14:05

SDNOpenFlow网络管理

2013-04-17 10:30:07

GlassGoogle

2021-03-08 10:27:42

CIO销售策略IBM

2020-11-02 00:32:34

技术策略CIO首席信息官

2020-09-02 10:57:23

物联网扩展策略IOT

2014-03-31 09:59:03

2015-05-06 14:36:56

CIO云计算风险云迁移

2017-07-04 09:49:36

ActivityAndroidLife场景

2010-09-09 15:21:17

丁磊

2020-02-10 13:22:35

编程语言机器学习Python

2012-04-23 03:55:43

QCon

51CTO技术栈公众号