贺志明的博客

2004年个人工作总结
从踏入12月以后，就开始思付要写2004年的年度工作总结。一直没有动手，除了忙碌可以作为理由以外，更重要的是，不知道该怎么把这一年做过的许多零乱而繁杂的工作总结成文。
有人把工作总结当成一种形式，作为应付上级领导的苦差，我却发自内心地想写总结，通过总结，可以清楚、明晰地知道自己一年来做过什么，欠缺什么。好的，需要继续发扬的；不好的，需要加以改进的，都会在总结中一一罗列，鞭策自己。
2004年，我都做了哪些工作？还得从头回顾，娓娓道来。
作为质控部一员，我的工作却囊括了质控、研发、营销三大部门，随着公司的机构调整、人员变化不断调整和变化。按照部门分类，可以把我2004年的工作总结如下：
4.1 质控部门工作
质控部门的主要职责是负责监督和控制研发中心内产品和项目开发的工作进度与质量，包括质量保证、软件测试、过程监督、配置管理、技术评审。我在质控部门的工作也围绕着这几项来开展。
4.1.1 配置管理工作
配置管理工作是我的主要职责，在这一年内，我负责了研发中心所开展的十二个项目（包括三水项目、SAM行政事业版、天津项目、南海项目、SAM经营版、新疆项目、资产运营管理系统项目、江西国资委产权管理系统项目、河北省国资委业绩考核项目、技术准备项目、茂名项目、技术支持性项目，下文所提的十二个项目均指上述十二个项目，不再重要提及）的配置管理工作。
（1）根据项目的规模、性质、简繁，视情况针对各个项目开展常规的配置管理工作。包括：
制定配置管理相关制度和流程（有相关文档，但未遵照执行）
配置管理计划的制定（当项目规模较大时）
配置库的建立（按照项目编号，每个项目建立一个配置库）
对项目内各成员的用户帐号和权限的分配
定期检查配置库的使用情况，督促开发人员定期提交、更新相关的代码、文档，有需要时设置Label，记录重要基线
定期对配置库进行备份，设置对配置库进行日自动备份，每半年进行一次资料刻录。
（2）对研发中心内所有成员的配置管理培训，使受训人员了解公司配置管理流程及VSS使用情况，从而更好地开展项目过程中的配置管理工作。
包括：
4月份针对软件产品与项目的配置管理过程、配置管理工具VSS的使用等方面的知识，对研发中心全体成员进行了一次总体培训。
对4月份后研发中心新招聘的员工分别进行公司配置管理过程及配置管理工具VSS的使用培训。
注：个人编写、准备的培训材料包括：配置管理基本知识（见附件一：配置管理培训.ppt）和VSS使用说明（见附件二：VSS使用说明.doc）。
4.1.2 制度编写及流程改进工作
为了更好地提高工作效率，规范部门工作、个人工作，方便部门与部门之间的交互，这一年，在工作过程中结合领导要求、个人想法、同事意见，经过思考，在工作过程中制定、颁发了一些制度、整理了一些文档，对质控和研发工作的改进提供了一些帮助。包括：
（1）年初，研发中心设立产品、项目、质控三个部门伊始，各个部门之间独立开展工作，信息比较闭塞，而各个部门之间工作关联性大，需要不断沟通和交互。为了减少沟通成本，使部门与部门之间的信息交互、沟通能够更方便、更快捷，提议建立了项目部、产品部、质控部各个部门的部门配置库，将各个部门的制度及规范、会议、培训、计划与总结、个人周报等各种信息统一集中管理，大大方便了公司高层领导了解各个部门的工作开展情况；部门与部门之间相互了解彼此工作开展情况；部门成员之间了解彼此的工作开展情况。（见附件三：部门配置库管理办法.doc）
注：后面由于公司机构设置，将产品部、项目部合并为研发中心，也将配置库进行了合并。
（2）为了规范SAM行政事业版及后续产品序列号管理，编写了SAM行政事业版系统系列号管理办法（见附件四：SAM行政事业版系统系列号管理办法.doc）。
注：因产品的销售没有如计划般覆盖全国，该办法没有产生作用，如果尘封硬盘。
（3）为了规范公司内部产品的发布，将公司内部所有已经定版的产品、项目安装到SS服务器统一发布，并将各个系统的访问地址整理成文（见附件五：公司系统访问地址.doc）供公司内部开发人员、技术支持人员、市场人员访问系统，了解各个系统功能。
注：因为后期SS服务器中毒瘫痪，部分系统不再采用BS浏览器访问模式，采用需要到各台机安装才能使用的CS模式，没有再将此项工作持续进行下去。目前上面公布公司的网址因为SS服务器中毒后瘫痪未恢复无法再访问，系统的发布需要另觅它处。
（4）为了方便公司新老员工对公司所有项目情况有一个整体的了解，对公司历年来开展的项目信息进行了整理（见附件六：公司历年项目信息列表.doc）。
（5）由于前期质控部在了解各项目进度进展时需要分别与每个项目的具体负责人交互，当涉及的项目、人员较多时比较费时，且无法及时了解每个项目的进度情况，建议由项目负责人每周填写项目进度周报（见附件七：项目进度周报.doc），再统一将每个项目的进度信息汇总到“项目进度综合报告”（见附件八：项目进度综合报告.xls），以方便公司领导、质控人员及时了解各个项目的进度，开展后续的测试等工作。
注：后期部门合并，人员减少，质控部门纳入研发中心一起开会后，可以通过会议了解各个项目每周所开展的工作汇总项目进度信息，取消了项目进度周报。
（6）针对开发人员在开发过程中使用VSS出现不及时提交、更新代码、使用VSS时出现的普遍错误，编写了配置库管理规范（见附件九：配置库管理规范.doc）和使用VSS常见错误（见附件十：使用VSS常见错误.doc）。
（7）针对开发人员在项目开发过程中，对个人代码没有较好地把关，出现较多常见的低级性错误，对测试的依赖较强，造成测试人员工作量大且繁琐。部门内决定对项目测试过程中出现的Bug定期进行统计，并将统计结果公布到公告栏中（见附件十一：项目缺陷统计表.xls）。
（8）针对各个项目发布版本混乱，经手人过多且没有对项目过程中重要的版本进行label记录，造成有些重要版本无法追溯的情况，制定了项目重要版本记录表（见附件十二：项目重要版本记录表.xls），对十二个项目可以追溯的重要版本进行了整理，记录在表中，并在研发中心部门内推广、执行。
（9）以质控部的角度对研发中心2004年所开展的所有项目，从质量、进度、成本等各个方面进行总结、分析，为公司后续要开展的项目提供经验、指导，方便公司领导、研发中心所有成员回顾、了解2004年的项目质量情况（见附件十三：2004年项目质量总结.doc）。
4.1.3 软件过程监督工作
软件过程监督工作包括：
对项目的软件过程执行情况进行监控，定期向上级反馈各个项目的软件过程执行情况。
对项目开展的计划进度与实际进度进行跟踪，每周定期更新项目进度综合报告（见附件八：项目进度综合报告.xls）记录各个项目每周的进展。
4.1.4 软件测试工作
由于质控部人手少，负责测试的只有一人，测试任务繁重，在测试工作紧张的情况下有时也协助测试人员做一些简单的测试工作，包括：
协助进行SAM经营版的简单测试工作（主要针对财务异常警示子系统和决策支持子系统）
对北京机关事务管理局演示版本的测试
对资本管理系统的测试（拿到新疆去的第一版）
协助进行三水产品化项目的测试
协助产权关系管理系统客户端的测试
测试工作主要针对上述各个系统的功能、界面提出完善性建议及分担部分Bug的查找工作。
4.1.5 评审工作
评审工作也是质控部门的工作之一，在质控部门参与的评审工作包括：
前期协助组织了SAM经营版项目各个阶段的评审工作，包括会前发布相关评审通知、评审制品；会中进行评审意见记录；会后对评审结果进行跟踪。
中期由于公司部门机构调整、管理人员变化，取消了公司层面的评审，直接由项目内部进行评审，未参与其中工作。
后期参加了茂名项目的评审会议。
注：目前评审工作开展得比较薄弱，主要因为旧的软件过程制度不满足目前各个项目的需要，新的软件过程没有明确颁布，故没有明确应该以何种形式开展评审工作。这类
4.2 研发中心工作
4.2.1 文档编写工作
除了负责质控部门的工作以外，本人还担任了研发中心大部分项目的文档编写工作，一年中，写过的文档不下千页，实在是一项很考验耐心的工作。总结起来，2004年写过的文档包括：
SAM行政事业版用户手册（包括Word文档版和CoreDraw印刷版）
SAM经营版用户手册、安装手册
资本管理系统用户手册（拿到新疆用的版本）
三水项目（用户手册、安装手册）
江西国资委产权管理系统的软件功能列表、系统功能流程图、用户手册、产品白皮书
河北省国资委业绩考核管理系统的产品白皮书、用户手册、安装手册、演示PPT
茂名项目用户手册（正在进行中）
4.2.2 软件使用培训工作
因为负责研发中心内各个项目用户手册编写工作的缘故，对各个系统的功能、操作流程、注意事项均比较熟悉，可谓除了负责测试的小曾以外最熟悉公司所有系统的人。所以也担负了部分对公司内部成员使用系统的培训工作。包括：
在公司级内组织开展对技术支持人员、营销人员使用SAM行政事业版的培训
在公司级内组织开展对技术支持人员、营销人员使用SAM经营版的培训
根据需要对公司内各部门的人员单独培训单个系统的使用
4.2.3 演示数据准备工作
为了使公司系统在给客户演示的时候能够达到较好的效果，帮助商务攻单，先后配合进行了两次较为大型的演示数据准备工作，包括：
江西国资委产权管理系统一千多家企业数据的整理、导入数据库，形成产权关系树；
重庆客户业绩考核系统几百个Excel表的演示数据准备。
另外，平常还不定时的视情况配合商务人员准备其它系统的演示数据。
4.3 营销中心工作
8月份，负责营销中心文职工作的小曹离职以后，我开始接替她先前的部分工作。包括：
4.3.1 奥汀软件的管理工作
奥汀软件的管理工作量不多，无非就是拥有管理员的权限，每次营销人员负责的区域、客户发生调整、变化的时候；有新员工入职的时候；有老员工离职的时候给相关人员重新分配权限，帮助新员工学会安装、使用该软件。就是这么一件看似简单的工作，有时却令我扼腕。在使用奥汀软件的过程中，最痛苦的事情莫过于公司调整营销人员负责的客户，需要对各地客户进行经手人变更的时候。奥汀软件的经手人变更功能没有批量选择、批量修改功能，每次只能一个客户一个客户地选中——点击右键——经手人变更——选择变更后的经手人和变更原因，有时一调整就是几百个客户，连续不断地上千次鼠标点击，点到手酸。
由此，我深深体会到，在编程的过程中，考虑到用户操作的方便性是多么的重要，就是这样一个简单的批量选择、批量修改功能，开发人员在编码的时候花不了几个小时，但由于没有考虑到用户这方面的需求，导致成百上千个客户增加几十倍的工作量！这一点，会不会给开发人员一点启示呢？
曾经找负责奥汀软件客服的人员抱怨过这个问题，他给我的回复是，在我们的新产品中已经增加了这个功能。换言之，要用，付钱吧。多么令人讨厌的事情，我们总不能为了那个批量功能特意再掏钱买个新版本吧？
前段时间由于DS服务器硬盘突然无端端损坏，造成存放所有客户资料、联系记录的奥汀数据库丢失。而因为我先前不了解服务器的安装等原理，也没有人跟我交接数据库的备份工作，只找到了以前的管理员7月份的备份版本，造成7月份以后登记的全部客户资料和联系记录丢失，造成销售人员大大的不便，这其中的损失，没有估量。自此之后，我意识到备份工作的重要性，现在无论是营销方面存放客户资料的奥汀数据库还是研发方面用的项目配置库，都会作好几手的备份，保证万一有意外，也不致造成数据丢失。可见，简单的工作，如果没有人做，有时也能带来不可意料的后果。
4.3.2 建立配置库整理资料
一直以来，营销中心的各种资料都是放在公司的OS服务器或个人电脑上，这当中包括部门内的各种规章制度；各个产品的资料，包括宣传单页、产品白皮书；各地客户的资料，包括针对某个客户做的方案、演示用的PPT、相关客户的反馈意见表；各个产品的培训资料、公司领域知识的相关资料，零乱而分散地放在各个不同部门的目录，各个不同负责人的文件夹中。文件的命名有的以日期为后缀，有的以Vx.y版为后缀，有的以new或old为后缀，要找一份文件，真不知道哪里下手，找出来的，还不知道是不是最新的。
目睹此情，我把整个OS服务器翻了一遍，把分布在各个角落的文档一一翻阅，有用的，拿出来，按照部门规范、部门会议、产品资料、客户资料、系统安装、培训资料、行业知识七大分类对各种资料进行整理，用VSS建立了一个配置库，像所有项目的文档、代码那样，纳入版本控制，把文档都集中管理起来。
可惜宣传做得不够，营销人员也没有体会到这样做的好处，现在我整理出来的营销中心配置库，除了有新员工进来，我可以比较自豪地叫他通过这个配置库，系统而完整地找到很多公司以往客户、产品、行业知识的相关资料以外，平常营销人员写的方案、PPT等资料还是习惯各自放到自己电脑上，共享给别人的时候发邮件，用一个个的日期或者new、old的标记标示着版本的新旧，不习惯用配置库保存、管理自己的资料。一个人若想一下子找到另一个人负责的东西，比较难……
4.3.3 会议记录
在公司内，我还有另外一份兼职工作，就是整理会议记录。无论是营销部门、研发部门还是质控部门的会议，经常都会充当会议记录的角色。经常会在开完会，整理完会议记录发送到相关人员的邮箱后听到有同事对我说：“会议纪要整理得不错”之类的话语，有了这些鼓励，使我在参加每一次会议时用心聆听，不怠动笔。
4.3.4 协助其他人员的文档工作
小xia，帮我把这份标书排一下版吧，你排版比较熟；小xia，能不能替我整理一下各个系统的功能模块，你对各个系统的功能了解比较多…… 每当听到有人要我帮忙协助这样那样工作的时候，如果不是手头有事安排不过来，只要力所能及，我一般都来者不拒。这些工作不再一一细数，只记得某同事对我说，我要向唐总提议，年底设立“最佳协助奖”，设立了，就投你一票时，我会心一笑，其实，那都是举手之劳。
- 作者：zhiminghe 2005年07月20日, 星期三 21:04回复（0） |引用（0）加入博采
2003年个人工作总结
犹记得我的2002年工作总结是以“2003年，我希望做得更好！”为结尾的，时间如此匆匆，2003年的个人工作总结转眼间提到了案前。
2003年，怀着这种希望做得更好的心态，我不断学习、不断追求、不断进取。
3.1 前台文员→文档管理员→配置管理员
年初，刚开始得知要调来开发部的时候，我是喜忧兼半。喜的是我去年的工作得到了公司的肯定，给了我一个更好地发挥自己和学习的机会；喜悦过后，更多的却是迷茫，不知道将会面临什么，能不能胜任新的岗位是个未知数。那个时候，开发部的软件过程也刚刚开始建立，还没有配置管理员这一说法，只说是把我调职过去做文档管理员，负责管理开发部的技术文档，协助部门一些内务。
最初的学习过程是比较苦涩的，不懂软件工程；不懂VSS；不懂ROSE；不懂UML建模；更是从来没有听过配置管理……对于工作有关的一切都是问号，开会的时候更是经常当愣头鸟。工作中，学习成了首要的主题，不学习，就不可能做好工作。将近三个月的时间里，从VSS到配置管理；从ROSE建模到UML语言；从面向对象的了解到对软件过程认识……在不断地学习过程中，对工作，有了一个基本的概念。5月的时候，我的工作表现得到了领导的肯定，受到了表彰。
虽然如此，但我并不满足于只是做文档管理员，只做简单的文档管理工作，我希望学习更多的配置管理和软件工程方面的知识，将项目中简单的版本管理融入配置管理的思想。最早的时候，公司的开发文档资料处于一片混乱之中，每个开发人员的电脑里都存有一份自己开发的工作版本，找不到哪一份是最新的。收集整理了国资一期、二期、产品化项目、南海国资升级项目、公有物业等一堆残留资料以后，也对东进ERP、财务异常警示系统项目中进行了初步的版本控制。再接着，到了企业转制与处置项目、三水项目的时候，开始制订了配置管理计划，项目的配置管理能够按照计划较为有序地进行，开发资料也能够定期进行备份，确保公司宝贵资源不会丢失。
SAM一期项目是公司最大的一个项目，也是涉及人数最多的一个项目。能否按照以前的方法进行配置管理，是否能够考虑用其他更好的配置管理工具？这个项目该怎么管理，我思索良久。经过对另一个免费的版本管理工具CVS的一番摸索之后，对两个工具的优缺点进行了比较，最终还是选择了VSS作为项目的配置管理工具，但在目录结构、权限分配和流程方面作了不少的调整。就这样，在工作中不断学习，不断地改进，使我，使开发部的大家都对配置管理工作有了较为完整的认识。
现在，无论是三水项目、SAM一期项目，还是接下来要做的天津项目、新疆项目、肇庆项目……无论是谁，都会深深地意识到配置管理在项目中的重要性，主动地希望用工具来进行版本管理。而公司各个系统的资料也在我的“仓库”里完好地存放着，作好了备份。回想起一年前在还没有配置管理员这一角色前开发资料混乱的管理，仿佛已是半个世纪前的事情！
3.2 项目组成员→“自由人”→质量与进度监督小组成员
调入开发部伊始，我被纳入财务异常警示系统项目组，并且说明，我所扮演的角色比较特殊，凡属开发项目我都需要参与其中。于是，我先后加入了财务异常警示系统项目组、东进ERP项目组、南海国有资产管理系统项目组。那段时间，让我感觉开会、作会议记录成了工作中不可缺少的一部分。开发部大大小小的会议要参加，作会议记录；项目组内部的会议要参加，了解进度；各个项目组的评审会议要参加，要准备好评审的制品，作会议记录……
接着，我的岗位结构作了调整，我成了一个不属于任何项目组自由人，反而要对各个项目的制品、进度进行管理。工作的内容没有多大的改变，在结构上却开始发生了变化。
成为“自由人”的时间并不久，开发部很快地成立了质量与进度监督小组。我成为了其中的一员，从此，我又变成了一个“有组织”的人了。我们的小组成员不断增加，队伍不断壮大，成员由一开始的两个人发展到了现在的四个人。工作范畴包括对各个项目组制品质量监督、进度监督、测试、配置管理、里程碑评审……成立了小组以后，开始想到了制订规范和制度。这段时间，我更加积极地学习软件质量管理和CMM体系的知识。经过学习，再加上对工作的不断总结，我先后在开发部制订、颁发了开发资料管理办法、服务器数据库管理规定、个人工作管理表格填写说明、测试流程；草拟了配置管理规范、里程碑评审规范、需求管理规范，规范了软件过程的各种文档的模板。
3.3 写用户手册生手→“专家”
第一次写用户手册是在财务异常警示系统的时候。财务异常警示系统是公司第一个完全按照软件过程规范并且运用J2EE进行开发的项目，对于公司来说，是在技术上、开发制度上的一个里程碑的飞跃。我有幸地加入了项目组，除了负责配置管理工作以外，还负责系统用户手册的编写。
万事开头难，从来没有写过用户手册的我，接到任务的时候忐忑了好久，不知道要怎么写。财务异常警示系统面向的用户是具有丰富财务知识的财务总监，涉及了大量的财务知识，面对取数运算元、标准运算元、异常、方法……这一大堆陌生的术语，不仅要学会怎么使用它，还要写成文档，教会别人怎么使用。我只好尽量多学多问，问巫锦新，问林戈，抓住机会让他们教我怎么使用，怎么表述。终于，第一份用户手册出炉了，图文并茂，自我感觉比公司以前系统的用户手册好多了。因为如此，这份用户手册经过多次COPY，作为指导，被接下来一个又一个的项目在写用户手册时所引用。也就是在那个时候，我学会了怎样看ROSE模型了解用例，怎样通过需求规格说明书了解系统功能，怎样在什么也不懂的情况下问人……
自始之后，写用户手册和帮助的工作似乎变成了我的专利。东进ERP系统、企业转制与资产处置系统、三水公有资产管理中心系统、SAM事项审批系统、SAM行政事业版，每一个开发项目的用户手册或帮助似乎都和我脱不了关系，虽然这期间也有派其他部门、其他人员参与协助。而我，不知什么时候起，竟然成了写用户手册的“专家”。要负责指导、教会别人怎么应该怎么写，甚至挑剔着别人写的内容过于简单不够充分，不能说明系统的功能；排版不符合规范；截图随便，没有反映真实内容……
3.4 2003年获奖次数最多的SK员工
2003年，对我而言，在公司可以算是光荣的一年。
5月，因为调职开发部以后工作表现突出，我获得了公司的表彰和奖金；
6月，我获得了财务异常警示系统项目奖；
7月，在半年总结中，经过全体员工投票，我获得了进步奖；
8月，我获得了企业处置与资产转制系统的项目奖；
11月，对于工作的情况向唐总提了一些个人的看法，意外获得了合理化建议奖。
虽然奖金微薄，但我深知这其中饱含公司对我工作的种种肯定，而这些小小的荣耀也在一步一步地激励着我前进！
3.5 不足和遗憾
总觉得还有太多太多的工作需要完善，有太多太多的东西需要学习。
在配置管理方面现在只是进行了比较简单的版本控制，初步实行了需求管理，虽然写了这方面的规范，但还没有颁布执行，配置的审核、产品的发布管理……还有很多的东西需要规范，需要完善。
质量与进度小组需要规范的制度很多，目前还没有一个质量体系指导工作；测试方面没有制度；项目的进度监督需要有制度……方方面面的规范，都来不及在2003年做好。
个人的技术能力提高不大，不懂系统分析、不懂设计、不懂开发，在工作中时常感到力不从心。另外，到目前为止，只能熟练地运用VSS进行版本管理，对于其他版本管理工具如CVS、ClearCase的掌握不够，还没办法根据不同项目的情况自如地使用不同的版本管理工具进行管理。学习编程知识，能够看懂源代码，看懂分析设计模型，掌握更多的配置管理工具……这些都是我2004年工作所向往的。
写用户手册是一个工作量大、时间甚长的工作，除了做好本身的配置管理、质量与进度监督的专职工作以外，其他的时间几乎都花在了 “兼职”写用户手册上。现在，SAM行政事业版用户手册的编写正在紧张地进行着。这一次，我在总结以往经验的基础上，对其风格作了不少修改，比以前更加清晰、明朗、详细。我希望写成一个模板，一个值得不断借鉴、引用的模板，这样以后的系统都不必再烦恼用户手册该怎么写，每个人只要看到这个模板，照着里面的内容、格式直接引用就可以了。能够在公司培养成更多写用户手册的专家，我也可以功成身退，分配一点时间去学习新的东西！
3.6 完结
写着，写着，总结，再总结……不断地回想着2003年，可以总结的东西竟然如此之多。无论如何，我想我是进步很多的。计划着2004年我该怎样秉承SK“诚信、和睦、实干”的文化，百尺竿头、更进一步提升自己；盘问着今年的努力够不够，年度的加工资会不会有我的份？憧憬着，努力着……
革命尚未成功，同志仍须努力！迎向2004之时，我对自己如是说。
- 作者：zhiminghe 2005年07月20日, 星期三 21:02回复（0） |引用（0）加入博采
2002年个人工作总结
回顾2002年，难免感慨。
在管理部从事前台文员半年多以来，工作主要可以归纳总结如下：
2.1 例行工作
认真做好来电的接听、访客的接待工作，做好订饭、订水工作；
做好文具的购买计划和消耗总结工作；
做好每月的考勤工作；
做好长途电话的管理工作；
将公司内的图书、杂志编号、分类整理，形成电子文档，使图书、杂志的管理规范化；
协助做好招聘工作；
做好办公室内务管理工作。这其间，因为排气扇导致电源跳闸多次与装修公司、物业管理处协调；注意植物的保养、更换及办公室内的清洁、保洁；注意复印机、打印机、热熔装订机等办公设备的保养。
2.2 临时安排的工作
组织每个月的团队活动。先后组织到暨南大学打球、天河公司游泳、天河公司烧烤、员村文化宫打球、从化温泉度假，都取得了较好的效果，加强了同事之间的交流，活跃了公司气氛。另外，9月底曾策划员工欢送大会，欢送吴涛等离职员工。
办好公司的内刊。从七月到十二月，一共办了五期内刊。经调查，普遍认为水平尚可。但因为大多数人工作较忙或其他原因无法投稿，造成每一期内刊的都存在稿源不足的问题。未能想方设法调动员工的写稿积极性，除了自身原因之外，也与管理层等其他因素有关。
公司网站的建设。由于没有制作网页的经验，所以存在很多技术问题不知如何实现。在不断学习的过程中，修改了主页，实现了公司产品等部分链接。因为公司形象需要重新策划，此项工作暂时告一段落。
2.3 协助其他部门工作
销售部成立后，曾参与销售部的销售例会，整理会议记录及销售部一些常用资料、表格；
协助开发部制作国资、灯饰ERP等项目的部分图片；
协助市场部进行国资宣传资料的排版、整理；
另外还参与了公有物业产品化的测试及《授权管理》等几次幻灯片的制作。
总的来看，2002年的工作是尽职的，但也有不少的遗憾。考勤的管理一开始并不规范；长途电话也因为疏于管理存在一些不良现象；没有投入全心的精力去办内刊；网站的建设太过于缓慢而且效果不够好；工作的确不够饱和，时有不知该干什么的感觉；个人能力的提升不够……在管理部的遗憾，可惜因为岗位的调换已无机会弥补。
调到开发部，这是上级对我工作的肯定，对我个人而言是新的开始，也是新的挑战。除了要努力扮演好开发部“文档管理员”这一角色以外，希望我能在开发部掌握更多的技术知识，不断提升自我。
2003年，我希望做得更好！
_xyz