可是,近日有一位网易的程序员抱怨:公司要求每天都要加班,到晚上9点才能下班,效率高的做完事情之后,还要在公司没事干硬坐到9点,腰间盘都坐突出了!
有网易内部的员工表示:在公司里想到9点太简单了,吃完晚饭,上楼休息以下,然后可以打打游戏或者看下新闻,然后到9点直接下班,没有必要干坐着。
然而,还有网友反驳:在公司打游戏看书,不就等于告诉老板我活干完了吗?到时候老板又会再派点活给你,或者改个方案之类的,那你后面连干坐的时间都没有!
加班虽然是增加工作时间的方式,但是我们要提倡合庆空理加班,既亩宏然完成了当天的工作任务,允许正常下班并不过分。强制加班只会让员工对于公司的厌恶感加重,传出去还会败坏公司名声,而且由于员工待着个人情感加班,工作肯定没有多少实际产出,对于公司和员工来说,并没有任何好处!
欢迎刚入门的Java小白朋友们加入Java之家:79979,2590
群内提供免费的Java的学习资料(里面有企业级技术、日常练习案例等多个知识点的资料,每晚我还会
在群内直播上课)
导致程序员加班的原因很多,主要由以下几方面吧:
1.需求不清晰。需求人员或者项目经理、产品经理没有吧需求梳理分析清楚,等开发到一半甚至开发完了,才意识到需求错了,需要重新做,眼看项目或产品都快交付了,只能让程序员加班了。
2.管理问题。企业文化,就是加班,本来没啥活,但领导就觉得员工加班他心里踏实,所以那不管你是不是程序员,一律加班。
3.自身问题。效率低,解决问题能力不行,分配的工作任务无法在规定时间内完成,那只能加班,自行解决了。
4.工作任务紧急。突然要开发一个新功能,客户要求时间紧迫。不加班,无法完成。
5.工作量大。日常工作量就是大,明巧一个人干两三个人的工作,干不完,加班还干不完呢,加班成常态了。
从甲方角度看,我就想要什么产品3个月上线,这是战略和领导决策决定的,不能拖太长时间。
甲方以这个要求去找乙方,乙方销售为了完成业绩,他满口答应。
售前一般不会反对销售。
合同一旦签署完毕,销售业绩就认为算闭槐颂完成一大半,后续介入内部流程就可能减少。
这时候认为,按时交付的责任应该在研发方面。
开发和产品团队此时可能还需要进行需求分析,系统设计,提交文档,正规一些的测试部门还要审核文档。
然后这些事都走玩,开始开发任务。开发人员每天一个日报,每周一个周报,几乎天天开会讨论。
白天都在讨论问题,只有晚上其他部门都走了,无人打扰时,研发才可能专心敲代码。
没让专业的人做专业的事情, 是工作开展的大忌,在工业上,早已证明了一切,在工厂生产中,工人流水化作业,一个人只专注一件事情,会越做越熟练,越做越快,越做效率越高。
在软件开发分工越来越明确的今天,让后端人员抢前端人员的饭碗,去写网页、样式,效率能高吗?让后端人员去抢DBA的饭碗,去做数据库优化,效率能高吗?
不专业的人做不专业的事情,可能和公司的发展历程、组织架构、人员规划有关;也可能和任务安排有关。
公司发展初期,养不起很多专业的人,可能更需要“全栈”工程师,啥都一把捉;公司发展的过渡期,有点钱了,也意识到了要让专人做专业的事情,但是人员还没招齐,那没办法,你也得兼职着做各种各样的事情。如果公司有钱了,发展也成熟了,不是属于以上两种阶段,在IT组织中,连前端、后端、测试、架构、DBA、网络、服务器运维、技术支持、安全、产品,这些职能都没区分好的话,就会对工作效率有影响。IT一线工作人员,每个坑位,都需要一颗专业的螺丝钉。
开发人员不注重代码质量,导致后期返工,导致效率低
有 时候,快即是慢,对于经验不足或者习惯不好的开发人员,开发前期,被迫或者自己没意识到,为了追求进度,逻辑没考虑周全,没做好自测,代码能跑起来就算完 成任务了,表面上任务完成得很快。但是在项目后期,测试阶段,问题大规模爆发,甚至要返工,由于测试后期,离自己写代码的时候,可能隔了一段时间,有的东 西自己都忘了,再回过头去重新“熟悉”,效率能不低吗?更为严重的后果是让项目进度不可控。因此,就算进度再紧张,也顶住压力,必须要做最基本的测试,再进入下一个任务点。
个体组织人员膨胀,出现沟通成本大的问题,导致效率低
沟通成本是人员膨胀后,暴露出来的首要问题。
举个简单的栗子,很多公司都有每天晨会习惯,如果一个组有5个人,开晨会汇报工作,平均一个人汇报2分钟,就需要10分钟,现在一个组增加到10个人,一人汇报两分钟,都要20分钟才能汇报完。时间就这样过去。
再举个栗子,30人天的工作,分给2个人做,可能需要15天,共耗费30人天,但是分给5个人做,6天能完成吗?
信息在沟通、传递的过程中,可能会“失真”,你想的,不一定能100%说出来,你说出来了,别人也不一定能100%理解,而且每个人的理解能力、知识体系都不一样,理解起来容易产生偏差,产生偏差轿郑就容易做错事情。
因此,如果人员出现膨胀,要以项目为单位,进行合理的项目拆分、人员拆分。同一个“小项目”最好不要超过4个人负责。沟通的时候,推荐使用口头+书面+复述,减少沟通过程中的信息失真。
上、下属之间相互不信任,做事有阻碍或者导致重复工作,导致效率低
上 下属相互信任是一切工作的基础。如果上级不信任下属,不敢授权给下属,凡是都要自己过一遍,而上级往往是一对多的关系,这个时候,工作瓶颈会出现在上级身 上;如果上级不信任下属,搞一堆监督机制,为了下属不做错事情,又让别人同事过一遍,又要耗费额外的成本,劳民伤财,而下级得不到信任,做事受阻,久而久 之就会畏手畏脚,很难独当一面,或觉得自己有能力没地方使,干脆走人。
上级应该充分信任下级,放心授权让下级去做事情,但这些都一个前提就是要有一个较好的软件管理过程,包括开发环境和测试团队和在完成任务的过程中进行一些辅导和进行重要节点管控和监督。
上级不信任下级,经常碰到,而下级不信任上级也很要命。程序员是很有个性的工种,不好管理,往往特别多想法。就好像车轮子陷入泥潭中,上级说车子往前推,有的人又说,往后拉,各自发力,估计车子永远都摆脱不了泥潭,还谈何效率?
因此,如果有意见,前期可以提,但是解决方案一旦定下来,应该上下一心(即使有意见也埋在心底吧),朝着目标一起去努力。
不同部门之间沟通存在隔阂与障碍
软件开发过程中,在IT范畴内,不同部门难免有交集,例如开发与运维、开发与测试,不同岗位承担的责任、掌握的知识体系、考虑问题的角度往往不一样,导致处理事情受阻。
举 个栗子,有一次,开发人员为了验证某个问题,需要运维人员协助重启某个站点。对于开发人员来说,这个站点,用的人比较少,而重启也是一瞬间的事情,风险为 基本为0,但是由于运维人员掌握的知识体系不一样,怕重启了会造成很大影响,甚至害怕出了问题要自己承担责任,明明可以瞬间 *** 作解决问题的,又要等到中午 或者半夜三更没人的时候才敢重启,效率就是这样降低了。这个时候,需要运维人员,去学习一下相关知识,或者引入新流程,例如,重启站点,需要某个专业人士 口头同意,即可立即执行。
因此,不同部门之间的人,应该互相学习,才能更好地沟通;做事情,尽量做轻量级的流程化、标准化。
上级工作安排不到位
上级工作安排不到位,也会导致工作效率低。有时候会有这种怪现象,可能很多事情没做,但是下面的人没事可做;或者有的人很忙,有的人很闲。
软件开发分工,不像搬砖头,一人搬一车就行了。软件开发, 工作量化本身就是一个很难的地方,如果项目经理没有做项目计划,没有做工作点、任务点拆分工作就很难安排到位。特别是刚刚从程序员转型做项目经理的人,过 程性思维,不会对项目做整体的把握、整体规划,想到哪里就做到哪里,想到什么就分配什么工作,最后一团糟,一会把下面的人累死,一会又让下面的人闲死。
在职场中最想吐槽的很多:
一,不升蠢消消职,不加薪。
刚刚入职桥扮的时候,老板是说的天花乱坠,公司的发展前途多么好,将来会发展的如何还大,加入公司前途不可限量,将来是升职又加薪,后来,就没有后来了。没有升职,更没有加薪一说。
二,没完没了的会议。
白天基本是开会讨论需求,然后还要配合前端联调,不停地被打断,时不时地很有几个会议要参加,不是很重要的会议一边开会拿着笔记本一边写代码,有时候你会发现到下班了开发才刚刚开始,下班后终于可以安心敲代码了。
三,被迫的加班。
大概小公司的程序员不是程序员,五分钟带知给你断一次,前端后台服务器,电脑坏了找你修,软件安装也找,耳机听不到了也找,真以为就这样了?各位系统使用者各种不会使用的问题找你,一天只有大家都下班了才有时间写代码。
可以说为了生活,打工人早已用尽全力,一个合格的打工人必定是每天早上六七点就起床,赶首班公交车或地铁,通勤1小时以上到市中心上班,风雨无阻。
中午匆匆地敷衍一下胃,到了晚上9点过,地铁站依然是人头攒动,像是沙丁鱼罐头般。Lisa偶尔加班,当拖着沉重的身体进入地铁站时,发现身边都是加班人,那一刻,既觉得有些安慰,又觉得更加心酸。
为生计努力的人,做梦都想工作能够轻松一些,根本没时间矫情,没时间去思考生活的意义
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)