唐山医疗责任险项目是医疗项目组自2013年初从外包人员接手运维后第一个独立开发的地市级医疗责任险。在此之前医疗项目组完成了许多其他地市医疗责任险的各类需求变更。医疗项目组通过完成这些需求变更，锻炼了人员，了解业务熟悉了代码。这些为唐三医疗责任险的实现提供了良好的前提。

 

唐山医疗从十一月十五号正式立项。并且由于业务开展的需要，该项目的截止时间是基本确定的。需要在十二月就能够支持出单和业务结算工作以给业务的开展提供支持。该项目可以定位为一个时间紧，需求不是特别明朗的项目。因此在开展项目开发的初期就基本跟项目组成员确立了滚动式交付，迭代开发的模式。同时在分析需求的过程当中，除了流程性或者是页面调整性的不确定的需求，其他的需求任务在还不是特别明确的情况就开始了开发工作。由于流程性和页面调整类的需求，在不确定的情况下开发会带来后续过大的调整，而页面调整性的需求，在前期不确定的情况下开发到后续还是需要调整，属于浪费资源。而一旦排除了这俩类的需求。尤其是流程性需求确立下来了之后。90%的工作都是可以开展的。因此，虽然需求在很多细节还不完善的情况下，医疗项目组就开始进入设计和开发工作。为后续的测试和开工作赢得了时间。

 

医疗项目在今天已经正式上线。虽然比预计的上线时间晚了一个工作日。但还是得到了业务人员的认可。该项目的顺利上线为医疗项目组以后开发其他类似的地市级医疗责任险，积累了经验。该项目产出的上线脚本，开发功能点，工作量估算，实现方式等对后续的工作开展有很大的借鉴意义。下面是我对于本次唐山医疗责任险的一些总结。

 

 

1.项目成功的因素、

a) 领导重视：在项目的初期，部门领导就提前认识到该项目的时间紧迫，并且充分考虑了医疗项目组没有开展地市级医疗责任险的经验。通过从其他项目组借调人员，确保唐山医疗项目的人力充足。

b) 激励机制：在项目的开始，部门领导就已经为本次的医疗项目的开展争取了利益，这在人员鼓励上面起到一个良好的效果。使得后续项目开展过程当中，人员相比较而言更加有干劲。

c) 在部门领导参与的情况下，开展了开踢会议。虽然该会议非常短暂，也不够正式，但从后续项目的真个开展来看，该会议起到了非常重要的作用。第一，使得项目组成员都对该项目有了正确的认识，树立了一个非常明确的目标。第二，在该项目当中给出了几个基本的里程碑。这在后续我们项目计划没有发布的情况下，成为了项目组成员一致的认识。就是这个里程碑让我们的项目时间没有过多的偏离。

d) 对于项目比较重要的保费计算上，需求和业务人员在项目的初期就开展了保费计算释疑会议。并且很快就给出了保费计算方面的需求文档。对于保费计算项目组给予了足够的重视，没有盲目的开展保费计算的程序编写，而是通过充分的分析需求，对保费计算的设计做了充分的讨论。并决定不采用系统原有的保费设计模块。绕开了系统原来保费计算的负责度。

e) 开发的初期把一些显而易见的配置信息，在开踢会议之前就已经完成。比如说产品信息，产品承保信息，用户账号的配置等。这些基本信息的提前配置为项目组成员开展后续工作扫清了障碍。这些信息虽然都是不确定的，但其对应关系是不会变化的。而没有这部分的信息，开发人员就无法顺利的开展开发工作。因此把这些工作做在开踢会议之前，给予开发人员一个已经清楚的基础的开发环境，使得开发人员可以直接进入设计开发阶段。而不会存在卡壳的坏心情当中。

f) 由于在唐山需求之前刚刚开展了湖南解付结算变更需求的开发和测试工作，而本次的唐山地区的医疗责任险的结算，就完全借用了湖南地区的解付和结算。因此在结算这个相对复杂的功能上面，没有花费过多的人力。这应该是医疗项目组的好运气吧

g) 在投保模块开发刚进入开发阶段，提前就跟业务人员提出了投保单格式的确认等问题，使得在确定需求和不确定需求的衔接上面，做到了一个还算可以的连接。没有出现太多的等待业务人员确认的情况。从而使得项目组成员的工作时间得到充分的利用

