在项目中，会遇到各种各样的需求加塞和变更，导致在项目交付链末端的测试经常是苦不堪言，如果直接拒绝会被认为，工作支持不到位，甚至认为缺少挑战拼搏精神，甚至被认为价值观有问题。那么如何合理而友好的拒绝产品需求呢？
个人认为有三种方式值得和同学分享。一种是换方案不换目标；一种是换目标不换方案；一种是接受，但不断通过数据进行反馈。
1.换方案不换目标
具体来说就是在不改变上线目标的情况下，通过调整需求优先级，或者线上线不放量，先保证正常上线。
1）调整需求优先级
比如可以这样沟通：
能理解你现在急迫的心情，我们的责任就是支持业务上线，保障线上质量；但现在手头需求和工作比较多，时间已经基本排满，本期还有你的需求XXX和你们组XXX的需求，你看能不能你们内部先协调下，看那个需求可以往后推一下，然后把你这个需求加你来，同时要求这个需求在什么时候完成需求评审、XXX时候完成开发。
2）确保上线，分阶段放量
现在手头工作比较多，时间基本排满了，你这个需求是只要上线就行，还是上线后必须全量？如果只需要上线，可以先让开发完成，测试同学先简单测试下主流程和上线后的开关功能，先安排上线，上完线后暂时不打开开关，或者灰度少量用户，在下一版本给您优先测试，测试完成后在全量放开，你看这个方式是否可以行？
2.换目标不换方案
就是需要多个需求同时并行的完成时，和产品沟通协商调整优先级顺序。或者通过重新梳理拆分细化需求，完成其中的部分功能。这种方式最大好处就是让产品内部先梳理优先级，思考周全后再提交给研测。
现在手头工作比较多，时间已经基本排满，你看能不能先把现在做需求重新梳理下，看下这个需求哪些功能必须上线，哪些可以后期上线，我腾出2天时间帮忙把必须上线的需求挤一挤通过加班消化掉，但同时需要协调开发必须在XXX时间点完成。
3.接受，并持续反馈
有些需求是在推也推不掉，必须在这次排期上线。比如老板或者老板的老板拍下来的需求，但从你专业的角度，觉得不可能完成，或者按照这个时间点完成风险比较大，这个时候就需要灵活处理。先接受需求，随时反馈进度和风险，以供老板及时调整计划或者上线策略。
