编辑导语：无论在项目制交付过程中，还是在产品制迭代过程中，需求变更都是一个无法规避的难题。本文作者对自己工作中涉及到需求变更的问题进行了总结，希望能给你带来帮助。

需求变更无论是在项目制交付过程中，还是在产品制迭代过程中，都是一个永远无法规避的难题。

频繁的需求变更不仅会造成进度风险、成本风险，还会引起“舆情风险”让内外人员都产生不可控的负面影响。

虽然无法避免，但我们还是可以通过自己的成长和技巧尽量避免，或把变更引起的负面结果控制到可接受范围内。今天我把自己工作中所涉及到需求变更的问题进行总结，希望能对大家有所帮助。如有不完善之处还请留言指正。

01 为什么会出现需求变更？

需求变更的原因有很多，不过总结来看无外乎是需求/产品人员自身的问题：

在需求分析、设计、评审阶段，对场景和解决方案的考虑不全面，对政策、市场调研不准确。或是某些功能缺失、或者业务逻辑不闭环；还有一些细节问题没有提前想到，导致在后期落地的时候发现了。

也可能有关联方需要配合改造的内容没有调研清楚，后期发现对方无法配合推进；或是系统内的关联功能改造范围评估不准确，后期发现这种方案会伤筋动骨，在落地过程中开发团队发现实现难度过大，周期或成本不可控等。

尤其是在评审过程中研发组、关联方、客户等角色没有认真听，仔细想。后面真正需要大家配合时才发现有问题。

以上所列的需求分析过程中的完成度不够，能占到后期变更的大多数因素。

当然还有一些其他原因：比如政策或市场变动。在设计阶段方案没有问题，但是在落地过程中，政策变了、市场动向变了、用户要解决的痛点升级了，最终都指向——需求变了。

还有很玄学的原因，比如领导的想法变了（无论甲方、乙方）。

02 对待需求变更应有的态度

如果变更的原因是自己的问题，那勇于承认、积极应对，同时事后要反思、提升、避免。切勿推卸责任，搞得大家都不愿意再配合你、协助你。

如果变更是因为外部无法拒绝的原因，就要从情绪上尽快接纳、尽快设计新的解决方案。因为对于一些无法拒绝的变更，负面情绪不仅无效，反而更容易让事态发展走向不可控。

03 一些能用到的方法

掌握结构化思维能力（下个月会单独做结构化思维的总结）。在方案产出阶段，要先想，先想好，想全面之后，和关键人员碰撞之后，再落笔写文档。就像开发写代码时一样，一定要先做设计、评审通过之后再开撸。因为我们在写文档的过程中，容易陷入具体的功能逻辑里，而缺少了宏观的整体性考量，非常容易让产出物不严谨。

和关联系统充分沟通。不要不好意思，不要嫌麻烦，得不到的答案一定要追问，自己协调不了的一定要上报。现在多做一点，多确认一个问题，能给后面整体过程节省很多时间和成本。

和开发人员尤其是项目经理、技术经理之类的关键角色充分沟通。沟通方案可行性，沟通方案落地难度，同时考量他们提出的修改意见。当然在这个过程中可能会遇到两难境地，但既然我们是一个团队，总要内部协商出可行性方案。

保持与客户的及时互动。清晰客户的需求本质，并向客户整体介绍清楚我们方案的思路，最终评判此思路是否能得到客户的认可。这个过程中也会涉及到如何进行需求洞察、如何进行方案讲解等问题。

让方案直观易懂，才能让“干系人”提出建设性意见。在向客户、项目组内讲解、探讨设计方案时，界面类的功能尽量用原型图、UI图等直观的表达模式，让大家更有概念；后台类的功能尽量用流程图、时序图、数据流图之类的表现形式进行讨论，从而保证大家理解达成一致。最不济，拿个白板或者厕纸快速画一画，总比干巴巴凭空讲解效果要好很多。

变更，也有多种变更方式。当真的遇到需求产生变化，或者领导要新增需求时，先看此需求的真实程度，是否是“伪需求”，现有功能是否可以“曲线救国”，从而引导不做。其次评估此需求的迫切程度，对现有需求的影响范围，再看能否基于现有需求最小化解决，同时还可以提出能否用新功能置换出一定比例的非关键功能，从而保证进度及工作量不至于偏离过大。

04 总结

我们能做的是尽量减少因为自己工作不到位而引起的需求变更，同时在真正遇到变更时能够更快更合理的拿出最小化执行方案。

需求变更出现越早，此次变更的影响才会越小。因此我们在分析、设计、评审等“前阶段”尽早的识别风险、丰满方案，才能让后期变更的可能性降低。

当然，控制变更和控制蔓延是两回事，我在整理的时候有些内容更像是控制蔓延、应对蔓延的方法，在本文中就都删掉了，后续会再单独整理。

在我看来，需求人员因为自身原因导致的一些变更，可以类比于开发人员写代码时出现了bug。既可以避免，又不好杜绝。既要杜绝躺平，又要以积极平和的心态处理。

同时在发生变更之后，一定要有据可查，并及时通知所有干系人，否则难免在后期别人突然发现这里产生变更时，对相关人员一顿“输出”。

当一个需求人员能够减少、控制、应对好需求变更，那一定是一位高水平选手。