一向认为软件开发就像是在搭房子或者说是在构建一座宏伟的大厦，当然这根据工程的大小而定。其实细细想来软件工程的很多地方都是借助于建筑方面的知识，就从“工程”这个词来说就是从建筑学引进的，类似的还有等概念也是来源于建筑学。如此说来软件的开发和建造房屋一样，一般是多人合作完成的。如果您非要自己动手盖一个小平房也不是不可以，但请注意那一定是一个足够小的小平房。
其实要说起团队开发让人最头疼的不是什么技术问题，而是队员之间的合作问题。尤其是遇到矛盾重重的团队，那项目的进度一拖再拖将是家常便饭。团队开发绝不是架个SVN拉几个有水平的程序员就可以开始的事情！需要注意很多方面才有可能出色的合作完成一项工程。
l 给力的项目经理（项目组长）
首先，项目经理（项目组长）必须全面的了解项目的需求，根据需求和组员们商讨出一套合理的解决方案来。在这个过程中遇到不同的解决方案项目经理（项目组长）要敢于拍板，敢于承担责任。无论选择的对错都要比不选择要强，选择时畏首畏尾只会令项目延期，而选择错误大不了下次升级版本。一般说来在能实现功能的前提下，用户更加关心完成的日期而不是性能。因为每拖一分钟用户对软件能否实现的信心就减小一分。
其次，项目经理（项目组长）要有霸气。相信每个团队都可能会遇到不配合的队员，对于这样的队员尽量为他分配一些灵活性小的工作。如果队员严重影响合作那么就需要项目组长（项目经理）出面了，让你干嘛就干嘛，不要废话，出了事我担着！毕竟在一个项目中项目经理最大，项目如果出了问题客户或老板不会去责怪一个程序员，他会直接劈头盖脸的骂项目经理（项目组长）。所以在项目中队员有义务也有责任听项目经理（项目组长）的安排。这也是为什么项目经理（项目组长）在招人的时候格外注重队员的合作能力的原因（是否听从安排也属于合作能力的一种），招个不听话的人是多么郁闷的事情。
l 敢于否定自己
在项目的设计阶段，大家一起商讨具体的解决方案。很多时候大家是为了面子而不愿意否定自己的解决方案。其实这很容易理解，大家都是从程序员走过来的，程序员的通病就是常常盲目欣赏自己的代码，在软件设计的时候依旧“本性”难易，对于自己的设计不忍抛弃。一旦别人说自己的设计的有问题，恨不得马上和其大吵三百回合。争论，对于软件的设计绝对是好事，越争论对软件的需求、设计越清晰，“辩则明”就是这个道理。但是必要的时候（大多数人不肯定自己的时候）就应该好好的想一想：争论是因为面子还是因为自己的想法真的是完美的、无懈可击的？难道别人的想法真的是不可就要的、烂到不行的？如果是前者，无论你是谁（普通组员也好项目组长也罢）为了整个项目、为了团队，请放下自己的面子，否定自己！！！
l 不要正面否定他人的意见
无论什么时候都不要正面否定组员的意见，就算你是项目组长（或者项目经理）也不行！
在项目设计阶段，当组员为系统提出其他的见解的时候，如果你觉得合理那自不必说表示赞同即可。如果觉得不合理，你要做的仅仅是把你的观点摆出来和他的观点对比，让团队所有人进行讨论、选择，到底哪个更有利于软件的实现。
一旦项目设计完成，无论组员有任何好的方案都不应该采用！！！这时候要做的只是记下来为以后升级系统做准备，这也是为什么大公司的软件（例如windows系统）往往在上一个版本还未发行的时候下一个版本就已经开始准备了。很多时候开发人员就是在开发的过程中产生了更好的解决方案。好的解决方案——记录下来下次系统升级就从些方面做起。
为什么设计完成后不能“完善”？
如果在项目设计完成后再去修改设计，那么很有可能对项目其他部分造成影响。整个系统经过了长时间的设计可以说很少再有前后矛盾的地方。如果突然改变某一方面的设计，很大几率会造成牵一发而动全身的结果，甚至因为沿着这一处小小的改动走下去而使得整个软件前后矛盾，最终导致推倒从头再来的恶果。（还有什么比重头再来更糟糕？！！）
l 善于利用第三人避免“踢皮球”
不得不说的是任何详细设计文档，任何UML图都不会把系统的各个细节照顾到。毕竟文档以及UML仅仅是建模，一个大概的样子而已。这样一来难免会有细节部分没有涉及到如果非常不幸，这些细节恰恰是在两个开发者任务之间那就麻烦了。相互推诿责任，相互“踢皮球”是不可避免的，类似下面的话就会变成团队的主要语言。
A：“你的方法中怎么没有……的数据处理啊，这样传给我的我还得再处理！”
B：“处理这个数据不应该是你做的么？”
A：……
可能无论谁处理一下这个数据仅仅需要1个小时，但是争论到底是谁的责任却会花费数小时，这也是导致团队开发进度缓慢的原因之一。但是如果有另一个人在场（要是项目经理最佳），无论第三人到底向着谁，这场“战争”双方人员比例肯定是2:1。这样一来对于整个项目来说会大大缩短不必要的争论时间。
整个预期对话如下：