浅谈软件项目验收（转）

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

客户场景A：

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

客户场景B：

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

客户场景C：

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

客户场景D：

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

客户场景E：

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

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

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

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

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

3、验收责任不明确：

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

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

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

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