你好，我是搜狐社交产品中心总经理高琦，今天想跟你分享的话题是，怎么给研发打绩效不头疼又公正？

每次到了绩效考核的那段时间，我都非常纠结，即使最终做完了决定，还是常常感到无法满意，偶尔收到一些新信息后又会对之前的决定感到懊悔，觉得自己没有考虑周全，做到足够公正。后来和很多技术领导者沟通后，发现大家都对此有相同的感受，越希望追求客观公平的人越纠结。

因为自己没有更好的解决方式，这个问题一直搁置着，每隔一段时间就再纠结一次，不断循环往复。后来团队的一个变化，突然使得打绩效的问题变得非常简单，意外的收获让我大为惊喜。这次就基于这个意外的收获谈谈给研发团队打绩效这个话题。

这个变化就是团队引入了敏捷开发流程。当时引入敏捷开发并不是为了解决绩效的问题，而是为了平衡研发速度和质量，解决产品需求变化多且经常插入迭代导致的项目周期不可控问题。但这里我们不谈敏捷，只谈绩效。

给研发打绩效是门艺术

给研发打绩效难，究其原因，研发本质上是一种有创造性的工作，程序员和艺术家有非常多相似的地方，相信很多人都读过《黑客与画家》这本经典之作，既然是创造和创新，那么衡量就是一件很难的事情。

我们团队在这方面进行了不同的尝试，而这次在研发过程中引入敏捷的方式 (我们团队使用的是 Scrum) 就是一个意外之喜。敏捷不是让打绩效突然变得简单且公正，而是让团队从开始就进行改变，最终使打绩效的过程变成一件自然而然、水到渠成的事情。

敏捷实践，敏捷的核心在于透明、透明、透明，重要的事情说三次，当然，敏捷作为一种项目管理方式，其特点还有迭代、拆分子任务、站立会等等，能带来诸多好处，但是这里我们不是讨论敏捷，不再赘述敏捷的优点，而是强调敏捷中的透明对打绩效的影响。

另外，需要强调的是，敏捷是一种项目管理方式，而不是一种工具，例如腾讯在推进的敏捷管理平台 TAPD，腾讯及其投资的很多企业都在使用，但是我和相关使用者深入探讨的时候，发现大部分团队并没有深入理解敏捷的本质，最终使这样的平台只起到了一部分敏捷的效果。其实，使用什么样的敏捷工具并不重要，比如我们团队反而更青睐白板、便签、笔和 excel。

敏捷过程中对后续绩效考核影响的关键点

之前提到，透明是敏捷给打绩效带来的非常正面的影响，而在具体的敏捷过程中，透明主要由两个方面来体现，分别是评选迭代之星和燃尽图。

1. 评选迭代之星

每次迭代小组在完成一个迭代之后，都会开迭代总结会，在这个会议里有一个最终的评选，那就是每人一票，选出自己认可的对这个迭代贡献最大的人作为迭代之星，不能选自己。由于这个过程完全是由参与其中的人，根据本次迭代中每个人选择的需求难度、完成度、质量、代码 review 时代码的漏洞、帮助团队其他人的情况等等综合考虑的结果，而且因为一次迭代之星没有什么跟金钱相关的实际意义，就是团队共同的肯定，这里大家没有什么顾虑，被选为迭代之星的人就较为客观。

依据我们实践的经验，优秀的人很容易在这个过程中浮现出来，并且得到大家的一致认可。而到年终进行绩效考核的时候，荣获迭代之星次数最多的员工得到最高的评价，对于团队里面的每个人来说都是完全可以接受的，而且这个过程是一种良性的竞争。

2. 燃尽图

在小组之间进行对比和评判的时候，燃尽图是非常重要的参考。通常，燃尽图是各个尝试敏捷的团队最容易选择简化掉的部分，因为大家开始并不能理解画一个图能有什么实际意义。

