需求變更，在項目裡或大或小或多或少肯定會發生的，這點在我以前的一篇「重力總是起作用的」提過，需求變更就像重力一樣存在。項目經理不應該回避它而應該承認它從而積極的適應它。
在針對不同項目特點也應採取不同的方法來處理變更，這裡我來說下我在交付型項目（ToG，ToB 合同類項目）和ToC（自有產品類項目）針對需求變更我的一些心得體會。
交付型項目中主要的需求變更來源於客戶（甲方爸爸），只要有過交付型項目經驗的應該都深有體會，在交付項目中也有少數的需求變更來源於項目團隊內部（前期技術選型有問題，技術方案調整，鍍金等），那針對這種情況，項目經理應該怎麼應對呢？
首先，我認為當這種情況發生時項目經理不要馬上給客戶一個答覆：做或者不做（這是不負責任的表現）。應該是先分析，找出需求變更最真正的原因，比如客戶提出了需求變更，那原因是？ 動機是？ 這裡有些動機總結：
- 客戶前期對需求有整體的想法，但沒有細節，待項目進行中客戶逐漸知道他想要的細節功能。
- 上級要求。（這個在ToG和ToB項目裡還是比較常見）
- 由於市場、政策、合規等因素，出現需求變更。
- 甲方關鍵負責人變更。
原因和動機找準後，接下來就需要協助客戶梳理清楚需求，把需求變更涉及調整的業務形態搞清楚，並確保需求變更是準確的。（有些項目上遇到同一個功能需求客戶多次提出變更，其實就是沒準確搞清楚客戶真正想要的）
需求變更搞清楚搞準確後，項目經理就需要評估本次需求變更帶來的影響，這裡的影響主要是分析對項目組時間進度、成本、質量、技術實現難度、技術改造等方面，畢竟交付型項目最關鍵的還是在規定時間保質保量在成本範圍內完成項目。並且告知相關方需求變更帶來的影響並一定要獲得他們的認同，用戶沒有最終確認和認同的需求變更一定不能進入實施階段。
所有的需求變更，不管大小都必須要做正式的書面變更記錄，並且明確嚴格的按變更流程來執行（需求變更流程是在項目啟動階段就通過正式形式告知客戶）。需求變更還有很多各式各樣的情況，這就需要項目經理根據實際情況隨機應變來做處理。如需求變更的大小不一樣處理方式也是不一樣，對進度、成本、技術實現難度影響都比較小的需求變更，按變更實施流程走就可以，不需要修改計劃、變更合同和費用調整等。但如果是需求變更影響很大，就需要和用戶確認需求變更優先級、變更里程碑和實施計劃、變更合同和增加費用等方面，這些都需要項目經理靈活把握。要是最後項目經理自己真搞不定，那還可以藉助商務優勢資源同客戶洽談，或尋求高層領導幫助。
接下來說一下怎麼能在項目實施過程中減少和控制需求變更，裡面很關鍵的一點是在前期需求調研時一定要通過項目團隊的專業性去梳理和引導客戶需求，儘可能把用戶需求梳理清楚不形成需求盲區，這樣後期實施過程中出現大的需求變更的可能性也會降低。還有就是在簽署合同時，一定要把需求範圍列表明確的寫清楚，這樣也會減少用戶做需求蔓延。再者就是體現我們項目團隊的專業性（業務、技術、管理），讓客戶對產生認同和信任，這樣也會減少需求變更。
需求變更不可怕，項目經理也不要怕，需求變更可能會遲到，但永遠不會缺席。項目經理應該拿起自己專業知識和技能來擁抱它，是他成為項目成功交付的關鍵動力。
ToC（自有產品類項目），我更多的是採用敏捷開發模式來看待和處理需求變更，這一塊留到下一次點滴記錄裡去寫。
附上PM圈子百人社老師分享和總結的《項目實施過程中如何規避範圍蔓延》。「刀很鋒利，但主要還是看拿刀的人怎麼使用它」
閱讀更多 小Rain點滴 的文章
