今天的大多软件工作能否获得成功，取决于团队的协作，而不是个人的突出表现。我们将关注怎样创建并维护一个高绩效的团队，以产生潜在的杰作。让我们首先来定义什么是团队。什么是团队?
Merriam-Webster在线词典就 团队给出了四个定义。一个是过时的，另两个牵涉到动物。第四个解释也没有抓住本质：工作或活动中相关的一些人……站在同一方(如足球赛或辨论赛)。
在我看来，仅仅因为人们相互联系并致力于相同的活动或产品， 不意味着他们就是一个团队。
接下来，我在 Thesaurus.com 上查找 团队。尽管它提供了39个同义语，但却没有一个能与我想象中的概念相匹配。所以我摒弃了Roget 辞典不现实的解释，再次查找该词。我发现许多条目都包括：补充、同伴、联盟、协作、小团体，结合等。这比较接近于我的看法：团队成员彼此都影响着整个团队的成功，他们都向着一个共同的目标而合作。 远景驱动
什么因素决定目标?基于我所见过的高效软件开发团队，回答是“远景”。在九月专栏中，我提到文艺复兴时期杰出的大师召集学徒和临时工组成一个团队1，以帮助他们完成大型的工作。在这些项目中，大师的远景驱动着项目的进行。大师负责艺术工作的整体设计与执行，任何一个想多发挥个人创造性思维的学徒都会很快发现自己已经被开除。
对于软件团队也是这样的，远景通常也是由大师提出。如果他或她可以很好地将远景表达出来，其他人将围绕此远景并参与项目的工作。文艺复兴时期学术团队和软件团队之间有着许多相似的地方。尽管由某一人为软件团队提供远景是个不错的作法，但是，并不意味着由他来控制团队成员想要在基于远景的产品上发挥任何创造性。
更典型地，软件项目的远景来源于不止一人。当第一个Rational Suite团队组建的时候，我们团队三个管理者中的任何一位都认为他持有正确的远景。三位管理者都设想，如果将各自远景整合，Rational工具可以互补并有利于用户，但是直到他们花费了大量的时间共同推敲出一个远景，团队竟发现很难找准方向。最后，远景驱动我们的工作并终于改造了Rational。协作是一个特性
在Michelangelo时期，大师艺术家雇佣专门的技术工人：镀金、背景着色、渲染外层，等等。这些人依据大师的计划而工作。作为一个产品模型，这个环境有其优点也有缺点。指派给学徒较少的技术性工作，这样，大师就能够创作出更多的作品，但是这种方式也使大师承担着全部的负担。
我没有听说过由两位大师直接合作成功的任何项目。尽管一些杰出的工作是由一些艺术家来完成的，有一些人总是会从事别人所摒弃的想法。如果Leonardo da Vinci、Michelangelo，或者其他著名的大师在一个项目中协同工作，会发生怎样的情形?我的猜想是：a)他们完成不了这个项目，b)他们可能有杀死其它人的想法。天才通常善于从别人那儿学习，但是却不会愿意与他人共同分享亮点。
这并不是软件团队成员可接受的 办事方式。正在开发大型和/或复杂软件系统的团队需要管理多人的想法。如果团队的某一成员将自己当成Leonardo，你就会感觉出了大问题。在许多公司里，业务主管庇护着这些人;你不能够将他们随便摆一边，让其自由发展，因为管理者认为你应该容忍他们的一些坏习惯，以便更快地将产品推向市场。最好的策略是，在第一时间避免团队中出现这样的人。
能够兴旺和生存的组织是那些能够让有才干的人们协同工作并共享荣誉。通常，他们会遵循以下几点：
培养真正的协作文化。
使人们与项目相匹配。
适当奖赏个人及团队绩效。
不断提供挑战与学习的机会。
让我们依次看一下这些特性：培养协作文化
几年前，“软件开发是一项团队活动”是Rational提出的口号之一。可以说，直到今天，这个标语更为正确了。个体开发者在单独完成一个重要项目的时代已经成为过去了。在开源世界里，你仅需看看SourceForge (http://www.sourceforge.net) 的项目，就会发现真正成功的项目是由那些可以决定谁更适合于项目各类角色的团队完成的。前沿的十个软件开发工具项目(基于通俗性和稳定性)，平均团队人数为10.3，中等规模的团队一般为9人。只有两个团队仅包括两位开发者，另外，还有两个团队的人数超过了20。在前25名的项目中只有一个项目是由一位开发者单独完成。2
然而，简单地将一些人分配给某项目并不意味着你拥有了一个团队。要想创建一个有效的工作组，团队成员必须相互“检入”3且配合。敏捷开发中提到，团队成员应当可以认识到彼此的优点和缺点，并相互配合以取得成功。这是理想情况，但事实上却很难实现。有时你很简单地加入一个团队，然后，在没有作好充分准备的情况下开始工作。但是，有时你不能够顺利地融入到团队中，那么就必须尽力去改善一个糟糕的环境。
是否有一种合适的方法确保你组建一个高绩效的团队?我希望自己能够提出一个好的方法，但是至今却一直没有找到。有许多组织顾问声称，他们能够将一组人转换成一个高绩效的团队，我也曾应邀帮助团队更有效地协作。通常，结果是混合的。各人不同，所以很难找到一种转换的方法，就像很难找到适合每个人的一种奖赏办法(后面会介绍到更多)一样。
根据之前的培训和经验，技术人员不是易于接受协作环境，就是会生成反对情绪。大多数情况，我发现上组织顾问开展的“人际互动”活动并没有与技术贡献者相沟通。这些活动只能让他们感觉不舒服。
我希望，你可以接受每个人的风格并试着将他们统一。如果你能够在团队成员之间培养一种真正意义上的相互尊重，那么，你将有可能组建成一个高绩效的团队。尊重他人并不意味着需要“hang out”某人。而是指应当以专家的态度对付他们并尊重他们的能力和需要。接受新的团队成员
对于一个管理者而言，最严峻的挑战是在既有协作团队中增加新的成员。有些小公司起步于一个核心团队。当公司发展壮大时，该核心团队需要吸收新的成员，这时，就有可能发生一些冲突。结果可能是，新成员会被驱逐出来或者核心团队成员选择放弃并离开公司。
以下有几个方法，可以避免出现类似的情况。
首先，当新成员加入一个团队时，请确保他们的个性与本团队相匹配。例如，如果你的团队成员喜欢在代码构建时外出和玩飞盘，请不要接纳事务很多的新成员。
第二，不要聘请超级明星。尽管他们可能带来好的效果，但是你想要他们做的大部分工作可能对于有经验的人们而言已是重复工作，而且也不能够充分他们的才能。所以，请寻找合适的团队候选人。New England Patriots足球团队的招聘人员成功地采取了这种方式。他们挑选基于候选人如何很好地与团队其他成员互补这个原则来招聘新人，而不是看重个人的成绩。好的软件组织也应当是这样的。
第三，或许最重要的是，当团队中加入新成员时，为他们指派一些可以帮助他们掌握窍门并理解文化的良师。这将有助于他们更快地融入团队并产生一种归属感和成就感。
当没事可干的时候，你必须作出从团队中开除一部分人的艰难决定。然而，首先，请先估计他们的能力。他们必须具备一定的长处;否则你也不会聘请他们。发挥他或她的能力，使之对组织的目标作出贡献。帮助人们取得成功胜过以可有可无的态度对待他们，这样会让员工认识到自己的价值，并且对组织也是相当有益的。
遵循以下我建议的一些策略将有助于创建一个协作的工作环境。团队成员与项目相匹配
在很多时候，指派一些人参与某一项目，是一种挑战也是一种奖赏，对于此，我将在后面更详细地论述。然而一些人可能不乐意接受新的挑战。有时无法说服某人参与某项目。遇到这样的情况，该怎么办呢?
最简单的答案：另找他人来承担这个工作。如果一个人对该项目的工作不感兴趣，那么他或她不太可能发挥出最大努力。这并不意味着这个人对于你的组织没有任何价值;而只能简单地说明当前项目不适合他或她。当然，如果你所在组织仅致力于一种类型的项目，那么或许这个人与该组织之间并不协调。在这种情况下，最好的途径是请他或她离开公司。
然而，大多组织有许多种类型的项目，需要不同类型技术和个性的能力，管理者应当考虑每个潜在团队成员的资格和特性是否与项目相匹配。当你要求某人学习工作相关的技术能力时，学习积极性是一个关键的因素(参见后面讲述的挑战与学习的机会)。
大多数情况，人们可能会精确评估某特定项目的适用性。例如，我知道，我擅长于在小型团队中完成小到中等规模的项目。我曾参与过的大型项目都需要花费很长的时间(一年多才能看到结果)，并且团队成员用大量的时间处理组织的基础设施而不是干“项目的真正工作”。这样的过程让我感觉失望，并且不愿意连续好几周都坚持完成同样的任务。或许我缺乏专心，但是我更喜欢工作中有适当的变化。我不认为这会使我变得不好，但是，我不愿意将自己看成是大型项目中的理想标准。
一般来说，管理者必须平衡项目个别贡献者和他人之间的需要。理论上，两者是互补的。然而，如果存在差距，你可能不得不采取严厉的措施。如Spock在Star Trek电影，The Wrath of Khan中说到的，“少数服从多数。”当出现了不可解决的冲突，你必须支持团队而不是个人。奖赏个人和团队
我们都是为了获得他人的认可而工作。有的人由金钱奖赏而激励，有的人乐于接受某些不可触摸的奖励。技术人员，特别是软件开发者，通常在与他人不同时获得成就感。对于他们而言，金钱有两个目的。首先，根据Herzberg et al著名的理论，它是整体满足感中的“卫生学特征”。4开发者把金钱看成生存必须品，但是并不是产生工作满足感的主要驱动因素。当然，金钱也是身份的一种衡量尺度，但是没有其它的奖赏，即使金钱很多也代表不了地位的高度。
在大型企业中，工资的增长一般不代表个人的贡献。取而代之，他们依靠整个企业的绩效，以及上报的员工表现。管理者将钱分发给团队的各成员，通常，他们会选择给个人一些东西。所以即使每个团队成员的表现都很突出，管理者也不会因此而嘉奖每个成员。事实上，如果公司某一年的效益不佳，细微(或没有)增加工资就可能使员工失去动力。
小型公司可能有更好的弹性，奖赏中常常包括红利和股票等。尽管股票可能并无多大价值，仍然会使员工感到自己对于公司的成功作出了一定的贡献。当公司发展壮大了，技术员工所占股份可能减少，他们的主人翁感觉日益减少。技术专家开始对自己所从事的职业不再有激情，认为仅仅是一个工作。5个人认可
当奖赏技术贡献者时，会出现一个比金钱更大的问题。软件开发人员的定型 -- 只想坐在电脑屏幕前编写代码的性格内向的人 -- 这种认识是 错误的。 今天的软件开发人员是社会动物;他们已经学会在团队中工作。然而，很多人从内心深处渴望个人价值得到认可。从我的经验来看，当管理者认可团队某成员，对他或她说“我理解你，而且也花时间寻找你的兴趣所在，”这句话对于技术工作人员而言，是一个相当大的动力。
你可能看到过有些人在某公司工作五十年时，得到手表作为奖赏。大多数人更喜欢一个别的礼物(比如，我喜欢自行车)。了解每个员工真正想要什么是相当有难度的。你甚至可以直接去问问他们。
让我用一个例子来说明这个问题。在Rational软件(被IBM收购之前)，管理者有责任为员工五年的服务予以奖赏。当我工作达到五年的时候，我还没有遇到加利福尼亚经理，因为我在马萨诸塞工作。在这种情况下，她完全可以像许多其他管理者一样做：给我美国式的表达礼物认可，并让我去买自己确实需要的东西。然而，她没有这样做，她与我的同伴通话，并发现我喜欢收藏美国本土长笛和其它管乐器。某一天她在电话中问我的爱好，我告诉她我打算买一个日本竹笛 -- 尺八-- 以作收藏。之后，她送了我这个礼物。这管笛子是我收藏品中最有价值的一款，并不是因为它最贵重，而是因为它对于我很重要。有人认可我的能力，这让我感到非常高兴。
接下来，你将奖赏员工，我希望你能够花时间以将这件事情作得非常有意义。你花费多少时间都是值得的，员工将会非常感激你，并更努力地工作。团队认可
此外，奖赏整个团队也是非常重要的。这通常要比奖赏个人更难一些。你必须明白对于团队的每个成员，什么才是最有意义的。大多数成员喜欢在完成一个很有难度的项目之后能拥有额外的节假日，但是有的人可能希望去观看一场棒球比赛。
对团队予以奖赏也需要注意。如果你经常开展这个活动，那么团队会养成期望的习惯，并将此看成一种权利。在我记忆中，公司为团队提供午餐，接着又开始为加班的员工提供晚餐。从某种程度来说，这种方式可以让员工坐得更久，工作时间得更长一些。但是有些人的看法不同，他们开始抱怨饭菜花样太少，要求更贵的饭菜，等等。奖赏必须是特别的，并且不应该成为一个惯例。挑战和学习机会
软件开发是一项基于知识的职业。今天，没有任何一个人能声称他或她知道所有知识。事实上，甚至对于某一领域，也不可能有人能够做得到精通。此外，事物发展将会更复杂，即使我们在努力将其机制变得简单。这是软件开发人员最主要的任务。喜欢挑战并持续学习是在工作中取得成就所必须的。
幸运的是，正如同文艺复兴时期的大师教课一样，我们身边有知识渊博的老师，甚至写书和发表文章的大师级人物指导着我们。我们可以研究他们的代码并学习他们的技巧。另外，通过电子邮件、邮件列表、新闻组、会议和博客，我们都可以直接与他们取得联系。一些组织也认识一些大师，并给予员工一定的培训。对于大多软件专家而言，这样的经历要比任何其它可能的奖赏更有价值。在Philippe Kruchten领导RUP组时，我从中学到了许多，并且乐于完成Grady Booch派定的任务。
软件开发人员勇于接受挑战。他们喜欢学习新的知识。知识就是财富。对于管理者而言，分配团队任务时最显著的策略是观察各团队成员的特点并根据他们现有技能分配适当任务。换而言之，将数据库工作分配给最富有数据库经验的人，将用户接口的工作分配给最富有接口设计的人员，诸如此类。然而，尽管这样可能拥有成功的产品，这种分配却未必是最好的方法。
那么，让团队决定，使用以下策略来最大化成员的学习机会：
了解谁在某特定领域最富有经验。如果他或她宁愿作项目的开发人员或愿意为承担此任务的人员提供咨询，那么，请让他或她自己作决定。
让专家选择关注他们开发时间的其它方面。
让选择作主要开发者的员工在系统的另一面花费一定的时间。不要强迫他们，但建议他们，因为这是交叉培训和学习的好机会。
如果你的团队正在实践成对-编程，你可以督促他们频繁地更换搭档，并接触系统的不同部分，这样可以取得同样的效果。在这两种情形下，目标是双重的。首先，你想要培养多能的开发人员，他可以从事系统的任何一部分工作。第二，也是更重要的，你给团队成员更多的机会去面对新的挑战并学习新的知识。团队成员在刚刚完成某个困难项目后可能会有抵制情绪;他们可能想暂时作一个转换。这样就好了。但是，如果你不为团队成员提供这些机会，那些想要接受挑战和学习知识的人将会选择离开，这样，就给项目造成了需要很长时间才能填补起来的空洞。
在之前的工作中，我曾与一位杰出的女士合作。如果你遇到一些特别难以解决的问题时，那么，去请教她是最合适的了。她非常让人惊异。然而，她提出的所有解决方案都按最坏来排序，我从来不想将这些方案结合进我们必须交付的产品中。你必须懂得使用这些技巧的正确方法。我们称她为各类项目的技术咨询师;她很高兴，因为她解决过许多富有挑战性的问题，并且团队的气氛非常活跃，因为他们在真正产品中不需要处理她的代码。
同成功企业所遵循的大多策略类似，“打包”挑战和学习机会也需要花费时间。但是付出努力总会有好的回报。处在一个由已拥有清晰远景的个体所组成的团队，会发生许多令人惊异的事情。Michelangelo 和Leonardo da Vinci当聚集人员开展下一个杰作时就懂得了这点。同他们的指导远景一起，学习的承诺将团队成员紧紧地团结在一起，开始协同工作。构建适当类型的团队
我强烈建议：如果你拥有构建团队的经验，请确保你的目标是构建适当类型的团队。一些辞典谈到其它类型的团队：暴徒、小集团、派系等。这种团队是你想要构建的吗?
这又回到了奖赏的话题了。将你的团队带到荒野进行团队构建演习，分成更小的几个队伍，然后奖赏最先回到起点的那一队。如果团队中有人确实讨厌户外活动，他们可能感觉不满意。此外，也可能会在团队内形成一些彼此竞争而不是协作的小集团。
假定你需要构建一个大规模的团队。请关注人们，而不是事件本身。John Whiteside， Phoenix Agenda的作者，在数字设备会议上描述了一个重要的项目，该项目需要公司西海岸实验室与东海岸生产部门的工程师之间的共同协作。在团队构建阶段，管理者选择中间的地点将两组人员合并在一起。欢迎晚餐是在一个高校舞会之后。男孩站在一边，而女孩站在另一边。从每个海岸来的员工站在各自的队伍中，并拒绝与他人交往。团队不能够协同工作，项目最终失败了。如果公司组织一系列活动，让一小部分人参观另外一方的工作场所。双方工作人员可能会认识对方，这将形成一个完全不同的团队。
Chris Lowe，我以前在Rational时的同事和合作者，曾说过一些我永远都记得的话。“当人事部门改变人力资源时，事情变得更糟糕。”我认为这句话相当富有洞察力。在大多情况下，保持关注人们，然后其它的考虑也就没什么了。注
1在文艺复兴时期，大师们没有雇佣女子来从事艺术工作。女子仅完成一些最琐碎的任务，比如清理工作室的卫生。这就是我在示例中使用男性代名词的原因。
2如果你和你的朋友某一天感到厌烦，随便找一个项目源代码并猜测其中有多少开发人员。最接近的猜测获胜。
3Software for Your Head, Jim 和 Michelle McCarthy, Addison-Wesley Professional; 1st edition (December 27, 2001), ISBN 0201604566.
4在1957年，Herzberg和同事开发了激励-保健理论，关注识别引起工作中满足感和挫败感的因素。参见 F. Herzberg, B. Mausner, R.O. Peterson, 和 D.F. Capwell, Job Attitudes: Review of Research and Opinion. Psychological Services, Pittsburgh, PA, 1957.
5在 The Software Development Edge(Addison-Wesley, 2005)一书中，Joe Marasco讨论了技术工作者的补偿问题。参考资料
您可以参阅本文在 developerWorks 全球站点上的 英文原文关于作者 Gary Pollice是Worcester Polytechnic Institute的一名教授，负责讲授软件工程、设计、测试和其它计算机科学课程，并且指导学生作项目。在跨入教育界之前的35余年中，他曾开发过很多类型的软件，从企业应用程序到编译器和工具。他在企业中的最后一份工作是在IBM Rational Software，以“RUP 倔老头”而知名，另外还是Rational Suite团队最初组建者之一。他是2004年Addison-Wesley出版发行的《小型团队软件开发：以RUP为中心的方法》一书的主要作者。Gary Pollice获得数学专业的B.A.并获计算机科学的硕士学位。
