对于CR的理解

前言

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

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

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


对于客户来说,好的例子

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


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

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

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

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

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

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


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

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

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

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

(前提条件,你的设计书和用户的要件是一样的)

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

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

提案,

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

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

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



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

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




猜你喜欢

转载自blog.csdn.net/sxzlc/article/details/79953245
CR
今日推荐