绩效考核访谈

绩效考核访谈

交谈中请勿轻信汇款、中奖信息，勿轻易拨打陌生电话。

12:31:48

各位群友大家好，非常高兴今天能够和大家探讨一下研发绩效管理方面的东西。

12:31:53

先简单介绍一下我自己，我叫余波，来自5173，

12:32:48

我刚刚加入公司时，技术团队只有二三十人，随着公司的成长，目前技术团队已经扩张到两百多人。团队从小到大的过程，是不断克服各种问题的过程，在这个过程中我们积累了一点心得，今天和大家探讨的内容就是其中一部分：互联网技术团队的绩效管理。

12:33:52

今天的话题分为几个部分：

1、绩效考核的诉求

2、绩效的来源

3、互联网研发团队绩效方案设计

4、考核结果的应用

5、集中问答

12:34:24

在我分享的过程中，各位有可能会产生一些问题，为了保证整个分享的流畅，建议各位先找个地方记下来，我们在后面时间来集中互动，谢谢各位。

12:34:50

那我们开始吧，

12:35:07

在做绩效考核之前，我们要问自己一个问题：我们做绩效考核是为了什么呢?

12:35:35

我的答案是：为了识别团队的产能分布，以便在分布的基础上实施针对性的管理策略。

12:36:00

假如我们是在打仗的话，那么这个绩效考核就是为了收集一线情报，有了情报的支持，我们就会比较有方向，而不是凭直觉、拍脑袋。

12:36:31

所以，如果一个绩效考核办法，不能把杰出的10%和需改进的5%分辨出来，无论方案本身多么豪华，也是失败的。

12:36:47

这两端的部分，往往是我们管理工作的重点。

12:37:22

这10%的优秀分子，是火车头，是驱动力，他们能够基于现状，创造解决问题的方法，然后让85%的人使用它们的方法来产生更好的绩效。这10%的人，某种程度上决定了团队的未来。

12:37:56

后面5%的人，往往是产能的黑洞，这些人占用资源不说，往往还是抱怨、委屈和无能之集大成者，这些人如同病毒，自己所产生的价值有限不说，还有可能严重干扰别人，因为往往那些怪怪的味道，都是从这些人身上散发出来的。

12:39:40

当然被考核者，往往是比较不希望自己被揪出来的放在阳光下烤的。在我们制定绩效考核方案的过程中，曾经多次调研走访一线工程师，他们有一个普遍的声音，就是希望最终的结果是一片和-谐，要么大家都是50分，要么大家都是90分。

12:40:27

那么，如果真按照他们的意愿来操作，我敢打赌，我们将慢慢失去那杰出的10%，

然后我们怎么可能在杰出人才越来越少的情况下攻城略地呢?

12:40:59

说到这里，我们还要认识到一个事实，平凡的大多数(85%?)是中坚力量，他们有稳定的绩效产出，而且不容易跳槽，容易跳槽的是那10%的人，还有5%容易被跳槽的人。

12:41:40

接下来，我们谈谈绩效的来源。

12:42:22

有一个基本观点，

团队很小的时候靠的是个人能力，种子选手，以一挡十那种;

当团队达到一定规模的时候，种子选手的作用已经不是十分明显，中竖力量是“平庸的大多数”，这个时候流程的作用会非常明显，用流程来产生规模效应，同时用流程来规避对种子选手的过分依赖，降低绩效风险(种子选人是最不稳定的人群);

12:43:26

以上三个阶段，是一种大概的划分，其实在任何一个规模下，三个维度都是互相补充的：人、流程、文化。所以，我们所有的努力其实都是基于这三个方面的认知和努力。

12:44:03

人，流程和文化，我们逐个BalaBala。。。。。

12:44:40

首先人的方面，个人能力很容易理解，当然是越强越好，当然要在人力成本的限制条件下。除此此外，还有一个东西很重要，那就是合适的组织结构(单元)，我们每个项目组有一名项目经理带三四名工程师，我们发现这是一个非常精巧的配比，组员的效率容易挖掘，管理成本比较低，协同高效。

12:45:24

所以，后期虽然整个团队规模不断变大，但也都是基于这样的项目单元，通过细胞分-裂的方式来扩展的。这种在业务推动下的自然分-裂是非常经济和现实的。

12:45:59

基于项目类型的同质分-裂，分-裂出来的项目组的工作内容(项目类型)大同小异。与此同时，随着团队规模的不断扩大，分工越来越精细，还会有新的工种出现，新工种会专注于某一细分基础模块的工作，这是一种异质分-裂，典型的新工种是架构师。

12:46:46

团队规模很小的时候，设置专职架构师是件满奢侈的事情，项目经理往往是以一当十的用的，如果有一件事情不知道该给谁做，通常都是由项目经理兼的。

12:47:14

当系统规模越来越大的时候，着眼于全局的架构设计，再由项目经理兼做几乎是不可能胜任的，这个时候就必须依赖专职的架构人才，成立架构师团队。

