【www.bbjkw.net--经验交流材料】
总结是国家机关、社会团体、企事业单位等通过对过去一阶段工作的回顾和分析评价，判明得失利弊，提高理性认识，用以指导今后工作的一种常用文书。以下是本站小编为大家带来的关于工作经验及教训，以供大家参考!工作经验及教训
以下是我这几天能够想到的一些总结。基本上都是一些以往踩过的坑，或是自感不足的地方。先说我觉得重要的，还有很多细节无法一一回忆起，以后有想到再作补充。
一，耐心和细心
我在学校给人打杂和这两年工作越发觉得耐心和细心的重要性。这些年因为大意犯过不少错误，有几次甚至手误删光了数据库(幸好有有备份)。这样的失误在工程界也毫不罕见，见 GitLab 删库的事故。
还有无数次因为代码中的 Bug 头疼地找了很久时间的错误，有很多是因为思路的不清晰，还有不少是一时手快粗心导致的。最初开始写代码的时候如果能够更加谨慎，可以免去不少烦恼。我在这一点上吃过不少亏。
我相信和我一样很多人开始码农的职业生涯都是因为热爱，但是想要坚持下来还需要持久的热情和责任感。因为计算机会一五一十地执行程序员的所有指令，程序员要保证一个大量复杂的业务逻辑都能够顺利执行，不出错误，这需要极大的耐心和仔细完成高质量的工作。
减少 Bug 和失误的方法有很多种，比如软件工程上对软件的质量管理手段(单元测试，代码审查，还有，敲黑板提醒大家：定时备份，等等)，但，最终都离不开全神贯注投入工作的工程师。
二，最投入地工作，最投入地休息
高效地工作一个小时的效率可能会远远超过心不在焉工作两三个小时的效率，有时可能会更多。就像刚才提到过的一样，没有全心投入的工作就会导致无法耐心与细心，所导致的错误可能会造成后来更多的时间修复，甚至造成更大损失(比如写出一个一键删除数据库的脚本)。我曾经被这个问题困扰过很久，后来觉得这个能力和所有技巧一样，需要用心地练习。社交网络，嘈杂的工作环境和你的各式各样的私事都会严重影响你的工作效率。只有在你能够屏蔽所有的干扰(微博微信推特脸书网购炒股……)才能够进入这个状态。
顺便我一直关注的一个博客 Scott Young 写了很多文章讨论时间管理，其中也提到过如何高效地学习和工作。他尝试过很多 Project，比如学习中文之类。其中让他成名的是他在一年时间学完 MIT计算机课程(当然这未必适合所有人)。很有意思。
我心目中理想的工作状态应该是能够在工作的时间里高效地完成工作的内容，集中精力处理完所有的事情，然后能有时间休息。有足够的自己的时间从工作中解脱出来——在我看来是件挺重要的事情，因为长时间的紧张往往会降低工作质量，而充分的自己时间不仅可以让你得到放松，还能够投资到工作之外的事情上：比如业余时间学习，比如足够的反思与发散的思考。反之，低效而忙碌的工作往往会让你陷入恶性循环：经常加班加点干得很累，却什么事都没有做成。
对了，最后，能够全神贯注地钻研自己喜欢的事情是一种很特别的状态，会让你非常享受。
三，终生学习
刚才想到能够有更多自己时间的目的之一，也是能有更多时间学习。终生学习的概念应该有很多人都提过了，我也是一直坚信不移的。程序员是个高度依靠脑力劳动的职业，可能会是最需要终生保持学习态度的职业之一。
程序员在课堂中，和职业初期会接触到很多新鲜的事物，也会有一个很快的学习曲线。但是要保持技术的增长还需要不断地学习——通过书籍，博客，讲座，等等。计算机技术日新月异，而且每天都会有新的观点，思路和解决方案。只有不断开放自己的头脑才能跟上潮流。
这对很多人来说可能听上去是一个苦差活，但是从另一个角度考虑这是一个挺值得庆幸的事：并不是很多职业都能够有不断接触最前沿技术，最新的思路和最新的想法的机会。我见过不少经验非常丰富的老兵还在不断出现在技术讲座上，我的不少以往资深经历的同事还不时参加讨论组讨论交流。他们觉得一辈子做技术是件值得享受的事情。
有一个想法，不一定对。程序员应该需要有以下的学习方向：
- 对基础知识的复习，比如编程语言，算法，数据结构，计算机系统，网络原理，等等。对基础知识的掌握是自身职业发展的基石，对理解一切复杂的系统都是至关重要的。
- 对自身研究方向的理解。我觉得这一点毋庸置疑。无论你是网站前端，后端，系统工程，AI，云计算还是 SysAdmin 等等方向，都应该起码对自己业务熟悉。
- 对其他方向有一定的理解。我觉得花一点时间理解其他的系统对自身也有触类旁通之效，也能够对大型的系统(比如网站)的各个组成部分有更好的理解。这点可能尤其在小公司有更大的帮助。
- 涉猎科技/经济/人文/历史等等其他的学科。
另外前段时间看到池建强老师的博文：为什么要学习第二技能。我觉得可能有一定的道理。很多程序员最终能在其他的领域有所建树能够融合两个方向所学有所建树，也会是难能可贵的事情。当然这都离不开投资时间不断学习。
这个时代里最不缺的可能就是学习资源，我觉得现在找到优质的学习资源已经不难了，难的是找到时间。回到刚才说的高效工作，只有高效工作才能挤出更多的个人时间，只有挤出更多个人时间才能更好学习。个人的经验是这一点实际挺难，今后需要花更多的时间持之以恒。
四，总结反思流程
在工作中不断反思，总结流程，我觉得这也是积累经验的方法之一。比如问：有多少工作是重复劳动，可以自动化，被脚本替代的?有多少工作是可以精简的?反之，有多少工作是可以极大提高效率，是值得做的?
如此的反思可以总结出不少流程上的问题，比如组里曾经需要大量分析数据，需要有很大量的手工拷贝数据，再临时写脚本处理，并生成可视化的趋势图或是直方图作出比较。而且下次再分析一批数据还要有不少手工操作。后来我们讨论后，组里的另一同事和我花了不少时间写了不少 Python 来自动化大部分流程。尽管前期投入了不少时间，而且结果也不尽完美，但还是省下了不少重复的工作。长期看来还是值得的。
时不时反思思考自己的工作流程对自身经验有不少的好处，分享给团队也会有利于整个团队的增长和发展。程序员之间的相互交流实际上是很重要的一个环节。
五，学会和人交流
码农都是一心写代码的工程师，不需要和人交流——这可能是很多人对程序员的刻板印象。而这几年的经验是，善于交流的码农对周围的同事乃至整个团队的建设都有非常重要的作用。一个积极向上能够给周围同事给以鼓励的码农可以轻松地协调个人甚至一个团队的协作，一个技术高超但是性格差劲，与人沟通不顺的工程师可能会毁掉整个团队的建设。Netflix 技术大牛 Brendan Gregg 最近还专门撰文讨论了这个想法：一个聪明的混蛋不该留在团队里。简而言之，一个自私，自恋，目中无人，甚至嘲讽同事获取优越感的天才程序员不仅不会带来相应的成绩，反而会大大损伤公司中的士气，损害公司各个工程师平等讨论的机会，甚至会因个人偏见带偏整个公司的技术路线。
当然，一个善于交流的工程师仅仅做到礼貌待人还不够，高效的交流还包括及时地传递消息，及时地表达想法。短期来看，及时地让团队知道你的进度，你所面临的问题及你目前的解决方案会给你带来很多帮助。(我因为这一点没有做好浪费过很多时间，甚至有过不少不愉快的经历。)及时的沟通往往能够节省这些时间提升工作效率，也会打消很多误解。长期来看，分享你的经验，表达你对整个问题的考虑与思考，反馈你意识到的各种问题，对队伍和自己都有帮助。
在和组里同事闲聊时我听说过很多关于他们遇上的各种奇葩的领导和同事：比如无时无刻不在催促进度的老板，脾气差的老板，傲慢想当然而且自以为是的老板，从不主动和人说话的同事，项目没有按自己提议来就堵气的同事，等等。
和在任何一个地方一样，码农团队中的交流与沟通也是一门艺术。人情练达皆是文章，个人和团队都需要日积月累的培养。
六，更多时间写作
这两年里脑子浮现过很多想法一直想要表达，有些一直在徘徊，有些很快就忘记了。曾经答应过自己要多写些东西，但是一直拖拖拉拉。这可能是继减肥之后第二难实现的新年期望。
接下来的时间里会要求自己多写些东西。我也推荐所有的码农们能腾出一段时间写些技术总结，或是任何生活闲笔。写作的时候需要整理自己的思绪，让想法更有条理，甚至能发现自己思路里很多错误不足的地方。
如果能够再能够吸引一小批观众那就更好了。
七，锻炼身体，保持健康
这个就不多解释了。你们懂的。
工作经验及教训
总结：
数据融合项目自2018年10月中旬开始，至2019年2月上旬止，经过了接近四个月的开发进入稳定版。在此次开发过程中，在各个方面都遇到了一些问题，最终影响了开发的效率，和产品的质量。但是，也从中吸取了经验和教训，提升了自己。
概述：
项目成立的初衷是，针对现有监察委数据融合系统存在的，无可视化、效率低下、难以普及、难以操作等弊端，提出做出高效率的数据融合的v版。
在基于原系统的需求和设计上，进行了初步改良。 因此没有需求和产品的介入，直接进入了设计开发阶段。导致了需求不明确，项目蓝图不清晰。继而出现开发阶段需求反复调整。联调和测试阶段无可靠依据。
改良方案是：
利用codis的map存储特性，自动将同一key的不同数据进行整合，继而通过搭建集群、使用pipline等措施提高整合的效率。
利用kafka的partition独立消费机制，实现任务的分布式创建执行，使融合程序达到简单方便可横向扩充资源的目的。可根据任务量修改部署执行的环境、可通过集群技术增加组件的吞吐量，不至于因程序瓶顶而降低融合效率。
同样采用分布式技术执行融合过程。
采用es作为容器存储融合的结果，加速查询效率。
个人心路历程：
我加入项目组时，融合程序的日程是，即将开发完毕，在初步自测功能和性能。
所以我从项目使用的相关技术组件，环境搭建，以及程序设计实现的角度去了解整个融合程序。
由于前期需求工作的缺失，不足够完全清楚程序为了解决什么样的实际场景，又最终要达到什么样的效果，以及程序后续的被应用场景。
对程序的理解直接来源于，原数据融合程序的数据库设计，而个人对数据库设计的理解仅仅达到了我以为的程度，细节上的误读导致了后期才发现一些存在的不合理性。
即使是开发，也不能仅立足于技术和设计，还要结合需求场景等等因素，从本质上去理解程序的意义，给自己的设计以及开发指引方向，提供灵感，使工作更加合理，减少不必要的麻烦，提高工作效率和代码质量。
然后由于个人对业务上的不够熟悉，可视化系统原型设计上，没有很好的参与。对功能理解不到位。
仓促的做接口的设计，定义了很多不合理的参数，后续开发中一改再改。没有达成统一清晰的接口定义，在实现上也略显混乱。
同时，由于前端同事加入项目组时机过晚，也没有参与可视化原型的设计，也对功能不够理解。同时原型图设计的不够详尽，仅有页面没有交互，以及接口定义的种种问题。
使得前端同时在开发过程中，不能有效提出自己的想法和见解，过于被动依赖后端同时的支持，而需求变更等等问题，使前端工作进行缓慢，并且大量精力浪费在了讲解接口，功能，设计等方面。缓慢的进度也让所有开发人员感到疲惫倦怠。
无论是前端和后端人员，应该是直接对需求和功能负责，在需求传递时就应该到位，并参与原型设计，在理解工作目标功能设计等基础上，相互平等，相互协调，各司其职，达到思维碰撞，共同完成一个合理的、友好的、高效的功能。
希望在接下来的工作中能够吸取上述经验和教训，少走弯路，更高效率高质量的完成工作。
工作经验及教训
虽然我已经做了1年半的技术经理和项目经理，但是由于当时团队的原因，我还是从事了大量的开发工作。而今，我正式以纯技术经理的身份，参与到互联网项目的开发中，彻底完成了码农的蜕变。现在我来总结下我这1年多做技术经理得到的经验和教训。
1 时刻记住以团队运作为核心。作为团队带头人，你必须起到凝聚团队的作用，循循善诱也好，威逼利诱也好，你的让你的队员始终记得大家是一起做事情的，别人能做到的，你必须也能做到，没有例外。而你的工作出发点，也必须从团队工作的角度出发，这样，所有的刺头都不是问题，你直接让团队的影响去作用他，这样还不行，就换人。
2 项目阶段留足技术和项目文档。最好按版本进行整理，这样容易发现项目管理中的遗漏点。
3 及时跟踪开发人员的状态。如果是写日报让开发人员很烦厌，那你就得主动去观察审核开发人员的工作内容和工作结果，争取最早发现开发人员的问题。
4 大小问题都要向领导汇报。其实哪些事情重不重要从你个技术经理和项目经理这样的初级干部是看不出来的，你时时给领导报告，他至少不会觉得你烦，对吧?
5 充分利用项目管理软件。我在使用qc和jira的工程中，真的发现一款优秀的项目管理软件被合理使用，真的能激发团队的工作效率。
6 少责怪，多鼓励。现在的初中级开发人员都是90后，20多岁，心理敏感，但是容易被鼓舞，你在工作中少些责怪，多谢鼓励，他们会对你的凝聚力加深，并更有干劲。
7 自己也要加强技术学习。作为技术领头人，你是要指导开发的，你自己不行，带不出好的队伍。
大概就这些吧，一个优秀的技术经理的经验肯定会更多，但是就我目前的水平而言，我如果把上面的都做到了，我觉得我已经是个称职的技术经理了。
本文来源：https://www.bbjkw.net/fanwen465336/
推荐访问:工作经验及教训总结报告 个人工作经验教训总结