一次工作失误

    说明:说了那么多废话目的就是为了记录近两个月的工作情况,有时我们遇到的困难或不解不一定是工作技能的问题,做人的问题,可能是沟通问题、外部环境问题,自我认知偏差,急于求进,这一切作用到个人身上叫做工作能力。我简单整理如下:
一、工作方式
    新接触一项业务,不熟悉没经验的情况下,了解他人的沟通方式、工作习惯,熟悉现有平台和业务,勤总结勤思考。
二、沟通
    最主要的是搞清楚目标,沟通过程中分门别类做好记录,调整优先级,发现问题及时沟通、完成结果真实反馈。
三、技术学习
    这块主要体现个人的学习能力,没有好的办法,适合自己的方法才是最好的,但是要注意好深度和广度的扩展。动手做代替看,容易眼高手低;分类分块各个击破;做好总结、勤梳理;以工作需要学习技术,脱离初级水平可以扩展广度。
四、尝试管理
    管理不是简单的带一两个人,也不是一个人做完全部的工作,把部分模块分给队友,它是在有技术的基础上,熟悉开发过程、软件工程中遇到的各种问题,做好组织、计划、安排确保整个项目的顺利进行。

    这几天一直被这样的事情烦恼着,工作了一段时间,有点小膨胀,盲目自信,自我感觉良好,技术有点基础,工作比刚入职好多了,没有那么多不顺心,于是不甘心只做一个公司的小职员,想要展示自我,多得到信任和认可,多承担多得的心态就很控制不住。无意识间说话做事有点高调、但最终做事的结果比较低调,也出现不少问题,让我看到以前想法天真、自我、考虑表面、姿态高调、为人处事做的一塌糊涂。

    在一个小公司你要时刻准备接受挑战,项目管理不到位,没有专门的项目团队,没有开发计划,没有需求变更计划,说改动就改动,没有专门的测试阶段,从需求整理分析到最后上线全都要一个人或两个人搞定;你经常会遇到这样的情况,好不容易实现功能模块做好的效果,领导一句话:要求去掉一列、界面不自然换掉、需要加权限控制、嵌入到原有的业务系统中、部署到另一个业务平台、这个功能用户不要了去掉,做好了要求考虑程序的扩展性能等问题。你会很忙,要经常加班,频繁改动,大部分的时间花在业务数据处理、众多业务表之间的关系上。你会因为页面上需要改动文字、样式调整、多加一列、少展示一个列表、取到的数据不对挨批。遇到技术问题时,经常会听到这样的训话:有没有搞错,别搞那么复杂,这块很简单,就是提交一个表单把数据保存到数据库、做一些数据验证、加上点控制,你这样做不行吗?给我快点改过来;还有经常要求你别做太多解释,只看结果,你先把功能实现,问题是功能永远做不完,实现了功能,重复之前的改动,页面加上这一块去掉一列等等这样的问题。好不容易到最后阶段部署到正式环境,报错了,领导问你怎么回事?快点解决bug,做防御式编程屏蔽掉异常,反而要求你:该报错的就应该报错,把异常都屏蔽了怎么验证数据的正确性,用户怎么知道填报的对不对?除非你对整个业务系统熟悉了,完全理解业务需求,技术过硬,不厌其烦的保质保量的按照要求做,到独自承担一个子系统,所有的问题自己控制。对于新入职的或刚加入的新人来说,沟通问题、理解业务问题、熟悉现有平台、了解业务库、熟悉开发模式、快速融入团队都是一个不小的挑战,这也是在考验一个领导的能力;你经常会出现各种各样的问题,原因一部分在自己,另一部分看个人运气,遇到一个好的领导,原意教你带你是个人的运气。否则你就只有加班、挨批、频繁的改动,我的不幸从这开始了。

    新入职第一天上午进行简单的培训,了解公司文化、制度、工具、项目管理平台、员工手册等,下午就给分配一项任务,修改原有系统的bug,记得梁老师过来,直接问我webform熟悉不?给我浏览了一个业务系统的bug,要求修改过来。我把他演示的结果迅速的整理了一个修改功能点列表,发给他确认,没问题后着手开始工作,还算顺利,这不是一个复杂的业务系统,关于房建、地铁、市政数据的上报、审核、数据维护的一块业务,每个模块的开发模式都是一样的,用webform 中用户控件展示列表页、普通页面(aspx)展示数据维护和审核,所有的功能块在一个页面代码内全部实现,包含获取数据源、数据验证处理、数据持久化,页面上简单的交互功能用js实现。我对webform不是很熟悉,之前很少用到过,大学期间做过几个demo,还有点印象,又没有太复杂的业务逻辑,都是数据的处理,模式还都类似,意即修改一处,需要复制粘贴修改别处的。就很简单机器的修改完部署上去交付,中间有一块很花费时间,第一次维护一个老的项目,又不熟悉业务,且第一次跟该领导有工作交接,他说话很快,有时听不清,演示bug时简单给列了几点,出于尊重和礼貌我没听清楚的没在找他确认,自己在走流程发现的问题做记录并做修改。接着安排了下一个任务:写一个windows的服务要求把表数据由老的业务库导入到新库中,我开始意识到沟通将出现问题,再不能业务问题自个花费时间走流程,该确认的就要问。我在理解业务需求时出现了问题,挨批和自责是难免的,我开始注意到该领导不善于沟通(指的是技术管理者对技术实现中遇到的问题很清楚,讲解业务时会谈到重点给与技术实现上的建议),但是对业务非常熟悉,听起来很复杂的业务一口气可以说完,涉及到的表结构包括名称、字段、之间的关系也很清楚的写出来,讲解业务的过程中,你是不能轻易打断的,也不能反问,只能待他讲完,我拼命的在记录,一张纸写的很乱,他熟练的应用快捷键和无关的讲述通常是十分钟或近半个小时,还好最终搞清楚了目标:把五库合一库A表中的数据以服务的形式自动导入到ProjectShare库的B中,条件是先到新库中的C表检索某一个字段D是否存在?拿到C表中的部分数据结合A表中的数据导入到B中,导入前查看B中数据重复的不要入库;发给我一个工程,里面有类似的功能,是从另一张表导入到B表中的,并要求尽快实现功能部署上去,能借用原来实现的功能就直接复制过来。搞清楚这个目标我花费了不少时间,还特意写了一个复杂的sql语句,找关联两张表的字段,理解原来实现的逻辑,结果还挨批说理解需求不到位。实现的过程中,来了一个救火的电话,要求修改质量上报平台中的一个bug,加一个简单的新功能,我停下手中的工作,改完后,没做太多测试,直接把部署文件发给他,第三天我挨批了,老总把我叫过去训话,问我怎么回事?我得到的原因是:梁老师电话说过的,怎么做修改,我没有完全按照要求做,发给他的文件已部署上去就报错了,害的他改了半天,我技术不行,直接辞掉;我当场做出了解释,这件事才算过去,之余的时间我补习webform,了解到服务器端控件和客户端控件的区别、用户控件加载的流程、基于公司winstart平台的特性,主动找梁老师说明我对业务和平台不熟悉,索要相关的文档,工作中花费时间多的地方,要求沟通过程中能随时打断他提出问题,讨论问题,讲解过程中列出关键点,毕竟近半小时的沟通一下子把问题都说清楚,也不是轻易理出来的。得到帮助关系进一步缓和,逐步建立了信任,但还是时常挨批,我有机会以玩笑的方式顶撞和解释,个人觉得还是一个好的领导吧,平易近人,说批就批,一激动时就说不出话来那种,给与我很多帮助。我每天坚持按照要求写日志记录,把工作中遇到的问题,明天的工作安排,一周小结,发现的问题都列出来,因为新到公司一周,先后被找谈话三次,要求日志写的规范,建议和问题都写出来,方便领导了解你,老总很会说话,常常分辨不清楚是挨批还是表扬。我简单总结一点:表扬你时你要特别注意,可能在批评你,批评你时更要注意,你的问题大了。
 
    我先后提了几个建议和请求帮助:没有专门的测试保证质量;工作氛围沉闷,控制项目管理量化到具体个人具体任务,大家都很忙,都急于做任务,沟通很少,遇到问题讨论很少,经验不能得到共享,之余因为不了解几乎无机会沟通;我负责的业务开发部署上线挺乱的,没有版本控制和测试,原来公司的平台+项目的开发思想可以提高开发效率;项目管理平台中的任务不具体沟通存在问题;业务模块无重构,开发一个模块部署到多个系统中;业务经理很忙怎么请求帮助和沟通;我做的这一块工作不是太认可,技术上提升很难;得到的反馈是:工作氛围文化这块已经交给XX在负责,在改革,沟通问题大家都很好说话的,举了几个例子,之余时间聊天、一起吃饭等方式熟识,公司的文化是:承担、分享、协作、提升,以用户为中心等等,给我一些具体的跟同事沟通交流的具体建议,没了。这个时候我就想辞职,不想待了。这不是项目开发,也不是团队合作,是基于相同业务模式的开发,一个人独立负责一个业务系统,借助现有的基础平台和配置管理,熟手快速搭建一个,个性化的定制项目都出差了(进行现场开发),基本就是在维护老的项目,涉及到的业务也都是大同小异,只是目前不熟悉,都是XX审批系统、管理系统、上报系统、内容管理系统、OA系统、信息维护系统,我给自己新定了一个目标,迅速熟悉一块业务,独立负责一个子系统,我的噩梦又开始了。

    从带我的领导那儿得到反馈,后面会把我的工作内容逐步移交你,现在大部分的工作都是新模块开发,老的需要维护的我能做的都自己做了。工作之余我走的很晚,跟老A的关系得到缓和,明显感觉到态度上的转变,由之前挨批,变为聊天谈话,指出缺点,听我解释原因,我明显感觉到他是一个熟练的业务专家,对技术停留在CURD阶段,熟悉开发过程中常见的大部分问题,对管理和沟通不是很擅长,聊到技术时,提过几点:(1)优先实现功能,按照原来的代码思路,不需要重构不需要写那么麻烦,别人看不懂,读起来费劲;(2)现在的这几个系统都是之前老的项目,目前在维护,运行的挺好,没有必要用新的mvc框架重写一遍,还有风险;(3)业务系统对性能要求不高,要求能够快速实现功能,满足用户最基本的需求即可,但是对自己写代码也要要求,访问数据库能少查一次就少检索一次;(4)没什么技术问题,主要是把业务理清楚,搞清楚目标,分模块一块一块的做,完整的实现一个模块在开始其他的。后面我陆续接到其他业务模块,获取标段工程数据模块、专家管理、评标、计分模块、会员管理模块修改bug等,这些模块基本上是相似的,除了具体的业务流程上的差别,实现上都是列表查询页,CURD页、跳转到其他业务系统中的模块。在获取标段工程数据模块中因为业务问题我又开始挨批了,有一个点强调了多次,我还是照旧犯错,原因是这样的:老A不会看我写的代码,他只要求结果,结果正确ok,不对会要求我复述业务流程,关键节点,整理出文档。之前写过的一个数据转移服务,现在数据源有两个库,根据传递过来的参数项目编号和标段工程编号获取相关的数据,当项目编号不为空先到大项目库检索指定表拿到标段工程编号,在按照标段编号取到五库中的数据,当标段工程编号不为空时直接到指定库(wkdatanew业务库)取到数据。项目编号要到标段工程项目信息表中检索,业务搞清楚了结果我一看业务表,疯了。业务表很多,给的文档不是最新的,页面上要求展示的数据不能找到对应的字段,跟项目信息表的外键关联,字段命名都一样,看一会都看晕了,谁知道哪一个是哪一个,一不小心就会搞错,因为很多业务表存储的数据都一样,有的是主从表关系,有的是父子关系,到子表中都可以拿到数据,做这一模块时大部分时间都花在这,核对并确认字段含义。业务经理通常很忙,要经常出差或开会,几乎一周能在公司看到几次都不错了,沟通和需求有多次是通过电话,多次是下班后讨论的,一般我借助这样的方式,电话沟通后跟他快速确认几个点,迅速整理出来文档列出关键点和注意事项待他确认,一天发送两次情况反馈,描述结果遇到的问题、待确认的业务问题、部署情况、存在的问题。以这样的方式他对我的工作情况有个大致的了解,知道我一天都在做什么,待确认的业务和技术问题也会提前给与电话指导,找到沟通的点了,进行的挺顺利,这段时间挨批很少,也让我之前有想离开的想法搁置。在沟通和熟悉业务上他提过几点,原话描述不清楚了,也没有特意说,讨论问题时提出来的:(1)沟通要注意沟通的对象是谁?能够适当的切换你的角色,不要试图证明谁对谁错,目地是为了解决问题;(2)思考后想清楚了直接讨论关键点,直来直去不要试图掺杂解释、原因和个人因素,这样更简单明了;(3)理解业务不难,搞清楚目标,分门别类做好记录,别记乱了搞混了,注意大的节点,大节点下涉及业务上的注意点,注意我说话的重点,不清楚的立马提出来,不要自己理,事后花时间细节问题理不清,业务理不清楚后面的工作没办法继续了;(4)跟领导汇报工作这个得注意,不要涉及太多细节,理清结果和大的节点,做过的模块理清业务和联系、整合,用户提出一点能够快速映射到指定的块,你看做过的东西都忘了,下去多想想。

    有一点我很纠结到现在不知道如何改,跟周围的同事、领导、朋友关系始终不能更进一步,好的情况下停留在师生关系上,他人发现我有想法、不切实际、态度好,工作上挺乐意帮助或指点,当然挨批也很多。我很希望能够像我周围熟悉的朋友一样,有很多共同话题可以聊,以玩笑的方式谈存在的不足,起码关系自然不刻意。但是现实的情况是除了工作没有多余的话题可以谈,工作上遇到问题也是以训话的方式,最后要求回去好好反思,一句话:我把不住别人的脉,没有缘,不能谈到一块,聊不到一起,不会聊天,性格的原因。我周围有一个哥们让我很是羡慕,就是会沟通,不管领导还是朋友,话说的有点...但是关系处的很好,加工资挺严肃的一件事,搞不好最后就离职了,但是在他那儿,像开玩笑一样讨价还价,有事没事领导一起吃饭,关系很自然处的挺乐呵。我清楚一个问题,在一个公司想到长远发展,搞不定一个领导,说好听点,不被领导信任和认可,一直默默的付出和努力,至少目前看不到什么出路。前提是你有能力,找到乐意帮助你的人,带你指导你,原意教你东西这是多么幸运的一件事。我偏偏抓不住,我想到了以前在北京出差,最近工作遇到的人和事,别人给的建议,在不适当的时候情绪化,不管该不该说的都说了,我是表达出去了,不看结果。我会表达不会沟通,不注意沟通的效果,不懂切换角色,不会隐藏缺点,不分场合,有时是盲目自大,话抛出去了,让人不爽,经常让老A不爽。每次外出聚会一回来,老A就很不爽,不多说几句都感觉不到我存在:言多必有失、不要重复讲同件事、低调别把姿态放那么高、不会聊娱乐的话题、不要把事情说的那么简单表面...我把它当作生活的调剂品—吵吵闹闹,很少花时间多想。我并不是每次都这么幸运,不会每次都遇到好的公司和领导,我想起原来公司的领导,当初辞职的有多么情绪化。

     一个月的接触,我给带我的领导留下的印象还好吧,虽然挨批不少,但是签合同时经老总反馈(老总表扬时实际上也是在批你),对我的工作还是肯定不少的,愿意继续让我跟着他。我现在想来,当初留给他的印象可能是:工作态度还行,知道反思和总结也在改正存在的问题,理解业务和需求欠缺,沟通时试图表达证明自己,不注重细节。紧接着我接到了一个偏管理和设计的工作,在原来企业平台的基础上做一个报表的业务模块,发给我两份文档,要求我整理出来功能模块、理清业务需求、设计UI页面、设计业务数据库表结构、做好开发计划,并用mvc框架实现功能。我当时手中还有专家管理的模块在负责,没多想顺口答应了。我的麻烦从此又开始了。

    领导通常会在今天安排明天的工作内容,这周五安排下周的工作内容,一个下午我在忙手中的工作,就没来得及多分析两份文档,接着领导把我叫过去讲了很多需求细节,并讨论怎么实现,我听着需求不是很困难,也能理解,也在拼命的做记录。一个企业负责多个项目,一个项目有多个工程建设,有的工程是市外(除杭州市)工程,每个季度要求上报上个季度的数据,这些数据包括市外工程数据、统计口径外的产值报表上报、企业的经营情况报表上报,每季度管理部门设置统计口径外的企业,难点在理清业务的逻辑关系,确定统计报表、上报报表,根据要展示的数据怎么设计业务数据库更方便做统计,要展示数据的具体含义。有简单的权限控制,上报时间控制,已经上报的数据不可更新删除,页面给与提示信息,整理出来四个模块,分为:市外工程数据维护、产值报表上报、统计口径外的企业经营情况上报、统计口径外企业设置。我记得之前在原来公司参与项目的稽查监管系统,一个用户负责多个项目,项目在建设过程中每个季度要按时上报进度数据,这些数据包括:合同数据、进度节点数据、资金使用情况数据、问题反馈等,对上报的项目数据进行统计分析汇总,按照省市地区或处室行业展示一些统计报表,列表页按条件查询导出相应的项目数据,还有一块催报功能,对未按时上报的项目单位进行邮件或短信的提醒。当然市外工程模块没有稽查系统复杂,有相通的业务,理解起来不是很费劲。我花费一天时间在原来的基础上整理一份需求文档,包括:需求在整理、功能模块、数据库表设计、上报数据的控制项、梁老师提到过的注意点列出来,并附上个人想法。之所以把这块说的清楚点,是因为后面的问题都是因为业务没有完全理清楚,做出来的东西返工。发给领导后他给我反馈:简单明了,都看不懂是什么意思:业务数据库设计有问题、再重新看文档理清楚业务。我重新整理,有几个问题没有及时沟通:(1)统计口径外的企业设置跟以前业务系统数据有关联吗?是新的企业吗?(2)统计报表要求展示很多统计项数据,怎么设计相关的统计表?需求单独搞一张专门的统计表,在上报数据时更新该表的数据(ps:通过触发器或在程序中控制),方便展示数据;(3)细节问题已经上报的数据不可更改,但是有些基本信息数据下载页面时自动加载,哪些数据? (4)上报页面数据有不少个性控制,比如上季度有数据自动加载,已经上报的不可更改,部分统计数据。整理一下待确认的问题,周一找领导,他唉声叹气,跟之前一样说我需求理解的不到位,今天重点在梳理一遍,然后把他设计的表结构发给我,我就大致明白。我当时特想跑过去告诉他,业务数据库表结构的设计并不会减少业务的复杂度。我搞了四张表,他分拆成六个,独立出来一统计口径外的企业表,产值表和经营表拆分成主从表,把统计数据打乱到这几张表,这样就没有必要专门设计一张统计表用于展示数据,但是还是要在程序中更新统计数据的信息。之前挨批过多次,习惯了在怎么叹气我也不想争辩什么,下午根据表结构重新梳理需求发现是我理解不到位,对数据上报的流程、一些业务词汇(统计口径外、市外工程、市内工程、)没把握住。我把需求整理这块描述的详细些目地是为了说明源头没理清楚,后面做出来的东西返工很多,我有很多问题没有考虑清楚,包括页面字段展示的数据 来源、含义、怎么处理、权限控制、拿到该数据有关的业务表等。

    这个子系统用公司mvc框架(重写了mvc的视图页面,使其继承公司原有的UI样式,统一页面开发模式,扩展控制器做一些公共的处理比如跟当前登录用户有关系的数据,引用winstart平台:一个基础平台包括访问数据库、数据处理模块、用户权限、CRM设置等)做,搭建mvc框架用了一天时间,熟悉半天,最后确认要部署到现有业务平台下,老的业务系统都是用webform做的,怎么把mvc嵌入到webform中用了近一天。好不容易简单实现了市外工程项目数据上报,领导要求把列表页直接部署到菜单下。这说一个问题,很多业务系统都是基于公司winstart平台,统一UI样式,统一后台菜单配置,把页面挂上去,通过这样的方式提高开发效率,熟手可以快速搭建一个网站,不需要跟美工太多配合。突然这样要求,意味着mvc页面就不能通过crm简单配置实例化到winstart平台所支持的页面(这是由于平台的限制,只支持ascx页面,通过配置地址和后台菜单统一的UI挂到业务系统下),找到两种办法,一是修改原有的平台代码,使其支持aspx或cshtml页面,二是在页面写一端js脚本捕获跳转事件,改变url地址重新绑定使其间接支持aspx页面。最后找领导他要求搞两个解决方案,列表页放在一个解决方案里,其他的页面放在mvc框架,并共用业务层。这就给部署和团队开发带来了问题(一个用vs2010,一个用vs2012就这样统一开发,后面新加入一人,他不安装vs2012,只能把dll来回拷贝)。我在这个简单的项目上花费的时间不少,很多是无效的时间,我开始暴露出技术的不扎实和带人无经验,在工作安排、组织、计划上做的不够好,结果是没注意到各种小细节,花费时间和产出不成正比,没完整的把整个模块做下来,我总结如下:
