软件项目总结

总结是一种事后记录方式，针对于工作结束情况、项目完成情况等，将整个过程中的经验、问题进行记录，并在切实与认真分析后，整理成一份详细的报告。如何采用正确的总结格式，写出客观的总结呢？以下是小编整理的关于《软件项目总结》，供大家阅读，更多内容可以运用本站顶部的搜索功能。

第一篇：软件项目总结

软件项目管理总结

《软件项目管理》学习总结报告

软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上，软件项目管理的意义不仅仅如此，进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定发展。

项目风险管理是指为了最好的达到项目的目标，识别、分配、应对项目生命周期内风险的科学与艺术。项目风险管理的目标是使潜在机会或回报最大化，使潜在风险最小化。

1.项目管理在软件开发中的应用的成因

目前我国大部分软件公司,无论是产品型公司还是项目型公司,都没有形成完全适合自己公司特点的软件开发管理模式,虽然有些公司根据软件工程理论建立了一些软件开发管理规范,但并没有从根本上解决软件开发的质量控制问题。这样导致软件产品质量不稳定,软件

后期的维护、升级出现麻烦,同时最终也会损害用户的利益。

随着软件开发的深入、各种技术的不断创新以及软件产业的形成,人们越来越意识到软件过程管理的重要性,管理学的思想逐渐融入软件开发过程中,应用开发的项目管理日益受到重

视。

2.软件项目管理常见问题及解决方案

(1)缺乏项目管理系统培训

在软件企业中,以前几乎没有专门招收项目管理专业的人员来担任项目经理,被任命的项目经理主要是因为他们能够在技术上独当一面,而管理方面特别是项目管理方面的知识比

较缺乏。

解决方案:项目经理接受系统的项目管理知识培训是非常必要的,有了专业领域的知识与实践,再加上项目管理知识与实践和一般管理的知识和经验的有机结合,必能大大提高项

目经理的项目管理水平。

(2)项目计划意识问题

项目经理对总体计划、阶段计划的作用认识不足,因此制定总体计划时比较随意,不少事情没有仔细考虑;阶段计划因工作忙等理由经常拖延,造成计划与控制管理脱节,无法进行有

效的进度控制管理。

解决方案:计划的制定需要在一定条件的限制和假设之下采用渐近明细的方式进行不断完善。提高项目经理的计划意识,采用项目计划制定相关知识、技术、工具,加强对开发计

划、阶段计划的有效性进行事前事后的评估。

(3)管理意识问题

部分项目经理不能从总体上把握整个项目,而是埋头于具体的技术工作,造成项目组成员之间忙的忙、闲的闲,计划不周、任务不均、资源浪费。有些项目经理没有很好的管理方

法,不好安排的工作只好自己做,使项目任务无法有效、合理地分配给相关成员,以达到“负载

均衡”。

解决方案:加强项目管理方面的培训,并通过对考核指标的合理设定和宣传引导项目经理更好地做好项目管理工作。技术骨干在担任项目经理之前,最好能经过系统的项目管理知识,特别是其中的人力资源管理、沟通管理的学习,并且在实际工作中不断提高自己的管理素

质,丰富项目管理经验,提高项目管理意识。

(4)沟通意识问题

在项目中一些重要信息没有进行充分和有效的沟通。在制定计划、意见反馈、情况通报、技术问题或成果等方面与相关人员的沟通不足,造成各做各事、重复劳动,甚至造成不必

要的损失;有些人没有每天定时收邮件的习惯,以至于无法及时接收最新的信息。

3.软件项目管理的现状分析

软件项目管理的提出是在20世纪70年代中期的美国，当时美国国防部专门研究了软件开发不能按时提交，预算超支和质量达不到用户要求的原因，结果发现70%的项目是因为管理不善引起的，而非技术原因。于是软件开发者开始逐渐重视起软件开发中的各项管理。到了20世纪90年代中期，软件研发项目管理不善的问题仍然存在。据美国软件工程实施现状的调查，软件研发的情况仍然很难预测，大约只有10%的项目能够在预定的费用