12:47:43

架构师团队和项目团队的关注点是有很大不同的，前者我们称为创新线，更多关注创造力，后者称为项目线，关注项目吞吐。针对这两条线，我们设置不同的绩效管理办法，用不同的指标进行绩效跟踪。

12:48:04

组织结构问题解决了，我们相当于把一台“拖拉机”变成了“法拉利”。

12:48:30

正当我们踌躇满志准备上路时，我们发现摆在面前的是一条泥泞的小路，请问法拉利能够跑过原来的拖拉机吗?

12:49:04

即使能够跑过，我想也不敢跑太快吧，一不小心底盘就报销了，舍不得啊。

12:49:24

为了让法拉利们能够跑得快一点，我们需要一条高速公路。在高速公路上，我们设定规则，要求速度达到多少才能够上去，像拖拉机这种压根就不让上了，从而保证车流吞吐。这条高速公路就是流程。当我们已经不是三五个人加几条枪的时候，流程对绩效的影响是巨大的(因为流程，更多是为那85%服务的)。

12:50:00

流程的设计，最怕生搬硬套，两个关键点

12:50:22

一是注意各协作团队的综合能力配比，关注瓶颈节点。

比如收费站，就是高速公路的一个瓶颈节点，还有容易出车祸的路段也是瓶颈节点，直接影响车流吞吐(排队啊)。

12:50:54

具体到我们的工作现场也有类似的典型瓶颈，比如，当QC资源不足时，项目质量很大程度上要依赖开发团队自己，这个时候再强调什么理论上的职责分工就是不切实际的，这个时候要通过诸如代码走查制度、加强单元测试来弥补，这其实是一种典型的用开发换测试的做法。目的是打掉整个流程的瓶颈。

12:51:19

二是控制流程本身的成本，够用就好。

12:51:36

开发资源不足时，还一定要出详细的设计文档;QC资源不足时，还要求一定要有完整的测试用例，这些都是学院派干的事情。

12:52:01

靠谱的流程都是经过裁剪的，以牺牲某种特性来换取更大的好处，所谓两权相害取其轻。否则，我们付出的流程成本基本上是打了水漂，收不回来了。

12:52:22

更重要的是，流程成本不光是指我们遵循这个流程所花费的时间，还有繁琐的流程所吃掉的工作热情。

12:53:03

我依然记得在BenQ时，当时的副总张安佐有一句话：每天早上眼睛一睁开，就能够一跃而起的人是最幸福的。

12:53:56

而之于我们，如果一份工作能够让我们一跃而起，那我们怎么可能没有效率?一跃而起是源于我们内心对于团队及团队所做的事情的深深的认同，这种认同是一种人性文化的深耕。

12:54:18

接下来，我们谈谈，我们的具体方案设计。

12:54:34

先要介绍一下技术团队的生存背景，

12:54:49

对于一家电子商务公司来说，其真正的产品是“交易服务”，

交易服务由两方面构成，一个是产品和技术提供的在线交易平台(生产工具)，

另外一个是客服提供的过程服务(生产)，

而负责将“交易服务”卖出去的责任更多的落在营销(市场、运营)。

12:55:20

持续、快速的交付对用户有价值的交易服务，是电子商务公司的核心竞争力。

12:55:33

对于技术团队来说，持续、快速的交付高质量的平台特性，是技术团队的生存根本。

12:56:02

鉴于这样的特点，我们的项目特点是追求短平快，百分之七八十的项目的实施周期都在一周以内，项目规模很小。偶尔有大的项目，我们也是想尽办法把它分解成一二三期，从而降低项目的实施周期。这样做的好处是显而易见的，让一个特性最快与用户见面，是验证它是否有效的最好办法。

12:56:37

结合大部分项目周期都在一周以内的特点，我们把项目绩效的度量周期定为一个月，每个月会进行一次绩效回顾，让各项目组总结调整。注意，我们只是把月度作为度量统计的单位，绩效考核的周期还是以季度为周期的。月度的度量，决定项目奖金的分配。而季度绩效考核，影响的是季度奖。

12:57:03

为什么不选择月考呢?有两个原因。

12:57:22

首先如果每个月考一遍，管理成本太高了;其次，绩效考核的目的就是在对产能分布进行识别，我们还有20%的跨月项目的，用季度这样的宽度，可以更好的覆盖，让各个项目组之间的比对数据更具参考价值。

12:58:00

在上述原则的指导下，我们接下来谈谈具体绩效考核方案的设计

12:58:36

技术团队绩效考核方案的制定，整体遵守几个原则

1、使用项目绩效分，来衡量项目业绩

2、使用非项目绩效分(事件绩效分)，来衡量日常工作之外的创新、拓展贡献

3、对于同一类型岗位，使用统一考核模型(权重和算法可调)

4、对于差异性较大的小工种，使用个性考核办法

