IT部门如何制定“靠谱”的考核策略，听听这些CIO们的一手经验
如何明确IT任职资格标准、制定更合理晋升机制，实现能者多劳多得，同时杜绝慵懒懈怠?管理岗位合技术岗位是否分开?本文一起来听听这些CIO们的一手经验。
作者：景保玉来源：78CIO|2017-09-27 14:08
团队是体现企业战斗力的最小组织单元，很多情况下，我们张口闭口谈团队协作精神。但是，每个团队成员工作时的状态和心态截然不同，在一个团队中吃“大锅饭”难免有人懈怠，让其他团队成员心生不平。
如何明确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，一方面是建立新的业务支撑能力;另一方面是保障这个能力的持续、稳定运行。个人感觉两方面都是需要技术高手。
@映客直播李东林：提供一些考核指标做参考。
指标是什么?哪些指标值得关注?指标的优先级?如何设计指标合理并符合公司要求?
- 基于业务的指标设定
- 指标涵盖的范围：可用性、容量、频率(天、周、月)等
- 指标的承担者和检查者
- 指标的横向和纵向的回顾对比
- 指标的告警值设定
- 指标的数据来源
- 指标由哪些数据构成(列/字段，例：月份、服务名称、时间类型、响应时间等)
报表是什么?哪些信息应该写入报表?这些信息能否反应指标是否达成?优先级?采集方式是什么?
KPI是什么?
指标与报表的对应关系
面向服务
面向对象：IT架构支持。
- 系统类：性能(cpu、内存、IO负载)、状态(服务运行市场、磁盘状态)、故障(故障发生记录、故障处理记录、优化建议)
- 网络类
- 安全类
- 软件类
- 数据库
- 存储类
- 动力类
面向流程
- 服务台管理
- 事件管理(一线解决率、二线响应时间、三线响应时间、时间平均解决时长)
- 故障管理
- 请求管理
- 访问管理
面向人员
- 员工流失率
- 服务满意度
面向财务
- 成本分析
- 预算分析
@万合天宜新媒体影视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。