下面是一些压力下团队建设的原则：

　　1、给团队最大的自由度：这个指管理上的自由。不必受公司内部制度的限制，因为压力下的团队管理本身就是畸形的。

　　2、给团队配备最稳定的设备：这个我就不解释了，最稳定在这个情况下比最快速更重要。

　　3、给团队更多的可支配资金：应变很多资源和人员需求上的变化，比如需要购买书籍，配备外协人员等等，这些都需要快速以减少团队额外的时间上的浪费。普通项目则允许资金申报过程。

　　4、项目经理要有一定经验：这中情况下的团队让新手进行管理会是灾难性的。而且项目经理经验要非常丰富才可以胜任。普通项目中此条款也可以不遵循。

　　5、团队成员共同设计：项目应该由所有成员一起进行设计工作，以便尽快确定可行的设计方案，所有成员对设计也应该有很深的了解，方便以后的交流。此条款在普通项目中根据实际情况实施。

　　6、针对不同成员设计有针对性的优化开发方案：这种方法只是针对这个项目进行，可以按照个人爱好，能力，资源调配等等方面制定。这种方式是不适合公司发展的，人员变动后对项目影像比较大，因此普通项目不得按照此管理方式。

　　7、解决团队成员生活问题：在团队解决能力范围内的问题，要在项目开始之前首要解决。原因很明白。在普通项目中里面包含了冗余时间，项目进度可以承受成员处理生活上和其它方面的问题，这里最关心的是效率，因此此条款也不适合普通项目开发。

　　8、采用敏捷开发模式。这是轻量级程序的开发模式，项目经理的都应该具备这些知识了吧。

　　9、项目培训应提早进行：在合同签署之后的第一件事就是项目中的技能培训，比如行业、前沿技术等等。这个直接关系到项目进度、用户需求与稳定性的指标。

　　10、让管理层远离团队：如果是有经验的团队都有这样的经历，管理层的很多意见不适合压力下的技术开发，让他们离开团队才是团队正常运转的保证。很多情况下他们都愿意做你潜在的客户，他们会这么说，然后来参与到你的团队中，然后他们有很多意见，然后他们会以领导的身份告诉团队应该如何改进，而不是客户的身份。相信我，让他们离开你的团队，他们一般不会做好这样的角色互换，因为他们不知道客户要干什么，不是所有，是大部分。

　　上面所述只针对纯软件公司的小团队开发。如果要论述各种情况有点不切实际，这里我只论述了大部分公司存在的问题。但大家一定要明白，如果盲目利用这种方式去开发不可能完成的项目，结果还是失败的，因为你的出发点就错了，这种方法只是纠错，就象我们明天要提交软件了，今天晚上通宵了一样，是时间压缩，而不是真的效率提升，一般这种开发过后我都会给团队放一定的假期，因为他们为公司做出了效益，这是他们应得的。