和进度下交付。

1995年，据统计，美国共取消了810亿美元的商业软件项目，其中31%的项目未做完就被取消，53%的软件项目进度通常要延长50%的时间，只有9%的软件项目能够及时

交付并且费用也控制在预算之内。

软件项目管理和其他的项目管理相比有相当的特殊性。首先，软件是纯知识产品，其开发进度和质量很难估计和度量，生产效率也难以预测和保证。其次，软件系统的复杂性也导致了开发过程中各种风险的难以预见和控制。Windows这样的操作系统有1500万行以上的代码，同时有数千个程序员在进行开发，项目经理都有上百个。这样庞大的系统如果没有

很好的管理，其软件质量是难以想象的。

4.我国软件项目管理的前景

应该很清楚地意识到，项目管理在中国起步较晚，项目管理水平与高速增长的经济建设不相适应，也不利于参与国际竞争，必须奋起直追，赶超国际先进水平。展望未来，我们

面临的不仅有广阔市场的大好机遇，还有必须认真对待的严峻挑战：

(1)、随着中国加入WTO，工程建设市场竞争时代的来临，加大项目管理力度势在必行。只有稳定提高实力，迅速熟悉并掌握国际规则，主动溶人贸易体系，不断加强竞争实

力和项目管理水平，才不会在激烈的市场竞争中失败。

(2)、随着中国宏观控制体制调整和市场经济改革的深化，工程公司、项目管理公司和工程咨询公司等企业必须进一步深化管理体制和运行机制改革，加快重组，与世界接轨，建立现代企业制度，才能成为自主经营、自担风险、自负盈亏和自我发展的良好经济实体，在

项目管理中提供高质量、有针对性、有竞争力的服务。

(3)、目前，中国建设市场在管理体制、法制建设、运行机制、中介服务、价格政策和社会习惯等方面仍有许多有待改进的工作要做。中国必须建立法制的、政府监督的、自我约

束的管理体系，建立公开、公平、公正的投资中介市场，加大投资中介服务的法律责任，为

工程咨询和项目管理创造更好的市场环境。

(4)、中国公司应该进一步加强与美国、欧洲和澳大利亚的国际项目管理机构和协会之间的合作与交流。充分利用理工大学和学院加强项目管理的理论与实践研究，建立自己的项目管理体系，引进和开发先进的项目管理软件系统，提高项目管理水平，为工程公司、项目

管理公司和工程咨询公司的发展提供更好的环境。

(5)、中国必须培养自己的优秀项目管理专业人员，大力提高项目管理水平。专业人才匮乏是影响中国项目管理快速发展的主要因素，中国应当把培训和建立一支优秀项目管理专业人员队伍作为战略任务来抓。中国项目管理人力资源结构必须通过国内国际相关培训和认

证机构以及项目管理实践来改进。

只有采取上述的措施，中国企业才能适应可持续发展要求并在激烈的市场竞争中立于不败之地。刚刚在9月1日，邦永科技于广东亚洲国际大酒店召开首届渠道峰会，被业内同行称之为“来势汹汹”。此会议共在全国招募了30多个地区总代理商，11月份正式启动市场。据了解，邦永的产品定位为中低端，价位在5万到40万元之间。邦永目前加紧平面营销渠道建设的同时，还在酝酿许多与行业主管部门的技术合作，似乎对打造国内项目管理行业标准胸有成竹。无怪乎邦永拿出这么大的举措：据资料显示，2002年中国政府拨3000亿元专款用于各类政策性项目，省、市地方政府捐助至少1000亿元的专款，全国每年至少有2000个新的1亿元以上的大中型项目。如果这些项目都采用软件来进行管理的话，市场非常可观。邦永对这个市场充满信心，尽管项目管理软件市场在中国仍然处于启动阶段，但市场已经很大，高中端市场的容量在一亿元以上，3-5年内将达到6亿元左右。这还是一个

比较保守的数字。

