需求变更如此频繁，还甩锅给测试？

项目背景

有一个数据管理平台系统的项目，需求频繁的变更了15次，每次生产上线后总是能出现一些让人意想不到的bug。开发人员和测试人员对这个项目嗤之以鼻，开项目会的时候，有人调侃参与这个项目的人员都很有必要去看看心理医生。

需求变更的频繁的原因？

1.之前这个项目的项目经理和产品经理是同一个人，该项目经理写完产品需求设计说明书就请长假了，一直在医院。
2.于是项目就临时交到了第二个项目经理手里。第二个项目经理对需求一开始也不是很了解，也没有及时再和用户沟通需求。
3.开发直接拿着最早的的需求设计和原型设计进行了设计和开发，期间发现的问题只和产品经理进行了沟通。沟通完产品经理也没有及时更新需求。
4.测试人员也是拿着最早的需求进行了测试方案和测试用例的设计，不知道有些模块的需求发生了很大的变化。
5.评审测试用例时，开发和产品经理提出了要变更一些用例。但是第二天产品就进行了第一轮提测，测试也没有充足的时间完善用例，属于边测试边修改用例。
6.项目经理给客户分配了账号，客户方测试点过程中，发现很多设计不是自己想要的，于是就一直在提出要改进的新需求，于是这个项目的需求就开始了频繁的变更。

生产问题

1.系统一期进行了7次需求变更，登到生产上线后，客户又提出了很多新想法，也提出很多功能不是他们预期想要的。
2.在系统二期的开发过程中，开发一边做着二期的新模块，一边又按照要变更的需求调整着一期的系统结构。等到所有变更都 加上，进行二期测试完交付的时候，客户还是有很多不满意的地方。

产品复盘

1. 最后项目复盘，产品经理写的PPT，主要暴露了测试这边漏测和对需求理解不到位的情况。
2. 测试人员对产品经理写的资料表达了不满，指出一些问题，让产品经理进行修改。
3. 在测试人员看来，需求频繁变更才是产生问题的根因，因为需求频繁变更产生的风险被产品经理严重低估了。
   

小结

产品经理应该从以下方面进行反思：

1. 需求预测出现偏差，需求设计的结果偏离了客户的实际需求；
2. 需求调研偏差，业务场景覆盖不全面，后期又加了一些场景；
3. 没有合理的拒绝需求，没有良好控制需求变更的范围。