浅谈软件项目验收（转）

谈到验收，相信很多实施同事都是一个头两个大，觉得项目最麻烦的工作莫过于此，尽量模糊化，规避正式的验收。

客户场景A：

我们要推广的是8个公司，不是8个项目，你们都还没做完，怎么就能验收了呢？

客户场景B：

我们试点上线以后又提出了一些优化需求，你们给我们处理完了，再给你们试点验收吧？

客户场景C：

这个验收报告不能只是我签字啊，还有我们试点项目的用户和集团相关业务部门的老总都要签字的，让他们也看看评估下吧。

客户场景D：

工作流你们前期调研了吗，文档都没有啊，流程都没有稳定固化下来，怎么就能验收了呢？

客户场景E：

没错，你们的工作是做完了，可是我们现在通过系统什么都还看不到，不好跟老板交代啊，怎么给你们验收呢？

大家在看到上面几个场景的时候是不是有种似曾相识的感觉？作为实施人员，我们是否需要好好的思考一下，为什么客户验收难？找到问题的原因后，才能在后续的工作中有效的改进规避，不再陷入项目验收的泥沼。

1、项目目标及范围不清晰：

项目一启动就急忙开展了业务调研工作，对于项目的目标与范围未能与客户做清晰界定。实施过程中也没有进行确认，导致后期双方理解差异，产生争议。这也是很多同事不关注不重视实施任务书的结果，直接模板套用，前期风险评估不足，任务书也就失去了其意义。

2、验收标准明确时间过晚，对于客户需求未建立有效评估处理机制：

有些项目到了试点上线之后甚至正式验收之前，才与客户明确验收标准。殊不知验收标准与客户确认的时间越晚，对自身越加不利。很多工作都做完了，客户的想法肯定是你要把我的所有需求和问题都解决了，才能给你验收。上线之后冒出来的应用优化需求就作为了验收标准谈判的筹码，尤其是在前期没有跟客户明确建立问题评估处理机制的前提下，大部分情况下，我们都只能被动接受客户的要求。

3、验收责任不明确：

有了验收标准，可是找谁验收不明确，要么就是找客户项目经理，要么和项目相关的就全是责任人。前面在验收标准里面只界定了验收的范围及方式方法，但对于验收责任人没有清晰界定，就容易出现正式验收时相互推诿扯皮的情况。在蓝图方案阶段，与客户明确验收标准时必须明确各类验收工作的责任人，尤其是二次开发需求验收，一定是本着谁提出谁验收的原则。责权对等，一定程度上也可以规避减少部分优化需求。

4、项目成果文档不齐备：

一个项目做下来，文档没几份，很多工作都是通过口头确认，到了验收的时候口说无凭，验收工作的推进自然也就不靠谱了。其实让客户养成实施过程工作文档确认签署的习惯，你的正式验收也就成功了一大半，因为很多工作都已经阶段性确认验收过了，到最后的正式验收只是一个水到渠成的工作。

5、客户未看到应用价值，不满意：

最关键的一点，售前阶段是给客户画饼、提升期望值的阶段。可是如果到了实施阶段，如果客户发现前期传递的价值什么都没有兑现的话，肯定心里是不爽的，还会给你验收吗？当然，这里要说的不是要实施人员完全去兑现售前阶段传递的价值蓝图。一方面信息化系统的成功实施，一定不是实施方单方面可以实现的，一定是IT+管理的结合，系统成功落地，客户自身也是需要管理配套的。在这一点上，我们要做的就是勇于向客户提出管理改善建议及应用落地保障要求。另一方面在实施阶段我们解决的核心业务问题，展现核心应用价值，向客户灌输随着系统深入应用及管理提升，价值分阶段兑现的观点，也可以给后续服务的应用提升埋下伏笔。在这一点上，我们要关注的是系统的应用价值展现与输出，不能光有数据录入，没有输出，那么客户就会把系统定位成一个基础数据录入应用系统，而非一个管理平台。

一家之言，欢迎大家拍砖，也希望实施同事对于验收问题能有更加深入的思考与认识，并有效改进过程方法，以促进各自项目验收顺利推进。