观点：如何看待项目的需求变更和应对方法

需求变更可能产生的原因

1需求表达不到位。

2没有与客户认真沟通需求。

3需求理解不正确。

4没及时让客户参与。

早发现，早应对

我们身处软件工业时代这个令人振奋的时代，却面临着遗留系统这个令人尴尬的难题。事情总是这样的：软件最开初开发的时候总是非常清晰，清晰的需求、清晰的设计、清晰的代码，清晰的程序结构让人赏心悦目，甚至有些自我陶醉。

随后，软件开始需求变更，每变更一次软件的质量就下降一次。这样，软件经过数次的变更以后，需求文档变得模糊不清，设计思路跟不上变更的脚步，程序代码则随着业务逻辑的复杂而臃肿不堪，程序员开始读不懂代码，软件开发工作变得不再是一种乐趣。随着时间的推移，经过数年、数十次的需求变更，情况变得越来越糟，软件质量像滚雪球一样直线下降。

针对需求变更要早发现、早应对。

需求变更避免不了，既然不能避免，那我们就要敢于直面惨淡的人生。

引入需求变更管理机制,以降低需求变更带来的风险。需求变更管理的核心是减少变更所产生的影响，而非消灭变更。

通过变更管理可以降低开发返工、重工的工作量，以减少项目风险。

需求变更属于需求管理范围，同时也属于风险控制范围，对于产品经理要随时关注产品，定期对需求进行跟踪，做到“早发现、早治疗”，以防病入膏肓后才下手。

对已变更的需求要做到文档标记更新，编写需求变更说明，保证需求与开发工作一致，不要出现“两层皮”的现象。从技术角度考虑，技术架构要做到可扩展，以弹性的架构来解决变更的需求，把变更造成的影响降到最低。

需求变更流程

当发生变更时，正规的流程需要走变更申请，申请后组织人员对变更进行分析、评审，以判断变更是否必要，对项目的影响有多大。又必要又紧急的需求要排到开发计划中，尽快安排开发；对必要不紧急的需求要考虑是否可以放到下一版本安排开发；对紧急不必要的需求，要根据项目实际情况考虑，是否可以不要？对不紧急也不必要的需求应该直接砍掉，无须变更。评审完成后，对于需要安排开发的变更需求，先整理变更需求说明书，以帮助开发人员、测试人员了解变更内容，指导技术人员开发。

如何分析需求变更的合理性？从哪些方面着手？

从业务方面分析。需求变更基本都是因业务变化而产生的，当发生变更时，我们也要从业务角度多思考，变更的是否合理，是否必要，与产品定位是否相符，能给产品带来哪些好处？如果不做变更是否可以？

从技术方面分析。变更会对开发有多大影响，需求变更的部分是否已经开发？开发到什么程度？工作量多少？是否可以通过技术框架的扩容性很好的解决变更？

从项目方面分析。从项目角度考虑，变更会使项目的时间、资源、费用上产生多大影响？影响是否能够承受？本次变更的需求必须本版本开发完，还是可以放到下一版本迭代开发？

从以上三方面分析清楚后，变更的需求脉络也就理清了，变与不变、现在变还是以后变也能分析得透彻。

总结

需求变更对每一位产品人来说都会经常遇到，产生变更的原因很多，有外在的、有内在的，但不论是因为什么产生的变更，遇到了就要正确的、合理的分析、评估，给项目以正确的指导。

如果项目前期进行了大量的调研、跟踪、分析、评审，并请客户尽早参与，许多变更是可以避免的。

如果，技术框架设计的可扩展，程序设计的可扩容的话，当发生变更时也可以把变更对项目产生的影响控制到最小。

防微杜渐、未雨绸缪，还是那句话：“早发现、早治疗”。