如何对待需求变更？

---

虽然经过了严格的需求调研，深入的需求分析，但在产品开发过程中，还是会存在需求变更。作为产品经理一定要认真对待需求变更，通过合理的方法控制需求变更的节奏，尽量减轻需求变更对产品和项目的影响。

一、什么是需求变更？

需求变更是指用户或产品经理对软件功能或非功方面提出的更改要求。通常是发生在需求分析完成，产品还未开发或正在测试的过程中。如果产品已经上线或发布，一般再提出更改就不是需求变更，而是新需求了。对于需求变更的发起人员，通常是用户或产品经理。在项目进行的过程中，可能是用户对之前的需求有了新想法，也可能是产品经理对之前功能的实现方式有了新方案，都会产生需求变更。而需求变更通常会影响到项目的时间、成本或质量，如果某些功能已经进入到了开发阶段，需求变更的内容越多，时间越晚，造成的影响也会越大。

二、为什么会有需求变更？

需求变更其实不是变更的需求，而是变更的实现方式。对于需求的实现方式，没有最合理，只有更合理。随着信息的增加和思考的深入，需求变更在所难免。对于互联网产品，需求变更通常由产品经理提出，而对于项目型产品，用户也可以直接提出需求变更。所以总体来说，需求变更主要来源于软件、用户和产品经理。

1、软件可以随意更改的特性。 软件相对于硬件，最大的特点就是可以随意更改，或者说更改的成本相对要小。一辆汽车或一部手机，生产出来后，硬件就基本定型了，你可以根据自己喜好选择不同的产品，但一般不会要求更改产品的形状、大小、功能等，但软件在开发过程中，用户却可以相对容易提出更改需求。用户可以直接和软件设计者沟通，表达自己的需求变更，而对于硬件设备，用户面对的是销售商，一般无法直接和设计或生产者沟通。软件不是标准化产品，尤其对于TO B型软件来说，更是完全响应用户的需求。在软件开发的过程中会进行需求变更，软件发布以后还会进行版本迭代。虽然硬件产品，也可能进行版本的迭代，但周期一般都会比软件长很多。

2、用户表达不全面。 这里所说的用户表达不全面，并不是怪罪用户为什么不把需求表达完善，而是对于需求调研，无论是用户访谈和可用性测试，还是问卷调查和数据分析，目的都是为了能更深入和全面的了解用户的需求，但由于用户不专业或表达不全面，都会造成需求遗漏或对需求的理解不同，从而导致在开发的过程中出现需求变更。而用户无论是提出新需求还是需求变更，只要产品未交付，需求都有可能随时提出，用户不会考虑这个功能是否已经开发或会造成多大的项目影响，通常当用户提出需求变更后，都需要产品经理进行评估，并和用户进行解释和沟通。

3、需求调研不充分，需求分析不深入。 需求调研和需求分析，都是为了设计实现方案，通过产品功能来满足需求。当用户提出需求变更时，就说明了一个问题，前期的需求调研不充分，没有全面挖掘用户的需求，或者是需求分析不深入，没有以更好的方式实现用户的需求。所以，作为产品经理，一定要认真对待需求调研和需求分析，只有打牢根基，才有可能做出相对完善的产品，只有前期工作充分，才有可能保持产品的开发节奏，使产品和项目顺利完成。

三、如何对待需求变更？

以上图片，很大程度上说明通常情况下产品经理对用户提出需求变更时的态度以及产品开发对产品经理提出需求变更时的态度。正因为如此，我们更应该以客观的态度面对需求变更。

1、个人心态上要拥抱变化。

从古至今，世界唯一不变的就是变化。尤其互联网时代，信息大爆炸，各种各样的产品层出不穷，对于软件产品来说，更是唯快不破，需要持续满足用户的需求。所以对于产品经理来说，一定不能抵制需求变更，而是要时刻拥抱变化，以有限的资源，最大限度的提高产品的价值，不断优化产品的功能，以不断完善和合理的实现方式来满足用户的需求。另外在需求变更的过程中，需要产品经理厚着脸皮去和开发沟通，也是锻炼自己抗打击能力的一种很好的方式。

2、与用户明确变更范围和变更方式。

既然需求变更无法消除，就要在开始之前和用户沟通好需求变更的范围和变更方式。例如哪些种类的需求可以变更，哪些种类的需求需要通过合同约定，什么样的需求会影响开发周期，什么样的需求会增加开发成本等。提前和用户沟通清楚，也可以让用户有一个合理的预期，避免在后期需求变更时产生矛盾。

3、增加需求分析时间。

充分的需求分析，是减少需求变更的最有效的方式。大多数情况项目的时间是确定的，为了给开发留有足够的时间，往往会压缩产品经理需求分析的时间。大部分人认为需求分析只是出一个需求文档，在开始前预计的时间就不多，导致需求分析不充分，后期需求变更就会增多。所以，对于产品经理，除了要增加需求分析的时间外，也要在需求分析完成之后，最好在留一段发酵的时间，让需求在自己脑海中再消化一下，当发现有需要更改的地方及时修改，也可以减少后期需求变更的数量。

4、细化需求评审。

当需求分析完成后，一定要进行需求评审，要让所有项目干系人都参与。但大部分情况是产品经理在上面对着需求文档念，下面相关人员在看手机，真正关心的人并不多。这并不是别人的错，而是产品经理没有把产品原型做到位。需求评审前要尽量做出可操作和观看的产品，最好是带交互的原型，让大家都可以直观的看到，甚至可以操作和感受，这样才会激发大家的兴趣，也会提出一些比较合理的建议，从而减少后期需求变更的次数。

5、做好需求评估。

虽然要拥抱需求变更，但肯定不是什么需求变更都要做。首先要对需求变更进行详细的评估，是否满足产品的定位，是否合理。其次是要掌握好需求变更的时机，如果是在需求分析阶段，不会产生开发成本，一但某个功能已经在开发了，或者已经开发完成了，再进行需求变更，必然带来开发成本。具体成本的大小要看功能开发的工作量。如果是在产品即将发布的阶段，无论多么重要的需求变更，都尽量放到下个版本迭代。

总结

需求变更是一把双刃剑，一方面可以优化产品功能，提高用户体验，另一方面又会增加开发成本，打击团队士气。所以，一定要正确对待需求变更，通过调整心态、与用户充分沟通、增加需求分析时间、细化需求评审和做好需求评估的方式来最大化减少需求变更带来的影响，但不要用制度来限制需求变更。之前听过一个产品经理自豪的说，产品的最终形态就是他最初的需求分析，没有经过一次需求变更。这种情况有两种可能，一是他确实很牛，把所有的需求都考虑到了，根本不用需求变更，另一种可能是整个团队都在抵制需求变更，逃避功能优化。而在我看来，更大的可能是后一种情况。对于产品经理来说，虽然要尽量减少需求变更，但不排斥需求变更，让自己保持开放和理性才是应有的态度。

作者：时间之树 / 产品经理的思维方式