可能有人会说,做IT的想准时下班很难,尤其是在互联网公司。有些外企或国企倒能准时下班,原因是公司更像养老院。

    其实这里存在个误区:能否准时下班其实和工作效率和质量有关,取决于自己,而不在于其它因素。公司的氛围让不让准时下班是一回事,能不能高效高质工作,从而能准时下班又是另一回事。比如在工作中高效了,在下班的时刻完成了当天的工作,又没有返工,哪怕真的不得不在公司里多呆,那么也可以用这段时间准备明天的活,或者用这段时间看些资料充实自己,这就能跑赢时间,久而久之收入就能不断提升了。

1 主观上要端正态度,同时计划好当天要干什么

    哪怕事情再多,当天要干的事情都是可以列出来并且量化,比如,写xx模块代码,和xx组xx人交流接口,开xx会,和xx一起测试功能,和support组一起上线代码。而且,很多事情可以并行做,比如在开会时可以写邮件,和其它开发和测试一起联调时,在等待问题的时候也是空闲的,说穿了这就是简单的统筹法。

    不过,之前某段时间里,我养成了一些不好的习惯,比如空闲时不是见缝插针地写代码,而是干些无关的事情,比如看各种网页,也会看手机。

    后来我想办法做了改善,尽量注意,在空闲时就尽量多赶些事情。不过看网页就像会上瘾一样,空闲时要完全不看也不现实,现在我就尽量看些和工作无关但和技术有关的网站,比如我最近在学python,那么就到博客园或其它地方看些python资料,或者看些能提升个人收入的文章,比如股票。

    这部分的实施要点是,第一主观上不放纵自己,第二要看也看些有帮助的内容,而不是八卦之类的。而且,一旦明确自己当日要干什么,那么在空闲的时候就会感觉到还有其它事情,也反而不会出现到下班时才发现有活走不了的情况。

2 利用大脑的清晰程度,在不同的时间段干不同的活,同时好记性不如懒笔头

     每天早上来的时候,我脑子最清楚,这时候干些技术挑战性大的活,比如写架构代码,或者写设计文档,一般下午1点到2点的时候,比较想睡觉,我就干写回邮件,根据代码整理文档或者和别人交流扯皮,到了3点以后,脑子能恢复些,一般就review代码或者继续写代码。当然,每天我绝不是按这个固定模式干,但趁脑子清晰干重要活,在脑子比较模糊时干体力活,这个原则确实能帮我提升不少效率。

     但每天会来些杂事,比如别人找来问问题,而且一些会和联调是我个人没法确定时间的,在我状态不好的时候,照样会来些麻烦事。这时,如果我更要小心,把一些费脑子的事用笔记下来,或者和人扯皮时,也用笔记录下中间步骤,这样就不大会出问题了, 而且通过动笔的帮助,我也能提升沟通和解决问题的效率。

     这样做了一段时间后,我就发现,虽然事情依然多,但由于我用了脑子好的时候干麻烦事,当我脑子不好时又有了确认,我干活出错的概率小了不少。

3 找人沟通可以用邮件和电话,但最好要当面确认,必要时要多催

    在工作中,我们不可避免需要和别人协作和沟通,比如找Support发布项目,找别的Team沟通接口,我们手头上的事,也有可能pending在别的人手上。

    沟通就有可能产生语义上的歧义,也有可能因为对方事情一多,把我当前的事情放一边了,这时,千万不能因为“卡在别人”就坐等了,毕竟高效干好事情是我的责任,也是大家的责任。遇到这种情况,我一般会采取如下的策略。

    1 如果需要合作的时候比较简单,邮件能说清楚,那就用邮件。如果三言两语讲不清楚,就直接跑到对方座位旁沟通,然后用邮件等形式确认沟通结果,如果对方现在有会,那么就约个时间。

    2 比如对方约定10点给东西,那么到了大家确认好的时间点,但对方没动静,可以电话联系下,或者干脆跑到对方那边,如果对方确实有紧急的事,那么再定下一个时间点,同时邮件发送相关领导,到了下个时间点,继续上述流程。

    3 比如对方确实忙,需要我排队等,那么我就带着电脑到对方身边,边干活边等,比如我要找support更改产线配置,而前面有其它人排队,那么我就带电脑到support,边等边干活,有空闲就插入。

    4 遇到对方确实因为有紧急的事,没法当即处理,或者我就和领导沟通再安排时间计划,但如果我的事情也很紧急,那没办法了,只能每隔一段时间后再去催。

    上述措施的核心原则是;第一不能坐等,必要时得催,第二综合考虑优先级,不能什么事都以我优先,必要时得调整,但不能让事情没结果地一直拖下去。第三是态度上一定要积极主动,有了这个态度,就能不停地推动事情往前进了,第四要“脸皮厚”,这如果用在工作上其实不是贬义词,工作职责使然。

    遵循着这个原则,虽然我手头的事情还会有拖沓,毕竟别的team或许有更优先的事情,但延后的程度就大大改善了,而且哪怕延后,也至少能知道延迟多久,而不是遥遥无期。

