需求变更的一般性处理方法

需求变更通常由信息传递偏差、产品经理前期思考不足、需求文档质量不高、评审会细节讨论不到位、开发测试中发现设计与预期不符、业务形态变化等原因引起。为减少变更，需加强与业务方的沟通确认、深入理解业务、做好需求调研与风险评估，并在变更时及时通知项目组，合理规划变更方案，确保项目资源的有效利用。

为什么存在需求变更？

众所周知，开发小哥往往是听到“需求变更”脸色都变了。需求变更有外界的因素（eg：对接不当），也有自身的因素（eg：优化策略）；针对于这两者，都可能存在需求变更。

需求变更并不是越多越不好，而是一种风险规避的方式，在项目的进展阶段，越早进行变更，则能够将未来发生的风险降到最低，也能够使需求真正达到原本的目的，解决实际的问题。

但需求变更存在项目资源的浪费，所以原则上，能少则少，若有必要，及早变更。

产生需求变更的因素有很多，其中包括一下几点：

1. 信息传递有偏差，一般发生在与业务方对接需求的时候，导致需求方向错误，且没有经过逐次确认。
2. 产品经理前期对业务思考不足，导致设计出的需求无法解决现有问题。
3. 撰写需求文档时，逻辑性、完整性、合理性等颇有不足，导致文档不符合开发标准。
4. 评审会上对需求的细节没有讨论到位，排期评估上对需求的评估也有偏差，导致需求在开发当中需要及时调整。
5. 在开发或测试的过程中，当需求涉及到真实数据的时候，发现产品原本的设计方案与预期设想的不同，于是需要进行变更。
6. 业务形态发生变化，当在需求的开发过程中，公司的商业模式或运营模式发生改变，则产品也需要进行及时调整方向。

上述六点需求变更的原因中，除了第五、六点，其他方面基本都是可以通过一定方法来减少需求变更的频次的，第五点的变更原因，则是为了更好地达到原本的需求效果。

如何减少需求变更？

1. 涉及业务方的需求，在前期对接，且需求产出之后，与业务方确认需求方案是否满足业务。
2. 加强对自身业务的了解，多查看行业内的报告，了解自身产品实际数据、运营情况，业务发展方向，从而能够更好地对业务需求进行决策。
3. 做需求之前进行充足的需求调研、需求风险评估，需求成本评估等。
4. 评审会前、评审会中、评审会后三个阶段，产品经理都需要及时的进行需求疑问点的沟通及确认，避免因需求完整性、逻辑性、合理性而产生的问题。
5. 对于需求内容，往往需求撰写者深陷其中，无法直观发现问题，可以内部进行评审/讨论，从而在需求评审前解决掉需求文档本身存在的问题。
6. 产品设计中，多留意往常需求变更的原因（例如后台的设计等），灵活总结变更前后特点，做产品需求的设计时多注重灵活性。

需求变更需要做的事情？

一个需求变更，往往不是一瞬间的事，而是一个过程。

在产品经理察觉到需求需要变更时，则需要做几个步骤

1. 预先周知项目组该部分内容可能产生变更，若正在开发，则需要及时中止需求，避免投入更多的资源。
2. 保证需求合理性的情况下，尽量在最短时间内处理变更方案
3. 周知项目组相关人员变更背景，变更内容，变更影响点；同时项目组重新评估需求

做到这三步，才算是需求的变更结束。（往往大家容易遗漏掉第一步，导致部分的项目资源浪费，因为在意识到需求需要变更的时候，距离变更后的方案还需要一段思考及修改方案的时间。）