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