浅谈软件项目验收（转）

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

客户场景A：

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

客户场景B：

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

客户场景C：

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

客户场景D：

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

客户场景E：

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

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

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

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

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

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

3、验收责任不明确：

有了验收标准，可是找谁验收不明确，要么就是找客户项目经理，要么和项目相关的就全是责任人。前面在验收标准里面只界定了验收的范围及方式方法，但对于验收责任人没有清晰界定，就容易出现正式验收时相互推诿扯皮的