刚才看到 Fenng 写的这篇博文：大技术团队的危险性。其中的一些东西，确实有一些感触。
维基百科上对于“团队”的定义是这样的（http://zh.wikipedia.org/wiki/%E5%9B%A2%E9%98%9F）：
“团队由若干独立成员共同组建，有临时与长期之分。团队要为某一共同目标而奋斗，这需要团队成员贡献各自不同的专业特长。对团队的管理不同于上下级关系的管理，是横向的交流与沟通而不是纵向的命令与服从。”
虽然不是一个十分正式的定义，不过能说明几个问题。
- 团队不是一个人在战斗。
- 团队有统一的目标。
- 团队成员一定有分工。
- 团队的工作方式是合作的，而不是管制。
团队成员不光可以是个人，还可以是一个紧凑的组织，部门甚至公司。成员间进行平等的沟通、交流，相互支撑最终达到一个确定的、统一的目标。
由于沟通交流是平等的、横向的，那么就意味着任何沟通都是点对点的。当团队成员增加时，沟通的难度也就加大。
听起来有点像早期没有交换设备的点对点电话。在只有2个端点时有1条通信链路，3个端点就增加到3条，4个端点就增加到6条……那么对于一个有 n 个成员的团队，每个团队成员就需要有 n-1 个沟通链路。当沟通链路数足够大时，整个团队的人都在忙着沟通，而不是真正进行工作。当超过临界，沟通链路超过单个成员所能承受的极限时，为了维持团队正常的运作，有一些沟通链路会被忽略。一些工作关系相对疏远的成员不再进行沟通。这时从行政架构上虽然还是一个大团队，但是这个大团队已经不复存在，由若干个自然形成的小团队取而代之。
4-5个人组成了开发小组。4-5个开发小组组成了技术组。技术组、客服、市场……组成了项目组。项目1组、项目2组……组成了项目部……自最终稳定的团队结构是树形的，是分层的。站在每层去看，每层的团队都是小团队。当某一层上的团队开始有大团队出现时必然会有新的层次出现，将大团队重新划分为小团队。
这或许就是“无为而治”的道理吧。
硬是要将这种很有美感的、自然的组织架构重新排布，徒增本不需要的沟通链路，那么团队的结果或许跟瓦沙一样最终沉没。
June 17th, 2009 at 10:31
按照微软的软件经验,团队超过5个人,基本无法做事,就算有100个人做IE,也要切割成5人,5人的小团队来做事
July 16th, 2009 at 15:02
团队挺难设计的，如果人多了，浪费在交流也就是所谓的“沟通”上面的时间就多了，最后反而影响效果。