如何看待产品在开发、测试过程中加需求？

相信很多从事软件测试工作的小伙伴都遇到过这样的场景。本来工作一如既往的正常，产品突然在测试中又加了需求。这样的问题该如何看待？

图片来源于网络

1、个人心态上要拥抱变化。对于产品经理来说，一定不能抵制需求变更，而是要时刻拥抱变化，以有限的资源，最大限度的提高产品的价值，不断优化产品的功能，以不断完善和合理的实现方式来满足用户的需求。另外在需求变更的过程中，需要产品经理厚着脸皮去和开发沟通，也是锻炼自己抗打击能力的一种很好的方式。

图片来源于网络

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

图片来源于网络

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

图片来源于网络

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

图片来源于网络

5、做好需求评估。

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

图片来源于网络

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

来源：乐搏软件测试