在软件开发者的职业生涯中,我们一定会遇上一两个产生负价值的同事。你也许会想:负价值是个什么鬼? 曾经就有过这样一个同事。在 6 个月的时间里,他对代码库进行了两次更改。而这些更改不但没有起到好的效果,反而影响了产品的多个其他功能。这样的开发者,他做的事情不仅没有任何效果,还会影响其他人的工作,这就是他们所产生的负价值。为了解决他所带来的问题,整个团队都不得不花费很长时间来解决问题。
在软件开发者的职业生涯中,我们一定会遇上一两个产生负价值的同事。你也许会想:负价值是个什么鬼?
曾经就有过这样一个同事。在 6 个月的时间里,他对代码库进行了两次更改。而这些更改不但没有起到好的效果,反而影响了产品的多个其他功能。
这样的开发者,他做的事情不仅没有任何效果,还会影响其他人的工作,这就是他们所产生的负价值。为了解决他所带来的问题,整个团队都不得不花费很长时间来解决问题。
相信你一定也遇到过这样的“坑队友”。
还有一种开发者,他们写的代码都能正常工作,但是他们写的代码却只有自己能看懂,团队中的其他人要想看懂他写的代码,要花费大量的时间去理解。这样的开发者,在某种程度上也是在贡献负价值。
我们来算一笔账: - 糟糕的开发者花费 5 个小时,写了一堆难以理解的代码。其他 4 名开发者为了看懂这些代码,每个人都花费了 10 个小时:
- 总花费时间: (4 * 10) + 5 = 40 + 5 = 45 小时
- 而好的开发者,可能花费 10 个小时写了清晰明了的代码,其他 4 名开发者只需要 1 个小时就能完全搞懂:
- 总花费时间:(4 * 1) + 10 = 4 + 10 = 14 小时
- 可节省时间: 45 - 14 = 31 小时
而且这些数字还有可能会大量增长。我曾经见过这样一个情况:由于代码写的太糟糕,一名优秀的开发者花了两周的时间才搞懂这部门代码;如果这部分代码写的清晰明了的话,这名开发者只需要 2 个小时就能搞懂。
还有一种情况,也是最可怕的情况,那就是这些负价值开发者不愿意学习新的东西,而且他还是团队中的领导。由于不喜欢新东西,他会一直使用过时的代码编写方法,而且要求团队中的其他人要向他看齐。结果就是,整个团队中的每一个人都成为了负价值开发者。
我就有过类似的经历,我以前供职的公司中,本来所有人都在使用一种代码编写方式,这种编写方式每解决一个问题需要我们花费数个小时的时间。后来,有一个同事向我们介绍了一种新的方法,新方法解决问题只需要几分钟。但是,团队中那个做决策的资深开发者却不让我们使用这个新方法,因为他不喜欢改变。
大多数人在工作的时候,都希望能有一些成就感,我们希望感到自己的时间没有被浪费。对于开发者来说,最大的成就感就是做出有价值的软件。
我们也希望能和有才能的人一起共事。而如果团队中有一个这样的“拖油瓶”,开发者会感到非常不舒服。
对于开发者个人来说,如果团队中真的有这样一个负价值开发者,这个问题也很好解决:换个工作,毕竟市场对于开发者的需求程度很高。但是对于企业来说,这绝对是一个灾难。
那么话说回来,这些负价值开发者当初是如何找到工作的?一部分原因,是企业的面试流程设计的不够完善。还有一部分原因,那就是企业总是在不知不觉的降低自己的雇佣标准。
有的时候,企业会发现自己有大量的工作要做,而且时间紧迫,而公司内的开发者数量不够。在这种时候,企业最容易降低自己的招聘标准。
某些企业在这种情况下,就会进行“恐慌招聘”。可惜的是,并不是所有开发者都能给团队带来正面价值。我理解企业在用人方面的急迫性,但是恐慌招聘无法解决问题。坏的开发者不仅会拖慢你的速度,还会让那些优秀的开发者离开你的团队。
|