PS：文章中的一些理解，是基于我学习一些管理书籍的内容和在工作中实践总结的一些个人概念的叙述。是一种经验的分享，可能会包含错误和不全面。需要读者自己去判断和理解。
    为了能让大家对团队更好的理解，我讲的很细，导致了字数严重偏多。我本来想一起放上来，但怕大家看着睡觉，故分成了上下两部分。下篇会重点集中在团队的内部培训和团队成员的招聘，还有团队关系处理上。先把上篇放出来看看大家的意见和反响，也可方便我对下篇进行调整。 看完后，如果你觉得受用，请推荐下。共同提高，我们的工作和发展才能更和谐。

以团队开头：（如果你知道什么是团队，可以跳过）

    什么是团队？这里有个比较标准的解释：团队（Team）是由员工和管理层组成的一个共同体，它合理利用每一个成员的知识和技能协同工作，解决问题，达到共同的目标。
 
    在软件公司，一个基本的团队单位，是由Team Leader（也可能是项目经理，每个公司对头衔的分配不一样。这里以Team Leader为总的称谓）所带领的一群人（如程序员）。以数据结构来说，就是一个多叉树的结构；每一个节点都是下面子节点的领导；节点和子节点组成了一个团队。Team Leader的领导（项目主管或项目经理）又会管理着多个Team子节点（开发组，测试组，美工组等）；这些Team组成了一个大的Team团队，主管也是大Team的Leader。换句话说，每个节点都是下面子节点的Team Leader，至于起什么头衔，并不会影响Leader的职能。
 
团队类型和选择：（重要，直接决定着后续的多个因素）

    团队的类型其实没有一个什么固定的称谓和标准。一些团队领导在工作中不断调整团队成员的组成。当达到一个比较成熟的团队模式时，为了方便大家理解，会拿生活中大家熟知的一些事物来代替（如手术台类型）。
 
    其实，前人已经为我们总结出了很多成熟的团队组成类型。如：手术台类型。做手术大家一般比较熟悉，是以一个主治医生为主刀，其他医生为辅助，来完成整个手术。我们可以很容易的把这种模式与团队组成结合起来。一个团队中，以一个或两三个程序为主导，其余程序员为辅助来完成代码开发；这样的模式在国内游戏开发中经常使用。主刀也就是我们常说的主程（主要程序员或技术一把手），以主程为核心进行开发，其他程序员辅助完成附加功能。
 
    在实际的工作中，我个人倾向于交响乐队类型（这个是我个人的叫法，因为这个模式和交响乐队基本一样，也便于大家理解。我在后面的“团队合作”里进行了较详细说明和对比）。在交响乐团中，团员都有各自的技能，并分工明确；在指挥的指导下完成演奏。这里的指挥就是我们的Team Leader。
 
    团队的类型有很多，这里只是列了两个被大家广泛使用的类型；其它的类型，就请大家自己钻研了。
 
    选择什么样的团队类型，是一个Team Leader在组建团队时要解决的一个问题。不同的团队类型涉及不同的团队成员组成，并对团队成员技能的要求也不一样。这会涉及到你需要招什么样的人，这也是为什么我把副标题定为：打好你手中的牌。不同的团队成员就如同不同的扑克牌，你要去组织和打好它。发散下思维，可以把团队管理抽象成打扑克牌的过程，打牌就是在进行管理。
 
      不同的团队类型有不同的优劣。如手术台类型，对主程的要求很高。在整个团队开发中，主程的个人能力决定了整个项目的成败；在很多时候，主程也担当着Team Leader的角色。主程个人能力这个因素，导致了我不太喜欢使用这个模式；因为风险较集中。但是在一些尖端技术的开发中，往往又是需要手术台这种模式。原因很简单，尖端当然需要顶尖人才去做了。这个模式有一个好处，就是对其他程序员的要求不高，比较容易招到合适的人。
 
      再来说说交响乐队类型。这个是我普遍推荐的，很大一部分原因是我们并没有很尖端的技术要去实现，并且这个模式可以分散风险。但是这个模式对程序员的能力有一定要求，就是需要某方面的特定能力（具体需要什么能力，根据你的项目需要来划分）。我不需要你会很多东西，你只需要对特定领域有钻研；或者你对某个领域赶兴趣，并愿意往这个领域走下去。我需要你专精一点，如同交响乐队里面每个人有各自的乐器技能。但这模式也有个缺点，那就是在初级程序员的招聘上，基本很难找到有钻研一个方向的。毕竟他们对程序才起步。不过这个问题通过内部培训是可以解决的。后面会具体探讨内部培训。
 
    所以，选择什么团队类型要看项目需要和Team Leader的经验。发散下思维，其实在好多小公司或非正规团队，也是使用的手术台类型。3-5人一个团队就上架干活了，1个技术领头的（主程），搭配2-3个人就干了。这种类型好搭建，成本低。换作交响乐队类型，同等情况一般人员配置会稍多，成本稍高。但是作为长期发展来看，交响乐队类型的团队比较稳健和可持续发展；如果是要技术难点突破，手术台类型的团队就比较适合去攻克难题。
 
    提点敏捷开发，敏捷开发也是一种团队类型，被大家尝试过、讨论过、分析过。我也尝试过，最终还是转回了交响乐队的模式。这里简单说下我对敏捷开发的拙见。优势，快速开发，快！非常快！劣势，按照敏捷开发的理论，应该是没啥劣势。一切看起来是那么美好的敏捷开发，到具体操作起来却很多失败。其主要问题就是，敏捷开发对开发团队的人员平均素质要求太高，一般的中小公司，很难达到这个平均素质水平。这也是我失败的原因。
 
