在目前的软件研发流程中，存在一些问题，导致研发&测试的同学在工作过程中遇到很多困难，包括：

我将研发流程分为了五个大阶段，大部分内容与我们目前的工作流程基本一致，略有区别的和需要特别注意的点我用五角星标（☆）标记出来。

一、需求立项阶段 在需求立项阶段，一般是业务和产品基于目前业务发展等各方面情况，提出产品的改进想法，如果是技术改造类项目，则是由研发基于目前的系统，提出的系统优化改进想法。这个阶段会确定达到什么业务目标、要做哪些事情、什么时候做、对业务产生什么价值，然后判断需要投入多少资源，产生多少价值，也就是投入产出比（ROI）。 这个阶段中，一线研发和测试同学需要参与的地方不多，主要会有以下两点：技术可行性分析、需投入时间分析。

这个阶段产品、业务可能会咨询研发某些功能是否可以实现，研发同学可基于目标，提出多套方案，并分析多套方案的时间投入、研发难度、对产品未来的影响等给到产品业务同学作为参考，并给出研发建议。

这个阶段，业务产品也会咨询研发相应的投入时间，这个地方回答不好，可能就会给研发同学埋下一个坑。比如说“功能不复杂，三天就能做好”，这个地方的坑在于业务会理解成我的需求提出来后，三天就能上线，业务可能就会给出一个期望上线时间“三天后”。实际研发过程中，涉及产品文档、技术文档、研发、测试、发布等阶段，“三天完成”一般只代表研发时间，其他的时间并没有包含在内，实际需求提出后，可能要十天才会上线。而且实际需求提出后，是否立刻有资源投入去做、测试是否有资源、实际需求是否和现在有出入都是未知数，所以正确回答可以参考这样去回答“从目前给到的信息来看，粗略估计一下，功能不复杂，写代码大概三天左右，我只能评估到这里，具体上线的话还有看测试资源和到时候的项目排期情况”。主要就是明确目前只能评估技术开发时间，并不是给保证上线时间。

这个阶段，主要是确定“怎么做”、“花多长时间”的阶段，主要产出有《产品方案文档》、《技术方案文档》、《测试用例文档》。

研发、测试需要关注产品文档中需要修改的产品功能UI、功能链路图、页面交互跳转步骤、交互文案、异常链路处理方案等是否描述完整清晰，如有不清晰的地方，需要记录并推进产品进行修改补充。 如产品文档中核心链路基本不清晰、有比较大的不确定的点，导致无法进行技术方案编写，则可沟通修改后重新评审《产品方案文档》。

技术文档中，需要描述清楚具体改造点、系统间交互、库表设计、接口设计、安全性设计、性能设计等，详细见《详细设计文档模版》。这里重点说一下需要特别注意的点：清晰确定的实现方案，明确时间规划、明确测试范围、输出风险问题。

技术文档中的技术实现方案90%是确定的，包括新技术调研、细节的接口应该创建新接口还是使用老接口、是否增加字段、调用链路如何实现、如何做开关切流等，有不确定的点可提前线下与相关同学进行沟通确定，不能到技术方案评审时再来讨论该怎么做，这样不仅会浪费开会成员的时间，同时大量的讨论会分散大家的注意力，导致没法发现技术实现方案上的问题。

这个地方需要注意以下几点：

明确罗列测试范围，一能方便测试评估工作量，二可以作为测试用例编写的依据，方便测试能更多的覆盖需求边界，做到不遗漏。

在文档评审过程总会有新的问题产生，记录问题并给出责任人和输出结论的时间点。 没有完美的方案，某些方案会存在一定的风险，记录风险，并给出相应解决或规避方案，同步到项目组相关成员并达成一致。

测试用例文档需要包含正常流程测试、异常流程测试、受影响功能域回归、性能压测、边界测试等场景，在编写完测试用例文档后，需要进行“测试用例评审”。 测试用例评审的主要目的包括：

此阶段主要包含开发、联调、自测工作，需要特别注意一些点：

测试同学可以在此阶段准备测试用例及进行测试用例评审。

此阶段主要是测试同学的工作，需要注意以下几点：

此阶段主要工作内容是配置项配置、数据库脚本执行、线上部署、运营配置等，此阶段需要注意以下几点：

在进入开发、测试阶段后，不可避免会出现需求变更，变更原因有可能是产品设计有遗漏、研发开发测试过程中发现有未评估到的点，遇到这样的情况需要注意以下几点：