文章源自玩技e族-https://www.playezu.com/13242.html
文章源自玩技e族-https://www.playezu.com/13242.html
要理解需求变更，需要先知道什么是需求。文章源自玩技e族-https://www.playezu.com/13242.html
文章源自玩技e族-https://www.playezu.com/13242.html
需求所指的内容很宽泛，我们这里指就是产品经理提出的需求文档。需求文档是开发进行开发实现，测试进行测试验收的凭据。文章源自玩技e族-https://www.playezu.com/13242.html
文章源自玩技e族-https://www.playezu.com/13242.html
需求变更是在原有需求基础上追加和补充新的需求，或对原有需求进行修改和删减。需求变更对项目的影响是多方面的。文章源自玩技e族-https://www.playezu.com/13242.html
文章源自玩技e族-https://www.playezu.com/13242.html
文章源自玩技e族-https://www.playezu.com/13242.html
文章源自玩技e族-https://www.playezu.com/13242.html
需求变更有多种形式，总结起来，大概有如下几种原因：
（1）需求设计不够完善成熟
这种情况一般是因为产品经理没有想好或者是因为设计一个大的模块，很容易遗漏很多细节逻辑或者设计出不合理的地方。这种在需求设计还不完整成熟的情况下，就进行开发实现，很容易导致后续多次的需求变更。
（2）需求设想太好，研发技术不能实现
产品经理为了达到比较好的用户体验，设计的产品会需要非常大的开发量或者目前技术无法实现，最终导致需求不停的调整变更以达到产品设计与开发实现的最终平衡。
（3）需求设计了多套方案，迟迟不选取
需求文档写了多套方案，且产品经理迟迟未做选取，最终开发实现的方案不是最终产品经理最终希望的方案，也会导致后续的需求变更。
（4）需求文档一些表述有歧义
需求文档中的一些表述有歧义或有问题，开发与产品经理理解不一致有偏差，导致最后变更需求。
1、 需求变更的预防或提早发现
（1）需求分析阶段，要对需求文档进行研究与思考，多培养自己的需求产品意识，确保需求文档设计的完整性与准确性。对于一些细节逻辑，先要确保完全理解，对于不确定的地方或者觉得设计有问题的地方，要在需求分析阶段确认沟通好，避免后续理解有偏差，开发实现与产品设计不一致，最终造成需求变更；对于一些需求文档未考虑到的部分，尽力协助产品补充完善，提出自己的建议与想法；对于那些感觉设计不合理的地方，要提出自己的疑问与想法，与产品经理一起讨论，最终确定出比较好的方案。
（2）项目测试前，确保产品经理已经进行过产品体验，这样对于那些与产品设计不相同的地方能够提早发现，提前进行需求变更。
（3）项目测试前期，先进行预测试，这里一方面是为了确保需求完整实现，一方面也是作为测试对产品的体验，把自己当用户，发现不合理的地方时，及时提出来，避免后期可能出现需求变更。
2、 需求变更的处理流程
当需求变更不可避免的出现了，那就需要按照一定的规范流程来处理，一般是以下几个步骤：
（1）产品提出变更；
（2）产品、测试、开发对变更进行评估；这里的评估一方面是对需求变更合理性的判断，过滤不合理的变更，另一方面是讨论需求变更对开发测试增加的工作量，以及最终对项目的影响。
（3）产品公示需求变更；
（4）开发、测试评估需求变更带来的工作量，给出完成时间；产品发出需求变更后，测试要确认开发完成时间和及时调整测试方案与测试用例，以适应新的需求。
（5）产品进行体验走查；这一部分也是为了产品验证开发实现是否符合新的需求。
（6）进入测试阶段；当然是先预测试下再进入正式的测试阶段了……
3、 需求变更的总结
对遇到的每一次需求变更，尤其是测试中后期发出的需求变更，都应该记下来，便于模块测试结束或项目测试结束时作总结。总结时写出需求变更的内容、原因、测试增加的工作量及整个项目增加的工作量、对今后工作的一些指导教训等。
（1）对于那些可以预防或者提早发现的需求变更，总结出自己应该做哪些方面的改进与优化。
（2）项目的整个过程中，自己要有用户思维与产品思维，且不管什么时候发现需求不合理或遗漏的点，都应及时提出来。
（3）当产品经理频繁发需求变更，可以考虑优化修改下当前工作的流程规范，尽可能想办法缓解这种现象。