燃尽图 (见下图的示例) 是描述团队随着时间的推移而剩余的工作数量，可用于表示开发速度。不过在这里，我就不具体介绍燃尽图的画法和各种曲线展现出来的问题了。好的迭代小组，由于其拆分任务颗粒度合适，对任务难度评估准确，团队成员相互熟悉代码，燃尽图会趋近于一条直线。从燃尽图中我们可以看出各团队出现的问题。

  1. 先鼓起后落下：这是最常见的情况，原因是程序员对自己极度自信或者在做计划时漏掉了一些事情，造成初期进度缓慢，成员到最后通过疯狂加班使整个曲线快速落下，但这会导致最终项目质量低下。
  2. 一开始一切正常，然后突然停止燃烧：这是由于任务划分太粗糙，导致团队对工作量估计错误，到最后容易出现任务在余下时间内难以完成的情况。
  3. 先缓慢燃烧，然后到快燃尽的时候还剩下一堆没完成的任务，只能被推迟到下个迭代周期。

还有其他很多种情况，都能看出团队的不同问题。当然，绩效主要还是在各团队小组内部进行评比，每个小组通常会按照一定的比例分配 A/B/C，仅有一小部分需要几个团队来挣优质绩效的名额，而燃尽图就可以作为技术管理者评判团队的辅助手段。

为什么敏捷一直都是雷声大雨点小？

很重要的一个原因是，大部分团队在不了解敏捷核心的情况下，总是自以为是的进行简化，把非常关键的步骤精简掉了，导致最终敏捷流于形式，还浪费了时间，最后得出一个敏捷不靠谱的结论。

其次，敏捷教练也带来了一定的负面作用，由于国外的推崇，业界出现了专门的敏捷教练这个职业，比如我在第一次尝试敏捷的时候，公司就专门聘请了这样的教练来帮助我。然而，当时这个教练并不愿意参与到迭代内部，仅仅对流程和形式进行指导，让整个团队觉得这个人除了空有理论，百无一能，不久这个教练就被负面评价包围了，最后还影响了大家对敏捷的印象。

另外，部分团队成员会抵制敏捷，因为敏捷会使得所有工作变得透明，能力不足的成员会瞬间受到很大的压力，这种压力来自于团队整体。

最后，在实施敏捷的初期，相比于过去的管理方式，通常都是更费时间，而不是节省时间的。团队需要花时间适应这个变化，也需要做更多额外的工作，除了 coding，整个流程比之前多了迭代启动会、站立会议、随着任务状态的变化移动任务、最终的迭代总结会等，都需要花费额外的精力。从长期来看，敏捷会让迭代更快速，但在最开始的时候却是最容易被放弃的。

举个例子，我们的第一次实践最终也是以失败告终，上面四个问题都遇到了，但在第二次实践的时候，我们更加严格，并且在一次迭代中总结出的问题，第二次迭代时就能大为改善，极大的提高了团队对敏捷的评价，最终成功，给团队带来了巨大的变化。而作为团队的负责人，我也再没有因为给研发打绩效感到头疼，由于迭代中的表现每个人都有感知，绩效出来之后，大家都会比较信服。

或许实施敏捷对于团队来说是一个过程，但从我们团队的实践中可以看出，对打绩效帮助最大的其实在于团队整体透明度的提升，以及团队成员之间对彼此工作的了解，这使得相互之间的评价变得更客观。也许作为技术管理者你并不希望使用敏捷的方式，甚至不认为敏捷能极大的提升团队战斗力，但仍然可以尝试以下两个关键点：

使团队成员相互了解其他人的工作，而不是仅让一个人负责一个独立模块，每个人能够对其他人的工作提出意见；

在一定的迭代周期内，团队内部民主的选出大家认可的贡献最大的团队成员。

这两点是敏捷实践带给绩效考核最大的变化，这个变化是透明带来的，是团队认可的，是多维度的，也可以让技术领导者更加客观的看待自己团队中的每一位成员。

感谢你的收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~

作者简介

高琦，搜狐社交产品中心总经理，TGO 会员，2014 年加入搜狐，负责搜狐集团移动广告业务，负责搜狐移动端广告系统架构和性能优化，有效提升了业务指标，2017 年起，从零开始构建了搜狐资讯团队，产品在一年内日活突破百万。2018 年负责搜狐社交业务。