[探索]互联网技术团队的绩效管理实践4-创新线绩效管理



  创新线是一个非常宽泛的叫法,代指一切有显著创造性特征的工作序列,架构师团队就是一个典型的创新线团队。创新线的项目与项目线的项目相比,有显著的特点:难度大、风险高、周期长。也因为这些特点,创新线的绩效非常难量化。本文将以我们架构师团队的绩效管理方案实践,作些分享。

架构工作的使命?


  什么是架构师?不同的人有不同的理解,对我们这样一家互联网公司来讲架构师的工作最像医生,尤其像家庭医生。家庭医生负责为家庭成员提供全面的健康服务:体检、看病,提供保健建议,还时不时传授健康知识。
  架构师干什么呢?为系统提供全面的健康服务:通过对现有系统运行状况的了解,发起各种各样的重构提案,并根据资源状况选择性的实施已经成熟的提案。此外,架构师还负责向整个技术团队培训架构知识,通过提升开发团队的架构能力从而降低系统变更过程中的架构风险。所以架构工作的使命就是打造一个活蹦乱跳、健健康康的系统,为系统的健康长寿保驾护航。
  我们的架构团队组建起来不到一年的时间,还比较年轻。架构组成立伊始,就是奔着硬骨头去的,前前后后做了若干个大型分布式项目,这些项目对系统的稳定性(稳定性就是系统健康状况的一个直接表现,老“感冒发烧”可不行,所以它是我们灰常灰常关注的东西)起到了非常积极的作用。

  综合以上,我们对架构团队的总体要求为两个方面:
  1、行医:架构重构项目提案、实施
  2、为师:培训分享,提升整个技术团队的架构能力


创新绩效管理


  我们要想办法建立一些关联的参考指标,怎么样的指标合适呢?
  其实所谓“合适不合适”取决于两个方面,一是指标与绩效是否有足够强的关联度,即这个指标是否能够反应绩效的变化二是确认我们的诉求和期望是什么,不同的阶段有不同的诉求(追求数量?追求质量?追求效果?),满足诉求才是合适的。(我们需要的可不是看起来很美的理论模型)
  我们的架构团队成立不久,所以我们还处在比较低级的数量为主的阶段,按数量计是一个非常简陋却有效的办法,将每个事件以不同的重要性打分,再乘以数量,就可以得到一个综合的分数了。
  这些指标我们该怎么用呢?不同的架构团队面对的问题是迥异的,所以这些指标没有什么水平可比性。我们主要是看纵向时间轴,自己和自己比,只要在进步,那就是好事情——“关注成长,而不是关注成功”,或者说在目前的这个阶段,“持续成长”也就是一种“成功”了。

因此我们建立了如下指标:
1、创新提案数,即一段时间内发起了多少个创新提案。这个自然是越多越好,起码是每个架构师手上都有几个预研的方向。
2、通过评审的提案数。不能滥竽充数,还要关注提案质量,我们通过一个简单的评审决定提案的质量,这个质量当然与其价值相关。比如分布式存储系统,将图片等文件资源从数据库中搬移出来,降低了数据库的负担,同时节省了很大的数据库存储(钱哪),这样的提案一定要比一个“上传控件”要有价值。
3、提案实际应用范围。好的点子,变成好的方案,但束之高阁,没有被应用起来,那也白搭。所以这一点关注的是实际应用情况。比如分布式缓存搭好了,十几个站点,要分别应用起来,应用的越多(应用要调用项目线的资源,有大量的协调、集成工作,难度也不小),架构组的绩效肯定越好。这里有一个延伸指标,即客户满意度,谁是客户?对架构来讲项目组就是客户。架构组的产品是要让项目线应用起来的,所以我们会以客户满意度来关注架构服务的质量。
4、知识积累与分享。这个也以次数计,分为两种:一是正式的培训和活动组织,二是以Wiki等形式形成一些静态主题。

创新线绩效考核


  考核其实就是将指标分值化。跟项目线不同的是,架构组这些分是通过事件加分的方式累加出来的,而项目组是各组平行比较项目绩效分算出来的。
  架构组的绩效考核周期也是每三个月一次,季末的时候,由架构组提供一份工作报告,对上个季度的工作进行总结(绩效报告),根据这份总结,我们便可以将所有绩效事件及其得分情况汇总出来。
  同时在这份报告中,也要提供下个季度的工作内容,以便让架构工作更具计划性

  我们来看看具体的考核办法。
  考核内容有三个模块:任务完成情况(80分)、培训与分享(10分)、行为和附加贡献(10分)

一、任务完成情况(80分)

  任务完成情况由四个方面的状况进行积分考量,

1、项目的执行状态(30分)
  提案阶段计3分,评审通过8分,应用完成5分。举例:假设在某一季度中,提出了2个改进意见及解决方案,有一个项目制作了解决方案并获得评审通过,同时有2个项目在不同项目组实施,计算如下:3×2+8×1+5×2 = 24分,积满为止。
  提案其实就是一种创新,这是比较难的,所以我们分配了8分的比例,将提案转化成可以去实施的方案,这是技术含量较高的部分。至于在相关系统上进行应用就是相对常规的事情了。

2、项目的应用价值(30分)
  该部分主要是有项目评审阶段产生,项目评审通常是由相关主管领导(通常3-5人)参加,主要验证方案的正确性及可行性,在验证通过后,加入了评分原则,即由不同评委参与打分:重要紧急10分,重要不紧急6分,其它3分。积分方法同上,积满为止。
  这里的分值配比,其实就是参照经典时间管理的套路:重要和紧急两维四分法。由几个人拍脑袋决定。

3、项目实施的质量(10分)
  这个质量是指项目实施的测试质量等级,与项目线相同,A级10分,B级6分,C级3分。
  架构组的项目实施质量分与项目线的相比,所占比重要小很多,这是因为对于架构组来讲,关键是创造力(提案),至于开发过程中产生一些问题(往往很少)是可以被接受的。所以项目质量只占了10分,前面两项的内容(产生更多有价值的项目提案并实施)占了60分。

4、客户满意度(10分)
  通过满意度调查表产生分数。每个季度发放调研表格给相关服务项目组,然后取平均值。

二、培训与分享(10分)
  每组织一次正式的课程分享积4分,每产生一个主题Topic积2分。

三、行为和附加贡献(10分)
  这个10分是给领导拍脑袋的,作一些总体控制。

关联阅读


互联网技术团队的绩效管理实践1-我们是谁
互联网技术团队的绩效管理实践2-寻找绩效
互联网技术团队的绩效管理实践3-项目线绩效考核
互联网技术团队的绩效管理实践4-创新线绩效管理
互联网技术团队的绩效管理实践5-非项目绩效




 进一步交流: 扣扣,是用来扣的    

[本日志由 余波 编辑过]
上一篇: [项目管理]租房搬家也是做项目
下一篇: [资治通鉴]真的汉子
文章来自: 本站原创
引用通告: 查看所有引用 | 我要引用此文章
Tags: 绩效 创新 架构 互联网
相关日志:
评论: 0 | 引用: 0 | 查看次数: -
发表评论
昵 称:
邮 箱: 支持Gravatar头像.
网 址: 输入网址便于回访.
内 容:
验证码:
选 项:
虽然发表评论不用注册,但是为了保护您的发言权,建议您注册帐号.