总而言之，软件项目管理领域仍然是一个比较新的领域，竞争态势还远未达到白热化的程度，但前景十分可观。需要不断的去开发与研讨，才能让软件充分的发挥在项目管理的领域，但在软件项目管理中，存在在的各种风险管理应该根据不同的因素而做出不同的解决措施，让项目管理可以发挥到一定的程度，使之更加的完善。最后感谢张冰峰老师一学期来

的教导。

第二篇：软件项目需求调研总结

一、需求调研准备：

在需求调研过程中，应该做好三种准备，保持两种心态，做到五种提高：

三种准备

1)调研前应该将所有项目前期资料进行汇总，与相关的前期销售人员进行交流，以便对项目有一个基本轮廓的认识。

2)做好调研前使用资料的准备，如需求调研模板，需求调研问题列表等。

3)做好不怕一切困难的准备。

两种心态

1)保持一种和客户平等合作的心态，确定需求调研是为了给客户解决问题，探讨问题，而不是接受问题，更不是来指导工作的。

2)平静面对需求变更的心态，在需求调研过程中，往往双方对需求理解不一致，造成需求调研前后矛盾，应当心平气和的去引导客户，达到需求理解基本一致。

三种提高

1)首先提高自己业务知识，对于人力资源的标准业务应该基本熟悉。

2)其次应该努力的去熟悉用户的行业，学习用户使用的术语，标准，以便能够准确的理解用户。这就需要我们阅读用户所在行业的资料、文章，尽量多选取一些整体性介绍的文章，这样可以在短时间内能够对该行业有一个全面的认识，这样我们就能够较好的和用户进行交流了。

3)需求调研中，学会尽量不使用IT行业的术语，而采用浅显易懂的口头语言来解释IT行业中高深莫测的术语，以便用户能够很好的理解，提高自己的沟通交流能力。

4)提高自己的速记能力，文字表述能力以及归纳，能迅速的记录需求调研核心的问题，总结归纳形成原始的需求调研资料。

5)提高自己的总结能力，书写一份完整的、前后一致的、可追踪的需求报告。

二、需求调研过程的总体流程

需求调研中应遵循一定的流程，而且在调研过程中表现出规范，调研有条不紊，对客户有理有据，调研中资料做好备份，做到有备无患：

三、需求调研过程中注意问题

四、需求报告书写要求及标准

编写优秀的需求是没有公式化的方法的。这需要大量的经验，要从你在过去的文档中发现的问题学习。请在组织软件需求文档时，严格遵从这些方针。

句子和段落要简练。使用正确的语法，拼写，标点。使用术语，要保持一致性，并在术语表或数据字典中定义它们需求编写者还要努力正确地把握粒度。多个需求尽可能拆分开。

整个需求文档细节上要保持一致。

避免在需求报告中过多的申述需求。在多处包含相同的需求可以使文档更易于阅读，但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新，避免不一致性。

需求调研对于系统的构造，系统测试以及最后的客户满意，都会成为好的奠基石。并且要记住，没有高质量的需求，软件就象一盒巧克力，你永远不知道你会得到什么。我希望我们能得到一块“德芙”。

调研概要情况：X项目需求调研开始于2006-3-23结束于2006-6-15，内容包括现场需求调研4个人月和分析需求编写需求文档6个人月。参与调研的包括项目经理、技术经理和两个开发骨干，编写需求规格说明书字数95.4万。

1.把二期项目当作一个新项目来做调研，避免需求细节遗漏。在调研的初期我们曾经有过疑虑，这是一个二期的项目，那么调研的内容是否只针对二期的新需求，对需求内容二期和一期一致的部分就不必调研了?

经过讨论我们还是决定把二期项目当作一个新项目来做调研，即使二期和一期需求内容一致，我们也在调研会上讨论，并记录在调研笔记及以后的需求文档上。这样的好处是最大限度地避免了需求细节的遗漏。在现场调研时，发现有不少地方原来以为是二期不必修改的，经过讨论后发现还是需要修改。(往往危险的需求描述就在于“这部分做的和某个系统或某个版本的旧系统一样就可以了”)

