在需求变更的时候，最好对所有相关干系人都要进行通知和管理，很多时候，沟通的时候忽略了一些主要干系人，结果导致变更失控。
2、需求变更的反馈。
在进行需求变更的讨论和交流后，一定要反馈。反馈的时候，一定要告诉对方需求的实现目标和时间。因为有时候目标一致，因为人力资源问题，有时候双方的预期时间会不一致，这个时候，就需要双方重新协商，达成新的一致目标。
3、需求变更的确认。
当需要进行需求变更的时候，一定要有书面的文档和签字手续。这样，对双方的工作量都有明确的记录和认可。同时，确认书会让变更变得更有效和科学。
临时发生需求变更，容易导致新的需求考虑得更加不周全，项目的风险、产品质量下降的风险都会加大，严重的还会导致产品偏离原本的产品定位或想法。频繁的需求变更，对产品、项目进度和团队积极性都有非常大的危害。项目经理一定要不遗余力避免需求变更的情况。下面来看看需求变更产生的主要矛盾以及如何应对。
（1）由于实现难度而修改需求。
这种情况往往发生在设计人员已经给出了设计图和切图，开发人员开始开发，在某一个地方遇到了实现难题，比如按照原本的需求方案，可能有性能问题，或者开发难度太大，工作量比预期的大很多，等等。这时候，只好用一个妥协的产品方案来替代原本的需求。于是，设计人员需要重新作图，开发人员也有部分工作需要调整。有的同学可能会说，这种情况可不能赖项目经理了吧？是开发人员实现不了导致推倒重来的。这里要特别指出，如果你想成为一名优秀的项目经理，千万不要有这种思考习惯。项目中出现的任何问题，都有项目经理的责任。那么，这种情况要如何避免呢？那就是尽早地邀请开发人员介入，在需求方案还未敲定时，甚至在需求发起和讨论时就邀请开发人员一起参与讨论，即使开发人员对产品方案不能给出建议，至少也可以了解需求的来源，并且及时指出一些技术实现的难点。这种实现风险大、成本高的地方发现和提出得越早，越能保障产品后续环节的顺畅进行。需求变更发生得越晚，新的需求方案输出得就越仓促，考虑得就越不周全，对产品和项目都有很大危害。风险提出得越早，除可以避免团队成员工作量的浪费之外，还可以让大家对需求变更考虑得更周全。所以，在这里项目经理要注意，让开发人员尽早了解和知道接下来要做什么需求，涉及哪些技术难点，这既是必需的，也是应该的。
（2）对需求考虑不周全。
比如项目经理小明设计用户注册流程，方案是用户需要填写手机号才能顺利注册。这个方案已经由设计人员给出效果图和切图，且进入了开发阶段。那么，在这个过程中，小明从公司内部的其他同类产品中了解到，用户对手机号非常敏感，如果手机号是注册时的必填信息，则很容易造成在注册流程中用户的流失。于是，小明只好修改产品方案，将填写手机号一项改成选填，增加填写常用邮箱作为注册用户的唯一标识。这就是典型的在需求方案设计阶段，没有全面考量方案的例子。当然，这与小明的经验也有关系，一般新人难免在设计方案时对一些情况不够敏感，会有疏忽和考虑不全的情况。这需要项目经理高标准要求自己，从各种角度审视、考量自己的方案，尽全力考虑周全，那么就会在相当大的程度上避免需求变更，并且本人也会有所收获、提升能力。
（3）还有一种非常无奈但是常见的情况，即老板提出的需求变更，或者真的由于产品方向改变而出现的需求变更。
这种情况下，项目经理也并非完全没有责任。这时项目经理要思考，为什么老板在已经进入设计和开发的阶段才提出需求变更？是否因为老板之前并没有能够充分了解需求？这可能是因为老板太忙了，没有关注到这个项目，那么其实项目经理可以更主动积极地让老板了解产品项目的进度、整个需求的思考过程和最终方案。这样，如果老板有其他想法或不同意见，即可及早提出。
（4）在设计图出来之后，或者开发原型出来以后，甚至在测试阶段，发现之前的需求方案不合理。
这种情况一般是不应该发生的，项目经理的水平越高，发生这种情况的概率也会越低。但是人不可能完全不犯错，或者说，在看到真正的效果之前，甚至试用原型之前，有些交互体验的细节问题确实难以发现。这也是项目经理需要修炼自身的地方，平时应该多试用各种产品，体验各种交互和页面设计，这样才能在设计产品方案时不是单纯地拍脑袋，而是在有真正的操作体验的基础上去设计。但是也要说明一点，这种情况下的需求变更，不应该是非常重大的变更，一般都是交互体验或者页面内视觉逻辑的微调整。产品流程或产品逻辑的问题，应该在视觉效果图输出之前就能够被发现，而不是到视觉效果图或者产品原型阶段才能发现。
因此我们看到，避免需求变更的主要思想就是，让信息在团队内部，产品与产品之间， 团队与老板之间，进行充分的交流和沟通，避免信息不对称或不同步的情况，在信息充分同步的情况下，才能更早地暴露问题，提前修改需求方案，不浪费设计和开发等资源。
没有需求变更的团队是非常理想的，但是当理想照进现实，我们发现，事实上很少有需求不变更的情况。那么，当需求变更不可避免地发生了，该怎么处理，才能将危害降到最小呢？
其实，需求变更流程与产品的一般流程是一致的，首先是项目经理重新思考变更的需求， 全面考虑后输出新的需求方案，同时并行的是充分与设计、开发、测试等团队成员沟通，让大家了解需求为什么要变更，如何变更，以及修改后的方案会是什么样子，等等。在团队成员对变更后的需求都认可了之后，就要再次进入设计、开发、测试的阶段。在整个过程中， 项目经理同时要关注的是需求变更对整个产品版本进度的影响，一般需要设计、开发、测试人员重新评估工作量和提测时间，项目经理需要了解该变更是否会影响产品最终的发布时间， 如果确实有影响，无法通过协调其他时间来消化，那么要及时告知更大范围的团队成员。比如需求变更只涉及一个功能的开发和测试，但当这个需求变更会影响整个版本的进度时，就需要让整个产品版本涉及的所有开发、测试等人员知道版本发布计划的变更及原因。
