观点丨别一说“需求变更”就头大，我一个项目经理都没说啥

需求开发是一个获取明确并定义需求的过程，但这个过程中的需求并不是恒定不变的。

全文共1311字，阅读约6分钟。

在产品设计和实现中，客户也常常提出需求变更。要正确的处理需求的变化，首先要认识到在很多情况下，需求变更是不可避免的，这些情况如下：

1 时间

项目开发的目的在于解决用户的问题，可是随着时间的推移，形式可能发生一些变化，导致用户的需求也相应改变。原来存在的需求可能因为各种原因“不攻自破”，或者原来用户的主要需求变成了次要需求， 这些是需求改变的内在因素之一。

2 环境

项目开发是通过与其周围环境进行交互的方式来解决用户需求的。如果项目开发的外部整体环境有了变化，即使用户的需求依旧存在，那么项目的需求也应该发生改变。否则，项目开发完成也不能像设想的那样有效地解决用户的问题，关于环境引发的需求变化例子有很多，比如某手机品牌发布全新系统、某协议更至最新版本、某系统突然无法兼容其他功能等等。

3 缺陷

项目开发的理想结果是建立在一个完全无缺陷的需求基线，但这个基本上是不可能达到的目标。需求如同人生，这里面存在着复杂性、多边性、不稳定性等。随着项目的进行，需求在开发过程中或多或少都会留下一些缺陷，这是无法避免的。

4 定位

在开发和使用中，软件产品的用户可能会发生人员替换，新的用户有可能提出与原有用户不同的需求，这在维护期间和比较长的开发周期中往往会发生这一类的需求变更。

拿微信举个例子，在早期产品的定位是让用户发现“朋友”，主要推送摇一摇、附近的人等功能，而近两年，微信主要的产品定位是支付、小程序应用等，由于用户及功能定位变了，需求也随之需要改变。

5 认知

随着软件开发和使用，用户对软件领域有了更多的了解，这时他们所提出的要求也会越来越多，其中就加载着对原有需求的修改要求。在一个全新的领域或为一个没有软件开发经验的客户开发软件时，这种情况屡见不鲜。

6 竞品

在项目开发过程中有可能会出现竞品、类似的产品等等，这事往往需要开发者根据相关产品的情况，以此改变原有的需求和开发计划。

对于每一个项目经理来讲，需求变更是最正常不过的了，在需求开发之后冻结需求是不恰当的做法。但是，需求的变更可能会给项目带来很大的负面影响，随意的需求变更也是不恰当的做法。所以，我们首先要做的就是在形成需求基线后，进行需求的变更控制。

那么，如何控制需求变更呢？

1 授权

需求变更过程中，需要确认哪些人有权利提出需求变更？并控制需求变更人数，这样一来，大大解决了客户内部未达成一致就提出需求变更的问题。

2 审核

既然提出需求变更的要求，就要立即排出优先级，这意味着项目经理可以直观地分析出这些需求的重要性。审核的目的就是按照规则确定哪些立即修改？哪些以后逐步优化？对于核心模块的修改如果有了审核就可以严格把关，以免发生不良后果。

3 评估

每一次需求变更都是有代价的，所以需要评估变更对项目的时间成本、资金成本，以及质量等方面的影响，方便客户权衡利弊。

4 确认

评估后的结果要通知客户，并确认是否能够接受变更带来的影响。

只有通过上述的四个步骤之后，才会开始进行需求变更的后续执行，统一修改相关的文档和程序，最后进行测试和部署。

再一次说明，IT项目中需求变更是常见的问题，但变更控制不是为了让需求变更这件事更困难，而是让项目变得更为有序，方便之后工作员人的执行，否则就会出现恶劣的后果。看了这么多，相信你们也明白了，项目经理其实不害怕需求变更这件事，而是变更之后引发的一系列不确定的后果，从而让整体项目流产，这才是我们不愿见到的结局。

如有问题，欢迎在官方微信公众号留言，微信公众号搜索“外包大师”点击关注即可。