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

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

口述 | 张矗

整理 | Rainie Liu

 

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

你们好，我是来自马蜂窝的张矗。在座的不少朋友可能都用过个人一些 App，2012 年我来到马蜂窝进行二次创业，个人整个工做经历都是集中在互联网行业，今天分享内容更多的适合在互联网领域，其余领域的同窗能够参考一下。

 

没法衡量就没法管理

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

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

 

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

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

一、创造性工做

首先，咱们须要意识到本身所作的工做本质上是创造性工做、脑力劳动。脑力劳动是须要思考的，是须要灵感的，但是你的我的情绪、工做节奏、团队情况都会影响整个团队的产出，你也不知道灵感何时可以迸发，创造性的工做在互联网领域实际上是须要不少的试错，试错的成本也是很难预估的。

二、黑盒

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

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

三、经验量化

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

四、时间管理

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

五、协做

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

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

 

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

一、代码行数

 

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

二、BUG 数量

 

你们会以为考察 BUG 数量也不是一个好的方法，虽然在实践过程当中会不断地提出来用 BUG 数量进行考核，但当你真正用 BUG 数量考核时，一般会造成很很差的引导。由于极可能会出现，工做越多，BUG 数量就会越多的状况，从长期来看这样的引导是没法激励你们爆发出更大的潜力。

三、项目完成时间

 

项目完成时间的考核方法具备必定的迷惑性。咱们大多都喜欢把项目提早完成的团队，但项目完成时间一般是由项目执行者来决定的。若是用项目完成时间来考核你们，咱们必定会使用保守估计时间的方式，为本身留一段时间缓冲。

四、潜力>产出

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

总结来看，咱们但愿考核是激发你们更大的工做潜力，而不是引导你们回归工做或者是逃避问题。

 

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

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

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

我曾经工做的第一家公司也实施过 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 系统变得不是重点了，而变成咱们要去切换某个系统，推动第三方研发，这样的转化使得咱们的工做成果变得更有实际意义。

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

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

二、平衡

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

 

只关注业务的目标确实会造成短时间的现象，如团队贡献、考勤，但这两个目标都具有一个特色，它是一种阶段性的状态，它会阶段性的好或者是很差。

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

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

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

三、层级区分

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

 

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

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

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

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

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

咱们只有不断拓宽本身的眼界，提高本身的视野，才能使咱们不断从初级向高级进化。

四、评估周期

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

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

最后，咱们再回到关注目标这个词，若是你们在关注目标，实践关注目标这个事情碰到一些困难时，我也给你们提一个建议，你能够多想一想老板都在想什么，谢谢你们。

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

 

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