(1)沟通问题
    一开始就没把需求具体细化,包含权限控制、页面数据加载、上报流程、数据库表设计理清楚,只是理清楚了大致的流程,细节问题比如报表统计值显示,要求:第一次填报数据时可以手动操作,上个季度有数据时自动计算,已经上报的不可更改,新签合同金额是当前填报季度根据新签合同时期计算出时间段,拿到该阶段的数据统计值。以至于在后面实现功能后频繁的修改,发现需求理解不到位。
跟实习生的沟通,我也是经历过零经验,知道在初次接触新业务时遇到的问题,就找他简单的进行沟通,了解他个人的情况、目前做的情况、业务需求、用到的技术、注意事项、我的开发计划、涉及到的业务文档等,尤其搞清楚负责模块的业务流程、页面数据加载、svn提交代码、快速的进行页面布局,但是后期证明在开发过程中对业务还是没理解到位,强调过的没记住,照做不误,我把时间花在整理两个解决方案,讲业务,修改提交上来代码的bug。

(2)开发计划制定
    我不清楚具体原因,突然就空调了一个领导,把我移交给他,负责的模块涉及到的业务也要找他讨论,我后来找带我的领导得到的解释是:我需要经常出差,最近又很忙,这块你又熟悉,后面有什么问题直接找他沟通。他要求我停下手中的工作,再次整理需求文档、开发计划、功能模块和数据库表结构发给他。我在这犯了很傻的错,老总交代任务时工期给一个月时间,我当时未考虑太多,按照一周安排开发计划,并把文档提交给他。当时很诧异的反问我:别人给你一月你为什么用一周时间呢?我给出的原因是:四个模块已经完成了一个,其他几个模块都类似,我自己开发一周时间,现在两个人开发;需求文档、表结构设计已经确定、流程已经走通都发给他确认过了,又没有提出什么问题;这个没说出来,内心小膨胀吧,初次带人,也想证明一下自己的能力。结果证明一周时间根本不够,技术风险、两个人沟通问题、保质保量要求、细节处理、测试部署实施等都需要花费时间,领导给一月时间是必要的,当初做的决定太不经过大脑了。

