谨以此文与所有在琐碎、繁杂、平凡中日复一日地做着重复工作的人们共勉。 1前言 2 2002年个人工作总结 2.1 例行工作 2.2 临时安排的工作 办好公司的内刊。从七月到十二月,一共办了五期内刊。经调查,普遍认为水平尚可。但因为大多数人工作较忙或其他原因无法投稿,造成每一期内刊的都存在稿源不足的问题。未能想方设法调动员工的写稿积极性,除了自身原因之外,也与管理层等其他因素有关。 公司网站的建设。由于没有制作网页的经验,所以存在很多技术问题不知如何实现。在不断学习的过程中,修改了主页,实现了公司产品等部分链接。因为公司形象需要重新策划,此项工作暂时告一段落。 2.3 协助其他部门工作 总的来看,2002年的工作是尽职的,但也有不少的遗憾。考勤的管理一开始并不规范;长途电话也因为疏于管理存在一些不良现象;没有投入全心的精力去办内刊;网站的建设太过于缓慢而且效果不够好;工作的确不够饱和,时有不知该干什么的感觉;个人能力的提升不够……在管理部的遗憾,可惜因为岗位的调换已无机会弥补。 调到开发部,这是上级对我工作的肯定,对我个人而言是新的开始,也是新的挑战。除了要努力扮演好开发部“文档管理员”这一角色以外,希望我能在开发部掌握更多的技术知识,不断提升自我。 2003年,我希望做得更好! 2003年个人工作总结 犹记得我的2002年工作总结是以“2003年,我希望做得更好!”为结尾的,时间如此匆匆,2003年的个人工作总结转眼间提到了案前。 3.1 前台文员→文档管理员→配置管理员 最初的学习过程是比较苦涩的,不懂软件工程;不懂VSS;不懂ROSE;不懂UML建模;更是从来没有听过配置管理……对于工作有关的一切都是问号,开会的时候更是经常当愣头鸟。工作中,学习成了首要的主题,不学习,就不可能做好工作。将近三个月的时间里,从VSS到配置管理;从ROSE建模到UML语言;从面向对象的了解到对软件过程认识……在不断地学习过程中,对工作,有了一个基本的概念。5月的时候,我的工作表现得到了领导的肯定,受到了表彰。 虽然如此,但我并不满足于只是做文档管理员,只做简单的文档管理工作,我希望学习更多的配置管理和软件工程方面的知识,将项目中简单的版本管理融入配置管理的思想。最早的时候,公司的开发文档资料处于一片混乱之中,每个开发人员的电脑里都存有一份自己开发的工作版本,找不到哪一份是最新的。收集整理了国资一期、二期、产品化项目、南海国资升级项目、公有物业等一堆残留资料以后,也对东进ERP、财务异常警示系统项目中进行了初步的版本控制。再接着,到了企业转制与处置项目、三水项目的时候,开始制订了配置管理计划,项目的配置管理能够按照计划较为有序地进行,开发资料也能够定期进行备份,确保公司宝贵资源不会丢失。 SAM一期项目是公司最大的一个项目,也是涉及人数最多的一个项目。能否按照以前的方法进行配置管理,是否能够考虑用其他更好的配置管理工具?这个项目该怎么管理,我思索良久。经过对另一个免费的版本管理工具CVS的一番摸索之后,对两个工具的优缺点进行了比较,最终还是选择了VSS作为项目的配置管理工具,但在目录结构、权限分配和流程方面作了不少的调整。就这样,在工作中不断学习,不断地改进,使我,使开发部的大家都对配置管理工作有了较为完整的认识。 现在,无论是三水项目、SAM一期项目,还是接下来要做的天津项目、新疆项目、肇庆项目……无论是谁,都会深深地意识到配置管理在项目中的重要性,主动地希望用工具来进行版本管理。而公司各个系统的资料也在我的“仓库”里完好地存放着,作好了备份。回想起一年前在还没有配置管理员这一角色前开发资料混乱的管理,仿佛已是半个世纪前的事情! 3.2 项目组成员→“自由人”→质量与进度监督小组成员 成为“自由人”的时间并不久,开发部很快地成立了质量与进度监督小组。我成为了其中的一员,从此,我又变成了一个“有组织”的人了。我们的小组成员不断增加,队伍不断壮大,成员由一开始的两个人发展到了现在的四个人。工作范畴包括对各个项目组制品质量监督、进度监督、测试、配置管理、里程碑评审……成立了小组以后,开始想到了制订规范和制度。这段时间,我更加积极地学习软件质量管理和CMM体系的知识。经过学习,再加上对工作的不断总结,我先后在开发部制订、颁发了开发资料管理办法、服务器数据库管理规定、个人工作管理表格填写说明、测试流程;草拟了配置管理规范、里程碑评审规范、需求管理规范,规范了软件过程的各种文档的模板。 3.3 写用户手册生手→“专家” 万事开头难,从来没有写过用户手册的我,接到任务的时候忐忑了好久,不知道要怎么写。财务异常警示系统面向的用户是具有丰富财务知识的财务总监,涉及了大量的财务知识,面对取数运算元、标准运算元、异常、方法……这一大堆陌生的术语,不仅要学会怎么使用它,还要写成文档,教会别人怎么使用。我只好尽量多学多问,问巫锦新,问林戈,抓住机会让他们教我怎么使用,怎么表述。终于,第一份用户手册出炉了,图文并茂,自我感觉比公司以前系统的用户手册好多了。因为如此,这份用户手册经过多次COPY,作为指导,被接下来一个又一个的项目在写用户手册时所引用。也就是在那个时候,我学会了怎样看ROSE模型了解用例,怎样通过需求规格说明书了解系统功能,怎样在什么也不懂的情况下问人…… 自始之后,写用户手册和帮助的工作似乎变成了我的专利。东进ERP系统、企业转制与资产处置系统、三水公有资产管理中心系统、SAM事项审批系统、SAM行政事业版,每一个开发项目的用户手册或帮助似乎都和我脱不了关系,虽然这期间也有派其他部门、其他人员参与协助。而我,不知什么时候起,竟然成了写用户手册的“专家”。要负责指导、教会别人怎么应该怎么写,甚至挑剔着别人写的内容过于简单不够充分,不能说明系统的功能;排版不符合规范;截图随便,没有反映真实内容…… 3.4 2003年获奖次数最多的SK员工 3.5 不足和遗憾 质量与进度小组需要规范的制度很多,目前还没有一个质量体系指导工作;测试方面没有制度;项目的进度监督需要有制度……方方面面的规范,都来不及在2003年做好。 个人的技术能力提高不大,不懂系统分析、不懂设计、不懂开发,在工作中时常感到力不从心。另外,到目前为止,只能熟练地运用VSS进行版本管理,对于其他版本管理工具如CVS、ClearCase的掌握不够,还没办法根据不同项目的情况自如地使用不同的版本管理工具进行管理。学习编程知识,能够看懂源代码,看懂分析设计模型,掌握更多的配置管理工具……这些都是我2004年工作所向往的。 写用户手册是一个工作量大、时间甚长的工作,除了做好本身的配置管理、质量与进度监督的专职工作以外,其他的时间几乎都花在了 “兼职”写用户手册上。现在,SAM行政事业版用户手册的编写正在紧张地进行着。这一次,我在总结以往经验的基础上,对其风格作了不少修改,比以前更加清晰、明朗、详细。我希望写成一个模板,一个值得不断借鉴、引用的模板,这样以后的系统都不必再烦恼用户手册该怎么写,每个人只要看到这个模板,照着里面的内容、格式直接引用就可以了。能够在公司培养成更多写用户手册的专家,我也可以功成身退,分配一点时间去学习新的东西! 3.6 完结 2004年个人工作总结 有人把工作总结当成一种形式,作为应付上级领导的苦差,我却发自内心地想写总结,通过总结,可以清楚、明晰地知道自己一年来做过什么,欠缺什么。好的,需要继续发扬的;不好的,需要加以改进的,都会在总结中一一罗列,鞭策自己。 2004年,我都做了哪些工作?还得从头回顾,娓娓道来。 作为质控部一员,我的工作却囊括了质控、研发、营销三大部门,随着公司的机构调整、人员变化不断调整和变化。按照部门分类,可以把我2004年的工作总结如下: 4.1 质控部门工作 4.1.1 配置管理工作 (1)根据项目的规模、性质、简繁,视情况针对各个项目开展常规的配置管理工作。包括: (2)对研发中心内所有成员的配置管理培训,使受训人员了解公司配置管理流程及VSS使用情况,从而更好地开展项目过程中的配置管理工作。 4.1.2 制度编写及流程改进工作 (1)年初,研发中心设立产品、项目、质控三个部门伊始,各个部门之间独立开展工作,信息比较闭塞,而各个部门之间工作关联性大,需要不断沟通和交互。为了减少沟通成本,使部门与部门之间的信息交互、沟通能够更方便、更快捷,提议建立了项目部、产品部、质控部各个部门的部门配置库,将各个部门的制度及规范、会议、培训、计划与总结、个人周报等各种信息统一集中管理,大大方便了公司高层领导了解各个部门的工作开展情况;部门与部门之间相互了解彼此工作开展情况;部门成员之间了解彼此的工作开展情况。(见附件三:部门配置库管理办法.doc) (2)为了规范SAM行政事业版及后续产品序列号管理,编写了SAM行政事业版系统系列号管理办法(见附件四:SAM行政事业版系统系列号管理办法.doc)。 (3)为了规范公司内部产品的发布,将公司内部所有已经定版的产品、项目安装到SS服务器统一发布,并将各个系统的访问地址整理成文(见附件五:公司系统访问地址.doc)供公司内部开发人员、技术支持人员、市场人员访问系统,了解各个系统功能。 (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 软件过程监督工作 4.1.4 软件测试工作 4.1.5 评审工作 4.2 研发中心工作 4.2.2 软件使用培训工作 4.2.3 演示数据准备工作 4.3 营销中心工作 4.3.1 奥汀软件的管理工作 由此,我深深体会到,在编程的过程中,考虑到用户操作的方便性是多么的重要,就是这样一个简单的批量选择、批量修改功能,开发人员在编码的时候花不了几个小时,但由于没有考虑到用户这方面的需求,导致成百上千个客户增加几十倍的工作量!这一点,会不会给开发人员一点启示呢? 曾经找负责奥汀软件客服的人员抱怨过这个问题,他给我的回复是,在我们的新产品中已经增加了这个功能。换言之,要用,付钱吧。多么令人讨厌的事情,我们总不能为了那个批量功能特意再掏钱买个新版本吧? 前段时间由于DS服务器硬盘突然无端端损坏,造成存放所有客户资料、联系记录的奥汀数据库丢失。而因为我先前不了解服务器的安装等原理,也没有人跟我交接数据库的备份工作,只找到了以前的管理员7月份的备份版本,造成7月份以后登记的全部客户资料和联系记录丢失,造成销售人员大大的不便,这其中的损失,没有估量。自此之后,我意识到备份工作的重要性,现在无论是营销方面存放客户资料的奥汀数据库还是研发方面用的项目配置库,都会作好几手的备份,保证万一有意外,也不致造成数据丢失。可见,简单的工作,如果没有人做,有时也能带来不可意料的后果。 4.3.2 建立配置库整理资料 目睹此情,我把整个OS服务器翻了一遍,把分布在各个角落的文档一一翻阅,有用的,拿出来,按照部门规范、部门会议、产品资料、客户资料、系统安装、培训资料、行业知识七大分类对各种资料进行整理,用VSS建立了一个配置库,像所有项目的文档、代码那样,纳入版本控制,把文档都集中管理起来。 可惜宣传做得不够,营销人员也没有体会到这样做的好处,现在我整理出来的营销中心配置库,除了有新员工进来,我可以比较自豪地叫他通过这个配置库,系统而完整地找到很多公司以往客户、产品、行业知识的相关资料以外,平常营销人员写的方案、PPT等资料还是习惯各自放到自己电脑上,共享给别人的时候发邮件,用一个个的日期或者new、old的标记标示着版本的新旧,不习惯用配置库保存、管理自己的资料。一个人若想一下子找到另一个人负责的东西,比较难…… 4.3.3 会议记录 4.3.4 协助其他人员的文档工作 4.4 个人收获与体会 4.4.1 关于改进工作 4.4.2 关于身兼数职 4.4.3 关于写文档 尽管如此,现在动笔写一个庞大系统的用户手册之前,想到日复一日对着键盘敲字;对着系统界面截图;对着没有成熟稳定操作起来bug连连的功能;对着甚至没有任何文档参考的系统冥思苦想怎样表述它的功能时,再想到写完以后还要根据客户的需求发生变更,修改相应的系统功能再修改相关用户手册功能操作时,还是会禁不住汗颜。半是恐惧之中,可喜地发现,在写用户手册等文档的过程中,也能得到不少提高呢。 经过这样一个接一个项目文档编写的千锤百炼,我的写作能力大大提高。现在,无论叫我写什么文档,不管是用户手册、安装手册、会议记录还是产品白皮书,不管是用Word、Excel、Powerpoint还是要用上Visio、Project、Photoshop,虽然谈不上信手掂来,但是以前那种“纵有千言万语不知如何下笔”的心情却不会再有。某次当我苦恼着跟罗经理说不知道某文档要怎么写的时候,他开玩笑地对我说:“还有什么文档你不会写的吗?”,禁不住一乐,对写文档的恐惧也开始淡化。 因为对每个项目都有写用户手册的任务在身,所以不单会从宏观角度跟踪项目的进度,了解项目情况,而且会从细节着手,小到了解每一个功能、每一个按钮的作用,有意见可以及时反馈,帮助改进软件功能、优化界面。也因为这样,我比公司大多数人都了解各个系统的功能、操作,了解公司的产品。这些,何尝不是一种收获呢? 4.4.4 关于坚持 现在,虽然我还是有很多事情想过要做之后不能坚持,但却有一两件事情让我可以骄傲地说:我也是一个可以坚持的人。 生活中,我坚持每天自己做饭、带饭到公司来吃,这中间的理由有很多,不过最终发现,热爱做饭、并且爱吃自己做的饭是最大的理由:);坚持写网络日记,虽谈不上日日更新,却会隔三差五地去记录自己平凡生活的一点一滴,一年多下来也收获良多。 工作中,我坚持写个人工作管理表格,做到对工作日计划、周计划,日总结、周总结,不管上级领导有没有要求,主动自发地坚持;每周坚持在项目进度综合报告中记录这一周哪些项目做了哪些事情,进度如何,虽然也没人要求甚至没人关心那份文档。 因为这两样坚持,使我在一年结束的时候,可以把自己做过的工作回顾得这么清楚,把总结写得如此详细;可以有根有据地写出一份长达上万字的04年项目质量总结报告;可以有这么多的感触和收获……想起那句听过无数遍的“贵在坚持”。 4.5 结语 有位前辈在给我提意见的时候这样建议道:“以后信心要强,希望你能有发展,每天提高自己,有计划的学习。建议加强:文档管理、日常事务处理能力、人际关系(表达),书写能力。培养职业女性的气质,比如:穿着,站的肢势,说话的方式,果断大方的说话风格,从细节入手。不要像小女孩,一两句打击的话就让你心里不高兴,要懂得自己控制自己的情绪……”,这些话,我一直铭记在心,在此谢谢为我如此中恳地提过意见的他。我知道,自己还有很多很多需要学习的地方,也一直在努力,希望可以“每天前进一步”。 |
[转]我在软件公司成长的三年
上一篇 / 下一篇 2013-04-24 17:04:39 / 个人分类:个人学习
我在软件公司成长的三年
我在软件公司成长的三年
发布时间: 2007-4-13 10:22 作者: Swallow Xia 来源: 转载
谨以此文与所有在琐碎、繁杂、平凡中日复一日地做着重复工作的人们共勉。 1前言 2 2002年个人工作总结 2.1 例行工作 2.2 临时安排的工作 办好公司的内刊。从七月到十二月,一共办了五期内刊。经调查,普遍认为水平尚可。但因为大多数人工作较忙或其他原因无法投稿,造成每一期内刊的都存在稿源不足的问题。未能想方设法调动员工的写稿积极性,除了自身原因之外,也与管理层等其他因素有关。 公司网站的建设。由于没有制作网页的经验,所以存在很多技术问题不知如何实现。在不断学习的过程中,修改了主页,实现了公司产品等部分链接。因为公司形象需要重新策划,此项工作暂时告一段落。 2.3 协助其他部门工作 总的来看,2002年的工作是尽职的,但也有不少的遗憾。考勤的管理一开始并不规范;长途电话也因为疏于管理存在一些不良现象;没有投入全心的精力去办内刊;网站的建设太过于缓慢而且效果不够好;工作的确不够饱和,时有不知该干什么的感觉;个人能力的提升不够……在管理部的遗憾,可惜因为岗位的调换已无机会弥补。 调到开发部,这是上级对我工作的肯定,对我个人而言是新的开始,也是新的挑战。除了要努力扮演好开发部“文档管理员”这一角色以外,希望我能在开发部掌握更多的技术知识,不断提升自我。 2003年,我希望做得更好! 2003年个人工作总结 犹记得我的2002年工作总结是以“2003年,我希望做得更好!”为结尾的,时间如此匆匆,2003年的个人工作总结转眼间提到了案前。 3.1 前台文员→文档管理员→配置管理员 最初的学习过程是比较苦涩的,不懂软件工程;不懂VSS;不懂ROSE;不懂UML建模;更是从来没有听过配置管理……对于工作有关的一切都是问号,开会的时候更是经常当愣头鸟。工作中,学习成了首要的主题,不学习,就不可能做好工作。将近三个月的时间里,从VSS到配置管理;从ROSE建模到UML语言;从面向对象的了解到对软件过程认识……在不断地学习过程中,对工作,有了一个基本的概念。5月的时候,我的工作表现得到了领导的肯定,受到了表彰。 虽然如此,但我并不满足于只是做文档管理员,只做简单的文档管理工作,我希望学习更多的配置管理和软件工程方面的知识,将项目中简单的版本管理融入配置管理的思想。最早的时候,公司的开发文档资料处于一片混乱之中,每个开发人员的电脑里都存有一份自己开发的工作版本,找不到哪一份是最新的。收集整理了国资一期、二期、产品化项目、南海国资升级项目、公有物业等一堆残留资料以后,也对东进ERP、财务异常警示系统项目中进行了初步的版本控制。再接着,到了企业转制与处置项目、三水项目的时候,开始制订了配置管理计划,项目的配置管理能够按照计划较为有序地进行,开发资料也能够定期进行备份,确保公司宝贵资源不会丢失。 SAM一期项目是公司最大的一个项目,也是涉及人数最多的一个项目。能否按照以前的方法进行配置管理,是否能够考虑用其他更好的配置管理工具?这个项目该怎么管理,我思索良久。经过对另一个免费的版本管理工具CVS的一番摸索之后,对两个工具的优缺点进行了比较,最终还是选择了VSS作为项目的配置管理工具,但在目录结构、权限分配和流程方面作了不少的调整。就这样,在工作中不断学习,不断地改进,使我,使开发部的大家都对配置管理工作有了较为完整的认识。 现在,无论是三水项目、SAM一期项目,还是接下来要做的天津项目、新疆项目、肇庆项目……无论是谁,都会深深地意识到配置管理在项目中的重要性,主动地希望用工具来进行版本管理。而公司各个系统的资料也在我的“仓库”里完好地存放着,作好了备份。回想起一年前在还没有配置管理员这一角色前开发资料混乱的管理,仿佛已是半个世纪前的事情! 3.2 项目组成员→“自由人”→质量与进度监督小组成员 成为“自由人”的时间并不久,开发部很快地成立了质量与进度监督小组。我成为了其中的一员,从此,我又变成了一个“有组织”的人了。我们的小组成员不断增加,队伍不断壮大,成员由一开始的两个人发展到了现在的四个人。工作范畴包括对各个项目组制品质量监督、进度监督、测试、配置管理、里程碑评审……成立了小组以后,开始想到了制订规范和制度。这段时间,我更加积极地学习软件质量管理和CMM体系的知识。经过学习,再加上对工作的不断总结,我先后在开发部制订、颁发了开发资料管理办法、服务器数据库管理规定、个人工作管理表格填写说明、测试流程;草拟了配置管理规范、里程碑评审规范、需求管理规范,规范了软件过程的各种文档的模板。 3.3 写用户手册生手→“专家” 万事开头难,从来没有写过用户手册的我,接到任务的时候忐忑了好久,不知道要怎么写。财务异常警示系统面向的用户是具有丰富财务知识的财务总监,涉及了大量的财务知识,面对取数运算元、标准运算元、异常、方法……这一大堆陌生的术语,不仅要学会怎么使用它,还要写成文档,教会别人怎么使用。我只好尽量多学多问,问巫锦新,问林戈,抓住机会让他们教我怎么使用,怎么表述。终于,第一份用户手册出炉了,图文并茂,自我感觉比公司以前系统的用户手册好多了。因为如此,这份用户手册经过多次COPY,作为指导,被接下来一个又一个的项目在写用户手册时所引用。也就是在那个时候,我学会了怎样看ROSE模型了解用例,怎样通过需求规格说明书了解系统功能,怎样在什么也不懂的情况下问人…… 自始之后,写用户手册和帮助的工作似乎变成了我的专利。东进ERP系统、企业转制与资产处置系统、三水公有资产管理中心系统、SAM事项审批系统、SAM行政事业版,每一个开发项目的用户手册或帮助似乎都和我脱不了关系,虽然这期间也有派其他部门、其他人员参与协助。而我,不知什么时候起,竟然成了写用户手册的“专家”。要负责指导、教会别人怎么应该怎么写,甚至挑剔着别人写的内容过于简单不够充分,不能说明系统的功能;排版不符合规范;截图随便,没有反映真实内容…… 3.4 2003年获奖次数最多的SK员工 3.5 不足和遗憾 质量与进度小组需要规范的制度很多,目前还没有一个质量体系指导工作;测试方面没有制度;项目的进度监督需要有制度……方方面面的规范,都来不及在2003年做好。 个人的技术能力提高不大,不懂系统分析、不懂设计、不懂开发,在工作中时常感到力不从心。另外,到目前为止,只能熟练地运用VSS进行版本管理,对于其他版本管理工具如CVS、ClearCase的掌握不够,还没办法根据不同项目的情况自如地使用不同的版本管理工具进行管理。学习编程知识,能够看懂源代码,看懂分析设计模型,掌握更多的配置管理工具……这些都是我2004年工作所向往的。 写用户手册是一个工作量大、时间甚长的工作,除了做好本身的配置管理、质量与进度监督的专职工作以外,其他的时间几乎都花在了 “兼职”写用户手册上。现在,SAM行政事业版用户手册的编写正在紧张地进行着。这一次,我在总结以往经验的基础上,对其风格作了不少修改,比以前更加清晰、明朗、详细。我希望写成一个模板,一个值得不断借鉴、引用的模板,这样以后的系统都不必再烦恼用户手册该怎么写,每个人只要看到这个模板,照着里面的内容、格式直接引用就可以了。能够在公司培养成更多写用户手册的专家,我也可以功成身退,分配一点时间去学习新的东西! 3.6 完结 2004年个人工作总结 有人把工作总结当成一种形式,作为应付上级领导的苦差,我却发自内心地想写总结,通过总结,可以清楚、明晰地知道自己一年来做过什么,欠缺什么。好的,需要继续发扬的;不好的,需要加以改进的,都会在总结中一一罗列,鞭策自己。 2004年,我都做了哪些工作?还得从头回顾,娓娓道来。 作为质控部一员,我的工作却囊括了质控、研发、营销三大部门,随着公司的机构调整、人员变化不断调整和变化。按照部门分类,可以把我2004年的工作总结如下: 4.1 质控部门工作 4.1.1 配置管理工作 (1)根据项目的规模、性质、简繁,视情况针对各个项目开展常规的配置管理工作。包括: (2)对研发中心内所有成员的配置管理培训,使受训人员了解公司配置管理流程及VSS使用情况,从而更好地开展项目过程中的配置管理工作。 4.1.2 制度编写及流程改进工作 (1)年初,研发中心设立产品、项目、质控三个部门伊始,各个部门之间独立开展工作,信息比较闭塞,而各个部门之间工作关联性大,需要不断沟通和交互。为了减少沟通成本,使部门与部门之间的信息交互、沟通能够更方便、更快捷,提议建立了项目部、产品部、质控部各个部门的部门配置库,将各个部门的制度及规范、会议、培训、计划与总结、个人周报等各种信息统一集中管理,大大方便了公司高层领导了解各个部门的工作开展情况;部门与部门之间相互了解彼此工作开展情况;部门成员之间了解彼此的工作开展情况。(见附件三:部门配置库管理办法.doc) (2)为了规范SAM行政事业版及后续产品序列号管理,编写了SAM行政事业版系统系列号管理办法(见附件四:SAM行政事业版系统系列号管理办法.doc)。 (3)为了规范公司内部产品的发布,将公司内部所有已经定版的产品、项目安装到SS服务器统一发布,并将各个系统的访问地址整理成文(见附件五:公司系统访问地址.doc)供公司内部开发人员、技术支持人员、市场人员访问系统,了解各个系统功能。 (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 软件过程监督工作 4.1.4 软件测试工作 4.1.5 评审工作 4.2 研发中心工作 4.2.2 软件使用培训工作 4.2.3 演示数据准备工作 4.3 营销中心工作 4.3.1 奥汀软件的管理工作 由此,我深深体会到,在编程的过程中,考虑到用户操作的方便性是多么的重要,就是这样一个简单的批量选择、批量修改功能,开发人员在编码的时候花不了几个小时,但由于没有考虑到用户这方面的需求,导致成百上千个客户增加几十倍的工作量!这一点,会不会给开发人员一点启示呢? 曾经找负责奥汀软件客服的人员抱怨过这个问题,他给我的回复是,在我们的新产品中已经增加了这个功能。换言之,要用,付钱吧。多么令人讨厌的事情,我们总不能为了那个批量功能特意再掏钱买个新版本吧? 前段时间由于DS服务器硬盘突然无端端损坏,造成存放所有客户资料、联系记录的奥汀数据库丢失。而因为我先前不了解服务器的安装等原理,也没有人跟我交接数据库的备份工作,只找到了以前的管理员7月份的备份版本,造成7月份以后登记的全部客户资料和联系记录丢失,造成销售人员大大的不便,这其中的损失,没有估量。自此之后,我意识到备份工作的重要性,现在无论是营销方面存放客户资料的奥汀数据库还是研发方面用的项目配置库,都会作好几手的备份,保证万一有意外,也不致造成数据丢失。可见,简单的工作,如果没有人做,有时也能带来不可意料的后果。 4.3.2 建立配置库整理资料 目睹此情,我把整个OS服务器翻了一遍,把分布在各个角落的文档一一翻阅,有用的,拿出来,按照部门规范、部门会议、产品资料、客户资料、系统安装、培训资料、行业知识七大分类对各种资料进行整理,用VSS建立了一个配置库,像所有项目的文档、代码那样,纳入版本控制,把文档都集中管理起来。 可惜宣传做得不够,营销人员也没有体会到这样做的好处,现在我整理出来的营销中心配置库,除了有新员工进来,我可以比较自豪地叫他通过这个配置库,系统而完整地找到很多公司以往客户、产品、行业知识的相关资料以外,平常营销人员写的方案、PPT等资料还是习惯各自放到自己电脑上,共享给别人的时候发邮件,用一个个的日期或者new、old的标记标示着版本的新旧,不习惯用配置库保存、管理自己的资料。一个人若想一下子找到另一个人负责的东西,比较难…… 4.3.3 会议记录 4.3.4 协助其他人员的文档工作 4.4 个人收获与体会 4.4.1 关于改进工作 4.4.2 关于身兼数职 4.4.3 关于写文档 尽管如此,现在动笔写一个庞大系统的用户手册之前,想到日复一日对着键盘敲字;对着系统界面截图;对着没有成熟稳定操作起来bug连连的功能;对着甚至没有任何文档参考的系统冥思苦想怎样表述它的功能时,再想到写完以后还要根据客户的需求发生变更,修改相应的系统功能再修改相关用户手册功能操作时,还是会禁不住汗颜。半是恐惧之中,可喜地发现,在写用户手册等文档的过程中,也能得到不少提高呢。 经过这样一个接一个项目文档编写的千锤百炼,我的写作能力大大提高。现在,无论叫我写什么文档,不管是用户手册、安装手册、会议记录还是产品白皮书,不管是用Word、Excel、Powerpoint还是要用上Visio、Project、Photoshop,虽然谈不上信手掂来,但是以前那种“纵有千言万语不知如何下笔”的心情却不会再有。某次当我苦恼着跟罗经理说不知道某文档要怎么写的时候,他开玩笑地对我说:“还有什么文档你不会写的吗?”,禁不住一乐,对写文档的恐惧也开始淡化。 因为对每个项目都有写用户手册的任务在身,所以不单会从宏观角度跟踪项目的进度,了解项目情况,而且会从细节着手,小到了解每一个功能、每一个按钮的作用,有意见可以及时反馈,帮助改进软件功能、优化界面。也因为这样,我比公司大多数人都了解各个系统的功能、操作,了解公司的产品。这些,何尝不是一种收获呢? 4.4.4 关于坚持 现在,虽然我还是有很多事情想过要做之后不能坚持,但却有一两件事情让我可以骄傲地说:我也是一个可以坚持的人。 生活中,我坚持每天自己做饭、带饭到公司来吃,这中间的理由有很多,不过最终发现,热爱做饭、并且爱吃自己做的饭是最大的理由:);坚持写网络日记,虽谈不上日日更新,却会隔三差五地去记录自己平凡生活的一点一滴,一年多下来也收获良多。 工作中,我坚持写个人工作管理表格,做到对工作日计划、周计划,日总结、周总结,不管上级领导有没有要求,主动自发地坚持;每周坚持在项目进度综合报告中记录这一周哪些项目做了哪些事情,进度如何,虽然也没人要求甚至没人关心那份文档。 因为这两样坚持,使我在一年结束的时候,可以把自己做过的工作回顾得这么清楚,把总结写得如此详细;可以有根有据地写出一份长达上万字的04年项目质量总结报告;可以有这么多的感触和收获……想起那句听过无数遍的“贵在坚持”。 4.5 结语 有位前辈在给我提意见的时候这样建议道:“以后信心要强,希望你能有发展,每天提高自己,有计划的学习。建议加强:文档管理、日常事务处理能力、人际关系(表达),书写能力。培养职业女性的气质,比如:穿着,站的肢势,说话的方式,果断大方的说话风格,从细节入手。不要像小女孩,一两句打击的话就让你心里不高兴,要懂得自己控制自己的情绪……”,这些话,我一直铭记在心,在此谢谢为我如此中恳地提过意见的他。我知道,自己还有很多很多需要学习的地方,也一直在努力,希望可以“每天前进一步”。 看了这篇文章,很感动,也很受启发。 |
TAG:
我的栏目
标题搜索
日历
|
|||||||||
日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
1 | 2 | 3 | 4 | 5 | 6 | 7 | |||
8 | 9 | 10 | 11 | 12 | 13 | 14 | |||
15 | 16 | 17 | 18 | 19 | 20 | 21 | |||
22 | 23 | 24 | 25 | 26 | 27 | 28 | |||
29 | 30 |
我的存档
数据统计
- 访问量: 14759
- 日志数: 15
- 建立时间: 2011-06-01
- 更新时间: 2013-05-29