为何软件开发，人多，事少，还会工做量大？

本文所要分享的是软件开发过程当中，亲身经历过的“怪现象”。为何说怪呢，人多力量大，彷佛才符合常理，可是每每在软件项目开展的过程当中会出现人多、事少、工做量大的状况，这跟咱们以往的认知截然不同。

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

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

文章基本纯文字，须要空闲的时候，精心阅读哦。

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

没让专业的人作专业的事情， 是工做开展的大忌，在工业上，早已证实了一切，在工厂生产中，工人流水化做业，一我的只专一一件事情，会越作越熟练，越作越快，越作效率越高。

在软件开发分工愈来愈明确的今天，让后端人员抢前端人员的饭碗，去写网页、样式，效率能高吗？让后端人员去抢DBA的饭碗，去作数据库优化，效率能高吗？

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

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

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

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

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

沟通成本是人员膨胀后，暴露出来的首要问题。

举个简单的栗子，不少公司都有天天晨会习惯，若是一个组有5我的，开晨会汇报工做，平均一我的汇报2分钟，就须要10分钟，如今一个组增长到10我的，一人汇报两分钟，都要20分钟才能汇报完。时间就这样过去。

再举个栗子，30人天的工做，分给2我的作，可能须要15天，共耗费30人天，可是分给5我的作，6天能完成吗？

信息在沟通、传递的过程当中，可能会“失真"，你想的，不必定能100%说出来，你说出来了，别人也不必定能100%理解，并且每一个人的理解能力、知识体系都不同，理解起来容易产生误差，产生误差就容易作错事情。

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

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

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

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

上级不信任下级，常常碰到，而下级不信任上级也很要命。程序员是颇有个性的工种，很差管理，每每特别多想法。就好像车轮子陷入泥潭中，上级说车子往前推，有的人又说，日后拉，各自发力，估计车子永远都摆脱不了泥潭，还谈何效率？

所以，若是有意见，前期能够提，可是解决方案一旦定下来，应该上下一心（即便有意见也埋在心底吧），朝着目标一块儿去努力。

● 不一样部门之间沟通存在隔阂与障碍

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

举个栗子，有一次，开发人员为了验证某个问题，须要运维人员协助重启某个站点。对于开发人员来讲，这个站点，用的人比较少，而重启也是一瞬间的事情，风险为基本为0，可是因为运维人员掌握的知识体系不同，怕重启了会形成很大影响，甚至惧怕出了问题要本身承担责任，明明能够瞬间操做解决问题的，又要等到中午或者半夜三更没人的时候才敢重启，效率就是这样下降了。这个时候，须要运维人员，去学习一下相关知识，或者引入新流程，例如，重启站点，须要某个专业人士口头赞成，便可当即执行。

所以，不一样部门之间的人，应该互相学习，才能更好地沟通；作事情，尽可能作轻量级的流程化、标准化。

● 上级工做安排不到位

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

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

想要了解更多软件研发过程的开发经验，能够加群：650385180，里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源，如下的资源都在群的共享区，目前受益良多。

● 需求传达不明确或者理解有误差致使返工

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

不少时候每每是这种传达方式：

咱们须要的是这种方式：

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

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

先进的技术架构、统一高效地开发标准，是系统建设的基石，会大大提升软件的生产力，让开发人员专一于实现业务、商业逻辑，作更有价值，更高产出的事情。

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