(3)未考虑风险
    做这个简单的模块出现不少问题,像上面出现的两个人有沟通问题,你把业务、目标说清楚了对方不一定完全理解,就算理解了做的过程中不可能不碰到问题,只实现了功能没处理细节包括:数据验证、上报流程、异步处理、提示信息等。好不容易按要求完成了模块,领导看后又提出了需求文档中没有的需求,比如:填报时间不能只控制填报的是时间格式,还包括四个时间点的大小,填报顺序;列表页面不全,在加上这几列,把该市外工程上报的产值列表显示到下面,页面样式不好看在调整一下;省市要实现无刷新联动效果,重新部署到企业平台上,这个有权限控制等。我当时不停的在记录,不停的在忘,你说早干嘛去了,发给你文档确认时不说,不看,不提要求,这都做出来了要求改动。技术上的问题:开发过程中遇到奇葩的问题很正常,比如从外部传递一个企业编号,提交保单时保存到数据库,这个思路不难吧,也有多种方式,奇怪的是在本地调试都能通过,部署到服务器上怎么都接收不到参数,你说原理和思路吧:后台接收的参数无非就这几个来源,表单、上传的文件(Request.Files)、url地址传参、mvc的话有RuteData数据源等,最后查到原因是一开始部署到质量上报平台,现在直接把dll拷贝部署到企业平台,由于是mvc框架嵌入原webform系统中,路由机制请求的还是原来部署到质量上报平台上的页面。

