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

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

       针对不同类型的项目，项目经理可以有如下的应对：

       对于实施类项目，在同时存在项目经理和产品经理的团队中，项目经理不要把需求沟通的工作全权交给产品经理，项目经理也必须参与需求收集、理解需求、讨论需求。

       尽量获得一手需求，站在项目落地风险的角度，帮助产品经理一起识别客户的伪需求和不合理的需求。

       要有质疑的勇气，否则等到错误的需求流转到交付团队，到时变更成本更高。

       如果是项目经理和产品经理一人兼任，那么理所应当需要留意这种情况。

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

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

       对于实施类项目，把做好的原型稿或视觉稿尽早展示给客户，并且和客户进行需求确认，邮件、微信、签字等方式都行，形式不限。

       对于产品类项目，重视原型稿和视觉稿评审。

       要让问题在项目早期暴露出来，问题发现得越晚，处理成本越高。

       3、预留时间buff。

       既然需求变更是不可避免的事实，那么，项目经理在排期时就需要留有一定的时间buff。

       这个buff应该留多长?可以基于你对客户的认知、对需求的理解，通过自己判断或团队核心成员讨论得出。总之，排期时留些buff是很有必要的。

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

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

       项目经理可以从项目管理四要素出发，看下能改变哪一个要素：

       是降低系统的质量要求?——比如留些bug以后处理。

       是改变项目的交付范围?—— 比如多了一个功能进来总得砍一个出去。

       是延长项目的交付时间?

       还是改变实现功能的方式?

       给出合理的需求处理解决方案，是项目经理综合能力的体现。

       另外，别忘了一件重要的事情，就是把变更的后续跟进方案通知到整个团队，并且存档变更纪录。

       经常遇到需求小范围讨论完就改掉的情况，但是测试人员并没有通知到位，导致上线后才发现问题。项目经理需要有机制让团队避免这种情况。

       5、变更研发交付方式。

       如果项目的需求就是要经常变更，还有一种常见的办法就是把瀑布流的研发交付方式改成敏捷交付或迭代交付，小步跑，多优化，主动拥抱需求的变更。

       首先需要想想为什么会出现这种情况，可能的原因有：业务方提出需求的时候没想清楚，过程中想到了就马上提。

       业务方在没看到任何产出的时候，没有实际感受，等做一半的时候看到一些内容突然有感觉了，有新的想法;有时候是完全拍脑袋的有些新的想法，其实未必真的需要做。

       可以考虑应对的措施：

       1、接到需求的时候，先根据自己对业务的理解，尽可能的考虑有可能会出现争议或者变更的地方，进行确认。

       2、需求评审的时候尽量多提问题，促使业务方/需求提出方多思考各种场景，收集更广泛的意见。

       3、利用中度保真的原型，让业务方有真实的感受，让他们把想到的问题提出来。

       以上几个点，其实并不是让变更变少了，而是化被动为主动，在更前置阶段主动的把可能变更的点暴露出来。这样的好处一个是减少研发的返工，另一个是自己掌握节奏，而不是被拖着走。

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

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

       版权说明：

       1、特别声明：以上文章内容仅代表作者本人观点，不代表建米软件观点或立场。

       2、免责声明：本内容来自互联网相关创作者，不代表建米软件的观点和立场。

       3、文章版权：版权属于原作者所有，如有侵权、违规，可直接反馈本站，我们将立即删除。删除联系电话：400-8352-114