项目验收，既是对项目成果检验的关键一步，也是确认结果并进行查漏补缺的一步。那么既然项目验收如此重要，我们又该如何进行呢？周全的验收工作又要注意什么呢？

项目验收就好像你自己打的那套卷子交给老师评分一样，自己检查一点错都没有，或者知道哪里有一些错，但是结果还是需要交由老师评判。在还没有到交卷时间时，我们需要将自己的卷子修改到自己认为到最好的状态下进行交付。

一、为什么要做项目验收呢？

每个人做卷子时都希望能够拿到高分，但是怎么拿到高分呢？

其实可以很简单，那就是在做卷子的时候对于我们的卷子检查再三。而项目验收就是我们做的检查，所以项目验收是针对当前项目交付前做的最终检查，如果合格就是可以交付的，如果不合格那就没办法交付。

二、项目验收的流程是什么？

其实项目验收也是按照一定流程进行的，一般的项目在验收时都会经过程序员自测、冒烟测试、测试完成、UI验证、产品验收这几个普遍的流程之后才能够确认验收，进行项目的交付。

程序员自测

程序员自测其实就是程序员去测试自己所写模块是否与产品对该模块所提的需求完全匹配。

程序员进行自测是对自己所写模块的进一步检查，这样可以使对该模块的逻辑更加明确，同时加深对于该模块的记忆，并且可以最大程度确保每个模块程序书写的正确性。

冒烟测试

冒烟测试是对已经完成的全部模块进行流程性的检测，确认目前完成的系统是否可以确保按照产品的全部逻辑跑完基本流程。

冒烟测试主要是增加目前对产品流程的熟悉度，让测试人员可以进行详细的测试的准备工作，也是该系统是否可以进入详细测试的一个重要依据。同时也会验证出在此流程下是否有一些设计缺陷需要产品进行弥补。

测试完成

测试完成是对于整体的测试环节来说的，他是测试人员对于系统整体进行测试的一个结论，这个结论是已确认目前系统的功能、性能在测试环节已经完全符合产品提出的需求。

进行测试的主要原因是对当前系统的全部流程的一个回归，和对该系统是否存在缺陷性问题。测试完成的确认是因为确认之后就该系统就可以进行下一项目的交付，来进行更深一步的优化。

UI 验证

UI 验证是由UI设计师来验证当前的系统UI是否能够达到预期的效果。

UI验证是当前页面UI还原度的一个重要证据。UI验证是检测当前页面能否做到UI图级别的视觉效果，以及开发人员是否按照UI设计师的界面需求进行实现的一个重要准则。

产品验收

产品验收是产品经理在项目交付前进行最后需求与程序开发是否统一的过程。

产品经理进行验收是对整体系统流程的一个把关，也是对当前系统一次总的检查，在验收过程中需要综合UI验证以及测试时的一个结果来确认在产品经理在验收后是否可以交付该系统。

三、项目验收中遇到问题了呢？

项目验收本来就是一个需要承担责任和成长的阶段，当项目验收成功后，你会觉得整个世界都是晴朗的，但是你在验收过程中一旦发现出现问题，那有可能就会有原地爆炸的风险吧。所以当遇到了问题我们该怎么解决呢？

已构建的程序与之前的规则不相符

当我们开发的小伙伴已经完成了开发，但是你发现与产品确认需求时的规则并不一致，这时也许会觉得天噜啦，我要怎么办？

产品的规则其实确实是开发小伙伴需要遵从的准则，不过还是会经常出现开发完成的规则与确认需求时的规则不相符的情况，这是什么原因呢？

有一部分原因就是当时没有沟通清楚出现了这个原因； 还有一部分原因产品的规则之前不完善，所以开发直接按照自己觉得完善并且合 理的规则进行书写了。

事出有因，但也不是没有改正的方法。

NO.1 没有沟通清楚，且目前做的系统比之前产品规划的要完善，那就不需要修改，直接把当前规则补充到细则上。

NO.2 没有沟通清楚，但是目前系统做的并不尽人意，根据交付时间酌情修改：时间太紧急，如果按照原有规则可能无法按期交付，那就酌情进行规则细则修改，

在不影响工期的情况下进行修改；时间充裕，那就跟开发确认清楚该规则，明确到最小的细则，并且及时跟进，确保该规则是在正常情况下修改的。

NO.3 由于产品的规则没有细化并明确，导致开发按照自己意愿进行功能设计，结果出现部分与产品之前不相符的。如果时间允许可以在经过沟通后进行相应规则调整，当然不能仅仅调整代码，规则也可以进行相应调整，在不影响产品原有设计规则的基础上与当期的代码进行适配，将时间成本降至最低。

NO.4 由于产品的规则没有细化明确，开发按照自己意愿进行功能设计与之前的规则没有太大偏差。这个时候你应该感谢开发，与你所想的没有南辕北辙。需要的就是在此基础上进行更加明确的规则细化就可以了。

UI 还原度与验收时间有冲突

当我们 UI 同学辛苦设计的页面，并没有被前端小伙伴整体还原出来，估计 UI 同学会被憋出内伤呢。这个情况下又该怎么解呢？

这个根据现实情况来就好，告诉 UI 同学，你这个项目的 UI 还原度是多少，直接让 UI 同学去分析是否通过 UI 验收就好。但是如果时间节点有冲突时，可以告知UI 同学适当降低还原度。

四、验收后出现问题了呢？

这个项目被验收了，但是没验收多久突然就告诉你我们觉得这里不对，我们觉得那里需要改，这个跟我们一开始说的不一致，突然发现有 bug，好像觉得自己要宕机了呢。

需求方想要新增需求

需求方在验收之前觉得很符合自己的定位，但是在验收之后的使用过程中突然觉得，这里如果在新增一个功能就更完美了，于是就说，我觉得这个跟我之前想的不太一样，需要加上这个功能就好了。

在项目已经被验收成功的情况下，所有的新增功能都是属于新的需求，既然是新的需求，那就需要拿出签字的需求方案。只有提出了需求方案并且经过了签字才可以进行规划，同时规划还是需要将这个需求规划到下一期中，因为目前已经完成验收。

其实简单来说就是所有在验收后提出的需求都是需要提交方案，并且规划到下一期的。

需求方发现 bug

在系统的使用过程中突然发现，某个地方有 bug 了。

有 bug了就去修改就好了，这就是我们开发团队的维护情况了，有 bug 其实不可怕，毕竟我们在交付的时候并没有出现问题。其实在系统的使用过程中出现问题是不可避免的，所以在出现问题后及时修正才是最好的解决办法。

五、怎么确认验收结果呢？

验收结果是最激动人心的动心，但是我们需要怎么去确认这个结果就是我们想要的结果呢？

其实验收结果可以从外包和自家产品两个方向。

• 外包验收：甲方爸爸跟你说我觉得这个产品很好的，那这次验收基本成功了；如果甲方爸爸跟你说，这里也许还能再优化一下，那就需要记下优化的点，继续进行优化就好了，那这次验收基本就不能算成功了。
• 自家产品验收：自家产品其实主要就是满足当前需求方的需求，经过检测没有出现 bug，那之后再进行输出性迭代，就基本可以了。

所以，小伙伴们，你们现在的项目验收了没啊，我现在的项目差不多快验收了呢！

本文由 @薛小羊 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。