从一个女程序员的5年工作总结中学习工作经验

第一篇：从一个女程序员的5年工作总结中学习工作经验

从一个女程序员的5年工作总结中学习工作经验

冬日如期而至，一晃又是一年。

这是我参加工作的第五年，原以为会有一个阶段性的提升。哪想一场金融风暴，萧条至今。这个世道，有一份工作就应谢天谢地了。

我会用流水账般的文字絮叨今年的总结，很长很无聊(技术不多，基本上是工作方法。)对于怀揣抱负者，这份总结算是反面教材；对于初出茅庐者，我现在的心境是五年来的积累；还请看我刚参加工作时候的那些总结。

去年写完总结领导给让我设计一个数据库。这个数据库在我刚刚参加工作的时候设计过(不是目前这家公司)，那个时候由于对需求不了解，数据库设计的可拓展性不强。随着工作时间的增长，对于行业需求了解的增多，如今再让我设计几乎同样的数据库，真是一个弥补遗憾的好机会。

我开始翻看当年的工作涂鸦。(老师说过，好脑子不如烂笔头子。从工作第一日起，每日作了什么，遇到什么困难，解决方案，新想法都会随手写下来。跳槽的时候也带着这些笔记本。)笔记本中记录着我当年的青涩。那个时候想不明白的问题现在基本上都想通了，那个时候觉得拧巴的设计现在也能调整过来。那个时候的笔记本上还是中文满篇，而现在的工作笔记中已经很少出现中文了。也许积累就是这样，不知不觉间改变着我的习惯。

这个数据库设计到一个阶段我就被分配了新任务，至今还没有机会做进一步的完善。被调走的原因来自年初的一次多部门会议。那个会议主要是看看一年来产品的进展，各个部门参与意见评选一下产品中的销售点，调整销售计划。去年我开发了一个功能组件，功能挺强大，但操作起来不是那么直接。当时领导跟我们说如果对于自己开发的东西需要补充说明可以在会前交给他。于是我就这个组件做了一份详细的PPT，重新整理了逻辑流程，每个步骤都配有截图和详解。后来这个组件成为新销售计划中的最主要的推销点。

大老板开始重视这个功能后，就针对如何完善它集思广益。作为开发者我也成了与会成员。开这个会挺折磨人的，几个部门从不同的出发点对我做的东西提意见，本来还挺满意的作品一时间千疮百孔，有些细节是我完全想不到的。比如我用了纯红和纯绿来作为指示色，没有考虑到红绿色盲。

每次开完会我都会在当天整理一份记录发给与会者(总觉得这种自由发挥的会议大家噼里啪啦说了一通想法，等过几个礼拜我调整了代码后这些人又忘了当初的要求。不如白纸黑字记录下来有迹可查).这段时间我的工作大概就是开会，然后根据需求快速调整，再开会。通过几次这样的会议，原来的功能模块已经被拓展成一个功能更强大，便于操作的小型产品。结果是喜人的，但对与我来说意味着数据结构的大调整，说白了就是得重写。现在看来，这个过程是锻炼人的，不同角度出发的需求，对于用户使用细节的强调，一些专门为了演示开发的抓人眼球的功能等等。

接下来售前要开始对客户演示了。我们的售前外号“抓狂A”,每次演示前稍有不对就来找我们开发部。他已经让好几个同事都跟着抓狂过，这次轮到我了。即便我给他最详细的使用说明，一旦遇到问题”抓狂A”还是第一个就来找我。对于这样的人我没什么好办法，只能”候”着，随传随到，他加班我也跟着耗着。但是每一次问题解决后，我都会写一封邮件给”抓狂A”和我经理，说明他遇到的情况和解决方法，哪怕最愚蠢的问题也是。我怕我跟着耗了这么多精力，到时候他到客户前掉链子转头就让我背黑锅。我把”抓狂A”培训出来后也附带着发了一份基于某组件的FAQ给各相关人士。

第一季度效益实在不好，公司开始裁员。裁员大概经历了一个月，那段时间真是折磨人。我算是低空飞过，侥幸保留下来(估计是我听话又便宜)。

