对于CR的理解

前言

在什么阶段发现设计问题？

这其实是一个看似很白痴的问题，从V字模型来看，当然是在设计阶段发现问题最好。

但是如何能让客户意识到我们在设计阶段发现了很多的问题，并为客户节省了成本。

对于客户来说，好的例子

 我们在设计阶段，就判断出来，一个画面的返回按钮如果显示，会对整体流程造成不好的效果，建议不显示。

对于客户来说，不好的例子

我们在测试阶段，才发现画面上一些按钮的提示文言，在某种条件下没有显示（条件，诱导某种条件附加的商品时）。

对于按钮的提示文言不现实，用户的要件上并没有明确提出。只是用户提供的图片上没有显示而已。

这个其实在设计阶段就应该发现。但是到了测试阶段才发现。

（虽然没有发现，我们也能说得过去，因为和用户要件上提供的是一样的，但是，我们是可以早期发现并提出的）

对于开发方而言，此时，如果此处有变更，那么就作为CR来对应，工数增加。

==============================================

我们在按照客户的要求进行程序开发时，并不能一次性满足客户的所有的要求。

在开发的过程中，我们要对客户的变更点进行记录，这些都是CR

比如，根据用户要件的需求，我们完成了设计，可是发现有问题，就算是在测试时点发现的，这也是CR

（前提条件，你的设计书和用户的要件是一样的）

但是，有一点疑问，如果我们再设计阶段就能发现问题，是否还算是CR？

在设计阶段发现问题，总共数变少，对于用户是好事，但是对于开发方，总共数变少，却意味着钱的变少。

提案，

如果我们能在设计阶段，发现问题，那就表明用户的设计书一定需要修改，

问题是我们需要一个地方记录，我们发现了他们设计上的缺陷，

这也虽然我们前期看的仔细，花费了时间，却为整体节省了时间，我们需要让客户意识到这一点。

对于最开始没有提出的需求，变更之后，

变更部分对应的作业的工数，也要追加