项目想要开展，首先就需要知道客户想要什么，即：需求。但是随着进度的发展，项目的需求也不是一层不变的。那么当项目需求一定要变更，究竟要如何应对呢?
变更研发交付方式
如果项目的需求就是要经常变更，还有一种常见的办法就是把瀑布流的研发交付方式改成敏捷交付或迭代交付，小步跑，多优化，主动拥抱需求的变更。
首先需要想想为什么会出现这种情况，可能的原因有：业务方提出需求的时候没想清楚，过程中想到了就马上提。
业务方在没看到任何产出的时候，没有实际感受，等做一半的时候看到一些内容突然有感觉了，有新的想法;有时候是完全拍脑袋的有些新的想法，其实未必真的需要做。
精简的规格说明
有时，客户并不明白需求分析有如此重要，于是只作一份简略之至的规格说明，仅涉及了产品概念上的内容，然后让开发人员在项目进展中去完善，结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明。这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况。
但在大多数情况下，这会给开发人员带来挫折，也会给客户带来烦恼。
预留时间
既然需求变更是不可避免的事实，那么，项目经理在排期时就需要留有一定的时间buff。
这个buff应该留多长?可以基于你对客户的认知、对需求的理解，通过自己判断或团队核心成员讨论得出。总之，排期时留些buff是很有必要的。
可以考虑应对的措施
接到需求的时候，先根据自己对业务的理解，尽可能的考虑有可能会出现争议或者变更的地方，进行确认。
需求评审的时候尽量多提问题，促使业务方/需求提出方多思考各种场景，收集更广泛的意见。
利用中度保真的原型，让业务方有真实的感受，让他们把想到的问题提出来。
以上几个点，其实并不是让变更变少了，而是化被动为主动，在更前置阶段主动的把可能变更的点暴露出来。这样的好处一个是减少研发的返工，另一个是自己掌握节奏，而不是被拖着走。
优化流程，如果公司有复盘环节，可以整理下最近几个版本出现的这种变更带来的低效，反向推动业务部门在提出需求的时候内部先跑一下评审，在流程机制上促使业务方提出需求的时候多思考。
锻炼自己快速判断价值和优先级的能力，有些点其实做不做影响都不大，拍脑袋出来的想法，能快速PK掉就PK掉，避免让业务/需求方将自己看做是接收器，而是有判断力有思考的项目经理。