裁员带来的结果就是要每个留下来的人要做更多的事。我被借调到另一个组工作一段时间。对于这几周我称之为”人生体验”。我在这个组不是开发而是数据处理，用到工具(近似汇编的一种东东)，逻辑都不同。这个组是八卦的组，有故事的组，和谐的组。组长N姐，女同性恋者；组员J，基督徒，残疾人；组员Z,穆斯林；对我交接工作的M,变性人。M对于公司的感情非同一般，因为我们所有人陪着这他走过从他到她的人生最艰难的时期。如今被裁感情上很难接受，工作交接的磕磕绊绊。面对她的不配合，我不知所措，还好其他组员非常配合，旁敲侧击的诱导M。另外我处在新环境，不太知道如何和这些背景迥异的人相处，安静了不少。慢慢熟悉后才感觉好些。每次转组的前一天我都会发邮件给各个组员，希望J和Z能够抽出一点点时间在我转组前碰个面，更新一下情况。邮件中我还要询问一下需要的数据，文件准备的程度。我不希望转组后不能马上开展工作而影响工程进度。目前看来和这个组合作融洽，整体工作效率比之前M在的的时候提高了许多。

大概从8月初我就没有进行系统的开发，因为系统进入了升级后的稳定阶段。我就是改bug,和帮助测试。这个过程很烦，看很多别人的代码，改了bug后还要考虑是不是有影响到别的地方。测试也是，遇到某个人发回的bug的测试全部都不通过的时候挺郁闷的。这些给我带来的收获就是对于整个产品有了更全面更深入的了解。

总结一下今年

技术上没有特别大的进步，能胜任目前的工作

业务上随着时间的深入，了解得更多了。但是行业需求也会随着时间而变化。总之业务无止境。

经过裁员，更加理性的分析自己对于企业的价值。这个价值中技术仅仅占一部分，还是对于企业有用的技术。其他的价值诸如协作阿，按时提交任务阿，bug率阿这些细节的部分占的比重非常高。

需要提高的部分，英文写作部分，这是我的弱点。写个报告吭哧吭哧的可费劲了。

八小时之外

今年似乎没干什么，我妈说我的博客除了吃就是玩。我还没去远方旅行过，这个愿望留在冬天

多啰嗦两句

工作前三年拼得是踏实，踏实才能学东西，才能在锋芒最劲的时候避开人事争端。工作五年后拼得是激情，对于熟悉的工作如何才能精益求精，如何让自己增值。这个问题我也挺迷惑的，因为我是懒人。

多和领导沟通，表达自己的看法，也聆听领导的需求。只有多沟通才能配合的更好

最后还是那句话

低头做事，抬头做人 过幸福的小日子:)

第二篇：女程序员第七年工作总结

[女程序员第七年工作总结]今年的天气似乎特别暖和，虽说已经是冬天了我们这里依然一片秋色，女程序员第七年工作总结。

这是我工作的第七年，要是一段感情的话正是七年之痒的时候。如果在感情中每年作一份总结，是不是就不会有传说中的坎儿。

我所在的公司不大，地方也不大。见识不广，深度不够，太多的随遇而安让我的工作这么多年都起伏不大，必须承认我骨子里就是个吃货和懒鬼。这篇文章仅仅是自己过去一年工作的总结，对于有理想有抱负的好青年就当看个反面教材，然后鞭策自己更加努力吧。另外我现在的心境也是工作这么些年后的感受，欢迎阅读以前的总结，在那里你也许会找到共鸣。1.个人技术

话说毕业头两年我觉得技术噌噌的往上涨，会了好多东西，然后的几年就缓慢爬行了。一个是我的工作性质是做应用的本来也不探讨什么高深的技术点，另一个就是自己懒没有好好利用时间充实自己。

对我来说做架构的过程是一个挑战自己决策能力的过程。毕竟软件是有生命的，它不断成长完善，或者某些部分在不久的将来被卸掉，工作总结《女程序员第七年工作总结》。我看不到那么远，设计时间太长影响工程进度，只能折中平衡。实施是同样的道理，同一个函数可以用不同的方法实现。平衡与博弈是超出软件设计与实施之外的能力，也就是俗话说的经验。在这个方面我还太嫩。2.团队管理

