小的需求變更也要經過正規的需求管理流程，否則會積少成多。在實踐中，人們往往不願意為小的需求變更去執行正規的需求管理過程，認為降低了開發效率，浪費了時間。但正是由於這種觀念才使需求逐漸變為不可控，最終導致專案的失敗。精確的需求與範圍定義並不會阻止需求的變更。並非對需求定義得越細，就越能避免需求的漸變，這是兩個層面的問題。太細的需求定義對需求漸變沒有任何效果。因為需求的變化是永恆的，並非需求寫細了，它就不會變化了。注意溝通的技巧。實際情況是使用者、開發者都認識到了上面的幾點間題，但是由於需求的變更可能來自客戶方，也可能來自開發方，因此，作為需求管理者，專案經理需要採用各種溝通技巧來使專案的各方各得其所。（3）專案收尾階段的總結能力的提高往往不是從成功的經驗中來，而是從失敗的教訓中來。許多專案經理不注重經驗教訓總結和積累，即使在專案運作過程中碰得頭破血流，也只是抱怨運氣、環境和團隊配合不好，很少系統地分析總結，或者不知道如何分析總結，以至於同樣的問題反覆出現。事實上，專案總結工作應作為現有專案或將來專案持續改進工作的一項重要內容，同時也可以作為對專案合同、設計方案內容與目標的確認和驗證。專案總結工作包括專案中事先識別的風險和沒有預料到而發生的變更等風險的應對措施的分析和總結，也包括專案中發生的變更和專案中發生問題的分析統計的總結。

我一直在做專案管理，面對需求變更總結了 一些經驗：

1、客戶的不合理要求要委婉的拒絕，要不然他以為你好欺負，你越是什麼都答應他就變本加厲的讓你做更多的工作；

2、專案週期x個月（根據實際情況不一樣的專案不一樣的交付時間）要劃分為幾次迭代過程，每次迭代的功能開發提前列出來，告訴客戶本次迭代2周開發完成功能ABC功能（在不改變需求的情況下），如果需求改變本次迭代需要延長x天。讓客戶知道變更是有時間、成本代價的，別x個月時間到了說你沒完成任務，把責任還推到專案經理身上，你說冤枉不冤枉；

3、要告訴客戶變更是有專案管理標準約束的，不是口頭一說就變了，要按照專案管理的標準、要按照專案管理的需求變更流程執行需求變更。不是想變就能變的別把客戶的毛病慣出來，具體情況要靈活對待。

4、嚴格根據合同的要求進行功能開發、明確需求基線。明確需求基線也是明確deadline。否則只會無限的擴大需求範圍、延長專案週期。

以上便是本人在頻繁需求變更的血淚史中收穫的經驗，與大家分享。最重要的兩點1，讓客戶知道變更的代價；2，建立變更流程並真正實施變更流程管理。另外要學會於情於理、於公於私和客戶 “討價還價”控制好需求範圍、控制好變更流程。總之最重要的是識別哪些變更是必須的，哪些變更是靠溝通協調等軟技能婉拒的。