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