頻繁的需求變更,讓你痛苦過嗎?

編輯導語:無論在專案制交付過程中,還是在產品制迭代過程中,需求變更都是一個無法規避的難題。本文作者對自己工作中涉及到需求變更的問題進行了總結,希望能給你帶來幫助。

頻繁的需求變更,讓你痛苦過嗎?

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

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

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

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

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

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

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

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

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

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

還有很玄學的原因,比如領導的想法變了(無論甲方、乙方)。

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

如果變更的原因是自己的問題,那

勇於承認、積極應對

,同時事後要反思、提升、避免。切勿推卸責任,搞得大家都不願意再配合你、協助你。

如果變更是因為外部無法拒絕的原因,就要從情緒上

儘快接納、儘快設計

新的解決方案。因為對於一些無法拒絕的變更,負面情緒不僅無效,反而更容易讓事態發展走向不可控。

03 一些能用到的方法

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

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

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

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

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

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

04 總結

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

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

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

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

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

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

公眾號:不想延期了

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

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

頂部