与传统印象中的人多好办事不同，小团队的工作效率可能比大团队更高。原因何在？

这篇文章，作者从一个故事说起，为我们解释了为什么会产生这种现象。一起来看看：

1882年，法国人林格曼做了一个“拉绳子”试验：

20名学生分别以个人和集体形式拉一根5米长的绳子，绳子的一端为测力计。

2个人一起拉绳子时，每个人的平均表现是单独拉绳子时的93%，3个人时为85%，4个人时77%，而到8个人时，平均表现则只是个人最佳表现的50%。

心理学家将这种效应称为林格曼效应。

林格曼效应具体是指：多人合作时，个人努力的作用就会被削弱；导致个人缺乏竭尽全力的动力，个人贡献与团队贡献也难以区分，因此就会有人“滥竽充数”。

一、一个小团队的故事

前段时间，因为工作中的亲身体会，我开始对小团队和大团队的模式感兴趣。

我在网上搜到一个案例，作者说他朋友的公司做了一个教育行业的管理系统，业务复杂，决策人牵扯的多，需要对接的系统也非常多。但是他们顺利完成项目的时间和人数令人吃惊：2个多月，6个人（这6个人里一个美工，一个项目经理，其他都是开发人员）。

当朋友问作者如果这个项目交由他们来做，需要做多久。作者想了想说：顺利的话，半年吧。

差异如此之大，引起了作者的兴趣。他就一条一条列举出对于这个项目中的任务，如果是他们按照传统方式做，再对比他朋友公司的实际做法，都有哪些不一样。

具体的内容我就不一一列举了，在文末的参考原文里，大家有兴趣可以点击看看，我这里只举例其中提到的两条：

开发测试阶段：

朋友公司的团队几个开发人员从前端到后端，从开发到测试，都是他们自己做。

作者说如果他们公司来做的话，后台开发人员不做前端（普通的前端工作在做的，只是不做复杂的前端页面）；质量的保证是由测试人员去保证：测试把Bug提交到Bug管理工具，开发再去Bug管理工具查阅属于自己的Bug，等开发人员修改完Bug之后，再关闭Bug，测试再来做回归测试。

作者总结说：这些流程看起来琐碎，确实损耗了大量的资源。

验收上线阶段：

朋友的团队所有人都在项目现场，有问题，他们当场就解决。

作者说如果是在自己的公司，要先收集问题，让测试工程师去验证问题；然后由开发解决，解决之后再验证；然后再发布版本给现场的实施工程师，由实施工程师再更新上线，给客户验证。

所以，**作者总结说：问题很明显，规模大的团队和规模小的团队工作方式的差异非常大，组织资源的方式也有明显的区别。

通过这个案例，结合我搜索到的其他资料，我发现了一个有趣的现象：小团队合作正在被越来越多的企业推崇。知名的企业像亚马逊，谷歌、Facebook、百度都在内部推行小团队的运作模式。

今年因为离婚事件闹得沸沸扬扬的全球首富亚马逊CEO杰夫·贝索斯（Jeff Bezos）就有一条关于小团队的“两个披萨”定律：如果两个披萨不够吃，那么这个团队就过于庞大了。

两个披萨的概念大概就是6-8个人左右吧，当两个披萨已经不够时，你的团队可能需要考虑精简人员了！

贝索斯的这一定律正是佐证了小团队的必要性。

为什么企业会运用小团队模式？

必然是小团队模式产生了可见的成果，那么为什么小团队能够达到这样的效果呢，它背后的设置原理是什么呢？

我们一起来看看：

二、小团队的科学设置

我们从两个方向来看小团队设置的原理：

1. 大脑的构造
2. 人员的沟通成本