去年的总结里面我写了大段大段自认为的带领小团队的方法，如今总结为四个字：“敏捷开发”。年初的时候我的一个组员推荐我读了敏捷开发的书，才发现我那些实践中“创”出来的方法其实都是敏捷开发的一部分。建立在实践基础上的理论学习让人茅塞顿开。下面写一下除了去年那些方法我看过书以后觉得特别重要一定要记录的

1.tdd，testdriven develop.看过书才知道这个多重要，作为程序员，闷头写代码可以但是如果写测试很多人都会不情不愿的(尤其小公司，没有专门的人写测试的script)。但是test case的建立对于功能的拓展，维护是相当重要的，虽然开头看起来写测试是麻烦了一点但是这为以后节省的时间和资源是很大的。我所在的项目要是写script的话还是比较困难的，于是我要求我的团队写文档。

2.当我们结束每一个bug/feature是真的结束而非半吊子。结束就是包括代码，注释，对应文档等等。当团队build那一天不会因为某个看似完成实际上还需要那么两三句话的bug而耽误

3.无论是否面向客户，每一个build都是一个完整的msi，归档备-案。这样我们可以轻松的比较每个版本之间的不同。

前两个月又有两个人归到我的团队下，我们开会规范统一了编码规范，比如每一个函数前都会加三个单引号(这个在.net里面很好用，可以自动生成帮助)。比如如何命名函数，变量。其实经过一同工作大家的编码规范已经在不经意中逐步统一，这次只是正式明确出来以便新的组员尽快上手。

“敏捷开发”是现在比较流行的软件开发模式，我的认识是他非常合适8个人一下的小团队灵活作战。它充分发挥团队成员的主观能动性，可以比较及时地调整状态，降低资源损耗。虽然敏捷有正式的管理模式，工具，但一切一切的根源来自于团队成员间的坦诚交流，相互信任。这两样没有跟本“敏”不起来，大家心里都有自己的小九九，还不如不用“敏捷”。

信任和坦诚这种东西没有硬性标准，只能靠团队慢慢磨和，也靠缘分吧。这个方面我的运气不错，组内合作讨论的气氛非常好。从这些比我勤奋比我有经验的组员们身上学到了很多东西。目前我们组的这个运转模式得到了部门经理的认同，已经升级了现有的管理软件，我就可以比较规范的依据“敏捷”模式管理了。

今年我们部门作了一次人事变动，去年提及的那个不作为的经理走了新来了一个。在一定程度上我需要辅助他的工作，这也给我提供了一些作为代表参与部门间会议以及决策层会议的机会。一种会议是传递意见给大家，需要演讲。对于正式的演讲不够自信，总怕不能准确表达自己的意思。于是搭建了演示平台，特别作了事例分析，作了ppt用作主脉络。效果意外的好，得到了很多积极的反馈，对于以后的开发思路很有帮助。另外一种是听取意见的，售前的哥们很能“吹毛求疵”，挑得毛病那个细那个偏。关键还不早说开发周期尾端才说，一改又是麻烦。以前这样的会议我不是主角跟着听听就好，现在成了主听者，第一反应就是抵触，辩解。但是轮到我说话，我都只能说对不起，我们没有考虑周到，下次会注意，也希望在开发进程中多多交流。能有这样的态度也是工作时间长了的缘故，初出茅庐的时候应该不会这样说。“对不起”一说，明显感觉到售前松了口气，开发和销售本来就不是两个对立面，只有把这样“挑”的毛病细化，在开发进程中循环出现才会减少不必要的成本浪费。我们是小公司，这些个互相交流指正不需要大家很正式的到会议室坐下，就是互相串门子的时候带一句。做开发的把态度摆出来，欢迎各种意见建议，人家自然也就愿意过来。

最后总结一下今年的工作状态还不错的，一直都在学习和摸索中。适应了角色的转变，知道了如何应对问题。应付不来的，会去找适当的人寻求帮助。

工作之外，记得去年说想去西藏于是就在雪域高原过了圣诞新年，今年的旅行提前到了金秋九月，冬天估计就不去远的地方了。

最后还是那句话：“低头做事，抬头做人，过幸福的小日子。”

第三篇：一个女程序员第七年工作总结.