5、管理职能与执行职能考核分离

12:59:31

根据以上原则，我们将考核方案分为四条线：项目线、创新线、管理线、标准线

12:59:41

同时，整个绩效考核的维度框架，统一为：主营业绩80%、事件绩效15%、综合评定5%

13:00:03

主营业绩，是指你的岗位职责要求你承担的责任表现

13:00:18

什么是非项目绩效呢?顾名思义，就是项目之外的贡献产生的绩效，这个名字是我们一开始时候在项目部推出来的，现在已经在整个技术部门应用，所以现在叫称作“事件绩效”会更贴切些。

13:00:37

作为技术部门，项目一直是我们的主营内容，我们在制定KPI时，也是重点关注这个部分，比如通过人均项目绩效分来衡量项目产能。

13:00:52

然而日常工作中还有很多贡献不在KPI中，比如内部讲师作培训、比如招聘面试等等。这部分没在KPI上反应出来的贡献，显然不是无关紧要的。

13:01:11

此外，这些事情还与员工的工作热情有很大的关联：人们总是对做擅长的事情充满热情，比如擅长演讲的人乐意去作培训，擅长沟通的人乐意去面谈，对代码有洁癖的人乐意去做Code Review等等，如果这些贡献不能够在绩效上反应出来，做和不做没什么区别，谁还愿意做下去呢，热情在萎缩的同时，整个团队的能量也在萎缩。

13:01:41

除此之外，当团队越来越大，面对的事情也会越来越复杂，一线的情报传递上来往往会延时或失真，管理工作也因此往往会很被动，这个时候就需要激发一线员工的创造力和热情，让他们去开动脑筋，他们想出来的事情往往更加切合实际，而我们从中识别出“重要”的部分加以大力推动，岂不快哉。这样一来，我们就有了一个巨大的脑库，有源源不断的点子来推动团队的发展。

13:02:18

事件绩效的量化，我们也有一套办法，基本思路就是按照事件的价值大小，分级给一定的分值，然后又分解成基础分和执行效果分，所以会有一个换算公式：绩效分=基础分 + 价值基数 * 目标效果系数

13:02:37

综合评定，其实就是给管理上级拍脑袋的，大家可以注意到，这个比例非常小，这个靠感觉的不敢给的很大。当然，在团队很小的时候，我们也通常是别无选择的拍脑袋，那个时候是靠“英雄人物”推动绩效的。但现在显然不行了。

13:03:04

我们前面提到几条考核线，每一个考核维度在不同绩效线，也有不同的含义，

13:03:31

比如项目线主营业绩就是指项目贡献度，使用项目绩效分来衡量，这个绩效分由多个因素构成，比如编码工作量、比如协调工作量等等。我们有一个评审委员会，专门负责分配绩效初始分，每一个项目都会有一个初始分，后面还会根据项目的测试质量等级、进度执行情况对分值进行加减。具体的评分细则我就不展开了。

13:03:47

创新线的主营业绩分解成：发起多少提案，有多少提案被评审通过(可靠性和价值评估)，有多少提案被应用推广。

13:04:06

管理线，是指部门经理以上，主营业绩是指：部门人均绩效指标、提前商定的关键目标

13:04:17

标准线，主要是给一些助理类的职位的，不展开。

13:04:34

最后，我们要谈最后一个点，即考核结果的应用。

13:04:50

这方面不想讲太多，坚持一个原则：一定要认真的做绩效反馈。即直接上级，要和下属进行绩效面谈，告诉下属，哪里做的好，哪里做的不够，如果想获得更好的绩效，未来的努力方向是什么，以及可以利用的资源有哪些。

13:05:14

这方面虽然说的内容不多，但非常重要。正如我们一开始说的，绩效考核的目的是识别产能分布，然后采取相应的管理动作，那么绩效反馈便是其中一个管理动作，一切的管理动作都是围绕改善绩效展开的，而最有效的，往往是面对面的谈话辅导。

13:05:30

当然，谈话之后，还会有绩效跟进工作，这是一个持续改进的循环。

13:06:18

我今天分享的内容，我写过一个系列的博客，

http://cankao.gcw818.com

有更加细节在上面，有兴趣可以去我的博客浏览下

或想进一步交流，可以加我MSN&http://cankao.gcw818.com，还有QQ：942365

13:06:33

好了，今天时间比较有限，分享的比较快，大家一定会有很多问题。

现在请各位提问。

注：查看本文相关详情请搜索进入安徽人事资料网然后站内搜索绩效考核访谈。

【绩效考核访谈】相关文章：

访谈节目开场白04-06

学生家访谈心心得05-05

职业生涯人物访谈要点03-30

人物访谈节目制作合同03-19

员工绩效考核12-19

管理的绩效考核04-20

绩效考核总结03-23

绩效考核方案11-10

IT公司绩效考核07-14

绩效考核细则07-27