2.调研团队参加所有子系统的调研会议，可以相互补充避免需求遗漏。这个项目规模比较大，根据业务的类型不同，分成了6个子系统，各个子系统的业务信息互有接口。我们安排每个人至少负责一个子系统的需求，但是在调研时，只要可能，我们都尽量让每个人都参与所有系统的调研会议。对项目经理和技术经理则进一步要求了解所有系统的业务需求。这样做的好处是，对于子系统之间的业务关系，调研团队都可以有全面的了解，对业务的理解比较透彻全面，并且还可以相互补充遗漏。

3.多人调研，在会议后应该立刻回顾整理统一的会议笔记，消除歧义，避免遗漏。在开调研会时，全体与会人员都各自记自己的会议笔记，会后没有强调当天整理会议笔记(会议进度很紧，每天开会到晚上

8、9点钟)。这导致以后阅读会议笔记发现一些描述很简单理解上有歧义的内容，或者同一份需求在几个笔记上记录的内容细节上有差异，事后难以追溯正确的信息。给编写需求文档带来了一些困难，需要再次讨论需求。

4.需求文档编写完成后，在开发阶段也应该做检查和更新，避免文档错误对开发的误导。我们在完成大量的需求文档编写工作后，在开发阶段有部分文档没有做内容检查和及时更新。后期测试时才发现少数需求内容的矛盾和错误，导致需要重新修改。

建议：

1、如果在编写需求文档后，开发阶段应该做一边阅读需求文档，一边做需求文档的检查，对于保证需求质量效果会更好。

2、应该指定人负责需求追踪和更新，在开发阶段、测试阶段要保持和用户的需求沟通，这不是一个可有可无的简单工作，很重要，并且会占用责任人50%的工作时间。

3、企业业务管理信息系统的需求调研方法：我认为对调研的组织安排是非常重要的，好的调研安排虽然未必产生质量高的需求，但是一个不遵循调研规律的调研活动，必然是低效的。下面是H项目调研组采取的调研流程，供参考：

4、第一步不是立刻和用户当面讨论需求细节，而是要业务关键用户编写初步的需求报告，提供给开发团队阅读分析。需求报告的内容是，对业务流程的描述，对业务需求的描述。需求报告的质量往往和关键用户的投入多少有较大关系，经常在没有面对面沟通时，关键用户未必能对这份报告投入很多的时间和精力。但这是当面调研的基础，一定要做，有粗糙疏漏的地方可以再现场调研时再细化。这可以再调研前就和用户沟通，让用户编写。

第三篇：软件系统项目总结

XXXXXXXXXXX项目

项目总结

XXXXXXX科技有限公司

2016年6月

我公司自2016年3月3日与XXXXXXXX签订了《XXXXXXXXXXXX项目》的合同，严格按照合同要求与约定来执行合同，在甲方单位及监理单位的大力帮助下，通过近四个月的项目沟通与实践，已进入项目验收阶段，现在就此次项目作出如下总结：

1、项目开工阶段。

我公司在监理单位下达开工令后，编制了符合现项目状况的施工组织方案及项目实施计划，并按计划执行项目。

2、需求调研阶段。

由于此项目属于软件项目，我公司对甲方及使用方进行充分的需求调研，确认了甲方及使用方对项目的具体需求，力求全面的收集并理解甲方及使用方的需求，并完美的完成项目建设。

3、详细设计阶段。

在需求调研的基础上，我公司进行软件系统的详细设计。在详细设计中，描述实现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系，需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑，以便进行编码和测试。应当保证软件的需求完全分配给整个软件。

4、系统测试阶段。 我方对软件系统进行了模块测试和整体联调;也测试了正常操作情况测试和异常情况测试;按并进行了全覆盖测试和抽样测试。我方会在软件的后续使用中不停的跟踪软件的运营状况并持续修补升级，直到这个软件被彻底淘汰为止。

5、系统试运行。