h) 项目组成员距离非常近，使得沟通变的简单而高效。这种紧密矩阵为此类问询式的管理提供了非常便利的条件

i) 本次项目组团队的共同努力。

2.项目中暴露出来的问题

a) 虽然使用了迭代式交付的开发方式，但是没有明确的良好的制度来实施。项目管理反面处于基本的问询时的管理方式。该方式低效而过于依赖项目经理。汇报式的工作只通过周报的方式体现。没有良好的办法实施的了解项目组成员的工作情况，心理情况。

b) 没有较好的文档支撑。设计上也好，项目计划也好。都没有形成具体的文档。也就是没有给未来的项目管理工作提供比较好的记录工作。为未来的人员更替，带来了带来风险，组织过程资产没有增加。

c) 需求开发不够细致，后续的需求变更没有得到有效的管理，导致在后续测试人员的测试，bug修改上面都有了多余的沟通成本。有一些开发人员知道，需求人员知道的决议没有通知到测试人员。而测试人员在提交bug后。开发人员要么修改要么又得去跟需求商议。

d) 没有一个统一的全的项目计划。使得项目组成员在后续的部分时间里面有无所适从的状态产生。开发人员不知道哪些事情是紧急的，哪些事情是需要提前提交的。尤其是影响到测试人员的测试用例的编写时间。由于测试人员在后期才真正进去到项目当中，但没有统一的项目计划。在编写测试用例工作上没有提前，而是在开发人员已经开始交付版本的情况下，紧急开展用例的编写工作。使得测试工作略有滞后。同时由于没有一个统一的计划。在工作安排上面也没有做到合理。而是尽可能的往前赶，导致唐山医疗责任险项目在开展过程中做了一些无谓的加班。相信如果有项目计划，把时间和资源安排的更加合理。这些加班都是没有必要的。

e) 由于目前新开展的地市级医疗责任险项目都是基于原来的框架和代码上进行优化开发，但在开发过程当中。有部分需求和当前代码是不吻合的。比如，保险公司保费确认在其他地市该功能于保单关联功能没有一个先后关系，而本次要求是必须在保险公司确认保费以后才允许保单关联。此类的需求和历史代码不吻合，而功能又极为相似。给开发工作带来了比较大的困扰。当然此类问题不止此一个。在注册的校验，邮件的发送等地方都有存在。

f) 对于保费计算的设计还是不够细致。我们虽然详细的讨论了表结构，关系，如何存储取值。但最后阶段才发现，开发人员并没有把保费计算最终计算的因子取值存储到数据库中。产生该问题的原因是，开发人员对于系统的认识还是不够。该因子的存储一是有利于以后保费的追查。而是在系统对接的时候与保险公司核对保费。而开发人员由于对该部分的不了解。认为存储该问题是没有意义的。因此采取了不存储的决定。此问题到项目的后期才暴露出来。风险相对还是比较大的。

g) 问询式管理具有比较大的弊端。首先是低效，其次是容易引发项目组员冲突，因为没有计划的指导，使得项目成员对于目标没有统一的认识。。

3.后续工作建议

a) 尽快完善公司的项目管理方法和项目实施方法。从制度给予项目经理支持。这样在有利于项目经理开展工作的同时，也可以检验公司的软件实施方法，使得项目的成功不在仅仅处于个例而是归根于组织的实施方法和制度。

b) 项目计划制定要及早做，并及早做广泛的讨论。让项目成员通过参与项目计划的制定。一是有更好的参与感，另外一个是目标感更前，而且对于团队作战能力也有所提升。

c) 重视需求工作，需求处于软件开发的上游，需求上面的不严谨就是为后续的项目工作埋下定时炸弹，而且该炸弹一定会爆炸。建立良好的需求变更管理。变更通知到所有项目干系人。提倡拥抱需求变更，但要更加严格的管理需求变更过程。

d) 注重于业务人员的紧密结合。重点在于推动业务人员对于软件开发必须工件的提交。通过了解业务开展，深入理解业务人员的做法，和心态。只有了解才有认同。通过了解业务的开展情况，业务人员的切实困难，才能更好的预测业务人员对于某些必备输入的时间点。知晓这些能够为我们的后续工作带来一些指导。同时由于业务人员是需求提出方。让需求提出方更加了解我们的开发工作。知晓我们的里程碑，有利于业务人员安排后续的培训，上线，验收事宜。

开展更多的团队活动，争强团队建设，让团队更加具有战斗力