（2）项目验收的标准和要点

项目验收看似简单，但在操作上却是极其复杂和重要的工作，因为项目验收无固定统一的标准。一般来说，项目验收的标准包括：项目合同书、国际惯例、国际标准、行业标准、和企业的相关政策、法规。因此，开发团队对项目验收的标准情况了解越多，后期项目验收的难度和风险越小。因此，细读项目验收的标准例如合同书是第一步，必须要先弄清楚这个是什么项目，项目合同中有那些客户关注的问题。这样才能在验收前，有针对性准备好项目验收工作。

在项目验收的时候，对于项目中可能存在的一些问题，不要让客户想等系统没有一点问题或保证以后没有问题的情况下才验收。如果客户这样想开发团队麻烦了，微软那么牛，做的操作系统还天天打补丁。开发团队要让客户明白，所谓验收，是依照合同需求和能够满足企业的需求，结果和预期结果一致应该算通过了，而且还容许有一些小错误留在验收后改正。

一般来说，现场长时间验收检查不太可行。因此，在验收前准备阶段，项目负责人应主动、积极的与客户密切沟通，及时、准确地收集和理解验收条件。特别是客户对即将验收项目的真实、初步意见和评价，好是在验收前沟通好和形成书面正式的《项目评价报告》。如还留有一些可能影响或暂时不影响项目整体验收通过的细节、小问题、变更或异议、分歧等，应与客户协商解决处理好，做到事先沟通、达成共识。强调已经基本上完成项目内容，满足合同要求。

如何顺利地让客户进入验收状态？

如何才能顺利地让客户进行验收是一直困挠开发团队的一个难题，为了避免项目验收无期的局面，建议加强以下几方面工作。

（1）及时解决问题，端正处理BUG的态度

既然发现软件存在问题，应该尽力去解决，这是开发团队的责任。客户不肯验收，主要是害怕承担责任，毕竟还有问题没有解决嘛。如果换做我，我也不会给你验收的。因此，要想让客户方验收，首先要做好合同的明确规定和服务承诺。并以此为依据，让客户放心，让客户方验收。在开发过程中给客户感觉是不是用心的做事是很重要的，否则的话后期验收会有点困难了。

在项目过程中，需要注意平时承诺的积累，比如要做到讲诚信、讲原则。主要是三条：做不到的事情千万别随意承诺、承诺的事情一定要努力做到、每次做到的事情都要进步一点点。按这三条做事，即使在与与客户沟通中有这样或那样的不愉快和矛盾，客户也会慢慢接受，也会用更多积极性眼光看存在的BUG问题。当然，项目中如果有关键瑕疵，也是客户忌讳的，开发团队一定要理解这些瑕疵并解决好。

（2）平衡和识别项目干系人需求

在项目验收阶段前，要尽量识别和关注所有项目干系人的需求和态度，并时刻给客户灌输只要完成那几项工作代表项目可以验收了。当客户不肯验收时，要与客户展开深入的交流，明确客户为什么不愿意验收。有时客户的问题只是借口，所以要根据客户的表现判断出这个背后的问题所在。当找到问题后，协调相关的资源来解决。有时和客户直接把问题摊开沟通，或许是比较好的解决方法。

总之，开发团队应要对项目利害关系者进行关注，和关注他们关注的内容，或者他们担忧的内容。作为开发团队要做到尽量做好所能控制的事情，另外一些很难由开发团队控制的事情则需要借用一些其它的力量去完成。比如关注项目利害关系者的一些秘密需求是否得到了满足，或请高层领导运用一些商业手段来促成项目的验收等。

（3）重视阶段性成果验收，提高客户感知度

其实，软件开发项目验收远非是仅仅对系统的测试和检验这样简单，它是开发团队和客户在开发过程中双方合作博弈的结果。因此，在项目开发过程之中，与客户的沟通和绩效汇报是非常重要的。客户之所以迟迟不验收项目，简单的说是因为客户对开发团队做的项目不满意。

一般来说，满意=感知-期望。因此，客户不满意是因为客户的感知度非常低，而期望很高。换句话说，是由于开发团队对项目需求没有定义好，或者没有分析好，或在定义需求的时候没有考虑到客户的感知和期望，导致现在的项目验收困难。所以，一方面量化和降低客户的期望值，另一方面尽量提高客户的感知度是非常重要的。方法可以是对于每一个阶段性的成果，尽量让客户可以参与并且验收，目的是为了尽可能来提高客户的感知度。

（4）清晰处理好客户反馈问题的跟踪状态

在一个项目开发周期中，每次客户的反馈问题都需要认真做好跟踪记录。下次工作要根据前次备忘录的双方约定或客户的反馈问题继续进行，保障项目在双沟通的基础上不断前进，并用备忘录约束双方的行为。

建议在收集项目出现的各种问题时，采用问题跟踪记录表的形式，这样可以一目了然地显示出曾经收集到的各种问题、目前的解决情况、以及还有什么问题没有解决，或准备什么时候解决。这样客户和开发团队都会对目前的情况非常了解，通过不断地解决出现的问题，来收敛可能出现的问题。当存在的问题越来越少时，也表示项目开发已经在接近验收的标准了，也可使客户在需要验收的时候不能再找各种各样的借口来拖延验收。