首先，要解释下标题的意思。「人多」，指的是同一个项目团队、同一个小组或者同一个部门的范围内；「事少」， 指的是做出的效果，真正的产出少；「工作量大」，指的是，工作时间长，工作忙，实际的投入大。

     说白了「人多事少工作量大」，就是效率低，而影响效率的，原因千万种，有人员问题、沟通问题、流程问题、管理问题、技术问题，下面零散地列举下博主亲身经历过的问题：

一线工作人员，没让专业的人做专业的事，导致效率低

     没让专业的人做专业的事情， 是工作开展的大忌，在软件开发分工越来越明确的今天，让后端人员抢前端人员的饭碗，去写网页、样式，效率能高吗？让后端人员去抢DBA的饭碗，去做数据库优化，效率能高吗？

     不专业的人做不专业的事情，可能和公司的发展历程、组织架构、人员规划有关；也可能和任务安排有关。

     公司发展初期，养不起很多专业的人，可能更需要“全栈”工程师，啥都一把捉；公司发展的过渡期，有点钱了，也意识到了要让专人做专业的事情，但是人员还没招齐，那没办法，你也得兼职着做各种各样的事情。如果公司有钱了，发展也成熟了，不是属于以上两种阶段，在IT组织中，连前端、后端、测试、架构、DBA、网络、服务器运维、技术支持、安全、产品，这些职能都没区分好的话，就会对工作效率有影响。

开发人员不注重代码质量，导致后期返工，导致效率低

     开发前期，对于经验不足或者习惯不好的开发人员，为了追求进度，逻辑没考虑周全，没做好自测，代码能跑起来就算完成任务了，表面上任务完成得很快。但是在项目后期，测试阶段，问题大规模爆发，甚至要返工，由于测试后期，离自己写代码的时候，可能隔了一段时间，有的东西自己都忘了，再回过头去重新“熟悉”，效率能不低吗？更为严重的后果是让项目进度不可控。因此，就算进度再紧张，也顶住压力，必须要做最基本的测试，再进入下一个任务点。

个体组织人员膨胀，出现沟通成本大的问题，导致效率低

     沟通成本是人员膨胀后，暴露出来的首要问题。信息在沟通、传递的过程中，可能会“失真”，你想的，不一定能100%说出来，你说出来了，别人也不一定能100%理解，而且每个人的理解能力、知识体系都不一样，理解起来容易产生偏差，产生偏差就容易做错事情。

因此，如果人员出现膨胀，要以项目为单位，进行合理的项目拆分、人员拆分。同一个“小项目”最好不要超过4个人负责。沟通的时候，推荐使用口头+书面+复述，减少沟通过程中的信息失真。

上、下属之间相互不信任，做事有阻碍或者导致重复工作，导致效率低

     如果上级不信任下属，不敢授权给下属，凡是都要自己过一遍，而上级往往是一对多的关系，这个时候，工作瓶颈会出现在上级身上；如果上级不信任下属，搞一堆监督机制，为了下属不做错事情，又让别人同事过一遍，又要耗费额外的成本，劳民伤财，而下级得不到信任，做事受阻，久而久之就会畏手畏脚，很难独当一面，或觉得自己有能力没地方使，干脆走人。

上级应该充分信任下级，放心授权让下级去做事情，但这些都一个前提就是要有一个较好的软件管理过程，包括开发环境和测试团队和在完成任务的过程中进行一些辅导和进行重要节点管控和监督。

     因此，如果有意见，前期可以提，但是解决方案一旦定下来，应该上下一心（即使有意见也埋在心底吧），朝着目标一起去努力。

不同部门之间沟通存在隔阂与障碍

     软件开发过程中，在IT范畴内，不同部门难免有交集，例如开发与运维、开发与测试，不同岗位承担的责任、掌握的知识体系、考虑问题的角度往往不一样，导致处理事情受阻。

     因此，不同部门之间的人，应该互相学习，才能更好地沟通；做事情，尽量做轻量级的流程化、标准化。

上级工作安排不到位

     上级工作安排不到位，也会导致工作效率低。有时候会有这种怪现象，可能很多事情没做，但是下面的人没事可做；或者有的人很忙，有的人很闲。

     软件开发，工作量化本身就是一个很难的地方，如果项目经理没有做项目计划，没有做工作点、任务点拆分工作就很难安排到位。特别是刚刚从程序员转型做项目经理的人，过程性思维，不会对项目做整体的把握、整体规划，想到哪里就做到哪里，想到什么就分配什么工作，最后一团糟，一会把下面的人累死，一会又让下面的人闲死。

需求传达不明确或者理解有偏差导致返工

     探知客户内心潜在的需求很难，而需求确定后，信息传递的媒介，往往是需求文档。语言文字这种东西，传递的过程中容易失真，丢失原有的意思。这种情况尽可能比较，需求传递跨越太多层次才到最终到达开发人员身上。如果是这种结构，每层信息丢失2%都不得了，做错了，返工的效率和代价就十分巨大。

     最终的研发人员，应该接受到需求后，应该是反向和用户、产品经理、研发经理沟通，最终才能确定的。

技术架构过于落后、过于复杂

     先进的技术架构、统一高效地开发标准，是系统建设的基石，会大大提高软件的生产力。

     当你还在纠结页面兼容性，纠结这个界面必填怎么实现的的时候，人家通过工具简单配置，界面就自动生成了；当你还在纠结并发量大，分布式事务如何实现的时候，人家消息机制、两段式提交已经用的飞起来；当你还在纠结分布式系统，数据库拆分，如果做垮库查询的时候，人家ORM自动分库路由，数据分发机制已经用烂了；当扯不清、道不明各个系统之间的调用关系，猜不透单点改动的影响范围、运维上压力巨大的时候，人家服务治理框架应运而生……这所有的所有，都依赖于先进的软件架构，有现成的或者自主研发的。这一切的一切，都可以让开发人员如虎添翼，事半功倍。