马蜂窝张矗：我对技术团队绩效考核管理的几点思考

由于程序员的工作性质，使他们的工作时常很难量化。对于技术管理者来说，想要做好量化，应该从哪几个方面出发呢？本文为 2019 年 3 月 23 日马蜂窝技术副总裁张矗在由 TGO 鲲鹏会主办的 GTLC 北京站发表的演讲整理，希望可以通过文本和各位技术管理者一起思考。

口述 | 张矗

整理 | Rainie Liu

张矗，马蜂窝技术副总裁，北京理工大学工学硕士，TGO 鲲鹏会会员，拥有 10 多年的互联网技术和管理经验。2000 年加入新浪网；2007 年作为联合创始人参与创建开心网；2012 年加入马蜂窝旅游网，担任技术副总裁。

大家好，我是来自马蜂窝的张矗。在座的很多朋友可能都用过我的一些 App，2012 年我来到马蜂窝进行二次创业，我的整个工作经历都是集中在互联网行业，今天分享内容更多的适合在互联网领域，其他领域的同学可以参考一下。

无法衡量就无法管理

无法衡量就无法管理，这句话是管理学大师——彼得·德鲁克说的。其实后面还有一句话叫，无法管理就无法改进它。今天分享的主题主要是关于技术研发人员在绩效考核上如何进行衡量、量化。

我的分享主要分为三个部分，第一部分，对技术研发人员绩效考核这个事情的难度在哪里；第二部分，在做绩效考核这个事情上要去做量化的绩效考核，以及它的误区；第三部分，是在马蜂窝实践中所总结出来的一些思考。

绩效考核量化，难于上青天

由于程序员工作性质，很多时候工作无法进行量化，那么对于技术管理者来说，做好绩效考核量化就好比上青天。那么想要做好量化，应该从哪几个方面出发呢？

1、创造性工作

首先，我们需要意识到自己所做的工作本质上是创造性工作、脑力劳动。脑力劳动是需要思考的，是需要灵感的，可是你的个人情绪、工作节奏、团队状况都会影响整个团队的产出，你也不知道灵感什么时候能够迸发，创造性的工作在互联网领域其实是需要很多的试错，试错的成本也是很难预估的。

2、黑盒

技术研发的很多工作成果其实是一个黑盒。我们都知道用一些功能性的黑盒进行测试，但你并不知道黑盒后面真正发生了什么。同样是一个列表页，过去可能是排序，但今天可能变成推荐算法，工作量是不可同日而语的。

如果我们想用白盒测试，那么将会给成本带来很大的提升。有一个经常发生的现象，如果你是用外行考核内行的时候，黑盒效应会更加明显。

3、经验量化

经验对互联网行业中的工程师来说，作用是非常巨大的。举个例子，就像外科手术，有经验的大夫一刀下去，有问题的组织会给你清理得干干净净，并且术后对于病人的生活质量是有很大的保障和提升；没有经验的大夫可能会下刀更多，也没有清理干净，如果要让病人接受这样的手术还不如不动手术，这个类比放在代码重构是特别典型的事情。经验这个事情也很复杂，因为它很可能是局部的，你只是对某个领域有经验而已，并且它也是不稳定的，可能这一刀还可以，下一刀未必行。

4、时间管理

时间管理对于工程师的工作产能来说是非常重要的。很多工程师和设计师每天都会因为各种会议、面试，以及需求不断地被打扰，大家都身处其中，谁催得着急一些，那我就优先做谁的工作，只有到夜深人静的时候才能做一些自己真正想做的事情。那么不擅长于掌握时间管理的工程师经常会陷入应激式工作的方法，而不是统筹式工作的方法。这种多任务的工作，一件任务没有完成，另外一件任务接踵而来，会给心里形成一个巨大的压力，本质上是会造成崩溃的，并陷入绝望的状态，工程师应该都很清楚多任务系统切换起来效率影响也是巨大的。

5、协作

工程师很多时候也不是独自孤立地在工作，他需要与产品、设计师、测试、商务人员、销售共同完成互联网作品的呈现。在这个过程中，需要彼此间具有同理心，互相去理解对方，帮助对方弥补思维的缺陷，最终完成这件事情。在这个过程中你很难去比较谁的贡献更大，谁的工作更多，而且这里面还有不少很重要的岗位，以及它们还具有年龄的差异。

现在我们看各种发布会时，会发现不少 90 后的产品经理已经上位了。相信今天来到本次 GTLC 全球技术领导力峰会北京站的参会者大多还是 80 后、85 后的技术管理者，可能有些在场同学已经开始着急如何与 90 后产品经理一块 PK 了，这件事情已经发生了，如果你一味的忧愁可能会让事情变得更加复杂。