自试运行开始以后，我方及时对系统中出现的问题进行解决，对用户使用中提出的对功能的使用及更改需求进行完善。按照合同经过为期一个月的试运行，进入正式的系统运行阶段。

6、系统培训阶段。

为了让用户能更好的管理和使用系统，我们针对所有的系统进行了系统的专业的培训，以确保用户可以在最短的时间内熟练的使用系统，确保系统高效的运行。

为了更好的保障整个项目中各个系统的正常运行，我们将在以下方面做好服务：

甲方在软件使用过程中如发生故障或遇到疑难问题，乙方提供有效支持，保证30分钟响应，4小时内派人赶到现场，一般故障1天内修复，重大故障7天内解决。对所提供的软件实行6个月定期进行一次维护。

我公司非常荣幸参加XXXXXXX项目的建设工作，我们以最大努力完成XXXXXXX项目建设要求，我们将严格按照合同要求执行各个系统的维护和服务承诺，为XXXXX(建设方)美好的明天贡献我方一份微薄的力量。

项目负责人：

承建单位：XXXXXXX科技有限公司 时间：

年

月

日

第四篇：学习软件项目管理总结

学习软件项目管理和制作时光网上商城系统总结

这学期通过宋老师讲授软件项目管理这门课程，自己学到了很多东西。最初在单位做设计是一个盲目的过程，无计划、无框架设计，拿来需求大家把模块分摊，就开始埋头写代码，总认为设计代码是最重要的事情，但是经过几次尝试，每次做出的东西不是很理想，自己也不知道原因为什么会不理想呢，自己做的东西是按领导拿来的需求书上的要求做的，可为什么用户不满意呢。

通过学习软件项目管理这门课程后，我知道我们做开发失败的问题了。我自己总结了几点：

一、项目接到手，没有根据软件项目开发的流程进行分析、设计。

二、项目需求说明书、概要设计说明书、可行性报告、详细说明书、数据库设计说明书、软件详细设计说明书，测试报告这些文档东西应该是在设计过程中产生的，但我们工作中都是软件做完了，为了项目的验收急急忙忙赶制出来的。这些说明书已经失去了他们的意义。

三、人员的配合、管理也是很重要的。我们单位中领导就是项目经理，但是这个项目经理没有达标，有项目了他带领大家开会讨论，在会议上就把此项目的可行性和工作分工就安排好了。会下大家就埋头写代码，大家之间的交流也很少，直到模块要合并时，出现问题了大家才把自己的设计理念讲一下，再修改再合并。后期的修改合并工作是一个最费时的事情，把设计中的大多时间花在了这里，如果大家在最初按照流程走，定期交流，项目经理监控、督促就不会出现这样的事情。

四、做项目每个人员的态度认真也是很重要的。自己习惯了大企业中的慢生

活，我们开发软件都是快到项目验收了，才加班加点的工作，这样怎么能做出好软件呢。

宋老师还给我们布置了项目开发作业。我们小组设计了“时光网上商城系统” 我这次所经历的项目更让我明确了这点。在这个小项目里，虽然我们一个月完成了这个软件设计，但存在很多问题。“时光网上商城系统”包括9个模块，我在这个项目里，我参与了概要设计、详细设计、软件测试文档的编辑和会员管理模块、商品展示模块的设计。这两个模块的设计对于自己来说没有什么问题，因为在单位就是做这个的，但是在前期的概要设计说明和详细设计说明对自己有点困难，因为以前没有这样做过，没有什么设计框架，这时自己拿出宋老师讲的笔记和图书进行学习，再和队友交流，终于有了自己的框架。所以、在这个过程中我明确了技术的实在意义，明确了项目管理对我的指导，同时也明确了自己的今后项目开发应该怎样做。

整个项目进行的过程中，我一直在边学习边制作，每周与其他同学定时交流，整个过程我收获很多。

一、项目小组人员都职责明确，每周定时交流沟通工作进度，随时更新方便开发人员、测试人员之间的交流。

