編輯導(dǎo)語：無論在項目制交付過程中，還是在產(chǎn)品制迭代過程中，需求變更都是一個無法規(guī)避的難題。本文作者對自己工作中涉及到需求變更的問題進(jìn)行了總結(jié)，希望能給你帶來幫助。

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

頻繁的需求變更不僅會造成進(jìn)度風(fēng)險、成本風(fēng)險，還會引起“輿情風(fēng)險”讓內(nèi)外人員都產(chǎn)生不可控的負(fù)面影響。

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

01 為什么會出現(xiàn)需求變更？

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

在需求分析、設(shè)計、評審階段，對場景和解決方案的考慮不全面，對政策、市場調(diào)研不準(zhǔn)確?；蚴悄承┕δ苋笔А⒒蛘邩I(yè)務(wù)邏輯不閉環(huán)；還有一些細(xì)節(jié)問題沒有提前想到，導(dǎo)致在后期落地的時候發(fā)現(xiàn)了。

也可能有關(guān)聯(lián)方需要配合改造的內(nèi)容沒有調(diào)研清楚，后期發(fā)現(xiàn)對方無法配合推進(jìn)；或是系統(tǒng)內(nèi)的關(guān)聯(lián)功能改造范圍評估不準(zhǔn)確，后期發(fā)現(xiàn)這種方案會傷筋動骨，在落地過程中開發(fā)團(tuán)隊發(fā)現(xiàn)實現(xiàn)難度過大，周期或成本不可控等。

尤其是在評審過程中研發(fā)組、關(guān)聯(lián)方、客戶等角色沒有認(rèn)真聽，仔細(xì)想。后面真正需要大家配合時才發(fā)現(xiàn)有問題。

以上所列的需求分析過程中的完成度不夠，能占到后期變更的大多數(shù)因素。

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

還有很玄學(xué)的原因，比如領(lǐng)導(dǎo)的想法變了（無論甲方、乙方）。

02 對待需求變更應(yīng)有的態(tài)度

如果變更的原因是自己的問題，那勇于承認(rèn)、積極應(yīng)對，同時事后要反思、提升、避免。切勿推卸責(zé)任，搞得大家都不愿意再配合你、協(xié)助你。

如果變更是因為外部無法拒絕的原因，就要從情緒上盡快接納、盡快設(shè)計新的解決方案。因為對于一些無法拒絕的變更，負(fù)面情緒不僅無效，反而更容易讓事態(tài)發(fā)展走向不可控。

03 一些能用到的方法

掌握結(jié)構(gòu)化思維能力（下個月會單獨做結(jié)構(gòu)化思維的總結(jié)）。在方案產(chǎn)出階段，要先想，先想好，想全面之后，和關(guān)鍵人員碰撞之后，再落筆寫文檔。就像開發(fā)寫代碼時一樣，一定要先做設(shè)計、評審?fù)ㄟ^之后再開擼。因為我們在寫文檔的過程中，容易陷入具體的功能邏輯里，而缺少了宏觀的整體性考量，非常容易讓產(chǎn)出物不嚴(yán)謹(jǐn)。

和關(guān)聯(lián)系統(tǒng)充分溝通。不要不好意思，不要嫌麻煩，得不到的答案一定要追問，自己協(xié)調(diào)不了的一定要上報?，F(xiàn)在多做一點，多確認(rèn)一個問題，能給后面整體過程節(jié)省很多時間和成本。

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

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

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

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

04 總結(jié)

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

需求變更出現(xiàn)越早，此次變更的影響才會越小。因此我們在分析、設(shè)計、評審等“前階段”盡早的識別風(fēng)險、豐滿方案，才能讓后期變更的可能性降低。

當(dāng)然，控制變更和控制蔓延是兩回事，我在整理的時候有些內(nèi)容更像是控制蔓延、應(yīng)對蔓延的方法，在本文中就都刪掉了，后續(xù)會再單獨整理。

在我看來，需求人員因為自身原因?qū)е碌囊恍┳兏?，可以類比于開發(fā)人員寫代碼時出現(xiàn)了bug。既可以避免，又不好杜絕。既要杜絕躺平，又要以積極平和的心態(tài)處理。

同時在發(fā)生變更之后，一定要有據(jù)可查，并及時通知所有干系人，否則難免在后期別人突然發(fā)現(xiàn)這里產(chǎn)生變更時，對相關(guān)人員一頓“輸出”。

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

公眾號：不想延期了

本文由 @不想延期了 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議。