其实在业内目前大部分管理软件项目合同和技术协议现状是：不管项目金额大小，软件功能模块几乎是一个不少，用户要求软件公司承诺的服务内容和个性化开发也是一个不少。
软件供货商在竞争压力下很难完全杜绝的营销过渡承诺。在这种情况下如果要以完成合同和技术协议为标准进行验收，笔者以为达到合同原始要求发项目可能非常之少。
管理软件项目最开始一般技术协议只谈服务内容和实现目标，很笼统，结果在实施过程中很容易出现业务需求爆炸的情况，软件商难以应付。
这种情况下软件商就开始逐步细化产品功能点，按功能点确定软件细节，只要功能点满足，理论上就应该满足用户业务需要，用户就应该验收，至于业务能否运行，更多的是用户的责任，这里面更多的体现了软件商的自我保护。
实际运做时无论技术协议细致还是粗略，对大部分国内用户而言根本没有太大的参考价值，用户只会考虑其业务是否真的在系统上跑，并以此作为检验我们项目是否可以验收的标准，当然有的项目可以通过商务运做，在业务上线情况不太好的情况下也能验收。
所以现在管理软件项目一般模式是按照业务内容分几个阶段目标，完成一个业务目标就完成一阶段验收，收取一部分实施费用。
这种情况下项目验收的最小条件是一个或某几个基本业务面能够开始大面积的应用。
这些基本业务面是不是很简单，或者功能是不是很稳定，或者人员是不是一定全部都上线，或者业务面上功能是否存在可改进功能，这些问题都不一定有统一答案，但只要用户看到这些基本业务面可以运行并承认这个可预期的结果就可以谈验收。
在合同边界中没有涉及有些好功能或者有价值的地方，实施过程中项目团队可以留一手，可以不全部告诉用户，在验收前可以作为交换条件和用户去置换很难实现的其它技术要求。
成功项目验收的核心就是项目边界的确定。
实施人员平时做人要讲诚信，讲原则，才好验收，无非是三条：
做不到的事情千万别随意承诺；
承诺的事情一定要努力做到；
每次工作都使事情往前进步一点。
快速验收的心得
项目经理从一开始接手就必须建立三个内控里程碑目标。第一个里程碑是项目回款，第二个里程碑是树立样板，第三个里程碑是追加新合同。用做第三个里程碑的心态做第一个里程碑目标，看起来前期投入大一些，但自己投入也会促使用户投入，最终反而能更快实现第一里程碑目标。
越早谈回款，越早明确验收边界；越是边界清楚的项目，越容易验收。
实施进度越快越容易验收。实施周期越长的项目，新增需求越多，越不容易验收。
某块业务应用得到部分用户认可就是催款的最佳时机，一旦项目某个业务进入可使用状态项目经理就要主动谈验收条件，明确验收和回款的关系。
文章来源于领测软件测试网 https://www.ltesting.net/
