处理坏苹果

RobertMieson发来了个关于项目病理学的故事。

我所在的团队曾经开发过一个基于互联网的职位申请以及筛选系统（客户称之为“职位零售亭”）。我们的团队和客户商定了采用Windows、Apache、 PHP5和ZendFramework来实现这个“职位零售亭”——所有的团队成员都达成了一致意见，除了一个人，我在这里就叫他“Joe”。在整个技术审议阶段，Joe不停地鼓吹采用JavaScript，即便客户很明确地表示他们希望“职位零售亭”的绝大部分实现都采用服务器端技术，并且所有的校验都应该采用服务器端技术来完成。

事实上，客户已经就这个问题签字确认了。然而，这没能阻止Joe鼓吹JavaScript——他的方式还很粗暴。每当我们的项目在前进的道路上遇到点麻烦，Joe就会发表他的长篇大论。他宣扬，如果我们采用了JavaScript来实现这个“职位零售亭”，我们的日子就会轻松很多。Joe会不停地吵吵嚷嚷，说我们如何如何完全做错了，因为我们没有采用JavaScript。他甚至不屑于了解我们实际正在使用的技术。而且每当团队中有人试图温和地把Joe带回到大部队时（通常通过电子邮件的方式），他就会冲着那个可怜的家伙大发雷霆。以Joe这种力挺 JavaScript到了偏执的程度，他经常会发出诸如“好吧，如果我们用JavaScript来做的话……”之类的评论。他已经令人讨厌到了这种程度，以至于如果他直接退出（或者辞职，或者被解雇），整个项目组的境况将会更好。

读完这个故事后，我努力克制自己的身体不往前倾。我把手放在下巴下做沉思状，皱着眉头，然后想问问：你们试过用JavaScript吗？

Robert认为这是一个关于技术依赖的警示性故事，但我看到了另外的一些东西：一个有问题的团队成员，也就是一个典型的“坏苹果”。如果把一个坏苹果留在一筐好苹果里，结果你将得到一筐坏苹果，这就是“坏苹果法则”。一个人的态度将影响到一个团队。如果想使你的企业成功，那么你就必须有一个积极进取的团队。

我相信Joe曾经有过最好的意图，但当你积极地对项目宣战并以你的团队成员为敌时，你就成了项目的一个负担。

导语：

问题员工对于项目的损耗是很严重的，我们应该如何识别问题员工呢？这并不像想象的那么困难。我有一个朋友曾经把他团队中的某个人比喻成“癌症”。当你或者团队中的任何其他人使用像“癌症”这样一个词来比喻某个团队成员时，你的项目就已经有严重的病变了。你不必和团队中的每个人都成为朋友，当然那有一定的帮助，但对个人和职业一定程度的基本尊重才是任何团队正常运转所必需的。

Steve McConnell列举了一些警报信号，用以识别你的团队中是否有“坏苹果”。

他们掩饰自己的无知，而不是尽力去向他们的团队伙伴学习。他们会说：“我不知道该怎么解释我的设计。我只知道它能正常工作。”或者“我的代码太复杂了，没办法测试。”

他们对个人隐私有着过度的渴望。他们会说：“我不需要任何人来查看我的代码。”

他们很在意自己的地盘。他们会说：“我代码里的问题没人能修复。但我现在太忙了，没时间去管它们。我打算下周处理它们。”

他们抱怨团队所做的决定，并且在团队已继续前进了很久之后还会重拾旧题。他们会说：“我还是认为，我们应该回过头去修改上个月讨论的那个设计。我们当初选择的那个是行不通的。”