研发流程的反思

目前较为传统的研发流程：

               项目立项 > 需求产出 > 研发开发 > 研发自测 > showcase > 测试 > 产品验收 > 发布上线

但这个流程在测试一些较为复杂的项目时存在着部分问题：

        1、研发同学开发的产品与产品的PRD的预期存在出入。

        2、研发同学在开发过程中可能存在各种情况导致需求遗漏，而遗漏部分又不属于主流程，因此在showcase时也未能发现。

        3、在实际的开发过程中和产品进行沟通时存在未对齐的情况，需要测试反复去进行沟通对齐。例如：A、B两个页面均需要新建时进行校验不可名称重复，但在研发和产品的沟通中可能会听成A页面需要校验B页面不需要进行校验。

        4、开发在研发期间也会存在自己新增部分校验逻辑，但这部分逻辑实则未再需求中写出而产品实际也不需要这个校验。

        等等

     存在以上种种原因，会导致在测试过程中需反复和产品以及研发对齐需求，导致开发反复返工，同样也会增加测试时长可能会导致需求延期等情况。

        对以上问题进行反思后总结出以下原因：

1、研发、测试在需求评审时未对需求投入太多的时间，导致本身就不完善的需求评审通过。

2、开发过程中因工期较赶，遇到的问题未和产品沟通直接按自己预期实现。或发现产品需求存在漏洞时依旧按需求中要求去做不去再进行沟通

3、产品和研发并不需要对产品上线后的质量负责，若存在问题则由测试进行兜底负责，并不会对需求的实际应用进行考虑。

对研发流程的优化考虑

我们需要先考虑产品验收环节设立的初衷是什么？

目的是确保前期指定的需求功能完整——技术开发过程中遗漏功能的补充以及需求偏离后的及时矫正。

但是目前需求功能完整性基本上都已经在测试阶段完成了，而且如果真的在产品验收阶段发现需求实现效果与期待不符，需求回炉重造，这将会增加时间成功、极大的增加项目成本。

原来把产品验收放在测试环节后面的目的是什么？是防止主流程影响产品验收，可是项目经过开发自测基本上不存在主流程不通的问题。每次的产品验收都要花费一个小时，如果把这一个小时放到测试进行测试之前，那么这个回报率是否会得到最大化：

1、确保开发实现符合需求，提前调整，减少无谓的返工。

2、减少各方的沟通成本。

3、缩短测试周期，提升交付效率。

既然如此是否可以进行调整研发流程：

项目立项 -> 需求产出 -> 研发 -> 开发自测 -> showcase -> 产品/UED验收 -> 测试 -> 发布

需求评审过后，研发人员进行需求开发，在需求自测完成后，进行showcase，showcase通过之后，测试同学在测试环境搭建测试环境，通知产品进行需求验收，需求验收通过之后，在由测试进行测试以及发布。若在测试进行测试时改动到了流程交互等情况则再次和产品进行对齐看是否还需要产品进行二次验收。