团队广义上讲是一个集体的描述。狭义上讲是开发人员的集体，我们这里只讨论广义的概念。团队里面的主要成员是人，但也包括所使用的工具，设备等等资源，。这个概念任何书本上都没有澄清，但在我描述压力下的团队建设之前必须先要谈谈这个概念，以及这个概念所引发的一些经验。
 
一、团队的概念
 
　　团队是为达到统一目的集体的总和。它由集体中的人、工具、设备、以及一些辅助资源，比如说某些特定信息等等来构成。因此团队是具有独立工作能力的，有独立思维环境的一个团体。如果有人告诉我，他和朋友组成了一个开发office的团队，没有固定的工作环境，在互联网进行信息交流。我当然不会相信，因为他们不具备环境，是个不完整的，没有开发能力的协助而已。他们只能做一个完整团队的一部分。这里大家不要把团队局限在软件行业，一台计算机几套盗版的开发环境就可以了。因此为了使团队正常运作起来，关键部分就是环境的构建，人在团队的角色只是创造性劳动者。因此团队建设中针对人的部分可以描述为：为创造性劳动构建环境的过程；针对环境的部分可以描述为：为重复性劳动构建环境的过程。所以前者需要灵活，自由与严谨，后者需要稳定、快速与准确。简单的实例：比如软件开发中人员是相对自由的，他们可以自由交谈，可以自由调节休息时间等等，使用的计算机应该是快速的稳定的，虽然满足工作就好，但谁又讨厌更快的速度呢？信息也是团队的一部分，比如是面对某个项目要作的前期培训，应该具备准确的概念与快速入门的性质。这些都是团队的一部分。而且是缺一不可。至于团队人员的选择属于主观问题，一言不可尽其极，这里就不再论述了。
 
二、团队中的软件工程
 
　　上面我故意回避了一个问题，就是团队内部的项目管理。要说明这个问题，必须先要了解软件工程。软件工程包括两方面的内容：第一、软件的开发技术。第二、软件项目管理。软件开发技术包括了所有现在的开发细节，这个我没有能力来说明，在这里我只谈谈软件开发的项目管理部分，但一定要明白项目管理只是软件工程的一部分，而不是全部。软件工程论述部分可以参照我在www.csdn.com上的专栏文章《软件设计深度挖掘一》，时间有点久远，但里面我需要修正的东西不是很多。用www.google.com可直接搜索到。
 
　　下面我谈谈团队的软件工程。
 
　　团队的规模和软件工程匹配成正比，比如10人以下的团队，软件工程中很多问题都可以解释为人员的交流。而10-25人的团队则需要很少的中间信息交换的管理，比如使用邮件来发送任务书等等，25-50人团队则需要使用更多的中间质量保证，比如使用ClearCase来进行配置管理，vss显然不适应大规模软件开发。从小团队到大团队的过程中增长的不是软件工程的应用程度的变化，而是对软件工程的应用方式的改变。团队的大小和使用软件工程没有任何冲突，不同团队都要确保最终的软件质量，这个很显然，我们会在小团队应用灵活的，直接的交流方式，比如口头纠正一些肤浅的错误，直接互看代码，直接指出相互在开发中存在的问题，这样做因为我们追求效率，质量在递增的完善中显的十分完美。大团队为了避免信息交流的爆炸，必须采用一些中间管理步骤来确保各种团队信息流的负载平衡。项目管理也就在这样的需求下很自然的产生了。因此团队的软件工程就是完善的软件工程体现。只是很多情况下不知不觉的错过了总结的机会，当过程结束就很难再完善的归纳了，毕竟回忆是片段的。我会经常听到有人说自己参加的都是小项目，没有软件工程的经验，其实你所拥有的是软件工程的不同表现而已，没有参加过小项目的人对软件工程的认识当然也是不完全的。
 
三、压力下的团队建设
 
　　我们不可能总是在开发大型项目，因此开发模式中适合小团队的模式比较多，大团队的管理模式其实是很成熟的，几乎所有软件工程著作都非常适合大型软件工程。因此我们讨论小团队的团队建设以适应大部分的情况。
 
　　压力下改变的只有团队中的人。那么，压力下的团队是怎样的呢？
 
　　最严重的问题是他们会感到绝望。由于方方面面的原因都有可能造成团队成员的情绪变化，而且绝大部分情况都是不可逆的。当时间太短与项目太大之间的情况发生，团队必然会发生对项目能否完成的讨论，讨论带来情绪波动，之后是浮躁，心慌，工作效率低下也随之而来，其实产生这个的原因是因为他们参与了项目管理的讨论。在很多情况下团队所有成员是应该避免参与项目规划部分的谈论，而更大部分讨论应限制在项目本身，比如设计上。我不得不重点强调项目经理的作用，因为他要担负起不可思议的一对悖论问题的解决，一个根本不可能完美解决的问题的解决方案的设计。但团队人员很聪明，他们知道团队面临的问题，当然就有自己的想法，这个应该由项目经理来解答所有团队成员的问题。需要解释的问题重点应该是项目中的技术问题如何解决，使用怎样的质量控制及软件工程方法，项目资金问题，加班问题，完成项目的意义，如果没有按时提交项目的后果等等。
 
