需求頻繁變更，項目經理該如何處理？
發布時間：2021/6/2 9:42:00
1、預防為主，從需求源頭做起。
針對不同類型的項目，項目經理可以有如下的應對：
對于實施類項目，在同時存在項目經理和產品經理的團隊中，項目經理不要把需求溝通的工作全權交給產品經理，項目經理也必須參與需求收集、理解需求、討論需求。
盡量獲得一手需求，站在項目落地風險的角度，幫助產品經理一起識別客戶的偽需求和不合理的需求。
要有質疑的勇氣，否則等到錯誤的需求流轉到交付團隊，到時變更成本更高。
如果是項目經理和產品經理一人兼任，那么理所應當需要留意這種情況。
對于產品類項目，需求的相關工作以產品經理為主導，項目經理可以少操些心，但是當交付過程中發現需求頻繁變更時，項目經理就得多留意需求分析階段產品經理的產出物了。
2、重視原型稿評審，重視需求確認。
對于實施類項目，把做好的原型稿或視覺稿盡早展示給客戶，并且和客戶進行需求確認，郵件、微信、簽字等方式都行，形式不限。
對于產品類項目，重視原型稿和視覺稿評審。
要讓問題在項目早期暴露出來，問題發現得越晚，處理成本越高。
3、預留時間buff。
既然需求變更是不可避免的事實，那么，項目經理在排期時就需要留有一定的時間buff。
這個buff應該留多長?可以基于你對客戶的認知、對需求的理解，通過自己判斷或團隊核心成員討論得出。總之，排期時留些buff是很有必要的。
4、從四要素思考處理方案。
如果團隊決定接受這個需求，項目經理接下來就要看團隊怎么處理這個需求了。
項目經理可以從項目管理四要素出發，看下能改變哪一個要素：
是降低系統的質量要求?——比如留些bug以后處理。
是改變項目的交付范圍?—— 比如多了一個功能進來總得砍一個出去。
是延長項目的交付時間?
還是改變實現功能的方式?
給出合理的需求處理解決方案，是項目經理綜合能力的體現。
另外，別忘了一件重要的事情，就是把變更的后續跟進方案通知到整個團隊，并且存檔變更紀錄。
經常遇到需求小范圍討論完就改掉的情況，但是測試人員并沒有通知到位，導致上線后才發現問題。項目經理需要有機制讓團隊避免這種情況。
5、變更研發交付方式。
如果項目的需求就是要經常變更，還有一種常見的辦法就是把瀑布流的研發交付方式改成敏捷交付或迭代交付，小步跑，多優化，主動擁抱需求的變更。
首先需要想想為什么會出現這種情況，可能的原因有：業務方提出需求的時候沒想清楚，過程中想到了就馬上提。
業務方在沒看到任何產出的時候，沒有實際感受，等做一半的時候看到一些內容突然有感覺了，有新的想法;有時候是完全拍腦袋的有些新的想法，其實未必真的需要做。
可以考慮應對的措施：
1、接到需求的時候，先根據自己對業務的理解，盡可能的考慮有可能會出現爭議或者變更的地方，進行確認。
2、需求評審的時候盡量多提問題，促使業務方/需求提出方多思考各種場景，收集更廣泛的意見。
3、利用中度保真的原型，讓業務方有真實的感受，讓他們把想到的問題提出來。
以上幾個點，其實并不是讓變更變少了，而是化被動為主動，在更前置階段主動的把可能變更的點暴露出來。這樣的好處一個是減少研發的返工，另一個是自己掌握節奏，而不是被拖著走。
4、優化流程，如果公司有復盤環節，可以整理下最近幾個版本出現的這種變更帶來的低效，反向推動業務部門在提出需求的時候內部先跑一下評審，在流程機制上促使業務方提出需求的時候多思考。
5、鍛煉自己快速判斷價值和優先級的能力，有些點其實做不做影響都不大，拍腦袋出來的想法，能快速PK掉就PK掉，避免讓業務/需求方將自己看做是接收器，而是有判斷力有思考的項目經理。