技术工作量化的误区有哪些？

1、代码行数

大部分朋友都知道在技术工作量化上第一个误区是代码行数。当前我们常常对工程师提出要求——把代码写得精简易读，但有些“经验丰富”的工程师仍然很容易地在代码里加入很多没用的东西，或者是用工具实现代码行数的增加，以此来体现“彰显”工作量。

2、BUG 数量

大家会觉得考察 BUG 数量也不是一个好的方法，虽然在实践过程中会不断地提出来用 BUG 数量进行考核，但当你真正用 BUG 数量考核时，通常会形成很不好的引导。因为很可能会出现，工作越多，BUG 数量就会越多的情况，从长期来看这样的引导是无法激励大家爆发出更大的潜力。

3、项目完成时间

项目完成时间的考核方法具有一定的迷惑性。我们大多都喜欢把项目提前完成的团队，但项目完成时间通常是由项目执行者来决定的。如果用项目完成时间来考核大家，我们一定会使用保守估计时间的方式，为自己留一段时间缓冲。

4、潜力>产出

2018 年我加入 TGO 鲲鹏会时，在一次分享中，搜狐的高琦老师（高琦，搜狐高级技术经理 & TGO 鲲鹏会会员）讲解燃尽图时，从敏捷的角度看，燃尽图是一条倾向于直线的角度，如果我们倾向于把项目的预估时间和实际预估时间趋于此，用它们作为考核也会很有问题。

总结来看，我们希望考核是激发大家更大的工作潜力，而不是引导大家回归工作或者是逃避问题。

关于这些年我在马蜂窝技术工作的绩效考核思考

明白了难度和误区，那么这些年里我又产生哪些思考呢？

1、关注目标，而不是任务

我曾经工作的第一家公司也实施过 KPI，但是我觉得是非常失败的。因为它像一场运动，我完全预料不到结果，就这么过去了。

而在上一家公司，我们用到了 O（目的）G（目标）S（策略）M（衡量和检测）的方法，这个方法实施得相当不错，其中最核心的部分是 O 和 G 的制定过程，再到 S 和 M 的拆解，但 OGSM 的方法在互联网圈没有 KPI 和 OKR 这么流行，因此大家了解得也不多。

最近一两年，马蜂窝事业部也开始尝试使用 OKR 的方式进行绩效考核。因为 OKR 大家都比较了解，并且 OKR 的概念已经存在了很长时间，现在又不断地被提出来，去年起百度也是全面开始转向 OKR。

由此，我想到了如何量化我们的绩效指标上相当重要、熟悉的一个话语，关注目标，而不是任务。

我们经常说我发布了什么，启动了什么，创建了什么，上线了什么，这些都是任务而不是目标。目标应该是我将某某指标从 X 转变成了 Y，只有这样才是目标，目标应该是可量化的。

举一个内部的例子给大家分享一下，在马蜂窝内部有很多的员工使用的系统，如 OA 系统、企业邮箱、代码管理，以及各个事业部他们自己运营的系统，这些对于员工来说是相当复杂的，需要去记住每个系统的密码，以及我需要在哪一处登录。为了给大家提供一个更加安全、便捷的登录方式，我们计划去打造统一登录的 SCS 系统，并且把所有第三方的系统和我们自己研发的系统的登录都要切换到统一的登录系统中。

一开始，我们团队认为只要完成系统研发任务就完成了，可我们的目标并不是去研发一套 SCS 系统，而是要将没有使用 SCS 的系统从 50 个减少为 3 个，以此达到安全和便捷的目的，但是我们一开始并没有注意从目标出发。在完成研发任务的过程中，团队也解决了很多的问题，包括一开始没有想到的场景，以及思维转化的过程。渐渐地，研发统一登录的 SCS 系统变得不是重点了，而变成我们要去切换某个系统，推进第三方研发，这样的转化使得我们的工作成果变得更有实际意义。

马蜂窝对于团队的要求是，不光要求你会写代码，还需要具备沟通协调的能力，以及规范的能力。我们可以看看业务团队，或者支持业务团队的研发团队，他们的指标需要去确定，业务团队的目标就是整个团队的目标，业务团队的目标就应该成为支撑这个业务团队和研发团队的主要目标。

