软件项目实施总结

1软件项目实施总结

1、项目组组建

1、1多方项目组成员

给出多方项目组成员组成。很多吃过亏的客户，在搭建项目组的时候，甚至在招标书的时候，要求软件公司的项目组里面必须有项目管理专业人员，甚至持有pmp证书，或者有专业的需求分析人员，并持有系统分析证书。

1、2多方项目小组成员的稳定性

多方项目小组成员的稳定性。人员流动通知对方，申请多方认可。特别是相关负

责人流动，需要多方确认。

2、实施的进度日程表

给出系统上线日程表

3、软件模块实施的先后顺序

先上哪些模块，后上哪些模块。新系统和老系统并行运行的机制处理方式。历史数据的处理方式。

4、进入新系统的数据截断日期。

5、实施中多方会晤机制

定期会晤机制？1周几次？还是每几天1次，每天1次？

6、监理方的立场说明

监理方代表的是甲方的利益，出现冲突的时候应该从维护甲方利益出发，考虑问题。

7、问题诊断机制

实施出现问题时候，监理方应该要协助甲方诊断问题的类别，是来自于硬件提供商，

还是软件提供商，还是甲方的问题。如果不能诊断，应该主持召开多方会议确认问题的来源，类别。

8、问题的响应速度要求

当问题被诊断后，应该要求问题解决的时间，要求相关单位在规定时间内解决。如果问题不能在指定时间内解决，应该要考虑补救措施。

9、需求变更处理

当甲方提出需求变更后，监理方应该作出判断，这个需求是否合理，是否超出了实施前制定的需求基线，如果超出了需求基线，就有可能需要追加预算了。

当然软件需求变更存在一个工作量的问题，如果工作量较小，就不存在甲方追加预算。一般的项目实施都是有1个需求基线，然后免费的需求变更工作量有1个上限，当需求变更的工作量超出这个上限，就需要甲方追加成本了。

10、甲方2次开发的难度控制

当在设计甲方业务处理流程的时候，应该要考虑到甲方业务流程更改后，系统的可配置性。这1点也是j2ee的主要特点体现。当然，如果系统使用了工作流产品的话，可以从工作流角度来考虑解决。

11、财务核算处理方式的灵活能力

一般的企业单位，财务核算的方式是比较固定的，但是也会作变动，当这一块作出变动时候，应该要求软件系统能够比较好的能够实现。

例如：软件系统以前实行的是集中财务管理，后来改变成为半集中方式，或者分散方式。这写都要秋软件系统能够很好的实现能够很好的进行业务处理方式的平滑过渡。

12、甲方业务流程的整理

监理方作为甲方利益代表，应该和甲方一起协助亿方指定出甲方的业务相关流程，在甲方乙方有争论的地方进行协调，并且在流程指定时候应该就要考虑到流程的更改。监理方当然最好能够先帮助甲方进行流程改那就更好了。或者乙方能够提供工作流工具就好了，否则这部分工作会暂用监理方相当多的时间。另外需求搜集变更也会监理方需要高度关注的一件事情。

2软件系统项目实施总结

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

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

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

3软件项目实施经验总结

实施人员可以不懂编程么？可以，如果不担心项目进度受影响的话。

让项目最快的完成有一个最好的办法：项目实施过程中有一个好的销售人员，有一个好的开发人员，同时有一个好的实施人员，并且这三者是一个人。恩，真希望上帝能找个这样的人来。

理想情况只是用来想的，针对理想情况的进度安排大多是用来看的，非技术的东西也只是用来说的。

最好的办法不见得是最终用到的办法，绕些弯路反而有时会更早的达成目的，这一点在实施过程中常有体现。

软件系统的实施是一个看似简单实则复杂的过程，在一点点不易察觉的过程中，一天、半天的延后，最后会导致项目比预期时间晚半年、一年都是很有可能的。

客户不总是诚实的，售前也有可能被假象所迷惑，只有实施时才会发现真正的妖魔鬼怪，躲不开、避不过，实施的人要把自己当孙行者，有土生土长的妖怪可以一棒打死，有后台的妖怪只能寻找其真正的主人将其降伏。问题不总是那么严重，也不总是那么乐观，看不清事物的本质，就会迷失。

当实施中遇到技术问题，一般的常规解决办法都是寻求技术上的帮助，技术人员通常会给出一个解决方案，但请放心这仅仅是个开始，这世界唯一不变的就是变化，当需求分析不够深入，当解决方案不成熟，还有只要是软件就会存在BUG这个真理的影响，常会出现解决一个老问题，出现一个新问题的情况，这会延长项目实施周期，并对客户产生不好的影响，比不解决问题更甚，所以每次提出需求务必请实施人员尽量全盘考虑，每次对程序的改动都要慎之又慎，提前想好退路。

有项目了，有项目了。

做项目就像是人生，人生中的每件事都可以用项目管理的眼光去看。恩，上面这句话是不是有人听烦了？我们把词换一下，换成产品“做产品就像是做人，每个人最好的产品就是自己。”有没有点名人名言的感觉？我们可以把这个词换成“游戏”、“梦”……，好吧，我承认我小学语文学的还不错，会造句知道举一反三。

造句比赛结束，我们回到现实中来。我们会陆续发现每一个项目比想象中相似，每一个项目又都和预期有所不同。

寻求共性，如何在现有软件基础上解决客户化的需求是我们经常要考虑的问题。我认为项目经理在现场容易犯的一个错误就是：当客户提出需求后，满口答应，不假思索的就马上去动手写程序实现。我们是项目经理啊，我们不是孙子好吗？好吧，语气过了，我承认装孙子有时也挺好。

我认为正确的思路是，当客户提出需求，首先应该考虑这个需求要解决什么问题？这个问题是否能够称之为“问题”？在不改动代码的情况下是否有其他的方式、方法去解决这个问题。实际上项目经理想的最多的问题可能就是如何去拒绝客户的需求，其次才是详细的需求分析。

当客户的想法、需求、要求、欲望是合理的，项目经理应该要想出更加合理的说辞拒绝掉。理由只有一个，因为实现会影响项目的实施进度。这就是我所理解的为什么听话的人做项目慢，不听话的人做项目快的道理。

通常客户到最后才会明白的道理，我们在项目开始时就知道了，但是我们没有办法在项目之初就按实际的情况讲给客户听，因为客户不相信。能当项目经理的人应该都不是第一次做类似的项目，经验就是在此发挥作用，“如何尽量合理的拒绝掉用户的需求并且不影响项目验收和与客户的关系”。

在实施过程中应学会分清主要矛盾和次要矛盾，尽量避免为无足轻重的小事所耽搁。

说了这些，我得承认实际上我还没说到重点，这些小事总是耽误我的思路。

每个人都有自己做事风格，尤其在实施项目时更会把自己的做事方法发挥的淋漓尽致。

每个客户的人也不同，这就意味着用同样的做事方法在不同的客户面前有可能行不通，怎么办？凉拌吧。这也是很多简单问题变得复杂的根源所在，这也是中餐很难做成快餐的原因。

人性本善，还是人性本恶？真的不知道。通常在做选择题的时候我们最终面对的是一个哲学问题，实在很无解。

归根结底，我认为在实施过程中对项目实施周期的影响，人的因素要比技术因素大很多，尽量去认真对待人的问题吧。