(4)开发方式
    它不像正常的系统开发,产品开发,有需求变更文档说明、开发阶段、测试阶段、部署上线阶段,基本上是领导一句话,说不好就要频繁做改动。一边在开发新模块,一边在调整刚做好模块的页面布局,说看结果就要部署到环境。

我在新进公司做过不少错事:
(1)提建议
    提建议无可厚非,前提是合理有可行性,建议提出来了要有解决的办法,不能只发现问题,跟老总提时话到中肯,最好是写一份文档,前后说明的文档;建议内容跟工作相关的,最好不要涉及到管理、文化、要资源。对于新手最好不要提什么建议,有想法是好的,可能考虑不全,看问题的角度狭窄,在你工作一段时间后,有积累有工作成果,跟领导建立信任关系且对你有适当的认可。打算长远在此发展适当的提点建议是可行的,不要做这样的傻事:看书理解个皮毛不管结果提出来,2B青年欢乐多,无所谓。
(2)讨论
    不管跟谁沟通,讨论问题都要分清对象,切换角色,跟业务经理他可能对业务很熟悉,对技术细节把握不到位,了解他人的工作习惯、沟通方式、讨论问题的特点,找到一种方法,比如列出清单,写一份文档,讨论大的节点,结果反馈,分门别类做记录各个击破等形式;遇到技术问题最好新建一个工程,单独做一个demo测试验证,思考后拿到技术问题点找他人讨论,否则你得到的是思路,还要把当前问题的工作上下文描述一番,最后坏的结果可能是花费时间长问题还未解决,别人理解不了你的意思。可气的是有的直接贴出报错的图或直接报错让你帮忙调试,是开发中常见的问题还行,不是的话你还要理解上下文环境,查看调用,查看参数,遇到远程调用、多线程、工程引用混乱、页面缓存、部署到服务器端调试是要疯掉的,技术人员清楚,有的bug搞个一天解决不了是很正常的事,不过很少遇到过。在碰到这样的公司,不注重员工个人成长,项目经验共享,量化到具体模块任务,每个人都忙得要死谁乐意帮你?怎么沟通?一天请教两次问题下来是要疯掉的。遇到奇葩的问题很正常,在本地调试正常,部署到服务器就不正常,查到最后有页面缓存,配置环境设置,更新版本不匹配,数据问题,调用第三方程序集等,最终解决问题是学到东西了,但是效率低下是要挨批的。
