2006年工作总结

 

不知不觉，时间又走到了年末边缘。似乎整个项目的成长中，每到年末都有不同程度的感慨，回望这一年这一路走过的历程，感觉匆匆，但心里又多了几份成就与希望。06年我们完成了第一阶段的CAS开发，06年我们迎来了十多位从大学刚刚毕业的新同事，06年我们开始了新的希望，准备开发适合商用的CAS系统。回想这快一年的时间，有困难，有挫折，但是大家都能挺过来，并且能够开发出一套简单的CAS系统，心里面充满了成就感。我就以下面几个方面来总结一下这一年的工作。          一、第一阶段的工作 l         概要设计与详细设计阶段 第一阶段的概要设计和详细设计做得比较充分，给后来的编码和测试起到了指导作用。但在第一阶段存在一些问题，由于编写的人不够仔细导致了不少笔误，这给后来的编码、测试带来了很多麻烦。有些问题就是由于编写概要设计或者详细设计的笔误造成的。        我们目前的概要设计与详细设计文档维护与更新的工作量很大，第一阶段测试完成后，我们进行了概要设计与详细设计文档的更新，花了四个人一个星期的时间。是我们当时写概要设计或者详细设计的时候没有考虑充分，还是后期编码时改动过大，才导致这些问题的产生呢？我觉得是在设计的时候没有想清楚，记得看过一篇文章介绍BUG的引用70%是在设计阶段，而其它30%是在编码阶段，如果设计阶段没有想好，那会付出惨重的代价。所以以后一定要重视设计文档的编写。同时在设计过程中应该加强同行评审，俗话说同行评审是利器啊。        总结：对于文档中的笔误应该是能够避免的，我们文档中的笔误主要有以下几个原因。第一，拷贝。在编写相似业务过程文档时，我们通常是把相似部分拷贝过来，然后做一些修改，如果稍有疏漏，就会遗留某些地方没有修改。如果个人不能保证绝对的仔细，我觉得不要采取拷贝的方式，只要有一个地方忘记修改了，就会给文档带来“坏味道”，更可怕的是这种“坏味道”到后期会扩展到代码中，这样给工作带来了很大的麻烦。其实拷贝的问题在编码阶段也存在，这都需要我们注意。        对于概要设计和详细设计文档维护工作量很大的问题，我认为主要原因是在写概要设计或者详细设计时，对于某些业务处理没有想清楚，才会导致在后期编码才发现以前的设计不太合适，如果我们在编写文档时能够把一些业务想清楚，就不至于到后期还有这么多文档更新的事情。 l         编码与单元测试阶段        第一阶段编码时间非常短，并且编码的方式与以前的工作方式不太一样。我们以前写代码是边写边测试，其实这个测试就是单元测试，但是这个测试并不能代替单元测试。我在开发通信管理器时就是采用了这种方法，写了几个测试工具。但是在开发数据网关时，写代码是按照详细设计来编写的，当时在编码的过程中要求能够编译通过就可以了。如果详细设计一个业务处理函数有错误，并且在编码过程没有测试程序进行测试。那么这些问题就会沿后到测试阶段，数据网关发现问题最多的阶段就是在系统测试时，其实有些错误都可以在编码阶段解决的。        单元测试有相应的单元测试总结。        总结：        其实在编码的过程中我认为可以加入一些测试手段，比如可以开发一些模拟测试程序等，有问题尽量早暴露。 l         编码规范 为什么我首先来谈一下编码规范的这个方面呢？因为我自己是有体会的。我以前所在的公司是一个小公司，每个人都是按照自己的风格来进行编码的，所以就导致了大家的风格不一致，公司也没有要求一些规范，所以刚到CA组的时候我不能很好的执行编码规范。后来自己慢慢的觉悟到，执行编码规范其实是一个职业程序员起码的职业素养，大家在开发软件的过程中应该是一个统一的整体，而不是每个人独树一帜。假如每个人都是按照自己的编码风格去开发软件，那我们的软件质量又有什么保证呢？到后期的维护工作量会变得很大。        总结：如何让新员工来执行编码规范呢？我觉得我们以前的方式有点不妥，可能就是领导在会上说大家要执行编码规范，对于执行力比较好的人，他可能会自己去找编码规范来看，自己该知道怎么做；对于执行力不好的人，他可能心里知道要执行编码规范，但是脑子里面没有一些规则去指导他如何执行，所以我们得改进一下方法。以后能不能让一个人专门负责编码规范这方面的培训，假如有新员工入职，编码规范就相当于入职前必做的功课，这样才会记忆深刻，不至于到后期还要来强调编码规范。 l         集成测试与内部联调 第一阶段的集成测试是做得比较好的。我觉得集成测试的工作一样要让测试部门去做，因为测试人员和开发人员对于软件的看法和认识有所不同，如果让开发人员测试自己的软件，由于开发人员在测试的时候一般都会认为自己写的软件没有问题，已经测试过了。所以在测试的时候带着一种优越感，那这样就不可能把测试做充分了。 总结：集成测试尽量让测试人员去做。   二、新员工的成长 CA组的新人占了快一半，都是今年刚从学校毕业的。这可能是其他项目组少见的。三月份我给他们进行VC培训和他们接触得比较多，他们求知欲比较强，希望学到更多的知识和技能。这样就决定了我们老员工要花更多的时间去帮助他们，提高他们的知识和技能。目前CA组搞的技术交流就是一个很好的途径，谁掌握了新技术，就可以上去和大家分享，这样既能够传授知识给大家，又可以锻炼自己的表达能力。老员工在平常的工作中，应该多帮助新员工，当他们碰到困难，不管他是不是你这个小组的，都应该去热情的帮助他们，帮助他们成长，只有他们成长了，整个项目组才能够得到成长。 总结：技术交流要坚持做下去，并且要把它做好。   三、第二阶段的开发 第二阶段是在第一阶段的基础上进行开发的，并且增加、修改部分原有功能。第二阶段的开始是在2006年10月份，目前正处于需求预研与需求分析的阶段。第二阶段的主要开发任务有：开发适合商用的CAS系统，通过广电总局的DVB认证。第一阶段开发的CAS系统，具有简单的加减扰、加减密功能，与商用的CAS系统还有一段距离。再加上现在CAS系统的竞争越来越激烈，要想在这个环境中站稳脚跟，我们必须付出更多努力。 我们在10月8号进行了第一阶段的总结，在总结会上大家都提出了自己的看法以及我们待提高的方面，其中学渊有一个《经验》的PPT令我印象深刻，PPT里面总结了第一阶段开发中值得以后避免的一些错误，这需要我们在第二阶段的开发过程中时刻的提醒自己，不要再犯这些相同的错误。只有避免这些错误，我们才能够提高我们的产品质量、提高整个团队的开发能力。 总结：第一阶段犯过的错误在第二阶段一定不要再犯。

