高效完成任务不加班，老板却给加班的涨薪

高效完成任务不加班涨薪| 2016-01-28

在人们干体力活的时候，要评估他们干活有多努力并不是一件难事。你可以看到他们的动作和汗水。你也可以看到他们工作的结果：砖墙不断变高，地上的洞不断变大。分辨和奖励辛勤工作是人类的本能，这也是耐力运动如此迷人的原因之一。但如果像对待体力工作者一样，管理那些技术创新型员工，却往往会出现问题。因为高效的脑力工作者通常看起来并不是那么努力工作。

在 2004 年的时候，我作为初级开发者跟着一个很大的团队，为一家有线电视公司的计费和供应系统提供服务。就像所有的大系统一样，它由许多相对独立的部分组成，而每个部分则由不同的个人或团队来负责。其中模拟电视和数字电视的供应系统几乎是完全分开的，分别由不同的团队负责。

模拟电视团队决定基于微软 Biztalk 的一个早期版本来建立他们的系统。除了公司里的四个人，还有一支来自微软的团队，大家共同开发产品。他们看上去都工作得非常努力。人们常常可以看见他们在双休日工作到深夜。每个人都可以停下手中的活去帮助解决产品问题，他们常常扎堆在某一个人的办公桌前，就系统中哪些可能出错，或者如何解决某些问题提出自己的建议。他们一直非常活跃，任何人只要看一眼就能看出，他们不仅仅是像个团队一样地聚在一起，而是所有人都非常非常努力地在工作。

数字电视供应团队却完全不同。所有的代码几乎是一个家伙写的，我们叫他戴夫吧。而我是团队初级的维护开发者。起初我在理解代码的时候，碰到了很多麻烦。没有用一段长代码来描述整个过程是怎么发生的，反而是大量的小类和只有几行代码的方法。我的一些同事抱怨戴夫把事情搞得太过繁琐了。但是戴夫却很关照我，建议我阅读一些面向对象编程的书籍。他教我设计模式、SOLID 原则和单元测试。很快那些代码开始变得合理了，并且随着学习的深入，我越来越觉得他的设计是如此的优雅。这些设计在产品中并没有出错，反而让所有任务都完成的很顺利。由于修改代码变得相对方便，使得添加新特性也变得没有那么痛苦了。通过单元测试降低了产品中出现 BUG 的几率。

结果就是，我们看起来并没有非常努力地工作。我下午 5 点 30 分回家，从来不在双休日加班，我们从来不花费大量的时间聚在办公桌前，讨论那些失败的产品系统是哪里出错了。在旁人看来，我们的任务肯定比模拟电视那帮家伙的任务轻松的多。但事实是，我们的需求非常相似，只是我们软件的设计和实现更好，以及更好的配套措施，尤其是单元测试。

领导们宣布要根据大家的表现加薪。当轮到我的时候，老板解释说为了公平起见，只能给真正努力工作的人加薪，比起那些夜晚和双休日都在努力工作的英雄们，我们的团队看起来实在不怎么把公司的事儿放在心上。

有线电视公司是一个特殊的地方，软件设计的好坏，团队的表现，这些你可以看到最直接的比较。这是在绝大多数的组织里都观察不到的。即使一个家伙满头大汗地工作到很晚，不停地在解决问题，也很难保证一个非常复杂的系统可以正常工作，它可能根本就运行不了。除非你可以财大气粗到请好几个团队来相互竞争，但是拜托，不会有人真的这么做的。相反，另一个坐在角落里每天从 9 点工作到 5 点，每天都在上网的家伙又如何？他只是非常精通写稳定可靠的代码吗？还是他的工作比其他人的轻松？在旁人眼里，第一个家伙工作努力，第二个家伙则不然。努力工作是好事，懒惰是坏事，真是这样吗？

我想说其实努力工作的现象常常是失败的前兆。在一个有压力，容易被打扰的环境下，很难做好软件开发。长时间的工作也不是什么好主意。有时候，解决一个难题最好的办法是不要去想它，出去散个步，或者更好的方法是去睡个好觉让你的潜意识去解决它。我最喜欢的书籍里有一本叫《一个数学家的辩白》（A Mathematician’s Apology），是G.H.哈代写的，他是 20 世纪英国数学家的领军人物之一。在书里他描述了他的日常：早上工作 4 个小时，下午去看蟋蟀。他说每天超过 4 个小时的脑力活动既没有意义也没有效率。

我想对经理们说，评价一个员工要根据他们的工作成果，软件是否运行，而不是他们看起来是否努力工作。如果要凭直觉去判断的话，也许不要坐在你的开发者周围比较好，免除了那些主观因素的干扰，你可能会对他们的工作成果有更好的认识。远程工作尤其受益；因为你将不得不根据员工们的工作成果去评估他们，而不是简单地看他们坐在办公桌前花 8 个小时折腾 IDE，或者“热心地”互相围在一块儿提供“有用的”建议。

本文文字及图片出自伯乐在线