有一种声音会说业务团队的目标完成好或者不好，有些时候跟研发一点关系都没有，这会让我们形成阶段性的短视现象，我们更应该从长期来看它是否有更公平和有效的方法。但短期误判也是倒逼我们审视业务团队和目标很重要的方法，因为团队是需要长期投资才能看到价值。比如说管理团队，我们也需要帮助他们找到一些可量化的目标，这个可量化的目标包括系统的稳定性标准、性能维持标准，员工满意度标准等。

2、平衡

主要的方法确定了我们也需要加入一些平衡的因素来解决我们实际操作中的困难，那么我们该如何平衡呢？

只关注业务的目标确实会形成短期的现象，如团队贡献、考勤，但这两个目标都具备一个特点，它是一种阶段性的状态，它会阶段性的好或者是不好。

如团队贡献，你这个月在团队内部做了一个分享，你可能就拿到团队贡献；你帮助这个团队组织了一次团建，你也具备这样的团队贡献。再比如，考勤并不是让大家给自己的兄弟们上下班打卡，它可以带着主观的因素，你可以观察谁经常迟到早退，这是你能感受到的主观印象，你也会感受到有些人天天为了项目加班到很晚。这个过程你还需要识别有一些同学他是天天加班的，是为了混一个晚餐或者是打车费，这个鉴别还是比较容易的。

找平衡的过程也是把我们管理者的主观判断落实在客观标准的过程，团队中我们都会喜欢在群里积极回答别人的问题，乐于给大家做分享的同学，他们对团队的氛围贡献是非常有帮助的，因此更应该在团队贡献上拿到更多的分数。

有的同学会说把个人成长、学习能力、解决问题的能力这样的因素纳入到绩效考核的指标上来，但是我认为这是不妥的。个人成长这个事情很难衡量，这个月我看了一本书叫《成长》，在书中作者提到，他将能力范畴指标，与成绩晋升和基础薪资挂钩会显得更有效一些。

3、层级区分

当你跟团队成员设计目标的时候，一定要关注他当前所在的层级。

初级工程师，按时完成工作、写好代码、完成测试，以及做好文档的编撰就是他的目标，那你要从这个方向上想好怎么给他量化；

稍微有一些年限的工程师，需要做好架构设计、规避项目的风险，那么你可能需要从这些方面给他做好设计；

更资深的工程师或者是技术经理位，他需要做到判断需求的轻重缓急，做好项目的安排，以及项目上线后的跟踪和整个状态的反馈。

总之，对于越是高级的人员，他的绩效考核越是要跟业务 KPI 关联起来，当给他设计目标的时，一定要想他的目标对他的上级、部门、公司、用户和社会的意义和价值所在。

现在我们能看见有很多工程师，他的专业技能已经达到了高级的水平，但是在理解上级目标，确定自己的目标或者是行动还没跟上。“巨婴”就是指，需要哄着才能干活的程序员。比如我们上线一个新的功能，大家在上线前也都很努力，为了完成任务，加班熬夜终于在深夜把这个项目推上线，但上线后很多工程师没有对新的数据表现和用户行为做跟踪。现在大家的分工越来越细，很多这样的活都是产品经理或者是公司帮助你，那么这样的工程师必然沦为螺丝钉。

我们只有不断拓宽自己的眼界，提升自己的视野，才能使我们不断从初级向高级进化。

4、评估周期

最后一点思考就是对于评估周期的思考。我们都很希望上级能告诉我，未来一个季度该做些什么工作。举个例子，比如某个团队会支持很多客户的工作，但是他只知道我当前有这样的事，这个月差不多能干完，接下来两个月该干什么还不太确定。这时，我给大家的建议是不妨把考核的周期缩短，按月来考核。考核的内容包括这个月实际做的工作，实际支持的客户的成果等。或者，你也可以对下个月的挖掘作为考核指标，不超过三个月进行一次考核。在互联网领域里，三个月一次考核我认为也是上限，当你对未来不是那么确定时，不妨缩短考核周期。

总体来看，想要通过业务量化研发人员的工作，我们首先是完成思维转化，这样的转化对那些具有综合能力的研发人员，或综合能力比较强的研发人员更有利的；对于管理者来说，你要思考如何用其他的方法来确保搞钻研的科学家们不会被亏待，以此确保你的长期利益和短期利益的平衡，最终才能达到长期利益的最大化。

最后，我们再回到关注目标这个词，如果大家在关注目标，实践关注目标这个事情碰到一些困难时，我也给大家提一个建议，你可以多想想老板都在想什么，谢谢大家。

（本文转载自公众微信号：TGO）

关注马蜂窝技术公众号，查看演讲视频 + PPT