项目验收怎么做，才能避免翻车？思维导图

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

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

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

冒烟测试主要是增加目前对产品流程的熟悉度，让测试人员可以进行详细的测试的准备工作，也是该系统是否可以进入详细测试的一个重要依据。

同时，也会验证出在此流程下是否有一些设计缺陷需要产品进行弥补。

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

进行测试的主要原因是：对当前系统的全部流程的一个回归，和对该系统是否存在缺陷性问题。

测试完成的确认是因为确认之后就该系统就可以进行下一项目的交付，来进行更深一步的优化。

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

UI验证是当前页面UI还原度的一个重要证据。

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

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

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

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

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

有一部分原因就是：当时没有沟通清楚出现了这个原因；

还有一部分原因产品的规则之前不完善，所以开发直接按照自己觉得完善并且合理的规则进行书写了。

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

由于产品的规则没有细化并明确，导致开发按照自己意愿进行功能设计，结果出现部分与产品之前不相符的。

如果时间允许，可以在经过沟通后进行相应规则调整。当然不能仅仅调整代码，规则也可以进行相应调整，在不影响产品原有设计规则的基础上与当期的代码进行适配，将时间成本降至最低。

这个时候你应该感谢开发，与你所想的没有南辕北辙。需要的就是在此基础上进行更加明确的规则细化就可以了。

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

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

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

在项目已经被验收成功的情况下，所有的新增功能都是属于新的需求，既然是新的需求，那就需要拿出签字的需求方案。

只有提出了需求方案并且经过了签字才可以进行规划，同时规划还是需要将这个需求规划到下一期中，因为目前已经完成验收。

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

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

有 bug了就去修改就好了，这就是我们开发团队的维护情况了，有 bug 其实不可怕，毕竟我们在交付的时候并没有出现问题。

其实在系统的使用过程中出现问题是不可避免的，所以在出现问题后及时修正才是最好的解决办法。

甲方爸爸跟你说我觉得这个产品很好的，那这次验收基本成功了；

如果甲方爸爸跟你说，这里也许还能再优化一下，那就需要记下优化的点，继续进行优化就好了，那这次验收基本就不能算成功了。

自家产品其实主要就是满足当前需求方的需求，经过检测没有出现 bug，那之后再进行输出性迭代，就基本可以了。

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

作者：薛小羊