1、 在工作安排与分工的过程中没有经过慎重考虑，导致分配不均匀，使得员工的工作饱和度不一致。产生的原因：由于开发二组主要是由新员工组成，每个人的开发技能以及熟练程度不一样，所以在工作的过程中，我是根据开发技能的熟练程度来分配工作量的，这样就会导致开发技能熟练程度高的员工分配的工作量比较大，而熟练程度较低的员工分配的工作量比较少，因为他们不熟练，做完这些工作需要更多的时间。但这样就会导致一个问题的产生，工作饱和程度高的员工会觉得自己的任务比较重，压力较大。解决办法：（1）、提高开发技能欠缺的员工的工作技能，使得整个小组的工作技能稳步的上升。（2）、对于工作技能较高的员工多肯定多支持，而对于工作技能欠缺员工多鼓励多帮助。（3）、提高部分工作技能高的员工的待遇，这也是对他们工作的一种肯定。 2、 没有激励新员工的主动性，应该鼓励他们在交流会上多发言和提意见。产生的原因：新员工都刚刚从学校毕业，对自己的工作技能和工作能力都缺少信心，特别是在开讨论会时他们觉得老员工都没有说话，我们新员工那敢去发言。另外一点就是，新员工怕自己说错。解决的办法：（1）、加强组内非工作沟通。大家平常在一起工作都是以工作为基调的，上班的时候都是在讨论工作方面的事情，所以在沟通方面不够，以后可以多组织一点组内的活动。比如聚餐、唱K之类的活动。（2）、建立员工表达能力和表达欲望。技术开发人员都有一个缺点，就是表达能力欠缺，所以要加强员工在这方面提高的欲望，平常多给大家一个锻炼的机会和舞台。 3、 没有对新员工的技术研究进行一定的监督和考察，导致普遍成长不大。产生的原因：每个人想要学什么以及要学到什么程度都是取决于自己，在九月、十月我都给每个人安排了本月的学习计划，但是效果不好，大部分人都没有按照计划去执行，关键是员工的学习的积极性没有调动起来。解决的办法：（1）、提高员工学习的积极性，在组内多营造一些技术的氛围，多增加一些技术讨论。（2）、多与员工交流，使他们知道学习是自己的事情，而不是要别人每天来督促和监督。 4、 个人工作计划与安排还欠缺。产生的原因：以前工作就只需要把自己的事情做好就可以了，而现在要负责一个组的工作与安排，所以现在就要花更多的心思去考虑这方面的事情。解决的办法：（1）、尽量明确每一件事情的具体内容，根据事情的内容合理分配时间，写一些任务清单放在桌上，明确每一件事情。 5、 对于CAS项目的原理以及其他模块了解不深入。产生的原因：我只负责了数据网关、控制台两个小组。对于数据网关、数据库、控制台的业务是很了解的，但是对于其他模块比如ECMG、EMMG、终端的卡、ECA等了解不够，所以在给其他组的同事帮助不大。解决的办法：（1）、在做好本组内一些工作之余，多学习、多了解其他模块的原理，多向其他同事请教。（2）、由于以前一直都是做纯软件开发，对于数字电视的业务和原理没有了解，虽然来了CA组一年多了，但是觉得自己在这方面还很欠缺，以后只能多找点相关方面的资料多学习，一点一点积累了。