技术部门绩效考核访谈.docxVIP

Q交谈中请勿轻信汇款、中奖信息，勿轻易拨打陌生电话。 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%?）是屮坚力量，他 们冇稳定的绩效产出，而11不容易跳槽，容易跳槽的是那10%的人，还冇5%容易 被跳槽的人。 12:41:40 接下来，我们谈谈绩效的来源。 12:42:22 有一个基本观点， 团队很小的时候靠的是个人能力，种了选手，以一挡十那种； 当团队达到一定规模的时候，种子选手的作用已经不是十分明显，屮竖力量是“平 庸的大多数”，这个时候流程的作用会非常明显，用流程来产生规模效应，同时 用流程来规避对种子选手的过分依赖，降低绩效风险（种子选人是最不稳定的人 群）； 12:43:26 以上三个阶段，是一种大概的划分，其实在任何一个规模下，三个维度都是互相 补充的：人、流程、文化。所以，我们所有的努力其实都是基于这三个方面的认 知和努力。 12:44:03 人，流程和文化,我们逐个BalaBalao o o o o 12:44:40 首先人的方面，个人能力很容易理解，当然是越强越好，当然要在人力成木的限 制条件下。除此此外，还冇一个东西很重要，那就是合适的组织结构（单元）， 我们每个项目组有一名项目经理带三四名工程师，我们发现这是一个非常糟巧的 配比，组员的效率容易挖掘，管理成本比较低，I■办同高效。 12:45:24 所以，后期虽然整个团队规模不断变大，但也都是基于这样的项口单元，通过细 胞分裂的方式來扩展的。这种在业务推动下的自然分裂是非常经济和现实的。 12:45:59 基于项目类型的同质分裂，分裂出来的项目组的工作内容（项目类型）大同小异。 与此同时，随着I才I队规模的不断扩大，分工越来越精细，还会有新的工种出现, 新工种会专注于某一细分基础模块的工作，这是一种异质分裂，典型的新工种是 架构师。 12:46:46 I才I队规模很小的时候，设置专职架构师是件满奢侈的事情，项目经理往往是以一 当十的用的，如果有一件事情不知道该给谁做，通常都是由项口经理兼的。 12:47:14 当系统规模越來越大的时候，着眼于全局的架构设计，再由项冃经理兼做几乎是 不可能胜任的，这个时候就必须依赖专职的架构人才，成立架构师团队。 12:47:43 架构师团队和项口团队的关注点是有