頻繁的需求變更，讓你痛苦過嗎？

需求變更無論是在項目制交付過程中，還是在產品制迭代過程中，都是一個永遠無法規避的難題。

頻繁的需求變更不僅會造成進度風險、成本風險，還會引起“輿情風險”讓內外人員都產生不可控的負面影響。

雖然無法避免，但我們還是可以通過自己的成長和技巧儘量避免，或把變更引起的負面結果控制到可接受範圍內。今天我把自己工作中所涉及到需求變更的問題進行總結，希望能對大家有所幫助。如有不完善之處還請留言指正。

01 為什麼會出現需求變更？

需求變更的原因有很多，不過總結來看無外乎是需求/產品人員自身的問題：

在需求分析、設計、評審階段，對場景和解決方案的考慮不全面，對政策、市場調研不準確。或是某些功能缺失、或者業務邏輯不閉環；還有一些細節問題沒有提前想到，導致在後期落地的時候發現了。

也可能有關聯方需要配合改造的內容沒有調研清楚，後期發現對方無法配合推進；或是系統內的關聯功能改造範圍評估不準確，後期發現這種方案會傷筋動骨，在落地過程中開發團隊發現實現難度過大，週期或成本不可控等。

尤其是在評審過程中研發組、關聯方、客户等角色沒有認真聽，仔細想。後面真正需要大家配合時才發現有問題。

以上所列的需求分析過程中的完成度不夠，能佔到後期變更的大多數因素。

當然還有一些其他原因：比如政策或市場變動。在設計階段方案沒有問題，但是在落地過程中，政策變了、市場動向變了、用户要解決的痛點升級了，最終都指向——需求變了。

還有很玄學的原因，比如領導的想法變了（無論甲方、乙方）。

02 對待需求變更應有的態度

如果變更的原因是自己的問題，那勇於承認、積極應對，同時事後要反思、提升、避免。切勿推卸責任，搞得大家都不願意再配合你、協助你。

如果變更是因為外部無法拒絕的原因，就要從情緒上儘快接納、儘快設計新的解決方案。因為對於一些無法拒絕的變更，負面情緒不僅無效，反而更容易讓事態發展走向不可控。

03 一些能用到的方法

掌握結構化思維能力（下個月會單獨做結構化思維的總結）。在方案產出階段，要先想，先想好，想全面之後，和關鍵人員碰撞之後，再落筆寫文檔。就像開發寫代碼時一樣，一定要先做設計、評審通過之後再開擼。因為我們在寫文檔的過程中，容易陷入具體的功能邏輯裏，而缺少了宏觀的整體性考量，非常容易讓產出物不嚴謹。

和關聯繫統充分溝通。不要不好意思，不要嫌麻煩，得不到的答案一定要追問，自己協調不了的一定要上報。現在多做一點，多確認一個問題，能給後面整體過程節省很多時間和成本。

和開發人員尤其是項目經理、技術經理之類的關鍵角色充分溝通。溝通方案可行性，溝通方案落地難度，同時考量他們提出的修改意見。當然在這個過程中可能會遇到兩難境地，但既然我們是一個團隊，總要內部協商出可行性方案。

保持與客户的及時互動。清晰客户的需求本質，並向客户整體介紹清楚我們方案的思路，最終評判此思路是否能得到客户的認可。這個過程中也會涉及到如何進行需求洞察、如何進行方案講解等問題。

讓方案直觀易懂，才能讓“干係人”提出建設性意見。在向客户、項目組內講解、探討設計方案時，界面類的功能儘量用原型圖、UI圖等直觀的表達模式，讓大家更有概念；後台類的功能儘量用流程圖、時序圖、數據流圖之類的表現形式進行討論，從而保證大家理解達成一致。最不濟，拿個白板或者廁紙快速畫一畫，總比干巴巴憑空講解效果要好很多。

變更，也有多種變更方式。當真的遇到需求產生變化，或者領導要新增需求時，先看此需求的真實程度，是否是“偽需求”，現有功能是否可以“曲線救國”，從而引導不做。其次評估此需求的迫切程度，對現有需求的影響範圍，再看能否基於現有需求最小化解決，同時還可以提出能否用新功能置換出一定比例的非關鍵功能，從而保證進度及工作量不至於偏離過大。

04 總結

我們能做的是儘量減少因為自己工作不到位而引起的需求變更，同時在真正遇到變更時能夠更快更合理的拿出最小化執行方案。

需求變更出現越早，此次變更的影響才會越小。因此我們在分析、設計、評審等“前階段”儘早的識別風險、豐滿方案，才能讓後期變更的可能性降低。

當然，控制變更和控制蔓延是兩回事，我在整理的時候有些內容更像是控制蔓延、應對蔓延的方法，在本文中就都刪掉了，後續會再單獨整理。

在我看來，需求人員因為自身原因導致的一些變更，可以類比於開發人員寫代碼時出現了bug。既可以避免，又不好杜絕。既要杜絕躺平，又要以積極平和的心態處理。

同時在發生變更之後，一定要有據可查，並及時通知所有干係人，否則難免在後期別人突然發現這裏產生變更時，對相關人員一頓“輸出”。

當一個需求人員能夠減少、控制、應對好需求變更，那一定是一位高水平選手。

公眾號：不想延期了

本文由 @不想延期了 原創發佈於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議。