二、细致的计划可以让项目进行避免弯路。

三、项目经理时光的组织、督促和监督，小组人员的齐心，这个项目才顺利能完成。

四、这个项目制作把绕老师和陈老师讲的内容也都应用在初期系统构建和中期、后期的软件测试中。

五、通过学习认真分清了软件管理与软件工程的关系和项目管理知识体系。

通过本学期的学习，我感受到软件项目管理是一门非常需要学习的课程。我们所做的虽然是个小项目，但是在小组共同开发的时候还是需要用到项目的管理。如人员分配、时间、进度的计划、沟通计划、项目执行变更管理，以及质量管理控制等多种管理。自己对这门课程学到不是很好，但我相信在今后的工作中，能够更好的体验和感受项目管理的精髓，对软件项目管理有更深入的了解。

第五篇：软件项目投标问题总结

投标工作总结(经典)

在岳总的领导下，我有幸参与了此次招标的组织与协调工作，现总结如下：

一、工作问题

1、围标单位的标书出现了内容(技术人员的信息、资料等)遗漏问题，险些造成废标事件。

2、在标书准备的前阶段，没有静心研究招标文件，致使受到了岳总的批评指正。

3、行贿证明申请函的日期由于粗心差点造成错误。(将2010误写成2013)

4、报价文件中的单位(“万元”问题)出现了纰漏。

5、标书的检查工作不到位，导致胶印工作的返工，降低了效率。

二、工作总结

1、标书的文字准备工作需要特别细心，不能出一点差错，一旦出差错，返工既浪费时间又会使事情变的更繁杂，直接影响后面标书的质量和效率。这要求参与人：

(1)仔细研究招标文件，才能做到心中有数。

(2)严卡招标文件，按照招标文件要求进行筹备工作。 (3)响应评分标准，像考试一样力争获得最高分数。

(4)报价文件中的单位要谨慎对待。“元”“万元”的细节处要小心对待。 (5)页码的细节问题。

2、标书的检查、打印、胶印、签字、盖章、封装等流程中，检查变得尤为重要，否则的话会造成返工，甚至误工。

3、一个人不能同时兼顾两家单位的投标文件，否则容易出现问题。

4、指定人员要完全包干到人，包括：围标单位的对接、标书的文字准备、检查、胶印、盖章等工作，能够减少错误的发生。

5、确保每一位参与人都要细读招标文件。

6、项目演示环节建议提前进行演练，确保时间的合理性。

2013年11月12日

第六篇：软件系统项目实施总结

XXX医院HIS系统项目总结

2012年12月27日，我完成了HIS人生第一个独立实施的项目——XXX医院项目(ZLHIS标准版、医保接口)。医院有在2个住院科室，床位100，住院人数保持在50人左右，门诊诊室有7个，医生总数为9人，护士6人，收费室2人，西药房2人，中药房2人(不使用HIS系统)，院长2人。就项目规模而言，这是一个袖珍型项目，其特点可用“麻雀虽小，五脏俱全”来描述。过程辛酸不赘述，在此总结项目实施过程中出现的几点问题，希望能起一些警示、提示的作用。

TIP1：实施计划的制定，要双方均可接受，要具有一定可执行性

本次项目实施中，培训工作进行的过程与培训计划中的预计安排出入较大，原因就在于没有充分与院方人员沟通，安排的合理性及认可度都没有得到保证。

实施计划的制定，不应该是“一厢情愿”式的空想。项目实施是一个关系到多方人员配合完成的任务，因此在制定何时、何地需要何人配合完成何任务的计划时，要考虑到各个因素条件是否允许，就需要各方负责人在场商榷，得出一个都可以接受并且具有一定可执行性的方案计划。

应对措施：在以后的方案制定前与院方沟通，得出合适自己实施的方案提供给院方，然后确定实施方案。

TIP2：按计划执行

本次项目实施中，实施任务实际执行时间与计划时间偏差较大，主要存在以下几个原因：A.认为项目时间充足，不按照计划执行也可完成项目实施，失去紧迫感;B.前期工作出现纰漏或未完成，导致该部分工作延后。

