技术领导力实战笔记2022_02_01研发团队绩效考核Leader_如何做到赏罚分明
你好，我是肖军。
目前是苏宁劲科CTO之前在蚂蚁金服、苏宁易购担任过架构师总监、总经理CTO等不同的职位，也管理过十人、一百人、一千人等不同规模的研发团队。
在管理这些团队的过程中啊，我常常遇到一个关键问题，那就是如何制定团队中绩效考核的标准。
我相信这个问题啊也曾经困扰，或者说目前正在困扰着你。
所以今天我们就来聊一聊作为研发团队leader,在做绩效考核的时候啊，如何做到赏罚分明，要想做到赏罚分明，就需要先明确啊什么人。
因为做了什么事，基于什么量化指标和规则，获得了什么样的权益或者处罚。
销售团队呢可以通过用户数啊、交易量、利润等指标比较准确的来量化每个销售人员的业绩指标。
可是研发团队啊绩效考核的核心难点就在于每个研发人员的价值。
度量以什么指标来衡量一个研发人员做的好还是不好，以及这些指标数据获取的来源和计算逻辑的客观公正性。
下面啊我就通过我在二零一五年到二零一八年负责的一个研发团队的实践案例，来给你讲一讲当时遇到的问题以及解决方案。
在这个过程中呢，我遇到了三个问题。
编写核心模块的人代码量啊可能比写上层应用系统的代码量要少。
建行代码bug率高的呢有可能是团队中的核心骨干，因为做的多，可能错的概率也就会高一些。
生产故障数这个指标呢有可能会导致出了故障，推诿到历史问题。
前人的问题也有可能是做核心系统的人出故障的几率呢确实会大得多。
业务需求、响应时间啊以及项目交付周期，有可能啊会导致把需求拆小，本来一个需求就可以做完的，结果变成了多个需求。
业务投诉次数这个指标呢有可能会导致研发团队完全没有话语权，或者出现做了很多无效的业务需求。
第二个问题是难以分配团队成员的绩效权重评优名额或者奖金池，有可能是直接给到研发中心层面的，就是一个中心总计有多少个名额。
如是一个中心里面啊有产品经理，有开发工程师，他们的岗位职责不一样，而且产品经理和开发还分成c端，b端他们做的业务啊也都不一样。
而且呢开发里面还分前端开发、后端，开发算法人员等不同的角色评优名额分配是产品多还是开发多，这个又怎么决策呢？如果产品多，那是给c端产品多一些，还是给b端产品多一些呢？而果分给b端，那是前端后端测试，这又该怎么去分呢？第三个问题呢是考核结果难以强应用。
当时团队是以季度为周期来进行考核的。
对于评优这方面啊，只要全年得到两个优，就可以成为优秀员工候选人。
如果一个核心员工按照量个核PI指标，每个季度可能都是排名第一的。
这个时候是全部的优都给到这个人，还是平衡一下给其他人两个优。
对于惩罚这方面，面对平时善于做攻坚难难的核心骨干，那有可能啊还是行业里面难得的精英。
那出了特大事故，如果定的KPI是线上事故指标，按照规则呢可能会被罚的很重，有可能会导致他直接离职，损失了团队里面的核心骨干干。
针对以上三类问题啊，我们团队总结了一套绩效考核方案。
这套体系呢包括四个阶段阶段，一是战略解码，制定大团队的绩效基本盘，并提炼出北极星指标阶段。
二啊是团队共识，确定个人全局差异化指标阶段。
三呢是绩效数据展示与面谈阶段。
四啊是赏罚结果应用跟踪和战略复盘。
我们先来看第一阶段，基于战略解码进行绩效顶层框架设计。
这里面啊有两个基本原则，一个是团队绩效决定了个人绩效的天花板，也决定了赏罚的天花板。
第二个是绩效框架设计啊要和战略合拍。
首先呢我们定义个人绩效考核的顶层公式。
二效考核呢等于业绩指标，加上价值观考核指标乘以打法，再加上团队建设指标。
然后啊基于集团战略和支付平台研发中心的问题，抽象出北极星指标。
二零一五年啊，支付平台研发中心面临的问题很多，几乎每上线一个新版本都有生产故障，发生系统全链路支撑能力啊，只有九十九TPS,一旦搞大促活动就可能出问题。
那么产品方面呢，功能啊其实也比较薄弱，只有基础功能，银行渠道介入啊，只有十家很多大区的城商行银行卡不能使用，研发周期啊也比较长，上线一个需求可能要以月为单位来计算。
那么从问题现象来看啊，问题种类很多，有系统问题，有产品问题，有研发效率问题，有多中心协同协作问题，也有团队建设问题。
经过反复推演，我们制定的总体策略和打法呢就是以痛点问题为导向，同时输出技术能力。
具体来讲呢就是抽象出两个业绩指标，一个是获取四幺八六幺八八、幺八双十一双十二这五个大促节点呢，至少五个技术大奖。
另一个呢是接入业务所需的所有银行一个团队建设指标，行业顶级技术大会，输出五个讲师，集团项目支援十人以上骨干一个价值观、考核指标，利他共赢，帮助其他兄弟团队体系啊解决十个以上的核心技术问题。
这样呢我们就解决了两件事情。
一个是基于具体团队的绩效考核，顶层框架设计。
另外一个是解决了绩效考核赏罚的天花板。
比如当年年底的时候，研发中心几乎包揽了集团大促全部的十个奖项，银行渠道接入了七十八家，覆盖了业务所需的所有银行故障恢复时间呀可以实现秒级切换，而且呢生产事故为零。
这样呢一方面对内获得了集团决策层对中心研发能力的信任，也得到了其他业务线对我们研发中心的专业认可。
同时啊也加强了和集团的品牌部啊公共事务部、人力资源等职能体系部门的连接。
另一方面，对外提升了研发中心的行业影响力，形成了特定领域的行业专家。
从二零一五年到二零一八年三年时间，研发中心故意向其他业务中心输出技术，政府政副总监、产品政副总监、部门经理，系统owner二十多人，获得了二十多次集团大奖，十多次行业大奖，打开了加薪、升职更多的渠道和多样性。
然后我们来看第二阶段团队共识，确定个人全局差异化指标。
当基于战略解码进行绩效顶层框架设计好了之后呀，接下来就是把上面北极星指标进行解码，映射到我们具体的每条产品线。
每个系统每个人从收银台到收单到支付服务，到渠道接入层层分解。
比如收银台开发的KPI呢就是一级系统故障，恢复时间啊小于一分钟渠道接入。
开发的KPI呢是实现配置化接入。
同时啊每个KPI要设置合格指标，优秀指标，合格指标呢就是说要全力跳起来才能达到的指标。
那么优秀指标啊就是要超出预期的指标，比如恢复时间的优秀指标呢，就是秒级或者部分系统能够实现故障自愈。
所以这一步对于leader来讲呢，就两点要求，一方面啊要懂战略，才能映射到技术层面指标的解码。
另一方面要懂核心技术，必须知道核心问题在哪里。
这而分解前置指标，比如要实现故障恢复时间秒级、前置条件是你的链路可视化耗时c口分表、分库中间件研发等。
这些前置条件拆解到每一个人，这些所有的个体指标啊，能够推演汇聚成上一步的北极星指标。
当这些指标确定之后呢，要全员公示并面对面的和每一个人沟通达成一致。
这样从指标层面呢就确保了全局一盘棋第三阶段呀是绩效数据展示与面谈考核指标。
定下来之后呢，最重要的就是指标数据的获取和展示了我们团队啊，每个员工的周报或者月报都是围绕自己的核心KPI来进行的。
同时呢周报和月报啊也会发送给所有的人。
所以在绩效考核之前啊，基本上每个人都会知道谁做的好，谁做的不好。
考核的目的不是为了惩罚，而是为了提升业绩解决问题，让自己啊能够看到优秀的人都能从优秀案例中去学习。
为了考核的相对客观性呢，我们采取一加一加x的模式，就是一个HRBP,加上你的主管和你主管的主管。
再加上员工本人HRBP呢有一份数据，主管也有一份数据。
同时员工自己啊也会有一份数据。
而员工自己的这份数据呢是自己录入系统中采用自评加演讲案例的模式。
三方面对面的交流敞开了，谈做的好的地方，做的不好的地方要定制改进和辅导措施，这样考核就会公平公正，公开也更加透明。
第四阶段呀是跟踪赏罚结果应用与战略复盘。
首先呢确定赏罚机制跟跟踪结果应用情况。
当时啊我们采用的是一二三三一机制，前面的一二呢定义为优秀，一二中的一为优加，中间的三呢则是表现符合预期的。
最后三和一啊是优化调整大池子。
这样团队呢就会按照一二三三一的方式进行排序。
评优啊、奖金啊和晋升都是根据这个规则来的。
然后呀跟踪评优是否符合员工的预期。
我们不仅要跟踪优秀员工本人，还要和其他没有被评为优秀的人来谈，他们是否认可这些被评为优秀的人比否，真正起到了标杆和榜样的作用。
被处罚的呀也要跟进改进措施，是否在按照预期进行。
其次呀，就是要进行战略复盘了。
到二零一五年底啊，我们会对前面三步进行复盘，比如渠道接入数量和大促评奖，就不是二零一六年的基本盘了。
根据二零一六年的战略啊，我们会加入b端商户开放平台的建设相关指标，始终保持你的小团队啊和集团的大战略是合拍的。
这样呢才能保证你的赏罚措施的多样性。
人才分层后啊才会有对应的激励措施的分层，对团队来讲呢也能起到更多的激励作用。
这样一整个方案呢，我也就介绍完了。
最后呢我们来复习一下这节课的内容。
这节课呀我们分析了研发团队绩效考核标准、实践案例中的三个难点，并针对这三个难点制定了一套研发团队的绩效考核方案。
方案呢分为四个阶段，一是基于战略解码进行绩效顶层框架设计整体战略啊和具体的北极星指标呢，你可以参考绩效考核和北极星指标的公式就在上面。
第二呢是团队共识，确定个人全局差异化指标。
这个阶段啊对于管理者的要求呢是既要懂战略，又要懂核心技术，这样呢才能合理的去拆分指标。
第三呀是展示绩效数据并约三方面谈。
第四呢是采取一二三三一机制并跟踪赏罚结果，年底啊进行战略复盘并及时调整指标。
我们曾尝试过多种研发人员的价值度量的方案，有失败的，也有相对比较成功的。
上面介绍的这个绩效考核四部曲方案呀，目前在研发团队中运行的比较好。
所以呢通过这次机会分享给你，在以后的绩效考核中啊，你可以作为参考。
请你运用我给出的研发人员绩效考核方案，确定一下你所在的团队的关键指标，以及团队内部的绩效权重分配规则。
欢迎你把你的思考啊写在评论区，我会和你一起去探讨。
如果你身边有对绩效考核感兴趣的朋友呢，也欢迎你把这节课分享给他。