一个女程序员第七年工作总结 今年的天气似乎特别暖和虽说已经是冬天了我们这里依然一片秋色 写于2011年11月7日 这是我工作的第七年要是一段感情的话正是七年之痒的时候如果在感情中每年作一份总结是不是就不会有传说中的坎儿 我所在的公司不大地方也不大见识不广深度不够太多的随遇而安让我的工作这么多年都起伏不大必须承认我骨子里就是个吃货和懒鬼这篇文章仅仅是自己过去一年工作的总结对于有理想有抱负的好青年就当看个反面教材然后鞭策自己更加努力吧另外我现在的心境也是工作这么些年后的感受欢迎阅读以前的总结在那里你也许会找到共鸣 1个人技术 话说毕业头两年我觉得技术噌噌的往上涨会了好多东西然后的几年就缓慢爬行了一个是我的工作性质是做应用的本来也不探讨什么高深的技术点另一个就是自己懒没有好好利用时间充实自己 而今年64bit的普及赖以生存的AutoCAD开始嫌弃古老的VB6劳动力市场等等原因使我不得不接触掌握新技术一些技术点诸如SQL Server的spatial部分把GIS的理论算法引入我所在的应用领域利用AutoCAD的NET类重新设计已有系统Linq C多线程WPF编写美观的界面等等学习新技术是个享受的过程觉得自己开始跟得上时代的步伐当然如果项目时间紧的话也会有压力总觉得用原来的技术很短时间搞定的东西现在却大大增加了开发时间和上一次系统学习比起来这次自己就要稳重的多虽然过去几年并没有在技术点上特别精进但是基本功更加扎实了不会向上次那样不知道从哪里下手这次算是心理有底有步骤有计划地学习感觉好很多 技术点的学习与应用不仅仅对于我个人能力的一种提高更是在很大程度上帮助软件重新架构由于平台的转换我们有机会对原有系统重新作分析设计以前的我完全是一个实施者而现在所扮演的更多的是一个设计者这种角色的转变意味着责任更大如果出错就不是浪费我一个人的时间而是从整体上浪费团队资源去年写总结的时候我在寻觅软件设计上面的建议今年系统的看了UML和设计模式强烈的意识到从理解理论到灵活运用实在不是一件简单的事情我的做法是从大的系统中选取一个相对独立的子系统根据学到的理论自己搭个设计想想再搭另外一个跟团对讨论下找找感觉这个过程我大量依赖mindmap flowchar UML 开始的草稿是Mindmap把需求细分然后UML建立块之间的关系UML是个好东西虽然它的各种规范让设计在软件生命周期中所占比例加大但是它对于细节的考量是非常到位的如果我可以把所要软件的类图顺序图画