(3)汇报工作
    汇报工作跟讨论问题一样,需要分清对象,对领导说他关心的大的节点,结果怎么样?时间安排、计划安排、存在的问题、怎么解决?需要什么资源,技术细节问题就不必要多说,说多了只能反应你不会做事,技术能力不足,他是要换人的。对技术管理领导和业务领导也是不一样的,平时沟通时留意每个人关注点的不同,他需要了解什么就给与反馈,汇报内容的粗细看个人并时常做调整。
(4)沟通
    沟通是一个大的问题,不管新人还是老员工都会遇到,即使独自负责一块业务系统,那还需要跟领导汇报进度呢?经常会遇到这样的问题,沟通不到位,未完全理解到位,当面沟通确认后具体做的过程尚需要细节讨论,实现好的效果返工等。这是因为每个人的能力不一样,经验不一样,对业务和技术的熟悉度不一样,不同人的沟通方式不一样,沟通问题不能直接有效避免,但是需要注意以下几点:
1、工作要求目标导向,直来直去直面主题;
2、了解别人的沟通方式、工作习惯、相关的业务系统、平台特性等;
3、分门别类做好记录,理清目标,细节不理解的业务问题当场确定;
4、注意切换角色,用别人熟悉的方式沟通;
5、事前确认工作目标、做好记录、调整优先级、发现问题及时沟通、完成结果真实反馈;
6、借助工具
excel、world、mpp、powerdesgin,ppt等,列出一个时间表,功能列表,做好计划。

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页