　　压力下的项目管理过程就是人的管理过程。软件工程这个时候变的尤其的脆弱，我曾经经历过一个程序员因为椅子不合适而拒绝加班的情况，当然他很愤怒。执行项目管理的时候应该小心翼翼，甚至可以根据每个不同的人执行不同的软件管理方法。让团队感到前所未有正面情绪。在这个期间项目经理的责任就是一个关键问题了，不同人的管理模式会让工作量成几何级数的增长，协作方式的管理复杂化，优化了团队生产效率，增加了大量的管理负担。有压力的项目应该有很大的利润空间，因此增加项目管理资源应该也不是问题。比如每周出去一起出去吃饭，喝茶，打球等等项目活动都会让团队忘记压力，轻松的心态是取胜的关键保证。这种活动是必须的，从心理健康学上讲这个是一种必须要保持的平衡关系。还可以增加管理人员，来跟踪团队每个开发人员的开发细节来及时反馈。开发人员则不必受一些项目管理中产生的中间过程而耽误过多的时间，几年前，我曾有过这样的经历，我给我的团队骨干（2个人）配备了专门的技术秘书，他们负责一切的文档编写，单元测试的编写，以及完成这两个人的代码测试。工作中骨干们甚至是边开发边口述，秘书就及时的记录下来相应的细节，从而整理成文然后再给骨干们审查。一个原本要开发半年的项目，三个月就全部完成，相应的开发成本只增加了10%。最重要的是保证了产品质量。之后他们会风趣的告诉我，“这样开发真的很刺激，希望下次不要再经历了。。。”所以我想提醒大家，压力管理是短暂的一种畸形管理，不可能适合大部分的开发。如果团队连续3次进行这样的管理过程，我想他们会疯掉的。
 
　　到现在我还是没有提到加班问题。其实在压力下，加班是难免的，但我确实不能说提倡加班，因为造成团队在高压下工作应该是公司领导们的事情，强加到团队身上是侵犯人权的表现。每个人都有一定的工作能力，最重要的是我们不能把团队的理想强加到团队成员的身上，因为他们是自由的。加班问题这个矛盾我们还是回避了吧！
 
　　下面是一些压力下团队建设的原则：
 
　　1、给团队最大的自由度：这个指管理上的自由。不必受公司内部制度的限制，因为压力下的团队管理本身就是畸形的。
 
　　2、给团队配备最稳定的设备：这个我就不解释了，最稳定在这个情况下比最快速更重要。
 
　　3、给团队更多的可支配资金：应变很多资源和人员需求上的变化，比如需要购买书籍，配备外协人员等等，这些都需要快速以减少团队额外的时间上的浪费。普通项目则允许资金申报过程。
 
　　4、项目经理要有一定经验：这中情况下的团队让新手进行管理会是灾难性的。而且项目经理经验要非常丰富才可以胜任。普通项目中此条款也可以不遵循。
 
　　5、团队成员共同设计：项目应该由所有成员一起进行设计工作，以便尽快确定可行的设计方案，所有成员对设计也应该有很深的了解，方便以后的交流。此条款在普通项目中根据实际情况实施。
 
　　6、针对不同成员设计有针对性的优化开发方案：这种方法只是针对这个项目进行，可以按照个人爱好，能力，资源调配等等方面制定。这种方式是不适合公司发展的，人员变动后对项目影像比较大，因此普通项目不得按照此管理方式。
 
　　7、解决团队成员生活问题：在团队解决能力范围内的问题，要在项目开始之前首要解决。原因很明白。在普通项目中里面包含了冗余时间，项目进度可以承受成员处理生活上和其它方面的问题，这里最关心的是效率，因此此条款也不适合普通项目开发。
 
　　8、采用敏捷开发模式。这是轻量级程序的开发模式，项目经理的都应该具备这些知识了吧。
 
　　9、项目培训应提早进行：在合同签署之后的第一件事就是项目中的技能培训，比如行业、前沿技术等等。这个直接关系到项目进度、用户需求与稳定性的指标。
 
　　10、让管理层远离团队：如果是有经验的团队都有这样的经历，管理层的很多意见不适合压力下的技术开发，让他们离开团队才是团队正常运转的保证。很多情况下他们都愿意做你潜在的客户，他们会这么说，然后来参与到你的团队中，然后他们有很多意见，然后他们会以领导的身份告诉团队应该如何改进，而不是客户的身份。相信我，让他们离开你的团队，他们一般不会做好这样的角色互换，因为他们不知道客户要干什么，不是所有，是大部分。
 
　　上面所述只针对纯软件公司的小团队开发。如果要论述各种情况有点不切实际，这里我只论述了大部分公司存在的问题。但大家一定要明白，如果盲目利用这种方式去开发不可能完成的项目，结果还是失败的，因为你的出发点就错了，这种方法只是纠错，就象我们明天要提交软件了，今天晚上通宵了一样，是时间压缩，而不是真的效率提升，一般这种开发过后我都会给团队放一定的假期，因为他们为公司做出了效益，这是他们应得的。