4 把活分类,去掉一些不重要的或没意义的事情,还可以分派一些事出去

    工作高效的目的是让我的团队和个人高效地产生价值,如果高效地解决一些价值不大的问题,就违背了本意,所以在制定各种“高效”的战术之前,更要明确工作的目标,具体而言,要明确各种事情的优先级。

    如何甄别事情的优先级,每个公司每个人的策略不同,诸如“优先级高的先做”之类的套话,本文也不想讲,下面给出些我实施下来的经验。

    第一,在周会和每日站会等场合,同领导(或者产品或者其它能做决定的人)确认好事情的优先级,毕竟优先级不能由自己说了算,同时确认哪些事情当前可以不用干。

    第二,干活总是从优先级高的做起,有些事情,大家心知肚明能不了了之的,先观望,同时上报领导,让领导决断,至于领导出面去扯皮还是干嘛,可以给出自己的想法。

    第三,在做重要的事情前,先评估在自己手上是否有风险,如果需要人,或者要其它组沟通,预先提出,大家一起想办法。总之,如果这个事情我干不完,就协商下,分配些活给组员,如果其中包含的任务需要别的组出接口或者出方案,那么自己做未必能做好,也需要其它组一起干。

    第四,有些事情我能干,但别人之前有干过类似事的经验,那么可以协调下调整些活,但这个调整的动机绝不是让我个人更轻松,绝不能以“调整”为接口推活,而是让整个组的效率更高,更好地发挥自己的作用。

    在工作中,我们需要不停地提升自己的技能,更需要有高度的责任心和担当力,不过绝不能有过多的“个人英雄主义”,也就是说,干活前先需要明确目标,然后以“团队效率”为第一考量,确认好该做的和该别人做的。这样我实践了一段时间,少做了不少没意义的事,直接提升了工作效率,而且有些活在更专业的同事手里干的时候,我也没闲着,在一旁观察技巧,这样我的能力同时也得到了提升。       

5 说下实践后的效果,也说下多出来的时间可以干嘛

    当我存了“不拖沓高效干活及早下班”的心思后,虽然还有摸鱼的现象,但情况好很多,下面归纳下实践一段时候后的效果。

    第一,有时依然不能准时下班,还需要加班,但每天下班的时候我很踏实,因为我干好了每天的活。

    第二,基本上杜绝了“事情到最后依然是一团糟”的情况,哪怕有些问题没法解决,但团队和领导能第一时间知道风险,而不是临近截至日还在扯皮。

    第三,整个人能用更积极的态势干好工作中的活,乃至能用更积极的方式去挣钱。

    那么多出来的时间可以干嘛?如果是全用在追剧刷手机就没意思。

    第一,我用一些多出来的时间来放松自己,毕竟需要一张一弛,比如上班时间我可以用多个十分钟出去散步,下班后能用部分时间玩游戏和休闲。

    第二,有更多的时间可以积累技术,比如最近我看了不少spring cloud和python书,而且目前自己写书的进度也大有提升。

    第三,这段时间里大家发现我在博客园写的文章数量变多了,而且由于能用更多的时间构思,文章的点击量也有了提升。

    第四,探索和实践了其它挣钱的方式,比如去录制教学视频。

6 总结不足,归纳改进点

    1 上班的时候依然会看些无关网站,后面我需要进一步改进,如果存在不想工作的心思,宁可通过散步等形式调整,或者去看和工作无关的技术文档。

    2  当事情多的话,我就会很烦躁,这样就影响工作了。相比之下,部门经理级别的领导,事情比我还多,繁琐程度也远胜于我,但他们大多都能游刃有余。我可以多观察下他们和别人沟通交流的做法,多揣摩他们管理项目管理产品的心得,这样我才能进一步提高工作效率,更能从事更高级别的活。

    3 所谓一力降十会,技术和能力强了以后什么都会好,当前在解决一些问题时,由于不会,所以要到处查资料到处问人,多积累相关经验以后,效率和质量一定能进一步提升。 

7 总结:只要发心,提升自己只是体力劳动

    在我发心想要早点下班后的第一个星期里,我技术能力并没提升,但由于有了意识,能用比较积极的态势解决问题,仅仅如此,就明显感觉到了不同,之后就是不断总结经验不断试错不断改变方法的体力劳动。

    不怕念起,就怕觉迟,只要大家也一起下决心“要不断提升工作效率从而早下班”,就不会再怕升起“拖沓敷衍”之类不好的想法。坚持个把月再回顾,就会发心自己脱胎换骨了。

版权说明:

    有不少网友转载和想要转载我的博文,本人感到十分荣幸,这也是本人不断写博文的动力。关于本文的版权有如下统一的说明,抱歉就不逐一回复了。

    1 本文可转载,无需告知,转载时请用链接的方式,给出原文出处,别简单地通过文本方式给出,同时写明原作者是hsm_computer。

    2 在转载时,请原文转载 ,谢绝洗稿。否则本人保留追究法律责任的权利。

版权声明:本文为JavaArchitect原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/JavaArchitect/p/11062713.html