• 一天内“被喷”7.5小时后感


    朋友炒股两个月赚了10万,我帮他推广一下公众号,把钱用来投资总比放银行连通货膨胀都跑不过里强硬核离职,在家炒股 ,这是他每天的日志,有些经验是花钱也买不到的。

    一、被喷日程:

    8:30 会议室开会

    8:50  领导开喷

    11:45 上午被喷结束

    16:00 下午会议开始(开喷)

    18:00  由喷工作思路转向喷具体工作

    20:30 ”被“完成部分工作后回家继续干活

    被喷点一:考虑问题缺少宏观

        被喷如下:你们啊,做技术出身的,考虑问题就那么眼前一丁点的事,在我看来技术的问题都不是事随便找个程序员就解决了,总考虑这么丁点的东西怎么做管理?做管理要把眼界放开,考虑问题怎么能这么细节?这和写程序不一样!@#¥%……&*(.....30分钟+

        其实最近我也一直在考虑关于”技术思维“的问题,即做什么事都是喜欢钻进去而且为法自拔的陷入到细节中。根据自身的经历和身边的朋友来目测,这也许是做技术人员的一个通病,喜欢安静、踏实的干活,正是由于这样的心理导致程序员在考虑问题的时候不善于考虑处理事情的宏观思路。

        什么是宏观,这个概念是相对的。我举个例子(理想化的情况下):

        场景如下:

        村长:管理整个村,为每家每户做服务。

        县长:管理整个县及下面所有的村,每个村向县汇报内容。

        市长:管理整个及市下面所有的县,每个县向市汇报内容。

        过于细节的情况:县长发现某村的某户出现了矛盾,之身去该村处理该户问题。

        我们不能否定该县长的工作态度和工作成果。县长确实是在处理和解决问题,但如果一个县长总是处理村长该处理的问题,这个县长真的称职吗?当有一天市长来到该县问起:“这个县的总体情况怎么样?”,县长回答:“哦,A村的某户发生了什么矛盾,我是怎样解决的。B村的某户发生了什么矛盾,我是怎样解决的......”。

        宏观看待问题:站在县长的职位上,所谓的宏观回答市长的问题应该是“A村*****,B村******,但也有些住户是***样的,例如:A村的某户、B村的某户”。

        占在不同的位置考虑的问题不一样要宏观,在和职位匹配。

        回到我们热忠的行业:如果你是设计师,应该考虑设计而非具体的实现。如果你是架构师,应该考虑架构而非设计和实现。如果你是PM,应该考虑管理干系人的期望,页非技术实现细节。定好位,然后把高度提起来,坚决克制自己看到代码就想敲欲望。

    被喷点二:如果有多条路可走,一定要选择最取巧的

        被喷如下:解决问题的方式有N多种你信不信,这件事让我处理我有10种办法对付他,到你们手里怎么就这么难!@#$%^&*30分钟+

        园子里肯定有很多朋友都带过私企和外企的项目,这类项目用户有强列的需求和迫切的愿望,在带项目的时候用户会把前面的很多路都主动铺的很平,如:主动向领导汇报,主动发会议通知,主动发变更通知。导致我们这些半技术半管理的二不像人员在处理项目的时候一直以为用户即是如此。当遇到不配合的用户时还使用我们最善于使用的手法去处理这个问题:踏实的干活,客户肯定会满意的。很傻很天真有木有。

        当遇到问题的时候,一种方式行不通一定要换一种取巧并且能够快速推进项目的方式。举个最简单的例子,你与客户沟通始终得不到答案,对方的借口就是“领导出差”等领导回来再说。这种情况我们怎么办?为了推进项目上的工作我们仍然与该负责人联系?发邮件打电话催他?少年,做事不是写程序......

        方案(也许不妥):1、再次给该负责人发邮件,邮件抄送所有相关领导。2、直接给能定事的领导打电话。3、4、5、6...

        我们回头想想,为什么不能从一开始就直接找到这个领导然后让该领导去安排下面的人去处理此事呢?

        两种开展工作的线路,你会选择哪种?

        1.自下而上:与负责人沟通,定不了事让该负责人去找领导确定。

        2.自上而下:直接与领导沟通,让领导安排负责人去做具体的事。

    被喷点三:最大的风险就是自己不知道什么风险

        被喷如下:你说下,这件事你是怎么计划的?回答:第一步&&**,第二步&*(。|||| 什么?你就这么做?谁给你确认了?如果第二步不&*(。这么办你怎么规避这个风险?回答:即然已经第一步&&**,那么第二步一定是&*(。||||什么?第二步肯定不成立,你就是在闭门造车,这些问题不考虑清楚一但发生了怎么办?最可怕的就是自己都不知道项目有风险!@#¥%……&30分钟+

        做程序员出身的我们总是以为我们做的事就像写的程序,method a 调用method b 调用method c....然后结束...这又回到我们最初的问题,程序员考虑问题太理想化。当我们跳出程序员这个行业后会发现我们很多程序员的思维定式禁锢着我们做事理想化。预知不出风险的存在。如:我们要由北京去上海参加一个重要的会议,计划是坐飞机可以准时到达。那么我们是否要考虑飞机晚点的backup去规避不能准时到达的见险呢?做项目,要经常在自己考虑的问题前加“不”,如果“不怎么怎么样”,我的备选解决方案是什么来遇见风险。见险管理也是很重要的。

    后记:

        此博文只随便写了几点。悲催的被喷了整整一天,各种问题各种喷,说话被喷(工作思路有问题,这个问题你考虑过没有?那个问题考虑的太不全面),不说话也被喷(太技术开会不说话),请问我是该说话还是不该说话?虽然自信心有些小小的受挫,但仔细想想有很多点还是有道理的。有时候觉得自己更喜欢安逸的写代码,这也是一种生活方式。可是我们得到的是什么呢?走出程序员的圈子,很可能我们连事情都表达不清楚,不信?你对着镜子去概括一下新闻联播就知道了~

    版权:http://www.cnblogs.com/iamlilinfeng

  • 相关阅读:
    格式化HDFS出现java.io.IOException: Cannot create directory /opt/hdfs/name/current错误
    Hadoop集群安装教程(完全分布模式)——更新中
    将sql语句嵌入到c语言中——codeblocks
    centos虚拟机网络连接问题
    Linux虚拟机如何调整登录界面的分辨率——解决登录界面图标过大的问题
    Spring Cloud常用组件超时总结
    程序集加载与反射笔记
    ASP.NET分页
    显式向标识列插入数据
    JIT和程序的首次执行
  • 原文地址:https://www.cnblogs.com/iamlilinfeng/p/3290646.html
Copyright © 2020-2023  润新知