论文部分内容阅读
怎样能促使技术团队实现高效、紧密的合作？该如何处理团队中的“坏苹果”？知名技术博客作家、Stack Overflow创始人Jeff Atwood有三十多年的职业编程经验，下面是他的切身经历分享。
谁是“坏苹果”
Robert Mieson发来了个关于项目病理学的故事。
我所在的团队曾经开发过一个基于互联网的职位申请以及筛选系统（客户称之为“职位零售亭”）。我们的团队和客户商定了采用Windows、Apache、PHP5和Zend Framework来实现这个“职位零售亭”—所有的团队成员都达成了一致意见，除了一个人，我在这里就叫他“Joe”。在整个技术审议阶段，Joe不停地鼓吹采用t，即便客户很明确地表示他们希望“职位零售亭”的绝大部分实现都采用服务器端技术，并且所有的校验都应该采用服务器端技术来完成。
事实上，客户已经就这个问题签字确认了。然而，这没能阻止Joe鼓吹Java t——他的方式还很粗暴。每当我们的项目在前进的道路上遇到点麻烦，Joe就会发表他的长篇大论。他宣扬，如果我们采用了Java t来实现这个“职位零售亭”，我们的日子就会轻松很多。Joe会不停地吵吵嚷嚷，说我们如何如何完全做错了，因为我们没有采用Java t。他甚至不屑于了解我们实际正在使用的技术。而且每当团队中有人试图温和地把Joe带回到大部队时（通常通过电子邮件的方式），他就会冲着那个可怜的家伙大发雷霆。以Joe这种力挺Java t到了偏执的程度，他经常会发出诸如“好吧，如果我们用Java t来做的话……”之类的评论。他已经令人讨厌到了这种程度，以至于如果他直接退出（或者辞职，或者被解雇），整个项目组的境况将会更好。
读完这个故事后，我努力克制自己的身体不往前倾。我把手放在下巴下做沉思状，皱着眉头，然后想问问：你们试过用Java t吗？
Robert认为这是一个关于技术依赖的警示性故事，但我看到了另外的一些东西：一个有问题的团队成员，也就是一个典型的“坏苹果”。如果把一个坏苹果留在一筐好苹果里，结果你将得到一筐坏苹果，这就是“坏苹果法则”。一个人的态度将影响到一个团队。如果想使你的企业成功，那么你就必须有一个积极进取的团队。
我相信Joe曾经有过最好的意图，但当你积极地对项目宣战并以你的团队成员为敌时，你就成了项目的一个负担。
问题员工对于项目的损耗是很严重的，我们应该如何识别问题员工呢？这并不像想象的那么困难。我有一个朋友曾经把他团队中的某个人比喻成“癌症”。当你或者团队中的任何其他人使用像“癌症”这样一个词来比喻某个团队成员时，你的项目就已经有严重的病变了。你不必和团队中的每个人都成为朋友，当然那有一定的帮助，但对个人和职业一定程度的基本尊重才是任何团队正常运转所必需的。
Steve Mc Connell列举了一些警报信号，用以识别你的团队中是否有“坏苹果”：
①他们掩饰自己的无知，而不是尽力去向他们的团队伙伴学习。他们会说：“我不知道该怎么解释我的设计。我只知道它能正常工作。”或者“我的代码太复杂了，没办法测试。”
②他们对个人隐私有着过度的渴望。他们会说：“我不需要任何人来查看我的代码。”
③他们很在意自己的地盘。他们会说：“我代码里的问题没人能修复。但我现在太忙了，没时间去管它们。我打算下周处理它们。”
④他们抱怨团队所做的决定，并且在团队已继续前进了很久之后还会重拾旧题。他们会说：“我还是认为，我们应该回过头去修改上个月讨论的那个设计。我们当初选择的那个是行不通的。”
⑤所有其他的团队成员都在传说关于同一个人的俏皮话或者抱怨他。软件开发人员通常不会直接抱怨，因此当你听到很多俏皮话时，你必须去查探是否有什么状况发生。
⑥他们不会积极投入团队的行动。在我经历的一个项目中，就在我们第一个重要的截止日期的前两天，有个开发人员突然要求请一天假。原因是什么呢？他想那天去参加邻城的一个男装展销会——那清晰地表明他并没有融入整个团队。
让我把我的观点说得清清楚楚：如果你的团队主管或者经理没有处理项目中的“坏苹果”，那他就是玩忽职守。
你绝不应该害怕去调动（甚至解雇）那些从内心不为团队利益考虑的人。你可以培养一个人的技能，但很难培养出积极的态度。这些具有破坏性的人格在一个项目里逗留得越久，它们的影响就会越大。它们会以代码、关系和交流的形式，慢慢地把毒害传播到项目的每一个角落。
把某个人从团队中调走是很痛苦的。这件事对任何人来说都没有趣。但当你意识到你本应该在六个月前就把某人调走时，此时你就更加痛苦了。
坏苹果是团队的毒药
有一期《美国生活》采访了华盛顿大学的一位教授Will Felps，他曾经组织过一次社会学实验来证明“坏苹果”出奇强大的影响力。
大学生们每4人一组，组建了几个团队，并被指派了一个任务：在45分钟之内完成一些基本的管理决定。为了激励团队，他们被告知，表现最好的那个团队每人都能得到100美元的奖励。然而，他们始料未及的是，其中某些组里的第四位成员并不是学生。他们是被雇来扮演“坏苹果”的演员，并且具备下面其中之一的性格。
沮丧的悲观主义者。他会抱怨任务太无趣，并且公开质疑团队的取胜能力。
混球。他会说其他人的想法不够好，但自己又拿不出更好的方案。他还会说：“你们这些人都应该听我这个专家的。”
懒鬼。他会说“随便”以及“我无所谓”。
对于实验中的这些人物性格，传统的观点认为它们完全不会对团体有太大的影响。团体是强有力的，“团体动力”是强大的，因此团体应该主导个人，而不是反过来。如果追溯到几十年以前，有太多的研究表明，个人是遵从团体的价值观和准则的。
但是，Will Felps发现了相反的结果。
毫无疑问，有“坏苹果”的团队会表现得比较差。尽管他们所在的有些团队非常有天赋、非常聪明、非常友爱，但这些都无济于事。Will Felps发现“坏苹果”的行为有着深刻的影响——有“坏苹果”的团队比其他团队表现得差30%～40%。在有“坏苹果”的团队中，人们会争吵甚至打起来，他们没有共享相关的信息，交流得也比较少。
更糟糕的是，其他团队成员开始呈现“坏苹果”的特征。当“坏苹果”是一个混球时，其他团队成员也开始表现得像混球。当他是一个懒鬼时，他们也开始懈怠。而且他们不只是针对“坏苹果”才有这样的反应。他们相互之间也会像“坏苹果”那样彼此对待，足见“溢出效应”在起作用。
简而言之，他们的发现就是，团队的绩效可以从团队里最差的那位成员身上准确地预测出来。不管团队里最好的成员有多棒，也不管团队里的普通成员怎么样，这些都无关紧要。根本的决定因素是要看团队里最差的那位成员怎么样。拥有最差成员的团队也会表现得最差劲。
自我认知永远都是第一步。如果你不能判断出谁是团队里的“坏苹果”，那他有可能就是你自己。反思一下你在自己团队里的行为吧——你是否“失足”掉进了这些负面的“坏苹果”行为模式，哪怕只有一点点？最显然的解决办法是从源头上解决问题—除掉害群之马。
即使你自己就是那匹害群之马！
谁是“坏苹果”
Robert Mieson发来了个关于项目病理学的故事。
我所在的团队曾经开发过一个基于互联网的职位申请以及筛选系统（客户称之为“职位零售亭”）。我们的团队和客户商定了采用Windows、Apache、PHP5和Zend Framework来实现这个“职位零售亭”—所有的团队成员都达成了一致意见，除了一个人，我在这里就叫他“Joe”。在整个技术审议阶段，Joe不停地鼓吹采用t，即便客户很明确地表示他们希望“职位零售亭”的绝大部分实现都采用服务器端技术，并且所有的校验都应该采用服务器端技术来完成。
事实上，客户已经就这个问题签字确认了。然而，这没能阻止Joe鼓吹Java t——他的方式还很粗暴。每当我们的项目在前进的道路上遇到点麻烦，Joe就会发表他的长篇大论。他宣扬，如果我们采用了Java t来实现这个“职位零售亭”，我们的日子就会轻松很多。Joe会不停地吵吵嚷嚷，说我们如何如何完全做错了，因为我们没有采用Java t。他甚至不屑于了解我们实际正在使用的技术。而且每当团队中有人试图温和地把Joe带回到大部队时（通常通过电子邮件的方式），他就会冲着那个可怜的家伙大发雷霆。以Joe这种力挺Java t到了偏执的程度，他经常会发出诸如“好吧，如果我们用Java t来做的话……”之类的评论。他已经令人讨厌到了这种程度，以至于如果他直接退出（或者辞职，或者被解雇），整个项目组的境况将会更好。
读完这个故事后，我努力克制自己的身体不往前倾。我把手放在下巴下做沉思状，皱着眉头，然后想问问：你们试过用Java t吗？
Robert认为这是一个关于技术依赖的警示性故事，但我看到了另外的一些东西：一个有问题的团队成员，也就是一个典型的“坏苹果”。如果把一个坏苹果留在一筐好苹果里，结果你将得到一筐坏苹果，这就是“坏苹果法则”。一个人的态度将影响到一个团队。如果想使你的企业成功，那么你就必须有一个积极进取的团队。
我相信Joe曾经有过最好的意图，但当你积极地对项目宣战并以你的团队成员为敌时，你就成了项目的一个负担。
问题员工对于项目的损耗是很严重的，我们应该如何识别问题员工呢？这并不像想象的那么困难。我有一个朋友曾经把他团队中的某个人比喻成“癌症”。当你或者团队中的任何其他人使用像“癌症”这样一个词来比喻某个团队成员时，你的项目就已经有严重的病变了。你不必和团队中的每个人都成为朋友，当然那有一定的帮助，但对个人和职业一定程度的基本尊重才是任何团队正常运转所必需的。
Steve Mc Connell列举了一些警报信号，用以识别你的团队中是否有“坏苹果”：
①他们掩饰自己的无知，而不是尽力去向他们的团队伙伴学习。他们会说：“我不知道该怎么解释我的设计。我只知道它能正常工作。”或者“我的代码太复杂了，没办法测试。”
②他们对个人隐私有着过度的渴望。他们会说：“我不需要任何人来查看我的代码。”
③他们很在意自己的地盘。他们会说：“我代码里的问题没人能修复。但我现在太忙了，没时间去管它们。我打算下周处理它们。”
④他们抱怨团队所做的决定，并且在团队已继续前进了很久之后还会重拾旧题。他们会说：“我还是认为，我们应该回过头去修改上个月讨论的那个设计。我们当初选择的那个是行不通的。”
⑤所有其他的团队成员都在传说关于同一个人的俏皮话或者抱怨他。软件开发人员通常不会直接抱怨，因此当你听到很多俏皮话时，你必须去查探是否有什么状况发生。
⑥他们不会积极投入团队的行动。在我经历的一个项目中，就在我们第一个重要的截止日期的前两天，有个开发人员突然要求请一天假。原因是什么呢？他想那天去参加邻城的一个男装展销会——那清晰地表明他并没有融入整个团队。
让我把我的观点说得清清楚楚：如果你的团队主管或者经理没有处理项目中的“坏苹果”，那他就是玩忽职守。
你绝不应该害怕去调动（甚至解雇）那些从内心不为团队利益考虑的人。你可以培养一个人的技能，但很难培养出积极的态度。这些具有破坏性的人格在一个项目里逗留得越久，它们的影响就会越大。它们会以代码、关系和交流的形式，慢慢地把毒害传播到项目的每一个角落。
把某个人从团队中调走是很痛苦的。这件事对任何人来说都没有趣。但当你意识到你本应该在六个月前就把某人调走时，此时你就更加痛苦了。
坏苹果是团队的毒药
有一期《美国生活》采访了华盛顿大学的一位教授Will Felps，他曾经组织过一次社会学实验来证明“坏苹果”出奇强大的影响力。
大学生们每4人一组，组建了几个团队，并被指派了一个任务：在45分钟之内完成一些基本的管理决定。为了激励团队，他们被告知，表现最好的那个团队每人都能得到100美元的奖励。然而，他们始料未及的是，其中某些组里的第四位成员并不是学生。他们是被雇来扮演“坏苹果”的演员，并且具备下面其中之一的性格。
沮丧的悲观主义者。他会抱怨任务太无趣，并且公开质疑团队的取胜能力。
混球。他会说其他人的想法不够好，但自己又拿不出更好的方案。他还会说：“你们这些人都应该听我这个专家的。”
懒鬼。他会说“随便”以及“我无所谓”。
对于实验中的这些人物性格，传统的观点认为它们完全不会对团体有太大的影响。团体是强有力的，“团体动力”是强大的，因此团体应该主导个人，而不是反过来。如果追溯到几十年以前，有太多的研究表明，个人是遵从团体的价值观和准则的。
但是，Will Felps发现了相反的结果。
毫无疑问，有“坏苹果”的团队会表现得比较差。尽管他们所在的有些团队非常有天赋、非常聪明、非常友爱，但这些都无济于事。Will Felps发现“坏苹果”的行为有着深刻的影响——有“坏苹果”的团队比其他团队表现得差30%～40%。在有“坏苹果”的团队中，人们会争吵甚至打起来，他们没有共享相关的信息，交流得也比较少。
更糟糕的是，其他团队成员开始呈现“坏苹果”的特征。当“坏苹果”是一个混球时，其他团队成员也开始表现得像混球。当他是一个懒鬼时，他们也开始懈怠。而且他们不只是针对“坏苹果”才有这样的反应。他们相互之间也会像“坏苹果”那样彼此对待，足见“溢出效应”在起作用。
简而言之，他们的发现就是，团队的绩效可以从团队里最差的那位成员身上准确地预测出来。不管团队里最好的成员有多棒，也不管团队里的普通成员怎么样，这些都无关紧要。根本的决定因素是要看团队里最差的那位成员怎么样。拥有最差成员的团队也会表现得最差劲。
自我认知永远都是第一步。如果你不能判断出谁是团队里的“坏苹果”，那他有可能就是你自己。反思一下你在自己团队里的行为吧——你是否“失足”掉进了这些负面的“坏苹果”行为模式，哪怕只有一点点？最显然的解决办法是从源头上解决问题—除掉害群之马。
即使你自己就是那匹害群之马！