4、需求变更的影响
需求变更首先要评估一下需求影响的范围，然后评估一下对现有进度的影响，对项目交付质量的影响，是否需要增加成本（比如人力资源成本、服务器成本等），以及需求变更带来的潜在风险点。

5、预防需求变更
与其发生问题想办法，不如在问题发生之前去预防。
所以在考虑需求变更之前，我们先想想如何预防需求变更，产品经理提的需求，设计师设计的ui设计稿一定要经过团队内部的充分评审，让大家充分发表意见，做到需求理解一致，并最后邮件确认，也许你一个人无法发现问题，但是大家一起头脑风暴，就容易发现问题。
针对技术实现方案，技术团队的同事也要充分沟通，反复研讨，务必把一切能想到的问题提前想到。
对于外部的需求一定要充分沟通，能不变就不。
同时保持对业务环境的敏感，知道业务同事的习性，提前做好应对措施。
针对业务同时可能变更的需求，提早分析，做好预案。

6、接受OR 拒绝需求变更？
针对变更的需求，我们是接受还是拒绝呢？在说拒绝还是接受之前，我们先说一下PM的态度问题，针对变更的需求，PM一定要保持积极的态度，不能消极对抗对于变更的需求一概拒绝，在高度重视的同时，要有全局意识，要能看到变化给每个模块带来的影响，以及给整个全局带来的影响。
那我们判断是否接受变更可遵循以下三个原则：
1、变更对项目是否有利，如果无利，我们肯定拒绝。
2、如果变更对项目有利，那我们要接着看，变更需要投入的成本和变更带来的利益，也就是看投入产出比（ROI）如何，然后根据投入产出比判断是否值得更改。
3、如果值得更改，那接着看是否紧急，如果变更带来的收益不是我们目前急需的，也可以往后放。只要那些重要且紧急的变更需求，我们才考虑插入。