好那基本上就能证明这个东西我想明白了另外还可以把它解释给其他组员在设计思想上我一般会从业务逻辑出发比较注重可读性或者说是结构更符合人脑逻辑除非在非常要效率的地方一些函数类的分布才会看起来不那么顺溜每每这个时候一定要配有相关文档之所以会这样一层一层的大部分来源于自信心不强没有这些图表文档的支持我不确定是否能够把意思清晰准确的传达给团队其他成员当然也不能够保证过段时间自己就不会忘记目前我还在磕磕绊绊的前进中真心希望将来的某一天我可以熟练运用UML工具做个合格软件建筑师 对我来说做架构的过程是一个挑战自己决策能力的过程毕竟软件是有生命的它不断成长完善或者某些部分在不久的将来被卸掉我看不到那么远设计时间太长影响工程进度只能折中平衡实施是同样的道理同一个函数可以用不同的方法实现平衡与博弈是超出软件设计与实施之外的能力也就是俗话说的经验在这个方面我还太嫩 2团队管理去年的总结里面我写了大段大段自认为的带领小团队的方法如今总结为四个字敏捷开发年初的时候我的一个组员推荐我读了敏捷开发的书才发现我那些实践中“创”出来的方法其实都是敏捷开发的一部分建立在实践基础上的理论学习让人茅塞顿开下面写一下除了去年那些方法我看过书以后觉得特别重要一定要记录的 aTDD Test Driven Develop 看过书才知道这个多重要作为程序员闷头写代码可以但是如果写测试很多人都会不情不愿的 尤其小公司没有专门的人写测试的script 但是Test case的建立对于功能的拓展维护是相当重要的虽然开头看起来写测试是麻烦了一点但是这为以后节省的时间和资源是很大的我所在的项目要是写script的话还是比较困难的于是我要求我的团队写文档 b当我们结束每一个BugFeature是真的结束而非半吊子结束就是包括代码注释对应文档等等当团队Build那一天不会因为某个看似完成实际上还需要那么两三句话的Bug而耽误 c无论是否面向客户每一个Build都是一个完整的msi 归档备案 这样我们可以轻松的比较每个版本之间的不同 前两个月又有两个人归到我的团队下我们开会规范统一了编码规范比如每一个函数前都会加三个单引号 这个在NET里面很好用可以自动生成帮助 比如如何命名函数变量其实经过一同工作大家的编码规范已经在不经意中逐步统一这次只是正式明确出来以便新的组员尽快上手 “敏捷开发”是现在比较流行的软件开发模式我的认识是他非常合适8个人以下的小团队灵活作战它充分发挥团队成员的主观能动性可以比较及时地调整状态降低资源损耗虽然敏捷有正式的管理模式工具但一切一切的根源来自于团队成员间的坦诚交流相互信任这两样没有根本“敏”不起来大家心里都有自己的小九九还不如不用“敏捷” 信任和坦诚这种东西没有硬性标准只能靠团队慢慢磨和也靠缘分吧这个方面我的运气不错组内合作讨论的气氛非常好从这些比我勤奋比我有经验的组员们身上学到了很多东西 目前我们组的这个运转模式得到了部门经理的认同已经升级了现有的管理软件我就可以比较规范的依据“敏捷”模式管理了 今年我们部门作了一次人事变动去年提及的那个不作为的经理走了新来了一个在一定程度上我需要辅助他的工作这也给我提供了一些作为代表参与部门间会议以及决策层会议的机会一种会议是传递意见给大家需要演讲对于正式的演讲不够自信总怕不能准确表达自己的意思于是搭建了演示平台特别作了事例分析作了ppt用作主脉络效果意外的好得到了很多积极的反馈对于以后的开发思路很有帮助另外一种是听取意见的售前的哥们很能“吹毛求疵”挑得毛病那个细那个偏关键还不早说开发周期尾端才说一改又是麻烦以前这样的会议我不是主角跟着听听就好现在成了主听者第一反应就是抵触辩解但是轮到我说话我都只能说对不起我们没有考虑周到下次会注意也希望在开发进程中多多交流能有这样的态度也是工作时间长了的缘故初出茅庐的时候应该不会这样说对不起一说明显感觉到售前松了口气开发和销售本来就不是两个对立面只有把这样“挑”的毛病细化在开发进程中循环出现才会减少不必要的成本浪费我们是小公司这些个互相交流指正不需要大家很正式的到会议室坐下就是互相串门子的时候带一句做开发的把态度摆出来欢迎各种意见建议人家自然也就愿意过来最后总结一下今年的工作状态还不错的一直都在学习和摸索中适应了角色的转变知道了如何应对问题应付不来的会去找适当的人寻求帮助工作之外记得去年说想去西藏于是就在雪域高原过了圣诞新年今年的旅行提前到了金秋九月冬天估计就不去远的地方了最后还是那句话 低头做事抬头做人过幸福的小日子

第四篇：学习科学发展观演讲稿：从一个工程项目中看到的勇气

学习科学发展观演讲稿：从一个工程项

目中看到的勇气

托尔斯泰有句名言，幸福的家庭是相似的，不幸的家庭各有各的不幸。今天我把这句话套用一下：“危机中困境是相似的，应对的策略各有各的不同。”是啊，面对金融危机的挑战，包钢各单位都做着应对准备，而这些准备会因各自生产实际而不尽相同。不过无论措施和做法差异多么大，有一点要求应该是相同的，那就是在科学发展观的指导下，全体包钢人必须拥有团结一心、迎接挑战、战胜困难的决心和勇气。

下面我为朋友们讲述一个包钢项目建设中的典型事例，希望大家能从中切实感受到，到底什么才是包钢人的勇气。

