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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果變更是因?yàn)橥獠繜o(wú)法拒絕的原因，就要從情緒上盡快接納、盡快設(shè)計(jì)新的解決方案。因?yàn)閷?duì)于一些無(wú)法拒絕的變更，負(fù)面情緒不僅無(wú)效，反而更容易讓事態(tài)發(fā)展走向不可控。

03 一些能用到的方法

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

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

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

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

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

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

04 總結(jié)

我們能做的是盡量減少因?yàn)樽约汗ぷ鞑坏轿欢鸬男枨笞兏?，同時(shí)在真正遇到變更時(shí)能夠更快更合理的拿出最小化執(zhí)行方案。

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

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

在我看來(lái)，需求人員因?yàn)樽陨碓驅(qū)е碌囊恍┳兏?，可以?lèi)比于開(kāi)發(fā)人員寫(xiě)代碼時(shí)出現(xiàn)了bug。既可以避免，又不好杜絕。既要杜絕躺平，又要以積極平和的心態(tài)處理。

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

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

公眾號(hào)：不想延期了

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

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