实施计划的重要意义之一，就是为了让工作的进度有一个明确的参照物，为项目实施做出指引，从而更好的完成项目任务;既然有了实施计划，却又不尽量严格按计划来执行，对实施计划的意义和产生实施计划所消耗的人力物力都是极大的浪费，是对项目和自己不负责任的态度。B情况下，第一应对策略不一定是以破坏后期实施计划为代价的延期;如果情况确实不允许，也应该拿出与院方达成一致意见的方案来积极控制，而不是简单的往后拖延。

应对措施：A、时刻保持紧迫感，我正在经历的，是我一生最有精力的年代，任何不尽100%努力的态度都是对自己最好时光的浪费，是对自己的不负责任;B、尽力保证实施的过程按计划进行，向小组长及主任报告进度情况，在可能出现较大偏差前作出调整。

TIP3：养成良好习惯，有效使用测试库

本次项目实施中，在后台进行流程测试及报表修改等过程时，均大量使用到测试库;但在测试库中已经得到验证和校正的相关设置及修改等没有及时、有效的被移植到正式库中，导致项目启用后出现一些前期已经注意并处理过的问题，院方也觉得已经提出却没有得到解决，对实施人员信任度及对公司的认可度都会大打折扣。主要原因在于我没有养成良好习惯，对问题在测试库中处理没有及时移植到正式库中。 测试库的重要意义之一，就是为正式库提供一个验证及校正环境，使用测试库得出一些结果而没有应用到正式库中，这不仅仅对在测试库中进行工作的质量大打折扣，更是项目实施进度推进及实施质量的损失。

应对措施：时刻注意测试库的信息与正式库的同步，在测试库中作出的验证与调整作出记录并移植到正式库中。

TIP4：支持文档的及时提供与通知

本次项目实施中，培训计划的通知及启用前注意事项的通知等，都有消息传达滞后的现象;这些都降低了项目实施的质量及实施效率。培训工作开展的当天，才通知相关培训人员，导致很多培训人员不能及时调整工作安排，降低了培训质量;启用第二天将一些注意事项及说明文件发送到相关人员手中，其中有较多已经预见可能出现的问题其实已经在第一天出现并耗费了时间去处理，如果启用前提供并得到强调可能启用时出现的问题量及问题处理的及时性都会大有改观。

项目实施需要较多文档支持，包括需要通知相关人员的文件及对某些情况进行说明、强调的文档等，例如通知初始化人员初始化工作的时间及方式，培训工作的时间、地点和人物，启用注意事项，操作文档等。为项目实施服务，需要实施人员在实施过程中提前做好准备(部分需要打印)并与相关关系人进行沟通做出有效及时的相关动作。

应对措施：实施过程中，提前提供：应用流程说明、收费操作文档、医保操作注意事项、启用注意事项、其他情况说明等文件，提前打印出来分发并强调相关人员关注学习。

TIP5：培训环境的建立

本次项目实施中，在第二周就落实了培训需要的电脑及网络环境的建立，但在前期培训过程中讲解及练习环节都是临场才添加的需要使用到的数据，例如为护士讲解如何记账操作时发现没有在院病人;因此培训期间的时间有效利用率受了较大影响。主要原因在于对培训环境的理解不全面导致准备不充分，没有提前考虑周全。

培训环境的建立，远远不止电脑等硬件的购置及网络环境的搭建，更重要的是软环境的建立。培训过程中的讲解及操作练习都需要实际数据才能进行，因此需要提前准备好培训要使用到的数据及参数设置。

应对措施：凡事预则立，不预则废。培训前考虑可能使用到的数据环境，提前在培训使用的数据库中准备好数据。

TIP6：启用前的重要准备及测试

