有個小伙伴在微信上問我，他說面試官問他作為產品經理如何應對需求變更，今天我就來說說我的看法。

產品經理在項目中經常會遇到需求變更的情況，哪怕你計劃做的再詳細，也免不了受到一些需求變更的困擾，變化不可怕，（畢竟這個世界本身就變化的很快），關鍵是要建立起來應對變化的機制，在發生變化的時候，按照預先制定的機制來管理變更。

通常對發生的變更需要識別是否在既定的項目范圍以內，如果在項目范圍之內，就需要評估變更造成的影響，以及應對措施，及時通知受到影響的各方，如果在項目范圍外，就需要商務人員主動和外部溝通，看是否需要增加費用和時間，還是放棄變更。

1、需求變更原因

1.1 需求定義不明確

如果產品經理自己對需求都沒了解清楚，就讓技術同事進行開發，最后開發出來的東西只能是回爐重造，我之前做EHR項目的時候，因為薪資模塊上線比較急，說實話，我之前是做金融的，對薪資模塊的業務根本不是很了解，只是簡單的寫了一些需求，就讓技術小伙伴開發，估計技術小伙伴也懵懵懂懂，結果做出來的東西各種bug，不得不回爐重造，我重新梳理細節需求，不斷的給大家宣講。

1.2 需求理解有歧義

你說的是小龍女，其他項目組其他成員理解的是賈玲，所以我一般在項目評審的時候，都會讓技術的小伙伴主動的說一下他們理解的需求，這種做到彼此信息的理解沒有偏差。

1.3 業務需求變更

這個也是我們最討厭，和最無法可控的，在啟動開發之前變更需求還好，在開發啟動變更之后，對士氣的打擊很大，所以產品經理要不斷給業務灌輸一個意識，一定要明確需求，不能反復變更，如果逼不得已變更，外包的話，就要向業務方要時間要錢，自己公司內部的業務方需求，就需要給團隊要時間，讓業務方知道，經常變更需求該來的弊端，以此掣肘業務方的需求變更。

1.4 項目周期過長

這也是為什么推薦敏捷開發的原因之一，項目周期過長，容易發生變化，比如技術人員變動，導致的人力短缺，市場環境發生變化，導致業務需求發生變化，古人說的夜長夢多就是這個意思。

?

2、需求變更來源

需求的變更來源分為兩個部分，一個是內部來源，一個是外部來源。

2.1 內部來源

內部來源又分為兩個部分，一個是產品經理變更需求，一個是技術的小伙伴變更需求。

產品經理自己變更需求，主要原因分為以下這些：

1、需求沒有考慮清楚，邏輯有遺漏

2、產品設計變更

3、臨時插入需求，比如交互要調整、要加字段等。

?

技術小伙伴變更需求，主要原因分為以下這些：

1、技術方案變更

2、人員的變更

?

說完內部來源，我們再來看看需求變更的外部來源有哪些：

2.2 外部來源

外部來源有用戶、公司的同事、領導、以及市場政策等

1、用戶。比如產品的目標用戶的需求變了

2、公司的運營、市場、業務等部門變更需求。

3、公司的高層（分為本公司的領導、外部門的領導、以及公司的大boss，這里順便說一下，職場一定要和領導接近，那些決定你能升官的領導才是你真的領導）。

4、市場政策變化（比如政府政策的調整、潮流趨勢、以及突發的黑天鵝事件）。

?

3、需求變更的目的?

記住，所有的變更目的最終一定是能夠更好的實現目標，不是追責，也不是扯皮。

產品經理變更需求是為了貼近產品設計；

開發變更需求是為了技術方案更加合理化，便于實現；

用戶變更需求是為了貼近自身需求；

公司高層以最小的代價實現目標；

市場人員變更需求是為了適應市場變化；

政策變化是為了產品更加合法化。

?

4、需求變更的影響

需求變更首先要評估一下需求影響的范圍，然后評估一下對現有進度的影響，對項目交付質量的影響，是否需要增加成本（比如人力資源成本、服務器成本等），以及需求變更帶來的潛在風險點。

