本文要分享的是我在软件开发过程中亲身经历的“怪现象”。为什么奇怪？人多力量大，这似乎符合常理。然而，在软件项目开发过程中，往往会出现人多事少、工作量大的情况。这与我们以往的认知大相径庭。首先，让我们解释一下标题的含义。很多人指的是同一个项目组、同一个组或者同一个部门的范围；东西少是指产生的效果，实际产出的少；工作量大是指工作时间长，工作忙，实际投入大。其实是人多，事少，工作量大。说白了就是效率低下，影响效率的原因千千万万，包括人员问题、沟通问题、流程问题、管理问题、技术问题。遇到的问题：文章基本都是纯文字，有空的时候需要仔细阅读。●一线人员不让专业的人做专业的事，导致效率低下。不让专业的人做专业的事，是工作发展的大忌。在工业界，一切都得到了证明。在工厂生产中，工人们在流水作业中，一个人只专注于一件事，而且技术越熟练，做起来越快，效率也越高。在软件开发分工越来越明确的今天，让后端人员抢前端人员写网页和样式的活儿，能不能高效一些？让后端人员抢DBA的饭碗，做数据库优化，效率能高不专业的人做不专业的事，可能跟公司的发展流程、组织架构、人员规划有关；也可能与任务安排有关。公司发展初期，养不起很多专业的人，可能需要“全栈”工程师一下子搞定；在公司发展的过渡期，有了一点钱，也意识到要派专人干专业的事，但人手还是很缺。人手不够，也没办法，只能兼职做各种事情。如果公司富有且成熟，则不属于以上两个阶段。在IT组织中，即使是前端、后端、测试、架构、DBA、网络、服务器运维、技术支持、安全、产品，这些职能如果没有区分，也会对工作效率产生影响.对于一线IT人员来说，每一个坑都需要一个专业的螺丝钉。●开发人员不重视代码质量，导致后期返工，效率低下。有时候，快就是慢。对于缺乏经验或习惯不良的开发人员，在开发初期，他们是被迫的或没有意识到的。为了追求进步，逻辑我没有想通，没有做好自测，代码能运行，任务完成。从表面上看，任务完成得很快。但是到了项目后期，在测试阶段，就大面积的爆发了问题，甚至需要返工。由于是后期测试，我写代码可能有一段时间了，效率能不低吗？更严重的后果是使项目进度不可控。所以，不管时间有多紧，你还是要顶住压力，做完最基础的测试，然后再进行下一个任务点。●个别机构人员膨胀导致沟通成本高，效率低下的问题。通信成本是人员扩容后暴露出来的首要问题。举个简单的例子，很多公司都有每天早会的习惯。5人一组，早会汇报工作。平均一个人报2分钟，要10分钟。现在一个群增加到10个人，一个人汇报。两分钟，做完报告需要20分钟。时间就这样过去了。再举个例子，如果30man-days的工作分给2个人，可能需要15天，总共要花30man-days，但是如果分给5个人，能不能完成6天内？在信息的交流和传递过程中，可能会被“扭曲”。你想的不一定能100%说出来，你说出来别人也未必能100%听懂。而且每个人的理解能力和知识体系都不一样，理解上容易有偏差，有偏差就容易做错事。因此，如果出现人员扩张，需要以项目为单位，进行合理的项目拆分和人员拆分。最好不要有超过4个人负责同一个“小项目”。交流时，建议采用口头+书面+复述的方式，减少交流过程中的信息失真。●上下级之间互不信任会阻碍工作或导致重复工作，导致效率低下。上下级之间的相互信任是一切工作的基础。如果上级不信任下级，不敢授权下级，一切都得自己过，上级往往是一对多的关系。这时候，工作瓶颈就会出现在上级身上；如果上级不信任下级，搞一堆监督机制，为了让下级不做错事，让其他同事再过一遍，会多花点钱，浪费钱，下级也会做事不受信任和阻碍。有本事没地方用，就走人吧。上级应该充分信任下级，授权下级放心做事，但这一切的前提是有一个好的软件管理流程，包括开发环境和测试团队，以及一些指导和重要节点完成任务的过程控制和监督。经常遇到上级不信任下级，下级不信任上级的情况。程序员是非常个性化的工种，难于管理，往往想法很多。就好像车轮陷入了泥潭。上级说把车往前推，有人说往后拉，各出一力。估计车子永远也出不了泥潭了。但是一旦解决方案确定下来，你们就应该一起努力（即使有意见，也埋在心里），一起朝着目标努力。●不同部门之间沟通存在差距和障碍在软件开发的过程中，在IT领域，不同部门不可避免地会出现重叠，比如开发和运维，开发和测试，不同岗位的职责，掌握的知识体系，以及问题的考虑。角度往往不一样，阻碍了对事物的处理。比如有一次，开发者为了验证某个问题，需要运维人员帮忙重启某个站点。对于开发者来说，这个站点使用的人比较少，重启是瞬间的事情，风险基本为0。但是由于运维人员掌握的知识体系不同，重启恐怕会造成很大的影响影响。我什至害怕万一出了问题，我自己要承担责任。如果能瞬间解决问题，等到中午或者半夜没人的时候我才敢重启。这就是效率降低的原因。这时候就需要运维人员学习相关知识或者引入新的流程。例如，重启站点需要专业人士的口头同意，可以立即执行。因此，不同部门的人应该互相学习，才能更好地沟通；做事尽量做到轻量化、规范化。●上级工作安排不够。上级工作安排不当也会导致工作效率低下。有时会出现这种奇怪的现象。也许很多事没有做，但下面的人无事可做；或者有的人很忙，有的人很闲。软件开发分工，不像搬砖，一个人可以搬一辆车。在软件开发中，工作量化本身就是一个难点。如果项目经理不做项目计划，不拆分工作点和任务点，就很难把工作安排到位。尤其是刚从程序员转型为项目经理的人，过程思维，对项目没有一个整体的把握，统筹规划，想到什么就做什么，想到什么工作就分配什么。到头来，会是一团糟。下面的人累死了，一会儿下面的人就闲死了。●需求沟通不明确或理解错误，难以返工，难以发现客户的潜在需求。需求确定后，传递信息的媒介往往是需求文档。语言、文字等事物在传播过程中很容易发生变形，失去原本的意义。这种情况越是可比越好，需求传递跨了太多层才最终到达开发人员。如果是这种结构，每层损失2%的信息就很可怕了。如果做错了，返工的效率和成本将是巨大的。很多时候，往往是这样的沟通方式：我们需要的是这样的方式：最终的研发人员，在接到需求后，要跟用户、产品经理、研发经理逆向沟通，最后确定下来。●技术架构过于落后，过于复杂。先进的技术架构和统一高效的开发标准是系统建设的基石，将大大提高软件的生产力，让开发人员专注于业务和业务逻辑的实现，使其成为更有价值、更高产出的东西。当您还在为页面兼容性和如何实现所需接口而苦恼时，只需简单配置工具，接口就会自动生成；当你还在为大并发和如何实现分布式事务而苦恼时，人们已经使用了消息机制和两阶段提交；当你还在纠结于分布式系统，分库，做数据库查询，ORM自动分库分路由，数据分流机制用坏了；当各个系统之间的调用关系不明确，单点变更的影响范围无法猜测，运维压力巨大时，别人的服务治理框架应运而生。......所有这些都依赖于先进的软件架构，这些架构是现成的或自行开发的。这一切都可以让开发者如虎添翼，事半功倍。
