软件研发项目的需求本身就有模糊、变化、主观、不确定这些特征，相较于制造、建筑等传统产业，客户变更软件需求，是软件开发与生俱来的特性，是一个无法避免的事实。
结合个人经验，总结如下：
为了保证项目高质量、高效率完成交付，达到客户满意的效果，需要在项目规划阶段制定《项目需求范围说明书》，明确项目需求。实际项目执行过程中，不管怎么规划，由于商务合同和客户需求变更，难免会造成需求蔓延。对于不同场景下的需求蔓延，需要根据具体问题具体分析，制定相应的应对措施：
一.销售挖坑
在项目市场拓展阶段，销售人员为了拿下项目，客户不管提出什么样的需求，都承诺能够完成，后续实际交付过程中，承诺的需求由于没有预先评估，最终造成项目范围蔓延，成本增加。为了避免此类问题出现，结合《IT售前工程师修炼之道》学习总结，建议如下：
1.尽早参与项目
作为项目经理，最好能在售前阶段参与项目支撑，了解客户的需求；同时，介入商务合同签订工作，由于商务合同涉及到项目交付物及验收标准流程，所以，制定一份合理的商务合同对于后续顺利完成交付是一个保证。
2.完成售前工作交接
若没有计划参与售前支撑工作，项目拿下后，在售前移交到交付环节时，项目经理需要搞清楚需求交接内容，同时深入推演和探索潜在需求，制定解决方案，避免后续无法应对。
3.形成文字和材料集合
依据商务合同，制定合理的《项目需求范围书》，并以此作为依据，与客户完成双方确认，作为后续验收交付的依据。
二.客户需求变更
由于客户前期需求不明，在实际交付阶段，随着系统上线，客户根据使用的过程，会不断提出各种优化需求。对于客户的需求变更，根据不同场景，需要采用不同的举措应对，结合《敏捷软件需求》，总结如下：
1.建立需求变更流程
首先，双方制定负责对接项目的干系人，所有的需求变更都经过负责人审核无误后方可执行。
其次，采用合适的沟通渠道和时间节点评估需求。比如：客户每周统一收集需求，并在周五将收集的需求以邮件的形式反馈给项目经理。
然后，项目经理组织研发对需求评估。根据需求的紧急度和范围采用不同的举措，符合变更需求标准的按照优先级排序。
最后，对于确认的变更需求，排期优化升级。
2.客户提出需求范围外的
（1）安排后端研发评估，根据评估的工作量确定是否报备给领导。比如：客户提出的变更需求，只需要1人天工作量即可完成，那完全可以满足；若客户提出不增加预算的情况下，新增一个模块，评估工作量需要超过5天，这时候需要报备给领导，由上级决定是否支撑。
（2）按照变更流程，通过邮件，做到事事留痕。
（3）若领导不同意，展现项目经理情商的时候到了，需要不断的跟客户周旋，将实施以后造成的影响同步给客户，同时，引导客户项目二期规划。
3.交付验收后的优化需求
（1）接受刚开始提出的优化需求，同时进行过滤。对于交付验收后的优化需求，按照合同条款，可以不去做。实际执行过程中，由于甲方的强势和商务合同的范围模糊，往往造成需求无法界定的范围，所以考虑到客情关系，可以以专家的身份，参考合同核对，对于合同范围内的，无条件满足；范围外的，选择性的去做。
（2）降低反复提出“优化需求的可能性”。
增加试用时间，你们也可以安排产品或者运营同客户一起去操作，充分发现待优化需求。
其次，可以和你们的商务打配合，红黑脸策略，一个要推收款，解散项目团队去做其他项目，一个从客户关系角度去满足他们的优化需求，让客户觉得不断给你们提优化需求很麻烦，倒逼客户这个阶段把要优化的内容想清楚，降低反复提出优化需求的可能性。
这个阶段的优化需求确定一定要正式，商务对商务。
（3）后续商务合同中列清交付验收物与明细。