从厂区到白云西矿的白云矿浆管道工程是包钢XX年的“一号工程”。这项工程有这样几个特点：技术难度大、施工范围大。整个工程横跨4个旗县区的32个村、镇、嘎查，全长145公里，落差525米，需要穿越6座大山、3条河流、11道河谷、1条地震带，建设隧道1698米。土石方量巨大是这项工程留给人最深刻的印象。如果我们用工程土石方，筑一条高一米宽一米的土墙，那么这条土墙要在包头和北京之间折返3次。如果朋友们对这些数字缺乏感性认识，那么就听听包钢领导对它的形容吧：基于工程的复杂，崔臣董事长把它叫做“包钢的三峡工程”；基于工程的艰巨，司永涛总经理将它称作“包头市的南水北调工程。”其实，无论怎样称呼它，都在说明一个问题：以企业的一己之力完成这样一项浩大工程，难度太大了、困难太多了。

记得工程刚刚启动时，为工程提供技术服务的美国管道系统工程公司（psi）就向包钢建议，一定要聘请专业施工队伍，采用专业的设备和专用产品，才能完成这条号称中国第一条矿浆与输水管道并行的长距离输送管道建设。但是经过细致研究之后，公司果断作出决定，除了必要的工作外委，工程的勘测、设计全部动用包钢自己的技术力量；管道和设备的施工安装交给包钢建安和中国二冶；对于工程用钢，更是提出能用自己的产品绝不外购。之所以要这样做，包钢领导掷地有声：自己组织工程，不仅节省经费，还能积累建设经验、锻炼职工队伍、促进产品开发。包钢坚信，靠自己的力量，包钢人一定能把这件利国利企的大事办成、干好！

一场包钢建设史上前所未有的艰苦战斗拉开了序幕。

没有大规模野外施工经验，没有长距离管道施工设备，没有现成的管道用钢，包钢人义无反顾地扑向绵绵大山、茫茫荒原，扑向了漫天的飞沙走石和300多个严寒酷暑。

困难？当然有！由于缺乏施工经验，因为怕担责任，工程开始时，工人们连沟都不敢挖，在工程指挥人员的耐心解释下，工人们放下思想包袱，全身心地投入到工程建设中。

阻力？当然有！管道线路穿越村庄、田地。为了说服农民配合施工，确保工程进度，征地干部苦口婆心，披星戴月，施工队伍补路修桥，工程人员甚至进到庄稼地里帮助老乡收割。

艰险？当然有！在艾不盖地区，施工队伍遇到了一座石头山。为赶抢工期，在不具备机械开山的条件下，工人们每天挖山十四、五个小时，硬是用钢钎铁锤挖出了6.5公里的陡立“石沟”。

这时的白云矿浆管道工程，其意义已经超越了工程项目本身，升华成包钢“坚韧不拔、超越自我”企业精神的写照，谱写出包钢人不畏艰险、战天斗地的奋斗壮歌。每一次克服困难的过程，就是一次彰显包钢人英雄气概的过程。

我们的施工队伍在战斗中一天天成熟：他们科学布局，圆满完成了勘察设计任务；他们创新发明，解决了专业设备、专业经验缺乏的难题；他们研发攻关，管线钢源源不断地走下生产线；他们合理施工，严保工程质量，工程进度日新月异……到今天，白云矿浆管道工程稳步推进，正一步步地迈向胜利。

工程的事迹讲完了，朋友们，你们是否从中感受到了包钢人那种敢为人先、压倒一切的无畏勇气。

勇气是人类面对逆境和挑战时敢做敢为毫不畏惧的气魄。因为有了这样的勇气，包钢克服艰难险阻，让百里管道从无到有，蜿蜒穿行在天地之间；因为有了这样的勇气，每年包钢要完成几十个基建技改项目，让拥有世界一流装备的崭新包钢崛起在北国草原；因为有了这样的勇气，几十年来，包钢人与时俱进、不断进取，把自己锻造成共和国的钢铁脊梁。

朋友们：活生生的事实证明了这样一个真理，在任何时候，在任何危机面前，包钢人从不缺乏迎接挑战、战胜困难的勇气。我们坚信，在科学发展观的指导下，全体包钢人一定会在包钢党委的领导下，团结一心，无畏前行，战无不胜！

第五篇：xx年程序员工作总结

xx年程序员工作总结

撰写人：___________

日

期：___________

xx年程序员工作总结

做事要积极主动，态度决定一切