本次项目实施在启用时，由于对产品不熟悉及对需要进行的准备工作没有足够的意识，导致在启用当天门诊收费后没有发票打印出来，启用前仅在测试库中进行了测试而没有在收费室进行打印机关联及设置等，且没有进行实际打印的测试。虽然当时医院旧系统仍然在使用，没有对医院业务运营造成重大损失，但是这个错误在我心中的印象是非常深刻的。

系统启用是项目实施中的关键性事务，关系到项目里程碑进展及医院业务开展，其重要性不言而喻。因此在，系统启用前需要做好充分的准备工作，例如：A.流程测试，B.票据打印测试，C.登陆账号、权限分配审核，D.重要基础参数设置的检查(例如药品库存检查、票据严格管理)。

应对措施：启用前，必须在正式库中测试门诊与住院收费单据打印、预交款单据打印，一日清单打印等，检查全局参数设置、收费室药房等本地参数情况。

TIP7：与院方的沟通方式

本次项目实施中，有两次与院方的沟通效果不好。一次是用于不当，与一位院长沟通的时候说了：“这个功能，那些大医院可能用的更多……”该院长当即表态“那如果我就是要用这个功能呢?”我明显感觉到院长的防御姿态瞬间提升，沟通进入尴尬境地;第二次是我非常直接的询问院方财务管理人员(每日收费结存人员)是谁，院长没有回答。

对于院方内部事务，特别是涉及内容较为敏感时，可以通过其他渠道了解;对于一些可能损伤院方自尊心的事务，尽量采用委婉或者隐晦的用词进行沟通。沟通始终要注意在合适的时间找对合适的人、使用恰当的词句及方式;否则不仅达不到沟通效果，还影响与院方的关系及项目实施工作的开展。

应对措施：学习卡耐基《说话的艺术》，在接下来项目中注意沟通方式及时间、频率。

TIP8：抓住关键性事务

本次项目实施中，一开始我认为初始化是项目实施中最重要的工作，因此一直在进行初始化数据的准备及对初始化人员的培训;后来在启用前一周才开始关注医保接口实施的具体方法步骤，然后让初始化人员又对收费项目进行医保对码，引起了初始化人员的强烈不满，认为初始化工作没有一次性结束;如果将收费项目的建立与医保对码放到一起进行，可能不会引起不满，而且条件是允许的，初始化数据的录入与医保接口实施并非逻辑先后关系。医保接口实施及医保刷卡测试的速度都相当慢，在启用前一天才完成所有测试。

经过这个项目，我认为该项目中除药品库存、费用流程至关重要，最重要的是医保刷卡功能的正常使用，因为该医院患者中绝大部分为医保病人，这是医院收入的主要支撑部分，医院安装新系统的主要目的就是为了解决原系统不能正常使用医保刷卡功能这一重大问题。

应对措施：时刻与同事、上级保持沟通，得到经验上的指导;项目实施方案中进行体现。

TIP9：项目外事务与项目的协调

本次项目实施中两次被综合部人员协调到另外一个医院处理“光纤交换机”事宜，两次都没有完成计划的任务，并且减少了自己在建项目的实际工作日，对公司的形象也产生了不好的影响。我方主要原因是：A.未得到关于该事务的足够信息;B.未判断清楚任务是否具备完成条件。

经过此事，我认为在涉及影响自己在建项目进展而被协调处理其他事务前，首先需要考虑的是是否会对在建项目的进度产生不良影响，其次是该任务是否能够正常进行并达成计划的结果;否则浪费时间不说，还不能达成结果。

应对措施：应答前，将被协调事务了解清楚，审核是否具备任务达成的条件。 问题诸多，不一一列出。

签完验收，一直期待的兴奋感并没有像我想象的那样从头顶瞬间灌注到脚底，而是一种难过的感觉隐隐在心中升起。系统使用存在的诸多问题，以及在这个项目过程中，学习到的东西都并非我期待的那样得到实现，对自己学习摸索的方式以及效率，对项目进度的把控能力都让自己感到失望。

第一个项目是做完了，但是我明白不管是从熟悉产品、学习业务、技术知识、项目管理等任何一个方面，我的HIS人生都才刚刚开始。