上周五下午四點(diǎn)十七分產(chǎn)品經(jīng)理一路小跑過(guò)來(lái)臉上帶著那種我知道又來(lái)了但我沒(méi)辦法的表情臨時(shí)加塞一個(gè)需求很緊急明天上線行不行我盯著他看了兩秒腦海中同時(shí)跑過(guò)當(dāng)前迭代的進(jìn)度、今晚的發(fā)布窗口、測(cè)試手里排著的活兒。這場(chǎng)景我干了十年開發(fā)見了不下幾百次后來(lái)終于琢磨明白一件事臨時(shí)加塞的需求和Bug骨子里是同一個(gè)物種。Bug是不請(qǐng)自來(lái)的代碼缺陷加塞需求是不請(qǐng)自來(lái)的業(yè)務(wù)變更Bug需要評(píng)估影響范圍、排修復(fù)優(yōu)先級(jí)、做回歸驗(yàn)證可一換到需求上大部分人卻靠一句很急就想推動(dòng)整個(gè)團(tuán)隊(duì)。這篇文章我想把這個(gè)類比徹底講透再把我這些年總結(jié)的用管Bug的方法管需求的實(shí)操打法分享出來(lái)。如果你也天天被這個(gè)很急先上線再說(shuō)折騰到懷疑人生建議耐心看完后面有能直接拿來(lái)用的評(píng)估模板和話術(shù)。1. 本質(zhì)上都是一回事需求和Bug身上那六個(gè)共同點(diǎn)1.1 先看定義一個(gè)偏了代碼一個(gè)偏了預(yù)期軟件工程里Bug的定義是程序?qū)崿F(xiàn)與需求規(guī)格不一致導(dǎo)致的功能缺陷。正常跑通的業(yè)務(wù)流程因?yàn)槟扯未a判斷錯(cuò)誤、某個(gè)邊界沒(méi)覆蓋就出了幺蛾子。而需求變更尤其是臨時(shí)加塞的那種本質(zhì)上是業(yè)務(wù)預(yù)期與當(dāng)前已實(shí)現(xiàn)、已規(guī)劃方案不一致。業(yè)務(wù)方心里想象的是一個(gè)樣子你代碼里跑的是另一個(gè)樣子兩邊一碰就得改。你看這兩件事從定義出發(fā)就是同一類問(wèn)題不一致。Bug是代碼跑偏了預(yù)期加塞需求是預(yù)期跑偏了代碼。區(qū)別只在于Bug是已經(jīng)存在的壞東西需求是還沒(méi)做的、看起來(lái)不錯(cuò)的東西。但落到團(tuán)隊(duì)執(zhí)行層面兩者的沖擊一模一樣都要臨時(shí)改變計(jì)劃都要重新評(píng)估影響面都要擠占本來(lái)就不富裕的研發(fā)資源。1.2 把兩者的生命周期并排放一放差距馬上出來(lái)做測(cè)試的同學(xué)都知道一個(gè)Bug從被發(fā)現(xiàn)到關(guān)閉要經(jīng)歷完整生命周期發(fā)現(xiàn)、提交、復(fù)現(xiàn)確認(rèn)、評(píng)估嚴(yán)重度、排修復(fù)計(jì)劃、修復(fù)、回歸驗(yàn)證、關(guān)閉。游戲公司管Bug尤其嚴(yán)格每個(gè)Bug都有編號(hào)、有嚴(yán)重級(jí)別、有指派人和deadline漏了一個(gè)都別想發(fā)版。需求呢很多團(tuán)隊(duì)的需求生命周期是下面這樣的階段Bug的標(biāo)準(zhǔn)流程需求的實(shí)際現(xiàn)狀需求應(yīng)該有的流程提出提交Bug單必填復(fù)現(xiàn)步驟群里一句話/茶水間隨口提口頭提出30分鐘內(nèi)登記受理專人確認(rèn)是否有效能否復(fù)現(xiàn)沒(méi)有人說(shuō)收到我來(lái)評(píng)估產(chǎn)品負(fù)責(zé)人明確受理評(píng)估按嚴(yán)重程度和優(yōu)先級(jí)定級(jí)很急兩個(gè)字代替一切按影響面、成本、風(fēng)險(xiǎn)定量評(píng)估排期進(jìn)入修復(fù)隊(duì)列或緊急插隊(duì)直接塞進(jìn)當(dāng)前迭代進(jìn)迭代或需求緩沖池開發(fā)修復(fù)并關(guān)聯(lián)單號(hào)硬寫沒(méi)有變更記錄按正常標(biāo)準(zhǔn)開發(fā)驗(yàn)證測(cè)試回歸確認(rèn)修復(fù)關(guān)閉上線后沒(méi)人記得這回事按驗(yàn)收標(biāo)準(zhǔn)逐條打勾復(fù)盤定期分析Bug產(chǎn)生原因幾乎沒(méi)有迭代復(fù)盤時(shí)回溯來(lái)源這個(gè)表格一擺出來(lái)問(wèn)題就非常清楚不是需求本身比Bug難管而是我們從來(lái)沒(méi)用管Bug的標(biāo)準(zhǔn)去管需求。Bug管理那套是經(jīng)過(guò)幾十年軟件工程驗(yàn)證的需求管理完全可以平移過(guò)來(lái)用。1.3 為什么Bug有管理需求卻經(jīng)?？亢鸶丛谟谡J(rèn)知偏差。Bug在所有人的意識(shí)里都是壞東西它會(huì)導(dǎo)致線上故障、收入損失、用戶流失所以從上到下都同意必須用流程框住它。而需求天然被認(rèn)為是新東西好東西大家默認(rèn)多干活總沒(méi)錯(cuò)有需求說(shuō)明業(yè)務(wù)在跑。但干過(guò)幾年項(xiàng)目的人都明白沒(méi)有管理的需求跟沒(méi)有管理的Bug一樣都是債務(wù)。Bug欠下的是代碼質(zhì)量債臨時(shí)加塞的需求欠下的是需求債——團(tuán)隊(duì)節(jié)奏被打亂、測(cè)試時(shí)間被壓縮、技術(shù)方案沒(méi)時(shí)間打磨最后全變成線上問(wèn)題來(lái)找你還。那些以流程繁瑣著稱的大廠編程、測(cè)試、修Bug都有成套規(guī)范不是因?yàn)樗麄儽日l(shuí)都閑而是因?yàn)樗麄儽粺o(wú)管理狀態(tài)坑過(guò)太多次最后只能用流程去擋失控。需求管理的道理一模一樣。2. 臨時(shí)加塞的需求畫像哪些值得接哪些必須擋2.1 三類最常見的加塞需求我觀察下來(lái)臨時(shí)加塞的需求看著五花八門剝開外殼就三類。第一類是偽緊急型。業(yè)務(wù)方端著手機(jī)沖過(guò)來(lái)競(jìng)品已經(jīng)上線了我們必須明天跟等你接過(guò)來(lái)一看需求描述里連目標(biāo)用戶是誰(shuí)都沒(méi)寫。這類需求往往是想做很久了但一直懶得說(shuō)清楚等到某個(gè)外部刺激出現(xiàn)就包裝成十萬(wàn)火急來(lái)逼你。第二類是老板意志型。業(yè)務(wù)方自己也一臉懵大老板在會(huì)上說(shuō)的必須做。你再追問(wèn)細(xì)節(jié)他兩手一攤。這類需求最麻煩因?yàn)槟悴唤臃路鹁褪窃谶`抗天意但硬接你連驗(yàn)收標(biāo)準(zhǔn)是什么都不知道。第三類是補(bǔ)丁型。之前某個(gè)功能上線時(shí)沒(méi)想清楚用戶反饋回來(lái)了或者數(shù)據(jù)不對(duì)了只能回來(lái)補(bǔ)。這類需求最諷刺——它本該在第一次需求評(píng)審時(shí)就想清楚結(jié)果因?yàn)楫?dāng)初圖快、圖省事把隱患一路拖到爆雷時(shí)刻。三類需求的畫像可以歸納成下面這張表類型常見話術(shù)真實(shí)面目應(yīng)對(duì)策略偽緊急型必須明天上早就想做但沒(méi)整理清楚要求當(dāng)場(chǎng)補(bǔ)場(chǎng)景和收益老板意志型上面拍的源頭模糊沒(méi)人負(fù)責(zé)追溯決策源頭找拍板人確認(rèn)范圍補(bǔ)丁型線上出問(wèn)題了上次偷懶留下的債承認(rèn)是技術(shù)債按Bug等級(jí)處理2.2 一眼分辨真急和假急被加塞需求磨了這么多年我總結(jié)出真需求的三條硬標(biāo)準(zhǔn)缺一條都要打問(wèn)號(hào)。第一有明確的用戶場(chǎng)景。能說(shuō)出來(lái)誰(shuí)在什么情況下遇到了什么問(wèn)題、為什么必須現(xiàn)在解決而不是我覺(jué)得用戶需要做了總比不做好。第二收益可以說(shuō)出數(shù)字。真急的需求背后一定有可衡量的業(yè)務(wù)指標(biāo)轉(zhuǎn)化率提升多少、用戶流失減少多少、合規(guī)風(fēng)險(xiǎn)消除多少。說(shuō)不清收益在大促前喊沖銷量的通常都是假急。第三有客觀的時(shí)間窗口。比如大促當(dāng)天、促銷活動(dòng)開始、某條法規(guī)生效這些是客觀存在的節(jié)點(diǎn)。如果Deadline只是這周趕緊弄出來(lái)那多半是拍腦袋定的。拿共享單車之租賃需求預(yù)估這類場(chǎng)景舉例業(yè)務(wù)方想臨時(shí)加一個(gè)地鐵口高峰期的調(diào)度提醒功能如果他能說(shuō)出早高峰地鐵口周邊取車失敗率高達(dá)18%加了提醒模塊預(yù)計(jì)可以減少一半的失敗投訴這就是真急。如果只是我早上上班經(jīng)常掃不到車加個(gè)功能吧那叫個(gè)人愿望。2.3 量化評(píng)估把感覺(jué)上很急變成算出來(lái)很急靠感覺(jué)判斷需求遲早被感覺(jué)坑。我常用的思路是把需求量化成一個(gè)簡(jiǎn)易公式需求價(jià)值 ≈ 影響用戶比例 × 發(fā)生頻率 × 單次收益或損失金額然后對(duì)比它的研發(fā)成本研發(fā)成本 ≈ 開發(fā)人天 × 人力成本 測(cè)試工時(shí) 風(fēng)險(xiǎn)系數(shù)兩個(gè)數(shù)字一出來(lái)該不該做、該什么時(shí)候做基本就擺在那了。假設(shè)一個(gè)加塞需求能影響的首頁(yè)用戶只有5%一個(gè)月發(fā)生一次單次帶來(lái)的收益撐死幾千塊而它要吃掉3個(gè)人天擠爆當(dāng)前迭代導(dǎo)致另一個(gè)價(jià)值十倍的需求延期——那答案就是不做或者推遲。我設(shè)計(jì)過(guò)一個(gè)10分鐘快速評(píng)估表任何加塞需求來(lái)了直接往里面填后面第4章會(huì)有完整模板。這招特別適合那種空氣里彌漫著焦慮的會(huì)議室表格一擺所有人瞬間從拼嗓門回到拼數(shù)據(jù)。3. 三層根因需求為什么會(huì)走到臨時(shí)加塞這一步3.1 業(yè)務(wù)側(cè)它不是故意折騰是決策鏈條太長(zhǎng)我以前總以為業(yè)務(wù)方就是懶后來(lái)跟一個(gè)運(yùn)營(yíng)負(fù)責(zé)人深聊過(guò)一次才明白問(wèn)題沒(méi)那么簡(jiǎn)單。他們部門的需求來(lái)源是老板一個(gè)方向、客戶三句抱怨、同行一個(gè)動(dòng)作、數(shù)據(jù)一封周報(bào)。這些信息在他們腦子里兜兜轉(zhuǎn)轉(zhuǎn)內(nèi)部討論幾輪再等領(lǐng)導(dǎo)批復(fù)等排期確認(rèn)——等整套流程走完一個(gè)月已經(jīng)過(guò)去了。所以業(yè)務(wù)方嘴里說(shuō)的臨時(shí)加塞在他的視角里一點(diǎn)都不臨時(shí)。這是我上個(gè)月就提了你們一直說(shuō)沒(méi)資源現(xiàn)在再不落地就來(lái)不及了的需求。歸根結(jié)底是業(yè)務(wù)側(cè)的決策鏈條太長(zhǎng)信息傳遞到研發(fā)側(cè)時(shí)已經(jīng)嚴(yán)重滯后。這就引出老牌需求管理工具DOORS一直強(qiáng)調(diào)的需求可追溯性每個(gè)需求都應(yīng)該能追溯到最早提出的人、時(shí)間、背景。但現(xiàn)實(shí)是需求傳到開發(fā)這邊只剩下一句客戶要求四個(gè)字。所以遇到加塞需求時(shí)我第一件事不是接需求而是問(wèn)一句這個(gè)需求最早的源頭是誰(shuí)當(dāng)時(shí)的背景材料有嗎3.2 技術(shù)側(cè)當(dāng)場(chǎng)說(shuō)簡(jiǎn)單后面全是債需求被搞成臨時(shí)加塞技術(shù)側(cè)也脫不了干系。我見過(guò)太多開發(fā)同事業(yè)務(wù)方問(wèn)這個(gè)好不好做他連代碼都沒(méi)翻張口就是簡(jiǎn)單一天搞定。結(jié)果開工發(fā)現(xiàn)涉及十幾個(gè)模塊然后開始瘋狂加班。還有一類問(wèn)題是不敢追問(wèn)。需求描述模糊比如做一批好看的彈窗大家心里各有各的好看但當(dāng)場(chǎng)誰(shuí)都不說(shuō)靠猜開始做做完被否再改再來(lái)一個(gè)臨時(shí)加塞的需求——其實(shí)不是新需求只是返工。正確的做法是當(dāng)場(chǎng)給自己爭(zhēng)取評(píng)估時(shí)間。業(yè)務(wù)方?jīng)_過(guò)來(lái)說(shuō)明天要上你可以這樣回應(yīng)行我半小時(shí)內(nèi)給你答復(fù)我拉上測(cè)試一起看下影響面。真正靠譜的團(tuán)隊(duì)從來(lái)不靠口頭拍板而是靠當(dāng)場(chǎng)列影響清單、當(dāng)場(chǎng)評(píng)估風(fēng)險(xiǎn)、當(dāng)場(chǎng)給結(jié)論。3.3 流程側(cè)沒(méi)有緩沖區(qū)所有變更都擠在最后一刻我觀察很多團(tuán)隊(duì)的迭代節(jié)奏排期排得滿滿當(dāng)當(dāng)一個(gè)迭代恨不得塞二十個(gè)需求一旦中間冒出任何變更唯一的處理方式就是擠。要么擠掉測(cè)試時(shí)間要么擠壓別的需求要么全員加班。為什么擠因?yàn)榈?jì)劃里根本沒(méi)有給緊急需求預(yù)留空間。成熟的團(tuán)隊(duì)在規(guī)劃迭代時(shí)會(huì)明確預(yù)留10%到20%的緩沖容量。這就像高速路不堵車的前提是每條車道不要壓滿車總要留一點(diǎn)變道空間。沒(méi)有緩沖區(qū)任何一個(gè)小需求都會(huì)變成壓垮迭代的最后一根稻草。還有一個(gè)流程盲區(qū)是需求變更觸發(fā)條件。很多團(tuán)隊(duì)連需求凍結(jié)這個(gè)概念都沒(méi)有——迭代啟動(dòng)后新需求還能源源不斷加進(jìn)來(lái)。真正的做法是設(shè)定一個(gè)凍結(jié)點(diǎn)比如迭代啟動(dòng)后第3天開始凍結(jié)之后的需求統(tǒng)一進(jìn)入下一個(gè)迭代除了P0級(jí)別的緊急需求其余一律排隊(duì)。這個(gè)做法其實(shí)是把游戲行業(yè)的發(fā)版凍結(jié)規(guī)則平移到了需求管理上。4. 用Bug的生命周期給需求套上籠頭從提交到復(fù)盤4.1 先把Bug生命周期這套成熟流程搬過(guò)來(lái)既然Bug有提交、受理、評(píng)估、修復(fù)、驗(yàn)證、關(guān)閉的完整生命周期需求完全可以照搬一套提交所有需求必須登記。口頭提出的需求提出人必須在30分鐘內(nèi)補(bǔ)一條記錄否則默認(rèn)不接受。這招能過(guò)濾掉一半的隨口一問(wèn)。受理指定一個(gè)明確的受理人通常是產(chǎn)品線負(fù)責(zé)人。他要在24小時(shí)內(nèi)給出接受、拒接、需補(bǔ)充材料的明確結(jié)論而不是讓需求在群里石沉大海。評(píng)估評(píng)估影響范圍、研發(fā)成本、業(yè)務(wù)風(fēng)險(xiǎn)給出建議優(yōu)先級(jí)。排期可以進(jìn)當(dāng)前迭代或者進(jìn)需求池或者直接被拒掉。開發(fā)驗(yàn)證和正常需求同一套標(biāo)準(zhǔn)該寫用例寫用例該驗(yàn)收驗(yàn)收不能因?yàn)槭桥R時(shí)加的就可以先上線再說(shuō)。復(fù)盤每次迭代結(jié)束專門盤點(diǎn)加塞需求的數(shù)量、來(lái)源、占比連續(xù)兩次都是同一個(gè)來(lái)源就該去找那個(gè)團(tuán)隊(duì)聊了。這套流程跟游戲測(cè)試Bug的生命周期管理是一個(gè)道理。為什么測(cè)試同學(xué)從不在這個(gè)Bug到底歸誰(shuí)管上浪費(fèi)時(shí)間因?yàn)槊總€(gè)Bug都有owner。需求也應(yīng)該這樣。4.2 優(yōu)先級(jí)對(duì)照把Severity和Priority換到需求上管Bug的人都知道Bug要分嚴(yán)重程度和優(yōu)先級(jí)。嚴(yán)重程度說(shuō)的是破壞有多大優(yōu)先級(jí)說(shuō)的是多快得修。需求也一樣我習(xí)慣分成四級(jí)跟Bug分級(jí)完全對(duì)應(yīng)級(jí)別對(duì)應(yīng)Bug等級(jí)定義處理時(shí)限P0Blocker/Critical不做會(huì)直接引發(fā)線上事故、合規(guī)風(fēng)險(xiǎn)或重大資金損失立即啟動(dòng)第一時(shí)間投入資源P1Major影響核心用戶的核心流程但還能繞過(guò)去本周內(nèi)必須排期P2Normal體驗(yàn)問(wèn)題、次要功能優(yōu)化做好皆大歡喜進(jìn)下個(gè)迭代P3Minor/Enhancement備選池、長(zhǎng)遠(yuǎn)想法做不做看收益放入需求池定期清理關(guān)鍵是明確誰(shuí)有權(quán)把需求定成P0。我見過(guò)不少團(tuán)隊(duì)P0的頭銜被濫用業(yè)務(wù)方覺(jué)得老板說(shuō)一下就是P0。所以我建議立一條規(guī)矩P0必須由技術(shù)負(fù)責(zé)人和業(yè)務(wù)負(fù)責(zé)人共同確認(rèn)必須有明確的量化理由。大促必須上是量化理由嗎不完全算要加上預(yù)計(jì)影響XX%用戶、預(yù)計(jì)帶來(lái)XX收益才算。4.3 快速評(píng)估模板一個(gè)加塞需求10分鐘定生死下面這個(gè)模板我用了很久每次有臨時(shí)需求過(guò)來(lái)我就讓產(chǎn)品經(jīng)理和開發(fā)負(fù)責(zé)人當(dāng)場(chǎng)填完10分鐘之內(nèi)大家就能達(dá)成共識(shí)字段填寫內(nèi)容需求一句話描述用一句話說(shuō)清楚要做什么提出人/源頭誰(shuí)提的最早什么時(shí)候提的用戶場(chǎng)景誰(shuí)在什么情況下遇到什么問(wèn)題預(yù)期收益量化影響多少用戶能帶來(lái)多少轉(zhuǎn)化/收入/體驗(yàn)提升受影響模塊前端/后端/數(shù)據(jù)/支付等研發(fā)成本預(yù)估開發(fā)人天測(cè)試人天技術(shù)風(fēng)險(xiǎn)是否有并發(fā)、兼容、數(shù)據(jù)遷移等隱患建議優(yōu)先級(jí)P0/P1/P2/P3處理結(jié)論立即做/做核心子集/排下迭代/放入需求池這套評(píng)估一旦成為肌肉記憶加塞需求帶來(lái)的焦灼感會(huì)大幅降低。因?yàn)槿艘坏┻M(jìn)入填表的流程情緒就會(huì)退后理性就會(huì)上線。表格本身不神奇神奇的是它強(qiáng)制每個(gè)人把感覺(jué)翻譯成了信息。5. 需求文檔是剛需把臨時(shí)起意翻譯成可執(zhí)行方案5.1 口頭需求的致命傷信息的衰減快到超乎想象團(tuán)隊(duì)里有一個(gè)著名的段子業(yè)務(wù)說(shuō)的是A產(chǎn)品理解成B開發(fā)做成C測(cè)試驗(yàn)成D上線后用戶要的是E。雖然夸張但每個(gè)干過(guò)項(xiàng)目的人都會(huì)心一笑。尤其是臨時(shí)加塞的需求從業(yè)務(wù)方的手機(jī)屏幕到開發(fā)同學(xué)的IDE中間往往只隔了一場(chǎng)五分鐘的對(duì)話。人的短時(shí)記憶和語(yǔ)言表達(dá)能力是有極限的。我做過(guò)試驗(yàn)一個(gè)包含三個(gè)功能點(diǎn)的口頭需求五分鐘后讓雙方各自復(fù)述能對(duì)上的通常不到一半。這還是雙方都很認(rèn)真的情況下。更別說(shuō)臨時(shí)加塞時(shí)大家都在趕時(shí)間細(xì)節(jié)根本來(lái)不及過(guò)。需求文檔或者需求規(guī)格說(shuō)明書存在的意義就是對(duì)抗這個(gè)信息衰減。它把我以為你懂了變成白紙黑字你確認(rèn)過(guò)。一份好的需求文檔不是流程負(fù)擔(dān)而是團(tuán)隊(duì)的安全網(wǎng)。5.2 輕量級(jí)需求規(guī)格書的骨架很多開發(fā)一聽寫需求規(guī)格書就頭大以為要寫幾十頁(yè)大PRD。臨時(shí)加塞的需求根本來(lái)不及。所以我推薦的是輕量級(jí)版本一頁(yè)紙足以但必須覆蓋七個(gè)關(guān)鍵部分模塊必須回答的問(wèn)題背景與目標(biāo)為什么做做完什么樣算成功用戶故事與場(chǎng)景誰(shuí)在什么情況下想做什么功能與交互細(xì)節(jié)具體長(zhǎng)什么樣點(diǎn)哪里發(fā)生什么驗(yàn)收標(biāo)準(zhǔn)一條條能打勾的硬性條件邊界與異常哪些明確不做出錯(cuò)怎么辦依賴與前置依賴誰(shuí)需要什么數(shù)據(jù)什么接口變更記錄誰(shuí)在什么時(shí)候改了什么臨時(shí)需求來(lái)了先別寫代碼花10分鐘把這張表填完。你會(huì)發(fā)現(xiàn)大部分需求在填到邊界與異常時(shí)就會(huì)原形畢露——要么邊界說(shuō)不清要么異常情況根本沒(méi)想過(guò)。這種情況下做出來(lái)的功能硬傷大概率在后面等著。5.3 Story、Task、Bug到底差在哪處理需求時(shí)很多人分不清用戶故事Story、任務(wù)Task和Bug的邊界導(dǎo)致管理粒度一團(tuán)亂。我習(xí)慣用旅行來(lái)類比Story是我要從上海去北京這是一個(gè)完整的、用戶可感知的價(jià)值單元Task是訂機(jī)票、查酒店、收拾行李是實(shí)現(xiàn)這個(gè)價(jià)值的具體步驟Bug則是到了目的地發(fā)現(xiàn)酒店訂成了蘇州是執(zhí)行環(huán)節(jié)偏離了預(yù)期。三個(gè)層次價(jià)值不同管法也不同。Story講究業(yè)務(wù)價(jià)值是否成立Task講究執(zhí)行是否高效Bug講究修復(fù)是否徹底。臨時(shí)加塞的需求通常直接落在Story層——它連用戶故事都講不清楚就直接被拆成了Task讓開發(fā)去跑結(jié)果自然很難看?，F(xiàn)在還有一些團(tuán)隊(duì)會(huì)借助AI掃描代碼排查潛在Bug、評(píng)估設(shè)計(jì)是否合理這是好事但我想提醒一句AI能幫你發(fā)現(xiàn)代碼層面的問(wèn)題卻替代不了需求層面的定義和溝通。需求文檔沒(méi)寫清楚AI再?gòu)?qiáng)也做不對(duì)。6. 一個(gè)真實(shí)加塞需求的完整處理從周五下午到周一上線6.1 事情是怎么發(fā)生的去年大促前三天運(yùn)營(yíng)經(jīng)理突然在群里喊了一句競(jìng)品首頁(yè)上線了限時(shí)折扣模塊轉(zhuǎn)化率看著很不錯(cuò)我們也要上明天必須出瞬間群里炸開鍋。開發(fā)、測(cè)試、設(shè)計(jì)全被了一遍大家第一反應(yīng)都是又來(lái)一個(gè)臨時(shí)加塞。但我沒(méi)有慌。因?yàn)榻?jīng)歷過(guò)太多次我第一件事是在群里問(wèn)出三句話需求背景是什么目標(biāo)用戶是誰(shuí)驗(yàn)收標(biāo)準(zhǔn)是什么運(yùn)營(yíng)經(jīng)理回復(fù)了一長(zhǎng)串語(yǔ)音大意是大促期間用戶對(duì)折扣敏感這個(gè)模塊能提升客單價(jià)具體細(xì)節(jié)到時(shí)候再看。這就是最典型的假急需求開局方向很誘人細(xì)節(jié)全是空白。但這次我們沒(méi)有直接懟回去而是啟動(dòng)了快速評(píng)估流程。6.2 處理鏈路每一步都在做什么決策第一步登記。會(huì)議室里我打開需求評(píng)估表當(dāng)場(chǎng)把運(yùn)營(yíng)說(shuō)的場(chǎng)景、預(yù)期收益、Deadline填了進(jìn)去。填到用戶場(chǎng)景這一欄時(shí)運(yùn)營(yíng)自己發(fā)現(xiàn)需求范圍其實(shí)可以再收縮——他要的核心不是完整的限時(shí)折扣頻道而是一個(gè)能突出折扣力度的入口。第二步產(chǎn)品認(rèn)領(lǐng)。產(chǎn)品經(jīng)理把用戶故事補(bǔ)齊大促期間在首頁(yè)看到該模塊的活躍用戶點(diǎn)擊后能看到限時(shí)折扣商品列表預(yù)計(jì)影響20%的首頁(yè)訪問(wèn)用戶預(yù)估客單價(jià)提升15%。雖然數(shù)字是拍出來(lái)的但至少可驗(yàn)證、可復(fù)盤。第三步技術(shù)評(píng)估。我拉上后端同事看了半小時(shí)代碼確認(rèn)了兩件事前端首頁(yè)布局可改后端已有成熟的折扣接口可以復(fù)用。但有個(gè)風(fēng)險(xiǎn)點(diǎn)新模塊的折扣計(jì)算要和現(xiàn)有優(yōu)惠券系統(tǒng)疊加確認(rèn)否則可能出現(xiàn)疊加邏輯沖突。評(píng)估結(jié)果是開發(fā)1人天測(cè)試0.5人天風(fēng)險(xiǎn)中等可控制。第四步?jīng)Q策談判。我沒(méi)有回復(fù)做不了而是給運(yùn)營(yíng)兩個(gè)選項(xiàng)A是全量做但要把當(dāng)前迭代里的用戶畫像V2推到下個(gè)迭代B是只做核心的折扣展示和跳轉(zhuǎn)砍掉你剛才提到的個(gè)性化推薦部分明天照常上線。運(yùn)營(yíng)思考了十分鐘選了B。第五步開發(fā)測(cè)試上線。周六上午開發(fā)周六下午測(cè)試重點(diǎn)回歸了優(yōu)惠券疊加場(chǎng)景周日中午發(fā)布留了半天緩沖。周一的數(shù)據(jù)顯示模塊點(diǎn)擊率不錯(cuò)轉(zhuǎn)化率也確實(shí)有提升基本達(dá)到了預(yù)期。6.3 復(fù)盤這半小時(shí)里我們找到了問(wèn)題根源事后我們專門做了復(fù)盤結(jié)論非常清晰這個(gè)需求本身值得做問(wèn)題出在提出時(shí)機(jī)。運(yùn)營(yíng)側(cè)其實(shí)有月度運(yùn)營(yíng)日歷但從來(lái)沒(méi)有同步到技術(shù)側(cè)。如果他們?cè)诖蟠偾皟芍馨杨A(yù)案拿出來(lái)這個(gè)功能會(huì)以P1的正常姿態(tài)排進(jìn)迭代根本不需要加班。差別在哪里提前提它是計(jì)劃內(nèi)的工作質(zhì)量和排期都可控拖到最后一刻它就只能靠加班和壓縮測(cè)試來(lái)?yè)Q時(shí)間。誰(shuí)都沒(méi)有惡意純粹是機(jī)制缺失。所以這次復(fù)盤的最后我們建立了一條新規(guī)運(yùn)營(yíng)側(cè)每周五同步下周及下月的運(yùn)營(yíng)安排到需求池產(chǎn)品側(cè)負(fù)責(zé)評(píng)估是否需要技術(shù)介入。7. 協(xié)作與心態(tài)把臨時(shí)加塞變成團(tuán)隊(duì)能力的試金石7.1 說(shuō)不的正確姿勢(shì)是給選項(xiàng)直接說(shuō)做不了在業(yè)務(wù)方聽來(lái)就是你不行或者你不配合關(guān)系容易鬧僵。我這些年學(xué)到的經(jīng)驗(yàn)是永遠(yuǎn)不要只給一個(gè)否定答案要給的是一組選項(xiàng)。比如面對(duì)一個(gè)臨時(shí)加塞需求我會(huì)這樣說(shuō)全量做沒(méi)問(wèn)題但現(xiàn)在的容量有限你有三個(gè)選擇第一全量做把迭代里的X需求推到下周第二做核心子集先覆蓋最關(guān)鍵的用戶場(chǎng)景完整版下個(gè)迭代跟上第三按當(dāng)前排期放到下下個(gè)迭代。你傾向哪個(gè)這招特別好用因?yàn)榘褯Q策權(quán)交還給業(yè)務(wù)方之后他自己會(huì)開始算賬、權(quán)衡而不是把焦慮全傾倒給你。人一旦為自己的選擇負(fù)責(zé)就不好意思再亂加塞。7.2 迭代緩沖區(qū)和需求大盤前面反復(fù)提到緩沖區(qū)這里再展開說(shuō)下怎么落地。在做迭代規(guī)劃時(shí)我會(huì)建議在排期表上直接標(biāo)注出緊急變更緩沖區(qū)占整個(gè)迭代容量的10%到20%。這塊容量平時(shí)不安排任何需求只用于消化真正的P0/P1臨時(shí)需求。如果迭代結(jié)束時(shí)緩沖區(qū)沒(méi)用滿就用來(lái)做技術(shù)債清理或體驗(yàn)優(yōu)化——總之不能讓這塊容量閑置到被其他需求搶走。另一個(gè)長(zhǎng)期動(dòng)作是做加塞需求大盤。每個(gè)月月底我會(huì)把當(dāng)月所有臨時(shí)加塞需求的數(shù)量、來(lái)源、占用容量、導(dǎo)致延期的情況匯總成一張表。數(shù)字是最好的說(shuō)服武器。當(dāng)某個(gè)業(yè)務(wù)方這個(gè)月已經(jīng)塞進(jìn)來(lái)六個(gè)緊急需求時(shí)下個(gè)月再提我只需要把表格截圖發(fā)出去他自己就不好意思了。需求管理系統(tǒng)從Excel到專業(yè)軟件都行關(guān)鍵不在工具而在可追溯、可統(tǒng)計(jì)、可復(fù)盤這三個(gè)詞。工具只是把這三個(gè)詞固化下來(lái)。7.3 最終心態(tài)臨時(shí)加塞不會(huì)消失但破壞力可以干了十年我最終接受了一個(gè)反直覺(jué)的結(jié)論臨時(shí)加塞的需求其實(shí)是業(yè)務(wù)活力的證據(jù)。一個(gè)產(chǎn)品如果半年沒(méi)有任何緊急需求那多半意味著業(yè)務(wù)僵住了、沒(méi)人關(guān)心了。真正需要消滅的從來(lái)不是加塞這個(gè)動(dòng)作而是加塞帶來(lái)的失控感。我現(xiàn)在看到產(chǎn)品經(jīng)理沖過(guò)來(lái)第一反應(yīng)已經(jīng)不是皺眉了而是把手邊的需求評(píng)估表遞過(guò)去來(lái)說(shuō)說(shuō)看這是個(gè)P幾驗(yàn)收標(biāo)準(zhǔn)帶了嗎那一刻我清楚我已經(jīng)從那個(gè)被動(dòng)接活、天天焦慮的人變成了流程的owner。需求管好了Bug也會(huì)變少因?yàn)榇蟛糠志€上問(wèn)題追根溯源都是當(dāng)初那個(gè)先上線再說(shuō)的需求埋下的雷。