说这些，可能有人会觉得，这些都明白，都是大道理，只是怎么样执行的问题，下面我举一个真实的例子。

我曾经带过的两位新人，A君上班，交代给他负责的东西，是永远没有结果的，我交代给A做一个数据展现的部分，A君告诉我他不会JSP的技术，我给他推荐了一些书籍以及我曾经写过的demo，并告知不能光学，要有成果展示，可以通过这个数据展现来学习jsp技术，但是最后的结果是他下班就走，走之前没有跟我汇报任何进度，我最后只能换人做这个东西。这里我并不是推荐职场新人要加班，但是做事的态度要认真负责，新人可以对技术不懂，但是要有负责的态度，起码应该汇报一下今天的进度。

再来对比一下另一位B君，也是同样接到这个任务，首先B君懂jsp,但是他不懂JSTL，我给了他时间学习，结果B君在很短的时间内，学了JSTL并将总结发给了我，我相信这么短的时间内，他毕竟掌握的有限，但是学习了，又有总结，这种态度令我非常满意。在第二天，B君就把数据展示做出来了，而且确实是我想要的样子!不得不说，同样的事，同一水平线，不同人做的时候，态度和积极性就决定着一切，所以一个人只要工作态度好，我相信这个人的工作绝对不会差。

提问的技巧

作为一个新人来说，不懂就要问!这里我要说两点：

1、如果是单纯技术上的问题，如果可以google到的，我认为就可以自己消化掉!问的问题一定要先google，然后带着自己的想法，去问一些有经验的人，收获会更大!

举个例子：曾经的我，埋头写代码，那时候很怕上司知道自己不会这，不会那!所以拼命的掩盖自己不会的东西，自己查资料，下班了问同学，上论坛发问。但是由于逻辑和现实需求不一样，所以结果并不理想!如果那个时候，我把自己不理解的地方和上司谈，也许会很快的就能完成这个任务，而不是返工。

2、如何提问?问谁?

很多新人不知道如何提问，也不知道问谁。我的建议是，先把你要问的问题梳理好，最好可以有电子版或者打印版的整理，方便其他同事查看和解答。然后就是提出的问题，要让回答的人感兴趣，这样他不但会给你解答问题，还有可能将问题延伸，让你学到更多的知识。对于如何让回答的人感兴趣，就是仁者见仁，智者见智了!看个人发挥了!

对于问谁，我觉得你不了解其他同事的时候，要先问你的上司，当你了解了你的同事每个人擅长的领域之后，就应该把自己的问题归类，然后问最擅长的人。这样会事半功倍!

任务分解

不知道大家做事都是怎样一个逻辑，当年的我做事就是一团糟。当我拿到一个日志分析的任务的时候，就想着做，埋头苦干，但是自己越做，脑子越浑，完全找不到头绪。后来，上司找到我，给我做出了任务分解，我按照任务分解来做，清晰了很多。直到现在，我还保持着做任务分解的习惯。

其实做任务分解可以帮助你更深入的了解你要做的事情，任务分解包括一个事情，你需要分几个步骤去做，每个步骤要做到什么样子，什么程度，多长时间做完。几个步骤为一个里程碑。如果具体做的时候发现一个步骤的事情做起来超过了一个星期，我觉得这属于任务分解的不够细，需要将这个任务再次分解，让你的工作更透明，更有效率。可以使用一些任务分解工作，将自己的工作路线和步骤明确，要善用工具。

主动汇报

+

主动沟通

曾经的我就是埋头苦干，但是从不汇报进度，其实这样是不好的。后来我的领导找到我，问我的进度，才发现意见有所分歧，理解有差距。索性只能重新来过。

新人一定要注意这个事情，有情况，有成果，有可展示的东西就一定要及时的主动汇报这个事情的进度，做成果展示，在对事情有不理解的时候也需要主动的沟通，使之和所有参与人员的意见一致再去做，保证你做的事情的正确性和有效性。

记住一句话：当领导找到你问进度的时候，你是被动的!

上面几点，看似简单，做起来很难!到现在任务分解和提问很多职场新人是不具备的，需要慢慢磨练，但是我们相信，只要有良好的态度，良好的习惯，工作一定会慢慢越来越好!相信自己的明年会越来越好!

范文仅供参考

感谢浏览