你好，我是肖军，目前是苏宁金科CTO，曾就职于蚂蚁金服集团、苏宁易购集团，担任过架构师、总监、总经理、CTO等不同职位，也管理过10+、100+、1000+等不同规模的研发团队。在管理这些团队的过程中我常常遇到一个关键问题，就是如何制定团队中绩效考核标准。
相信这个问题也曾困扰或者正在困扰着你，所以今天我们就来聊一聊作为研发团队 Leader，在做绩效考核的时候如何做到赏罚分明。要想做到赏罚分明就需要先明确：什么人因为做了什么事，基于什么量化指标和规则，获得什么权益或处罚。
销售团队可以通过用户数/交易量/利润等指标，比较准确地量化每个销售人员的业绩指标。可是研发团队绩效考核的核心难点就是每个研发人员的“价值度量”，以什么指标来衡量一个研发人员做得好还是不好，以及这些指标数据获取来源和计算逻辑的客观公正性。
案例分析
下面我通过我在2015年～2018年负责的一个研发团队的实践案例，给你讲讲当时遇到的问题以及解决方案。在这个过程中我遇到了3个问题：
- 难以找准关键指标；
- 团队成员难以分配绩效权重；
- 考核结果难以强应用。
下面我们具体分析一下这三个问题的实际场景。
难以找准关键指标
我们曾经用过代码量、千行代码 Bug 率、生产故障数、业务需求响应时间、业务投诉次数、项目交付周期等这些指标去考核。这些看上去还挺合理的考核方式，实际运行时却是漏洞百出。比如：
- 编写核心模块的人代码量可能比写上层应用系统的代码量少。
- 千行代码 Bug 率高的有可能是团队中的核心骨干，做得多可能错的概率就高些。
- 生产故障数这个指标，有可能导致出了故障推诿到历史问题、前人的问题，也有可能做核心系统的人出故障的几率大得多。
- 业务需求响应时间以及项目交付周期，有可能导致把需求拆小，本来一个需求就可以做完的，变成了多个需求。
- 业务投诉次数这个指标有可能会导致研发团队完全没有话语权，或者出现做了较多无效业务需求。
团队成员难以分配绩效权重
评优名额或者奖金池，有可能是直接给到研发中心层面，就是一个中心总计多少名额。但是一个中心里有产品经理，有开发工程师，他们的岗位职责不一样，而且产品经理和开发，还分成了C端、B端，他们做的业务都不一样，而且开发里还分前端开发、后端开发、算法人员等不同的角色。
评优名额分配是产品多，还是开发多，怎么决策呢？如果产品多，那是给C端产品多一些？还是给B端产品多一些呢？如果分给B端，那前端、后端、测试分别分多少？这个又怎么决策呢？
考核结果难以强应用
当时团队是以季度为周期进行考核，对于评优这方面，只要全年得到2个优，就可以成为优秀员工候选人。如果一个核心员工，按照量化 KPI 指标，每个季度可能都是排名第一，这个时候是全部的优都给到这个人，还是平衡一下，给其他人2个优？
对于惩罚这方面，面对平时善于做攻坚克难的核心骨干，有可能还是行业里难得的精英，出了特大事故，如果定的 KPI 是线上事故指标，按照规则可能会被罚得很重，有可能会导致其直接离职，损失团队核心骨干。
绩效考核方案
针对以上3类问题，我们团队总结了一套绩效考核方案，这套体系包括四个阶段。
- 战略解码，制定大团队绩效的基本盘，并提炼北极星指标。
- 团队共识，确定个人全局差异化指标。
- 绩效数据展示与面谈。
- 赏罚结果应用跟踪与战略复盘。
第一阶段：基于战略解码设计绩效顶层框架
这里面有两个基本原则，一是团队绩效决定了个人绩效的天花板，也决定了赏罚的天花板；二是绩效框架设计要和战略合拍。
首先我们定义个人绩效考核的顶层公式：
$$绩效考核 =（业绩指标 + 价值观考核指标）\times打法 + 团队建设指标$$
然后基于集团战略和支付平台研发中心的问题，抽象出北极星指标。2015年，支付平台研发中心面临的问题很多，几乎每上线一个新版本，都有生产故障发生，系统全链路支撑能力只有99 TPS，一旦搞大促活动，就可能出问题。产品方面，功能比较薄弱，只有基础功能，银行渠道接入只有10家，很多大区的城商行银行卡不能使用。研发周期也比较长，上线一个需求可能需要以月为单位来算。
从问题现象看，种类很多，有系统问题，有产品问题，有研发效率问题，有多中心协同协作问题，也有团队建设问题。经过反复推演，我们制定的总体策略和打法是：以痛点问题为导向，同时输出技术能力。
具体来讲，就是抽象出2个业绩指标、1个团队建设指标和1个价值观考核指标。
这样我们就解决了两件事情：一个是基于具体团队的绩效考核顶层框架设计，另外一个是解决了绩效考核赏罚的天花板。比如当年年底的时候，研发中心几乎包揽了集团大促全部的10个奖，银行渠道接入78家，覆盖了业务所需的所有银行，故障恢复时间可以实现秒级切换，且生产事故为0。
这样一方面对内获得集团决策层对中心研发能力的信任，也得到了其他业务线对我们研发中心的专业认可，同时也加强了与集团的品牌部、公共事务部、HR等职能体系部门的连接；另一方面，对外提升研发中心的行业影响力，形成特定领域的“行业专家”。
从2015到2018三年时间，研发中心共计向其他业务中心，输出技术正副总监、产品正副总监、部门经理、系统 Owner 20多人，获得了20余次集团大奖，10余次行业大奖，打开了加薪、升职更多的渠道和多样性。
第二阶段：团队共识，确定个人全局差异化指标
当基于战略解码进行绩效顶层框架设计好了之后，接下来，就是将上面的北极星指标解码，映射到我们具体的每条产品线、每个系统、每个人，从收银台到收单，到支付服务，到渠道接入，层层分解。
比如收银台开发的 KPI 就是一级系统故障恢复时间<1分钟，渠道接入开发的 KPI 是实现配置化接入；同时每个 KPI 要设置合格指标、优秀指标，合格指标是要全力跳起来才能达到的指标，优秀指标就是超出预期的指标，比如恢复时间的优秀指标就是秒级或者部分系统能够实现故障自愈。
所以这一步对于Leader就有两点要求：一方面要懂战略才能映射到技术层面指标的解码；另一方面要懂核心技术，必须知道核心问题在哪里，进而分解前置指标，比如要实现故障恢复时间秒级，前置条件是你的链路可视化、耗时 SQL、分库分表中间件研发等拆解到每一个人。这些所有的个体指标，能够推演汇聚成上一步的北极星指标，当这些指标确定后，要全员公示，并面对面地和每个人沟通，达成一致，这样从指标层面就确保了全局一盘棋。
第三阶段：绩效数据展示与面谈
考核指标定下后，最重要的是指标数据的获取与展示了。我们团队每个员工的周报或者月报都是围绕自己的核心 KPI 来进行的，同时周报和月报会发给所有人，所以在绩效考核之前，基本每个人都知道谁做得好，谁做得不好。考核的目的不是为了惩罚，而是为了提升业绩，解决问题，让大家都能看到优秀的人，都能从优秀案例中学习。
为了考核的相对客观性，我们采取1+2+X的模式，就是1个HRBP+你的主管和你主管的主管+员工本人。HRBP 有1份数据，主管也有1份数据，同时员工自己也会有1份数据（员工自己录入系统中，采用自评+演讲案例的模式）。三方面对面的交流，敞开谈，做得好的地方，做得不好的地方，要定制改进和辅导措施，这样考核就会相对公平公正，公开透明。
第四阶段：跟踪赏罚结果应用与战略复盘
首先，确定赏罚机制并跟踪结果应用情况。当时我们采用“12331”机制，前面的“12”定义为优秀，“12”中的“1”为优+，中间的“3”则是表现符合预期的，最后“31”是优化调整大池子。这样团队就会按照“12331”的方式进行排序，评优、奖金和晋升都根据这个规则来。
然后跟踪评优是否符合员工的预期，不仅要跟踪优秀员工本人，还要和其他没有评优的人谈，这些被评为优秀的人他们是否认可，是否真正起到了标杆和榜样的作用。被处罚的，也要跟进改进措施是否在按照预期进行。
其次，要进行战略复盘。到2015年底，我们会对前面3步进行复盘，比如渠道接入数量和大促评奖，就不是2016年的基本盘了。根据2016年的战略，我们会加入B端商户开放平台的建设相关指标，始终保持你的小团队和集团的大战略是合拍的，这样才能保证你的赏罚措施的多样性，人才分层后，才会有对应的激励措施分层，对团队也能起到更多的激励作用。
总结
这样一整个方案我们就介绍完了，最后我们来复习一下这节课的内容吧！
这节课我们分析了研发团队绩效考核标准实践案例中的3个难点，并针对这三个难点制定了一套研发团队的绩效考核方案。方案分为四个阶段：
- 基于战略解码进行绩效顶层框架设计。整体战略和具体的北极星指标，你可以参考下面这两个公式：
$$绩效考核 =（业绩指标 + 价值观考核指标）\times打法 + 团队建设指标$$
$$北极星指标 = 2个业绩指标 + 1个团队建设指标 + 1个价值观考核指标$$
- 团队共识，确定个人全局差异化指标。这个阶段对管理者的要求是既要懂战略又要懂核心技术，这样才能合理地拆分指标。
- 展示绩效数据并约三方面谈。
$$绩效数据（3份数据）=HRBP+主管和主管的主管+员工本人$$
- 采取【12331】机制并跟踪赏罚结果。年底进行战略复盘，并及时调整指标。
我们曾尝试过多种研发人员的价值度量的方案，有失败的，也有相对比较成功的，上面介绍的这个绩效考核四步曲方案目前在研发团队中运行得比较好，所以借此机会分享给你，在以后的绩效考核中，你可以做为参考。
思考题
请你运用我给出的研发人员绩效考核方案，确定你所在的团队的关键指标以及团队内部的绩效权重分配规则。欢迎你把你的思考写在评论区，我会和你一起探讨，如果你身边有对绩效考核感兴趣的朋友，也欢迎你把这节课分享给他。
精选留言
2022-11-12 17:10:47
正好也想借此机会，请教个困扰我们很久的问题，业务方时不时投诉我们研发的问题，其实很多都是业务的问题，业务自己完不成指标，就往研发身上推，就导致研发侧绩效始终不好，请问这类问题，肖老师有什么建议的解决方案呢？
2022-11-12 21:52:04
这里和没有评优秀的人谈，对于优秀的人是否认可，我觉得实际上很难操作，至少阿里不会这样，因为每个人都会更认可自己一些，如果两个人差距不大，很容易出现矛盾和冲突吧。
2022-11-09 07:48:57
2022-11-08 21:01:02
2022-11-08 20:31:13
2022-11-23 14:44:42
另外，看似只解决了分配问题中的赏罚分配的问题，还没有解决工作分配的问题。高价值的工作与低价值的工作，获得的报酬肯定是不一样的，但是付出的艰辛有可能是差不多的。很多公司是跟领导关系好才能获得好的差事，闷声干活的人只能干别人挑剩下的脏活累活。
2022-11-14 11:16:35
我以前在制定考核规则的时候就想过一个问题，那就是要不要考核经营指标，也就是收入之类的。后面想想还是觉得应该加上。部分做得再好，公司不赚钱，也是有问题的。比如，技术把性能指标都做的很好，但实际业务量根本没起来，这其实是浪费了公司的研发资源，没有把事情用在更重要的事情上。
2022-11-09 10:40:31
2022-11-08 22:48:41
2022-11-08 15:57:18
2024-02-06 09:40:23
2023-02-25 09:29:54
2023-02-20 22:16:54
* 《01｜研发团队绩效考核：Leader 如何做到赏罚分明？》
【R】赏罚分明 = 谁做何事的因 + 量化的指标和规则 + 获得的权益或处罚。
【.I.】赏罚分明，起点、过程、终点，哪个点最有效果？猜测，就心里效果而言，起点 〉过程 〉终点；就荷包效果而言，起点〈 过程〈 终点；就综合效果而言，只要团队持续多轮项目合作，即所谓团队成员间，就投入和收益开展多轮博弈，最后留下来的，都认可当下的赏罚，不认可早已离开团队。当然，即使心里不舒服、嘴上叽里咕噜，实际上不离开，就是最好的行动证明。
【.I.】每次看到效果显著的管理案例，尤其是数字亮瞎眼的那种，总会提醒自己，这样的案例，既要关注实施前的状况，更要关注实施后的状况。可能是因为摘了低垂的果实，更可能是吸干了未来的血。记得曾经有个案例，当年的项目进展和成果，亮瞎所有人的眼。当再多问一句，这个团队然后呢？答案同样亮瞎眼，除了团队主管，都已经各奔东西。
— by 术子米德@2023年2月20日
2023-02-14 17:05:25
2022-12-16 10:54:12
2022-12-15 17:06:53
2022-12-10 12:28:03
2022-11-17 20:12:51
2022-11-15 09:00:22
2022-11-08 20:21:54