?

5、預防需求變更

與其發生問題想辦法，不如在問題發生之前去預防。

所以在考慮需求變更之前，我們先想想如何預防需求變更，產品經理提的需求，設計師設計的ui設計稿一定要經過團隊內部的充分評審，讓大家充分發表意見，做到需求理解一致，并最后郵件確認，也許你一個人無法發現問題，但是大家一起頭腦風暴，就容易發現問題。

針對技術實現方案，技術團隊的同事也要充分溝通，反復研討，務必把一切能想到的問題提前想到。

對于外部的需求一定要充分溝通，能不變就不。

同時保持對業務環境的敏感，知道業務同事的習性，提前做好應對措施。

針對業務同時可能變更的需求，提早分析，做好預案。

?

6、接受OR 拒絕需求變更？

針對變更的需求，我們是接受還是拒絕呢？在說拒絕還是接受之前，我們先說一下PM的態度問題，針對變更的需求，PM一定要保持積極的態度，不能消極對抗對于變更的需求一概拒絕，在高度重視的同時，要有全局意識，要能看到變化給每個模塊帶來的影響，以及給整個全局帶來的影響。

那我們判斷是否接受變更可遵循以下三個原則：

1、變更對項目是否有利，如果無利，我們肯定拒絕。

2、如果變更對項目有利，那我們要接著看，變更需要投入的成本和變更帶來的利益，也就是看投入產出比（ROI）如何，然后根據投入產出比判斷是否值得更改。

3、如果值得更改，那接著看是否緊急，如果變更帶來的收益不是我們目前急需的，也可以往后放。只要那些重要且緊急的變更需求，我們才考慮插入。

??

7、變更的流程

7.1 收集

對于變更的需求，需求變更方需要通過一定的流程提交給產品經理，不論是郵件還是流程協作工具confluence這種，亦或是自己做的企業效能工具，通過系統的好處就是做到有跡可循，責任到人，事后也方便對需求變更進行統計，以分析變化的原因，降低變化。

7.2 評估

將變更的需求提交給變更控制委員會評審，變更委員會可根據上面的拒絕OR接受需求變更原則進行評估，這個評估的過程就是需求分析的過程，也是頭腦風暴的過程。需求變更委員會最好由項目所涉及的多方人員共同組成，應該包括產品經理、項目經理、用戶方和開發決策負責人等。

7.3 變更

需求如果確認變更，那就走變更的流程，變更的需求再開一次評審會，給項目團隊的成員詳細講解一下。?

7.4 修改

評審過后的需求，產品經理要修改對應的文檔，開發計劃的排期也需要重新排。

7.5 歸檔

妥善保存變更的相關文檔，無論是以后自行查閱還是給到接盤者，讓接盤者接手，都很有意義。

?

對于變更的需求，產品經理對上要反饋現狀、明確目標、提出解決方案，對下要組織變更評估，明確目標，體現團隊工作成績。

當然，最好的情況是不變更需求。

最后歡迎有問題的小伙伴加微信：chanpin628?溝通交流。

此外我們的官方網站也上線了，每日分享高質量的文章、原型素材和行業報告，小伙伴可自行前往索取，支持搜索，需要的小伙伴可點擊底部的閱讀原文直接查看，或者復制網址：www.dadaghp.com 打開。

更多干貨可關注微信公眾號：產品劉

想學習更多關于產品、職場、心理、認知等干貨，可長按右邊二維碼，關注我們。

··················END··················

如果想系統的學習產品經理，線下學習可點擊線下實戰2.0，線上學習可點擊手把手教你做產品經理1.0

RECOMMEND

推薦閱讀

手把手教你編寫接口需求文檔

面試題，你的興趣愛好是什么？

最全的B端產品經理干貨知識

競品分析競的是思維

點擊“閱讀原文”

查看更多干貨

總結

以上是生活随笔為你收集整理的面试题，作为产品经理你是如何应对需求变更的？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。