1、添加功能属于需求变更，会改变范围基准，需要走变更流程。我们一般是先记录下来，然后与团队以及核心相关方分析添加功能的价值，将结论告知变更发起人，变更如果没有价值，发起人一般会撤消，如果有积极价值或者发起人坚持，我们就发起变更申请，由变更控制委员会ccb来审核是否变更，通过则更新项目管理计划，实施变更通知相关方，不通过就通知发起人。
2、关于修改功能，先查看当前功能是否满足合同交付条件。
如果满足合同交付条件，再分析如果去修改会不会影响项目的进度、成本、范围，如果对项目没什么影响，可以顺手改之，那么我们为了维系客户关系，那就去改，如果对项目有影响，那我们就不要去改，说明对项目交付的影响，可以建议客户放到下一期里面优化相关功能。
如果当前功能不按照客户说的去改，项目就没有办法交付，要是出现这种情况那一定是前期需求没有做好。那就只能从新做需求。针对这种情况常用的解决办法有两个，第一个，可以用Axure等工具做出原型找客户确认，第二个，及时给客户演示汇报项目，听取客户意见，多与客户沟通。
难点：1）范围蔓延，客户经常性要求修改或添加小功能，出于维系客户关系去做了，积少成多造成项目范围蔓延超出预算甚至不能及时交付。我们先把合同上的功能实现了，优化的可以放到最后，有时间资源的话了再做，或者下一期项目再优化。2）客户需求不定多次变更，改来改去还要改，造成成本超支。其实这个可以和客户友好沟通的，这个项目就这些资源预算，我们如何确认需求，确认几次需求就要定下来。
结合例子说明一下。
