如果一个项目大到一定的规模，需要不同角色的人参与，那么也应该是有更多的小编队来做这一块事情；甚至更极端的做法，就是一个项目在建设之初，就考虑到会有很多小编队或个人参与到项目建设过程中，预留了多人、多团队协作的支撑工具，比如说nodejs的NPM，go语言和rust语言也有相应的规划；
小编队有很强的执行力小编队不会说这个事情需要做个评审；
小编队不会说这个事情安排的资源不够，需要协调更多的资源；
小编队会把这个事情当成自己的事情，不会像大军团一样，把这个事情当成大家的事情来对待；
我们来看个图：
（图片遗失，暂不补充）
小编队有很强的创新力软件行业不像建筑行业，90%以上的优秀软件一开始都是个人或者小编队创造出来的；很少见一个优秀软件是一个大规模的组织创造出来的。
一个案例张小龙曾经说过一段话：
好的工具就不应该黏人，应该帮助用户非常高效率完成任务，而不是说用完了还要拿到手里玩一会儿、多用一会儿，那不是一个很高效的表现。但是对这样的一些想法的话，我特别希望它能够根植到大家意识里，时刻想一下什么是我们做的对用户有价值的事情；
假设你是马化腾，你会怎么给张小龙定KPI呢？考核微信的日活吗？……
无论你制定什么KPI，都会导致团队去围绕着那个KPI去完成任务；
KPI考核准则里有一项原则就是“可度量”，当你提出一项纯数据目标的时候，团队就会围绕着那个数字去工作。而偏离了做好产品的初心。
一个团队工作的目的不应该是完成KPI，工作的目的应该是做好产品，完成KPI只不过是做好产品这件事情的副产物，就像一个人好好工作的目的不应该是为了赚钱，他好好工作的副产物是赚了很多钱；
所以你制定了一系列的kpi考核制度，只能导致员工工作的动机更不纯粹。
最后一个组织只要发展良好，总是会吸引更多的资源，所以组织规模的扩大是无可避免的，但如果一个组织规模已经超过500人了，那么你应该把他看作是50~100个小团队来对待，而不是把他当作一个500人的大团队来对待；
------------------------------
2017-07-13完成以上内容
2017-07-30增补以下内容
康威定律
任何组织在设计一套系统时，所交付的设计方案，在结构上都与该组织的组织结构（沟通结构）保持一致。——梅尔.康威
这个定律说明，组织的结构对系统的性质和质量有着深刻的影响；
如果构建系统的组织更加松耦合，其构建的系统则更倾向于模块化，因此耦合度也更低；
如果一个系统足够重要，要求有更松的耦合，更模块化的设计，系统也会反过来要求组织具备这样的特性，这就是反康威定律；
我这篇文章并没有提到大军团的优势，并不代表大军团没有优势，
相反，有很多项目非“大军团”根本就完不成，比如：卫星里跑的程序，控制原子弹起爆的程序，导弹的制导程序，都需要大军团来做！
然而这些程序毕竟是少数，而且不是我们身边的东西，大部分时候，我们还是需要小编队来做。
亚马逊提出“两个披萨团队”的概念，就是说亚马逊要求组织内部不应该有团队大到两个披萨不够吃。
归根结底，就算非常庞大的组织，也应该强调小团队的协作模式。