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

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

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

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

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

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

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

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

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

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

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

余下全文(1/3)
分享这篇文章:

请关注我们:

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注