团队合作：（别跟我说你会团队合作，十有八九你在忽悠）

    团队合作根据团队类型的不同，合作的方式也是不同的。这就是为什么我在“团队类型和选择”后面标上重要。如果你现在对团队类型的功能性理解不清楚，下面好多问题你都会产生模糊不清的观点。那么我建议你最好花点功夫去弄清楚不同团队类型的组成模式。比如手术台，你可以想象在做手术时，医生们是怎么样合作的；在交响乐队演出时，大伙是怎么合作的。
 
    团队合作不是一群人在一起做事，不发生冲突，自己做自己的事情。通过我在工作中的观察，发现很多人都持有这一观念。根本原因是，我们从小到大就没有接受过团队合作的训练。虽然我们走上社会时会知道出去工作要合作，老师也会提醒。但我们脑子里的映象是，一群人在一起做事就是合作。不发生冲突和大伙一起做事，这只能是一个基本的工作态度。如果这都做不到，那么你根本就没有准备好做事。
 
    如果你要问我什么是团队合作。那我也只能给你字面意思的解释：团队合作指的是一群有能力，有信念的人在特定的团队中，为了一个共同的目标相互支持合作奋斗的过程。
 
    如果按照字面的意思来理解，其实是理解不了的。这只是一个理念，不是具体操作。要怎么做，我将给大家在下面道破。但是要记住一点，不同的团队类型，其合作的方式和具体实现都是不一样的。这样就会产生很多不同的合作方式，因为有很多不同的团队类型。如果你说你懂团队合作，这不是忽悠你自己吗？能弄懂弄会一两种方式的团队合作就很不错了。这里再提一下敏捷开发，敏捷开发对合作是另一种方式，这种方式明显对合作素质要求比较高。很多人连基本的两个团队类型的合作方式都不知道，就要他们直接跳到敏捷开发的合作模式。你说能不失败吗？
 
    下面我将通过交响乐队的演出来说明团队合作如何进行和为什么要这样做。这里只是一种类型的合作方式，我主要以交响乐队类型打开你对团队合作的理解。后面在慢慢讲解其他类型。
 
      一个交响乐队有很多团队成员组成，可以分成弦乐组、木管组、铜管组和打击乐组（如开发组，测试组等）。如弦乐组又是一个提琴的家族，包括小提琴、中提琴、大提琴和低音提琴（如开发组里面的前端，后端等）。不难发现交响乐队分工明确，职能清楚。对了，还有一个指挥（Team Leader），先忽略他。如果没有指挥，大家各自只顾自己的，你拉你的大提琴，我吹我的双簧管等，他弄他的长号。这样演奏出来的只能是噪音。也许大家可以商量下，我拉完大提琴，你在吹双簧管，他吹完你在演奏长号。不错哦，这是一个办法，好像没指挥啥事。如团体舞蹈表演里面就是这样的过程，通过观察别人的表演事件点是否完成或者到某个状态点时来启动我接下来的表演；通过上一个人的事件来触发下一个人的事件。但这有一个缺点，就是需要处理大量的上下文环境事件（前一个人表演结束，或者某个触发点）。一旦中间有人出错了（异常），就会引起后面的人整体出错，因为大家不能捕获异常和对异常进行处理。而且这样的一个表演，对表演者的个人素质要求很高，需要大家有很高的默契和能够对复杂不确定的异常进行处理。我们可以从中初略看到，引发异常的不确定因素很多。那么怎么处理和简化这个问题呢？回到我们的交响乐团，这里出现了一个指挥（其扮演着Team Leader的角色）。现在交响乐队的团队成员不用去观察复杂的上下文环境，而是专注自己的技能和观察指挥的手势（命令）来触发演奏（执行）的开关。这样问题就变得简单和好控制了，因为指挥可以纵观全局，并扮演着异常处理的角色。一旦有团员出现异常，指挥可以马上捕获这个异常，并用经验进行处理；且不用中断演出，团队成员也不用去关心有什么异常。每个人都有自己独特的功能，只用等待指挥的调用即可。问题是不是变得简单很多呢？但在这里突出了一个人的重要性，那就是指挥。其实很多人不理解指挥，认为指挥其实没什么大不了，就是在上面挥挥手。一个很简单和容易角色，没有乐器演奏者重要或技术含量高。不要指挥，不出现异常，其实也可以表演的很好嘛。如果你这样想，那是因为你不懂指挥的重要性，你不懂团队合作的精髓。如果你是这样一个团队成员，那么你不会信任你的指挥（Team Leader）。当异常出现时，这个演奏可能中断并崩溃。因为你不信任你的指挥，在出现异常时，你会用你的个人能力去判断该怎么做。这时指挥对你的调用将不起作用，那么这样就会造成一个无法处理的异常。这也是很多团队失败的原因。可见指挥（Team Leader）处理着整个表演的异常情况。（发散思维：根据这样一个流程，我们就可以很容易追踪到事故源。查明是Team Leader异常处理的方法有问题，还是异常调用出现问题。具体细节不是这篇文章讨论的重点，但是通过异常的判断很容易定位到责任人。）
 
    团队合作是要Team Leader来控制和主导的。对于团队成员来说，你只要明确的执行了Team Leader的指示，你就产生了一个合作。但这不是说你就会团队合作了。对于团队合作的精髓，Team Leader和团队成员都要很清楚的理解，要不然你们是不可能产生信任，那么也不会存在合作。经过我的观察和跟别人的交流发现，团队里面最大的问题是不信任。但产生不信任的原因是什么呢？用编程的思想“抽象”来处理这个问题，经过不断提取发现，最根本的原因是大家不懂什么是团队合作。
 
    回到交响乐队类型的团队，我们可以从中发现：程序员信任你的Leader，并完成Leader对你的指令。这就是交响乐队类型的团队合作。是不是很简单？希望你是真心理解了。记住“信任”这个关键词。
 
    简略说一下手术台类型的团队合作，主要是让你理解不同类型团队的合作差异。手术台：程序员要默契辅助你的主程（其实主程就是你的Leader）。注意这里的关键词是“默契”而不是信任。在手术台模式下，成败完全是由主程一个人决定的，程序员可以不去信任主程。但要和主程有一个默契，当主程需要什么时，马上提供相应的辅助。
 
    其实还存在一个每种类型的共同点，就是Team Leader你要信任你的团队成员。我不着重讲，是因为你要是不信任你的团队成员，你也不会去用他。你用人的基本前提就是：疑人不用，用人不疑。
 
    留给你自己去琢磨的，交响乐队类型，Leader需要了解你的每个团队成员技能，并且自己本身也需要会技术。基本上交响乐队类型的Leader都是从高级程序员发展而来。手术台类型，其实这个类型Leader的概念比较模糊。如果你分为主程和Team Leader，那么Team Leader不需要任何技术技能。这样Team Leader会有点多余，所以很多团队里面，主程就是Leader。这样的组织结构，成败完全在一个人手里。如果不是做技术难点攻破、核心技术开发，我个人不建议组建这种类型的团队。

PS：这里我要推荐大家去看一部电影《速度与激情5 Fast Five》2011年上映的片子，我把这部电影定义为是一部标准的讲解团队合作的片子，我组织部门的人都看了一遍。网上高清下载一大把。这个电影很好看，很有激情。电影中他们一群人组成了一个团队，分工明确，独特的技能。他们团队也出现了不信任，并处理不信任。是一个完整的交响乐队类型的演绎。这个片子2011年上映时，我看完心里感触很多。当我正通过阅读来学习团队管理时，对团队合作等好多概念还比较模糊，能理解但又不能很好的把每个地方结合。直到看完Fast Five，整个任督二脉被打通了。这个电影也触发了我想写一篇团队管理的文章，但一直迟迟没有下笔。