团队绩效考核的思考

0.114字数 2363阅读 1982

如果我做得很好,为什么有S、A、B、C这样的等级;如果我做得不好,为什么一定要等到考核时才反思

大部分人在工作中都会有考核,我所经历过的,有每月考核一次的,有一年考核一次的,目前是半年一次。7月初,是反思上半年工作的时候,因此我得填写下面的表格(省略部分内容,比如价值观的评分标准仅留下得0分的情况)。


绩效考核表格

在每个公司填写的表格都大同小异,请允许我先描述下填写这张表格的心情:我TM这半年都干了啥?这分打太高是不是不太好,领导会认为我自以为是?如果别人打很高自己打太低,是不是会被坑?领导给我打分太低怎么办?一定是他对我有意见?在纠结中,我填完了这张表格,发给领导,over!!!

回过头来仔细观察这张表格,我觉得至少存在以下问题:

  • 不管是自我评价还是上级评价都带有强烈的主观意愿,只要主观就会与实际产生偏差。
  • 关键绩效指标不能量化,那么评分的依据是什么?
  • 价值观评估我也就不说什么,你们高兴就好。

因此,这张表格是否可以真实的反映出一个人的表现,我是存疑的,那如何解决?

我总结的一个基本原则就是:关键绩效指标可量化,价值观相互评价

具体如何实施?

上面表格其实可以把考核指标分为3个类别:

  • A、关键绩效(业务类):产品功能、技术体系、准时完成任务、代码质量等等
  • B、关键绩效(贡献类):推动新技术落地、优化流程、开发新工具提升效率、技术分享等等
  • C、价值观

A类业绩指标考核

对于A类指标,可以通过各种项目管理工具来统一量化。比如,我们使用团队TAPD(敏捷管理工具)来管理各个迭代的开发,每个人的贡献、评估规模是否准确、是否准时完成任务都可以在上面体现,但有一个基本前提是每个需求预估的工作量需要非常准确。我们团队在实际的落地过程中,几乎每个迭代均有延误,甚至偶尔会出现一些需求因为前期协调原因导致不能如期上线。究其原因,我认为有以下几个方面。

首先,我们的产品经理前期准备工作不足,有些复杂的逻辑没能在其设计的原型上体现出来,开发接到需求时以为很简单,但实际工作量却不止如此。还有一些交互逻辑原型上没能体现,也没有详细说明,导致该需求在已经完成后才发现交互不合适,需要返工。解决这些问题,需要给我们的产品团队提出更高的要求。

其次,是各个角色的协调配合问题。一个story通常需要UI设计师、前端、后端等3个角色协同完成。而前端开发依赖UI设计和后端接口开发,往往UI设计或者后端出现延期时,前端开发就不能按照原计划日期开始或者完成,最后导致整个需求的延迟。这时就需要考虑“UI设计” 与 “前端开发”、“后台开发”的前后置关系,比如UI设计应该是前置的,需要设计师设计完成且产品体验确认OK后,才进入开发阶段,而“前端开发”和”后台开发”是并行的。

综上,整个story可以定义以下流转状态:规划中 -> UI设计中 -> 开发中 -> 已完成(产品体验) -> 测试中 -> 已完成。由于UI设计这种前置任务的延迟会导致前后端都出现等待情况,为了避免这个问题,UI设计工作一般需要提前一个迭代,就是说当前迭代内,设计师的工作是设计下迭代需求的交互和视觉稿,并且需要和产品人员共同讨论确定。如果发现UI设计没有最终确定,一般这样的需求是不建议进入迭代的。 最理想的情况是设计定稿,或者即使有些小细节未确定,评估也不影响本迭代开发进度。

解决了前面两个问题,最后就剩下开发自己预估了。我们团队在预估工作量时,往往把规模和工时两个概念混淆,但实际上它们还是有很大的不同。例如:同一个需求,资深程序员评估需要花费0.5天即可完成,普通程序员评估需要花费1.5天,这个就是工时,是一个绝对的概念;规模指需求的工作量有多大,是一个相对的概念,不会因为是资深或者是普通程序员的能力而变更其值。

我们团队目前都是按工时来预估需求的工作量,有太多的主观因素,会导致两个人的工作量在TAPD呈现出来是一样的,但实际工作量却大不相同。根据我们团队实际情况,可以设定1规模为半天的工作量,2规模为1天的工作量。在迭代会上,所有开发同学会针对某一需求进行估点,如果对规模估计有分歧,便阐述自己的理由,直到统一意见。一个迭代的总规模是固定的,估点完成后,按照优先级将超过规模的需求移到下一个迭代。最后根据预估的规模来安排时间,如果有任务延迟也一目了然。如果有紧急需求,那么需要产品和开发同学再次预估新需求的规模,然后根据优先级重新编排任务。

当团队严格按照以上流程完成每个迭代的任务时,我觉得基本上可以达到A类指标可量化的目标,对于代码质量,bug数量可以作为参考,但不应该是唯一的指标,具体问题具体分析吧。

B类业绩指标考核

对于B类指标,比如技术分享、推动新技术落地,不好量化,但仍然可以通过合理的方式来评价。比如我们团队可以统一规划未来一个时间段需要完成的技术任务(安全、监控系统、docker等)、自研工具......这些任务收集起来后统一放入需求池,然后由一个或者多个同学来认领,由认领的同学来推动实施,完成后将这个需求标记为已完成。对于这类需求的规模,团队讨论后得出一个相对值即可,当然这个需求池可以随时添加,只要团队意见统一即可。

这里提一下分享,其实目前我们不是没有时间分享,而是大家分享的积极性较低。如果要把分享纳入考核的话,给每次分享后打一个分数即可,比如每个人按照10分制打分,然后得出平均分,考核时累积一下分数即可。如果不纳入考核,每次分享后可以获得一份小礼物也是不错的。

C类指标考核

对于C类指标,肯定不应该凭自己高兴打分,我认为比较好的方式是职能团队间互相打分,比如产品和测试的同学给开发打分、技术支持给测试和产品打分、开发和测试给产品打分等等,通过这种方式来评价一个人的价值观是否更合理呢。

最后总结一下,本来就是吐槽一下目前的绩效考核方式,也许很多人也不觉得这样的方式有什么问题,但我个人仍不喜欢这样的方式,我试图寻找一些方法来解决这些不适,也希望找到更合理和客观的方式来进行考核。总之都是一家之言,欢迎大家讨论。

推荐阅读更多精彩内容