需求频繁变更，项目经理该如何处理？

1、预防为主，从需求源头做起

针对不同类型的项目，项目经理可以有如下的应对：对于实施类项目，在同时存在项目经理和产品经理的团队中，项目经理不要把需求沟通的工作全权交给产品经理，项目经理也必须参与需求收集、理解需求、讨论需求。尽量获得一手需求，站在项目落地风险的角度，帮助产品经理一起识别客户的伪需求和不合理的需求。要有质疑的勇气，否则等到错误的需求流转到交付团队，到时变更成本更高。如果是项目经理和产品经理一人兼任，那么理所应当需要留意这种情况。

对于产品类项目，需求的相关工作以产品经理为主导，项目经理可以少操些心，但是当交付过程中发现需求频繁变更时，项目经理就得多留意需求分析阶段产品经理的产出物了。

2、重视原型稿评审，重视需求确认

对于实施类项目，把做好的原型稿或视觉稿尽早展示给客户，并且和客户进行需求确认，邮件、微信、签字等方式都行，形式不限。对于产品类项目，重视原型稿和视觉稿评审。要让问题在项目早期暴露出来，问题发现得越晚，处理成本越高。

3、预留时间buff

既然需求变更是不可避免的事实，那么，项目经理在排期时就需要留有一定的时间buff。这个buff应该留多长?可以基于你对客户的认知、对需求的理解，通过自己判断或团队核心成员讨论得出。总之，排期时留些buff是很有必要的。

4、从四要素思考处理方案

如果团队决定接受这个需求，项目经理接下来就要看团队怎么处理这个需求了。

项目经理可以从项目管理四要素出发，看下能改变哪一个要素：是降低系统的质量要求?——比如留些bug以后处理、是改变项目的交付范围?—— 比如多了一个功能进来总得砍一个出去、是延长项目的交付时间?还是改变实现功能的方式?

给出合理的需求处理解决方案，是项目经理综合能力的体现。另外，别忘了一件重要的事情，就是把变更的后续跟进方案通知到整个团队，并且存档变更纪录。经常遇到需求小范围讨论完就改掉的情况，但是测试人员并没有通知到位，导致上线后才发现问题。项目经理需要有机制让团队避免这种情况。

5、变更研发交付方式

如果项目的需求就是要经常变更，还有一种常见的办法就是把瀑布流的研发交付方式改成敏捷交付或迭代交付，小步跑，多优化，主动拥抱需求的变更。首先需要想想为什么会出现这种情况，可能的原因有：业务方提出需求的时候没想清楚，过程中想到了就马上提。业务方在没看到任何产出的时候，没有实际感受，等做一半的时候看到一些内容突然有感觉了，有新的想法;有时候是完全拍脑袋的有些新的想法，其实未必真的需要做。

可以考虑应对的措施：

1）接到需求的时候，先根据自己对业务的理解，尽可能的考虑有可能会出现争议或者变更的地方，进行确认
2）需求评审的时候尽量多提问题，促使业务方/需求提出方多思考各种场景，收集更广泛的意见项目管理论坛
3）利用中度保真的原型，让业务方有真实的感受，让他们把想到的问题提出来
　　
以上几个点，其实并不是让变更变少了，而是化被动为主动，在更前置阶段主动的把可能变更的点暴露出来。这样的好处一个是减少研发的返工，另一个是自己掌握节奏，而不是被拖着走。

4、优化流程，如果公司有复盘环节，可以整理下最近几个版本出现的这种变更带来的低效，反向推动业务部门在提出需求的时候内部先跑一下评审，在流程机制上促使业务方提出需求的时候多思考。

5、锻炼自己快速判断价值和优先级的能力，有些点其实做不做影响都不大，拍脑袋出来的想法，能快速PK掉就PK掉，避免让业务/需求方将自己看做是接收器，而是有判断力有思考的项目经理。

8月起，《项目管理知识体系指南(PMBOK指南)(第七版)》将成为中国大陆地区PMI认证考试参考资料。与上一版相比，《PMBOK指南(第七版)》有较大调整，首次提出了项目管理的 12 项原则和8个项目绩效域，构建了一个专注交付成果、更全面的项目管理知识体系框架。它将帮助从业者更好应对当下灵活多变的环境，选择正确的项目管理方法（预测型、敏捷或混合型）来完成工作交付价值。

《PMBOK指南(第七版)》的中文版和英文版书籍已正式引入中国大陆地区，并将从2023年8月起，成为项目管理专业人士(PMP)认证考试等PMI认证的考试参考资料之一。

新版考试题目为180道题；
考试时间为230分钟；
题型将包括单选题和多选题，多选题将说明需选择几个正确选项。