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

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

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

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

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

一、一个小团队的故事

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

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

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

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

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

开发测试阶段：

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

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

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

验收上线阶段：

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

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