需求頻繁變更，項目經(jīng)理該如何處理？

1、預防為主，從需求源頭做起。

針對不同類型的項目，項目經(jīng)理可以有如下的應對：

對于實施類項目，在同時存在項目經(jīng)理和產(chǎn)品經(jīng)理的團隊中，項目經(jīng)理不要把需求溝通的工作全權(quán)交給產(chǎn)品經(jīng)理，項目經(jīng)理也必須參與需求收集、理解需求、討論需求。

盡量獲得一手需求，站在項目落地風險的角度，幫助產(chǎn)品經(jīng)理一起識別客戶的偽需求和不合理的需求。

要有質(zhì)疑的勇氣，否則等到錯誤的需求流轉(zhuǎn)到交付團隊，到時變更成本更高。

如果是項目經(jīng)理和產(chǎn)品經(jīng)理一人兼任，那么理所應當需要留意這種情況。

對于產(chǎn)品類項目，需求的相關(guān)工作以產(chǎn)品經(jīng)理為主導，項目經(jīng)理可以少操些心，但是當交付過程中發(fā)現(xiàn)需求頻繁變更時，項目經(jīng)理就得多留意需求分析階段產(chǎn)品經(jīng)理的產(chǎn)出物了。

2、重視原型稿評審，重視需求確認。

對于實施類項目，把做好的原型稿或視覺稿盡早展示給客戶，并且和客戶進行需求確認，郵件、微信、簽字等方式都行，形式不限。

對于產(chǎn)品類項目，重視原型稿和視覺稿評審。

要讓問題在項目早期暴露出來，問題發(fā)現(xiàn)得越晚，處理成本越高。

3、預留時間buff。

既然需求變更是不可避免的事實，那么，項目經(jīng)理在排期時就需要留有一定的時間buff。

這個buff應該留多長?可以基于你對客戶的認知、對需求的理解，通過自己判斷或團隊核心成員討論得出。總之，排期時留些buff是很有必要的。

4、從四要素思考處理方案。

如果團隊決定接受這個需求，項目經(jīng)理接下來就要看團隊怎么處理這個需求了。

項目經(jīng)理可以從項目管理四要素出發(fā)，看下能改變哪一個要素：

是降低系統(tǒng)的質(zhì)量要求?——比如留些bug以后處理。

是改變項目的交付范圍?—— 比如多了一個功能進來總得砍一個出去。

是延長項目的交付時間?

還是改變實現(xiàn)功能的方式?

給出合理的需求處理解決方案，是項目經(jīng)理綜合能力的體現(xiàn)。

另外，別忘了一件重要的事情，就是把變更的后續(xù)跟進方案通知到整個團隊，并且存檔變更紀錄。

經(jīng)常遇到需求小范圍討論完就改掉的情況，但是測試人員并沒有通知到位，導致上線后才發(fā)現(xiàn)問題。項目經(jīng)理需要有機制讓團隊避免這種情況。

5、變更研發(fā)交付方式。

如果項目的需求就是要經(jīng)常變更，還有一種常見的辦法就是把瀑布流的研發(fā)交付方式改成敏捷交付或迭代交付，小步跑，多優(yōu)化，主動擁抱需求的變更。

首先需要想想為什么會出現(xiàn)這種情況，可能的原因有：業(yè)務方提出需求的時候沒想清楚，過程中想到了就馬上提。

業(yè)務方在沒看到任何產(chǎn)出的時候，沒有實際感受，等做一半的時候看到一些內(nèi)容突然有感覺了，有新的想法;有時候是完全拍腦袋的有些新的想法，其實未必真的需要做。

可以考慮應對的措施：

1、接到需求的時候，先根據(jù)自己對業(yè)務的理解，盡可能的考慮有可能會出現(xiàn)爭議或者變更的地方，進行確認。

2、需求評審的時候盡量多提問題，促使業(yè)務方/需求提出方多思考各種場景，收集更廣泛的意見。

3、利用中度保真的原型，讓業(yè)務方有真實的感受，讓他們把想到的問題提出來。

以上幾個點，其實并不是讓變更變少了，而是化被動為主動，在更前置階段主動的把可能變更的點暴露出來。這樣的好處一個是減少研發(fā)的返工，另一個是自己掌握節(jié)奏，而不是被拖著走。

4、優(yōu)化流程，如果公司有復盤環(huán)節(jié)，可以整理下最近幾個版本出現(xiàn)的這種變更帶來的低效，反向推動業(yè)務部門在提出需求的時候內(nèi)部先跑一下評審，在流程機制上促使業(yè)務方提出需求的時候多思考。

5、鍛煉自己快速判斷價值和優(yōu)先級的能力，有些點其實做不做影響都不大，拍腦袋出來的想法，能快速PK掉就PK掉，避免讓業(yè)務/需求方將自己看做是接收器，而是有判斷力有思考的項目經(jīng)理。