《企业团队建设互联网技术团队的绩效管理互联网大讲堂某某某1222》由会员分享，可在线阅读，更多相关《企业团队建设互联网技术团队的绩效管理互联网大讲堂某某某1222（60页珍藏版）》请在金锄头文库上搜索。
1、互联网技术团队的绩效管理-互联网大讲堂-201012222010年12月22日15:06主讲：余波 博客地址时间：2010-12-22 15：00至17：00地点：互联网大讲堂群号：43046591余波： 各位群友大家好，非常高兴今天能够和大家探讨一下研发绩效管理方面的东西。先简单介绍一下我自己，我叫余波，来自5173，5173是一家电子商务公司，提供网游虚拟物品的交易服务，可以简单理解成垂直领域的淘宝，在虚拟物品交易这个细分市场，我们一直是领跑者。目前平台上每年产生的交易有数十亿，交易平台的注册用户和日均PV都是千万级。我刚刚加入公司时，技术团队只有二三十人，随着公司的成长，目前技术团队已经
2、扩张到两百多人。团队从小到大的过程，是不断克服各种问题的过程，在这个过程中我们积累了一点心得，今天和大家探讨的内容就是其中一部分：互联网技术团队的绩效管理。 今天的话题分为几个部分： 1、绩效考核的诉求 2、绩效的来源 3、互联网研发团队绩效方案设计 4、考核结果的应用 5、集中问答绩效考核的诉求： 在做绩效考核之前，我们要问自己一个问题：我们做绩效考核是为了什么呢？ 我的答案是为了识别团队的产能分布，以便在分布的基础上实施针对性的管理策略。假如我们是在打仗的话，那么这个绩效考核就是为了收集一线情报，有了情报的支持，我们就会比较有方向，而不是凭直觉、拍脑袋。所以，如果一个绩效考核办法，不能把杰
3、出的10和需改进的5分辨出来，无论方案本身多么豪华，也是失败的。这两端的部分，往往是我们管理工作的重点，10%的优秀分子，是火车头，是驱动力，他们能够基于现状，创造解决问题的方法，然后让85%的人使用它们的方法来产生更好的绩效，这10%的人，某种程度上决定了团队的未来；而后面5%的人，往往是产能的黑洞，这些人占用资源不说，往往还是抱怨、委屈和无能之集大成者，这些人如同病毒，自己所产生的价值有限不说，还有可能严重干扰别人，往往团队中那些怪怪的味道，都是从这些人身上散发出来的。所以，这也是管理者需要分配多一点精力的人群，当然，如果企业要裁员，通常也是把名额给这些人。只是在我的相像中，另外5%是可以
4、通过管理手段改善的，这是管理者的责任，当然也是我个人的一个感性假设，当然被考核者，往往是比较不希望自己被揪出来的放在太阳下烤的，在我们制定绩效考核方案的过程中，曾经多次调研走访一线工程师，他们有一个普遍的声音，就是希望最终的结果是一片和谐，要么大家都是50分，要么大家都是90分，但如果真按照他们的意愿来操作，我敢打赌，我们将慢慢失去那杰出的10%，然后，我们怎么可能在杰出人才越来越少的情况下攻城略地呢？说到这里，我们还要认识到一个事实：平凡的大多数（85%？）是中坚力量，他们有稳定的绩效产出，而且不容易跳槽，容易跳槽的是那10%的人，还有5%容易“被跳槽”的人，为什么需要绩效考核我们就说到这。
5、绩效的来源： 团队很小的时候靠的是个人能力，种子选手，以一挡十那种，当团队达到一定规模的时候，种子选手的作用已经不是十分明显，中竖力量是“平庸的大多数”，这个时候流程的作用会非常明显，用流程来产生规模效应，同时用流程来规避对种子选手的过分依赖，降低绩效风险（种子选人是最不稳定的人群），当团队更大的时候，平庸的大多数已经成百上千了，团队和工作的多样性让流程的局限性充分暴露出来，此时，靠的是一种类Web2.0的解决方案，所有员工自动自发的创造性、生产力，这种自动自发出来东西的有效性，需要用文化和价值观来驱动和指导，以上三个阶段，是一种大概的划分，其实在任何一个规模下，三个维度都是互相补充的：人、流
6、程、文化。所以，我们所有的努力其实都是基于这三个方面的认知和努力； 人：首先人的方面，个人能力很容易理解，当然是越强越好，当然要在人力成本的限制条件下，除此此外，还有一个东西很重要，那就是合适的组织结构（单元）我们每个项目组有一名项目经理带三四名工程师，我们发现这是一个非常精巧的配比，组员的效率容易挖掘，管理成本比较低，协同高效，所以，后期虽然整个团队规模不断变大，但也都是基于这样的项目单元，通过细胞分裂的方式来扩展的。这种在业务推动下的自然分裂是非常经济和现实的，基于项目类型的同质分裂，分裂出来的项目组的工作内容（项目类型）大同小异。与此同时，随着团队规模的不断扩大，分工越来越精细，还会有新
7、的工种出现，新工种会专注于某一细分基础模块的工作，这是一种异质分裂，典型的新工种是架构师，团队规模很小的时候，设置专职架构师是件满奢侈的事情，项目经理往往是以一当十的用的，如果有一件事情不知道该给谁做，通常都是由项目经理兼的，当系统规模越来越大的时候，着眼于全局的架构设计，再由项目经理兼做几乎是不可能胜任的，这个时候就必须依赖专职的架构人才，成立架构师团队，不然大家就成天火烧屁股了，架构师团队和项目团队的关注点是有很大不同的，前者我们称为创新线，更多关注创造力，后者称为项目线，关注项目吞吐。针对这两条线，我们设置不同的绩效管理办法，用不同的指标进行绩效跟踪。组织结构问题解决了，我们相当于把一台
8、“拖拉机”变成了“法拉利”。 正当我们踌躇满志准备上路时，我们发现摆在面前的是一条泥泞的小路，请问法拉利能够跑过原来的拖拉机吗？，即使能够跑过，我想也不敢跑太快吧，一不小心底盘就报销了，舍不得啊，为了让法拉利们能够跑得快一点，我们需要一条高速公路，在高速公路上，我们设定规则，要求速度达到多少才能够上去，像拖拉机这种压根就不让上了，从而保证车流吞吐，这条高速公路就是流程，当我们已经不是三五个人加几条枪的时候，流程对绩效的影响是巨大的（因为流程，更多是为那85%服务的）。 流程：流程的设计，最怕生搬硬套，我有两个关键体会： 1、注意各协作团队的综合能力配比，关注瓶颈节点，比如收费站，就是高速公路的
9、一个瓶颈节点，还有容易出车祸的路段也是瓶颈节点，直接影响车流吞吐（排队啊），体到我们的工作现场也有类似的典型瓶颈，比如，当QC资源不足时，项目质量很大程度上要依赖开发团队自己，这个时候再强调什么理论上的职责分工就是不切实际的，这个时候要通过诸如代码走查制度、加强单元测试来弥补，这其实是一种典型的用开发换测试的做法。目的是打掉整个流程的瓶颈； 2、控制流程本身的成本，够用就好，开发资源不足时，还一定要出详细的设计文档；QC资源不足时，还要求一定要有完整的测试用例，这些都是学院派干的事情，靠谱的流程都是经过裁剪的，以牺牲某种特性来换取更大的好处，所谓两权相害取其轻，否则，我们付出的流程成本基本上是
10、打了水漂，更重要的是，流程成本不光是指我们遵循这个流程所花费的时间，还有繁琐的流程所吃掉的工作热情。 文化：在我的理解中，所有的文化都是为了制造幸福感，当一个人幸福并快乐的时候，这本身就是一种强大的生产力，我依然记得在BenQ时，当时的副总张安佐有一句话“每天早上眼睛一睁开，就能够一跃而起的人是最幸福的”，某种程度上，我们所有人都在追求能够让自己每天一跃而起的事情，比如对于一个母亲那可能是为家人准备一顿丰盛的早餐，那么照顾好这个家就是她一跃而起的动力，而之于我们，如果一份工作能够让我们一跃而起，那我们怎么可能没有效率？，一跃而起是源于我们内心对于团队及团队所做的事情的深深的认同，这种认同是一种
11、人性文化的深耕。以上部分，是有关绩效来源的一些思考互联网研发团队绩效方案设计： 先要介绍一下技术团队的生存背景，对于一家电子商务公司来说，其真正的产品是“交易服务”，交易服务由两方面构成，一个是产品和技术提供的在线交易平台（生产工具），另外一个是客服提供的过程服务（生产），而负责将“交易服务”卖出去的责任更多的落在营销（市场、运营），持续、快速的交付对用户有价值的交易服务，是电子商务公司的核心竞争力，对于技术团队来说，持续、快速的交付高质量的平台特性，是技术团队的生存根本，鉴于这样的特点，我们的项目特点是追求短平快，百分之七八十的项目的实施周期都在一周以内，项目规模很小，偶尔有大的项目，我们也
12、是想尽办法把它分解成一二三期，从而降低项目的实施周期，这样做的好处是显而易见的。让一个特性最快与用户见面，是验证它是否有效的最好办法。结合大部分项目周期都在一周以内的特点，我们把项目绩效的度量周期定为一个月，每个月会进行一次绩效回顾，让各项目组总结调整，注意，我们只是把月度作为度量统计的单位，绩效考核的周期还是以季度为周期的，月度的度量，决定项目奖金的分配。而季度绩效考核，影响的是季度奖，为什么不选择月考呢？有两个原因：首先如果每个月考一遍，管理成本太高了，其次，绩效考核的目的就是在对产能分布进行识别，我们还有20%的跨月项目的，用季度这样的宽度，可以更好的覆盖，让各个项目组之间的比对数据更具
13、参考价值 在上述原则的指导下，我们接下来谈谈具体绩效考核方案的设计，技术团队绩效考核方案的制定，整体遵守几个原则： 、 使用项目绩效分，来衡量项目业绩 、 使用非项目绩效分（事件绩效分），来衡量日常工作之外的创新、拓展贡献 、 对于同一类型岗位，使用统一考核模型（权重和算法可调） 、 对于差异性较大的小工种，使用个性考核办法 、 管理职能与执行职能考核分离 根据以上原则，我们将考核方案分为四条线：项目线、创新线、管理线、标准线，同时，整个绩效考核的维度框架，统一为：主营业绩80%、事件绩效15%、综合评定5%；主营业绩，是指你的岗位职责要求你承担的责任表现；什么是非项目绩效(事件绩效)呢？顾名
14、思义，就是项目之外的贡献产生的绩效，这个名字是我们一开始时候在项目部推出来的，现在已经在整个技术部门应用，所以现在叫称作“事件绩效”会更贴切些。作为技术部门，项目一直是我们的主营内容，我们在制定KPI时，也是重点关注这个部分，比如通过人均项目绩效分来衡量项目产能。然而日常工作中还有很多贡献不在KPI中，比如内部讲师作培训、比如招聘面试等等。这部分没在KPI上反应出来的贡献，显然不是无关紧要的，此外，这些事情还与员工的工作热情有很大的关联，人们总是对做擅长的事情充满热情，比如擅长演讲的人乐意去作培训，擅长沟通的人乐意去面谈，对代码有洁癖的人乐意去做Code Review等等，如果这些贡献不能够在
15、绩效上反应出来，做和不做没什么区别，谁还愿意做下去呢，热情在萎缩的同时，整个团队的能量也在萎缩，除此之外，当团队越来越大，面对的事情也会越来越复杂，一线的情报传递上来往往会延时或失真，管理工作也因此往往会很被动，这个时候就需要激发一线员工的创造力和热情，让他们去开动脑筋，他们想出来的事情往往更加切合实际，而我们从中识别出“重要”的部分加以大力推动，岂不快哉，这样一来，我们就有了一个巨大的脑库，有源源不断的点子来推动团队的发展。事件绩效的量化，我们也有一套办法基本思路就是按照事件的价值大小，分级给一定的分值，然后评估时又分解成基础分和执行效果分，有一个换算公式：绩效分=基础分 + 价值基数 *
16、目标效果系数，“综合评定”，其实就是给管理上级拍脑袋的，大家可以注意到，这个比例非常小，这个靠感觉的不敢给的很大，当然，在团队很小的时候，我们也通常是别无选择的拍脑袋，那个时候是靠“英雄人物”推动绩效的。我们前面提到几条考核线，每一个考核维度在不同绩效线，也有不同的含义，比如项目线主营业绩就是指项目贡献度，使用项目绩效分来衡量，这个绩效分由多个因素构成，比如编码工作量、比如协调工作量等等，我们有一个评审委员会，专门负责分配绩效初始分，每一个项目都会有一个初始分，后面还会根据项目的测试质量等级、进度执行情况对分值进行加减，具体的评分细则我就不展开了。创新线的主营业绩分解成：发起多少提案，有多少提案被评审通过（可靠性和价
