案例情景：
該專案整個週期為2個月
,有3**能測試，當第
3**能測試結束時也就是即將進入預發布階段時，需求提出方才把使用者反饋資訊給了我們，要求我們按使用者的要求去改。改動的地方涉及到頁面的樣式，文案，
sql語句，校驗邏輯等，總共可能有
20個左右的檔案要被改動。我們建議只改頁面的樣式和文案，其他部分先不要改，等下次公升級維護時再改，否則可能會影響發布。在多次交涉無果的情況下，開發只能硬著頭皮改，測試只能再申請一輪測試，也就是總共要
4輪的功能測試。雖然大家努力地按需求提出方的要求做了，但是開發和測試變得很被動，也給專案管理帶來了潛在的風險。
問題：
公司有很完善的流程來管理需求變更，但是在實際專案管理中，需求提出方還是在出其不意地提出變更需求。專案管理中，如何來避免或改善這種情況？光靠流程顯然是不夠的，該怎麼辦？
專案管理中要改進的地方：
在這個專案中，需求提出方從需求定下來之後，似乎就是開發和測試的事情了，直到快發布的時候，需求提出方才給了使用者使用反饋。專案經理一直在跟開發和測試的進度，卻忽視了去和需求提出方及時溝通，如果在第一**能測試後，讓使用者就試用一下，給點反饋，我們就不會這麼被動了。
心得體會:
專案經理在專案管理的過程中，當前期的需求和計畫都確定後，不能光顧著跟開發和測試的進度，也要階段性的和需求提出人多溝通，讓他們及時給點反饋
,不要等到什麼都做好了，再讓使用者說「我要的不是這樣的，這裡要改一下」。永遠不要把問題留到最後一分鐘，超前一步，留點餘地。
需求變更管理
需求變更 是業界公認的專案管理重大挑戰，尤其是專案後期產生的需求變更，對專案的影響是非常大的。但是，需求開發不可能做到完美無瑕，而且隨著客戶對專案和系統的了解，很有可能提出新的需求或者對原有的需求作出修正。因此，需求的變化是不可避免的。對於如何應對需求變更，主要的思路有兩條 首先是從源頭做起，提高需...
軟體專案的需求變更管理
一 做好需求工程 需求分析是軟體工程專案最重要 最基礎的起始階段，為後續的規劃設計階段提供參照依據。在軟體研發專案過程中一定要樹立需求工程的意識，將需求視為一項系統工程。為了能夠全面做好需求管理，應根據專案實際情況嚴格劃分專案階段，清晰界定 定義專案階段的基線，在每個專案階段制訂 執行階段性需求管理...
如何做好需求變更管理？ 需求變更流程規範
一 引言 由於目前公司內部對產品的需求變動都只是口頭或郵件中進行通知，並沒有進行內部評審和相關需求變動後的記錄，導致後續出的產品某些需求增加了，某些沒有進行增加。這樣就會導致測試得到的資訊不完整，以及後續產品的維護困難。在這裡書寫乙份規範說明書，希望能得到一些改善。二 目的 控制需求變化引起的開發 ...