一次工作失误

    说明：说了那么多废话目的就是为了记录近两个月的工作情况，有时我们遇到的困难或不解不一定是工作技能的问题，做人的问题，可能是沟通问题、外部环境问题，自我认知偏差，急于求进，这一切作用到个人身上叫做工作能力。我简单整理如下：

一、工作方式

    新接触一项业务，不熟悉没经验的情况下，了解他人的沟通方式、工作习惯，熟悉现有平台和业务，勤总结勤思考。

二、沟通

    最主要的是搞清楚目标，沟通过程中分门别类做好记录，调整优先级，发现问题及时沟通、完成结果真实反馈。

三、技术学习

    这块主要体现个人的学习能力，没有好的办法，适合自己的方法才是最好的，但是要注意好深度和广度的扩展。动手做代替看，容易眼高手低；分类分块各个击破；做好总结、勤梳理；以工作需要学习技术，脱离初级水平可以扩展广度。

四、尝试管理

    管理不是简单的带一两个人，也不是一个人做完全部的工作，把部分模块分给队友，它是在有技术的基础上，熟悉开发过程、软件工程中遇到的各种问题，做好组织、计划、安排确保整个项目的顺利进行。

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

    在一个小公司你要时刻准备接受挑战，项目管理不到位，没有专门的项目团队，没有开发计划，没有需求变更计划，说改动就改动，没有专门的测试阶段，从需求整理分析到最后上线全都要一个人或两个人搞定；你经常会遇到这样的情况，好不容易实现功能模块做好的效果，领导一句话：要求去掉一列、界面不自然换掉、需要加权限控制、嵌入到原有的业务系统中、部署到另一个业务平台、这个功能用户不要了去掉，做好了要求考虑程序的扩展性能等问题。你会很忙，要经常加班，频繁改动，大部分的时间花在业务数据处理、众多业务表之间的关系上。你会因为页面上需要改动文字、样式调整、多加一列、少展示一个列表、取到的数据不对挨批。遇到技术问题时，经常会听到这样的训话：有没有搞错，别搞那么复杂，这块很简单，就是提交一个表单把数据保存到数据库、做一些数据验证、加上点控制，你这样做不行吗？给我快点改过来；还有经常要求你别做太多解释，只看结果，你先把功能实现，问题是功能永远做不完，实现了功能，重复之前的改动，页面加上这一块去掉一列等等这样的问题。好不容易到最后阶段部署到正式环境，报错了，领导问你怎么回事？快点解决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等，列出一个时间表，功能列表，做好计划。