作為常年跟軟件團(tuán)隊(duì)打交道的產(chǎn)品人我見(jiàn)過(guò)太多“需求管理”最后變成“需求事故”的例子。項(xiàng)目做到一半才發(fā)現(xiàn)需求對(duì)不上、開(kāi)發(fā)做完的功能被業(yè)務(wù)說(shuō)“根本不是我要的”、同一個(gè)需求被不同部門(mén)反復(fù)提了三四遍……這些問(wèn)題往往不是某個(gè)人的能力問(wèn)題而是需求承載的容器出了問(wèn)題。今天聊聊我一直在用的思路把需求管理做成“產(chǎn)品待辦列表管理化”——也就是讓所有需求都進(jìn)入一條統(tǒng)一、透明、可排序、可持續(xù)維護(hù)的待辦隊(duì)列讓需求不再靠腦子記、靠嘴傳而是靠一套流動(dòng)的管理機(jī)制來(lái)承載。這條思路適合誰(shuí)適合正在從“文檔驅(qū)動(dòng)”過(guò)渡到“敏捷節(jié)奏”的研發(fā)團(tuán)隊(duì)適合需求雜亂無(wú)章的產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理也適合想讓自己接手的項(xiàng)目更可控、更抗變更的團(tuán)隊(duì)負(fù)責(zé)人。它不要求你引入多復(fù)雜的體系只要求你把“需求”當(dāng)成“待辦”來(lái)管并且堅(jiān)持下來(lái)。下面我把這套方法從底層邏輯到實(shí)操步驟再到踩坑經(jīng)驗(yàn)完整拆給你看。1. 為什么需求管理會(huì)亂以及待辦列表為什么能救場(chǎng)1.1 傳統(tǒng)需求管理的三個(gè)坑我們先說(shuō)痛點(diǎn)別急著上方法論。第一個(gè)坑是文檔式管理。很多團(tuán)隊(duì)習(xí)慣在項(xiàng)目啟動(dòng)時(shí)寫(xiě)一份幾十頁(yè)的《需求規(guī)格說(shuō)明書(shū)》寫(xiě)完后丟給開(kāi)發(fā)然后大家默認(rèn)“按文檔做”。問(wèn)題是文檔是靜態(tài)的需求卻一直在變。文檔里第3章第2節(jié)寫(xiě)著“支持導(dǎo)出Excel”實(shí)際業(yè)務(wù)場(chǎng)景已經(jīng)變成“支持導(dǎo)出PDF且包含圖表”但文檔沒(méi)人更新開(kāi)發(fā)就照著舊文檔做了。等測(cè)試提bug產(chǎn)品才一拍大腿說(shuō)“忘了改文檔”。產(chǎn)品待辦列表的好處是需求不是一次性交付物而是持續(xù)維護(hù)的條目每條都有狀態(tài)和負(fù)責(zé)人變更時(shí)會(huì)直接反映在待辦條目上不需要靠維護(hù)一個(gè)巨型文檔來(lái)同步。第二個(gè)坑是傳話筒式管理。需求散落在各個(gè)地方微信群里老板發(fā)的一句話、客戶電話里的臨時(shí)反饋、測(cè)試人員在評(píng)審會(huì)上提出的疑問(wèn)……這些需求如果不進(jìn)同一個(gè)池子就會(huì)在口口相傳中失真。A同事聽(tīng)到“做一個(gè)篩選”B同事聽(tīng)到“做一個(gè)高級(jí)篩選”最后開(kāi)發(fā)實(shí)現(xiàn)的是普通篩選誰(shuí)都沒(méi)錯(cuò)但需求被傳歪了。待辦列表解決的是“單一事實(shí)源”問(wèn)題任何來(lái)源的需求都先落到隊(duì)列里經(jīng)過(guò)結(jié)構(gòu)化描述后再進(jìn)入評(píng)估失真的可能性被壓到最低。第三個(gè)坑是重復(fù)造輪子式管理。一個(gè)平臺(tái)不同業(yè)務(wù)線都在提“用戶權(quán)限管理”的需求但因?yàn)楦髯詾閼?zhàn)根本不知道別人已經(jīng)在做了。以至于同樣的功能被開(kāi)發(fā)了兩遍測(cè)試還要維護(hù)兩套用例。待辦列表強(qiáng)制所有需求在同一個(gè)池子里可見(jiàn)大家排需求優(yōu)先級(jí)之前先去列表里搜一下有沒(méi)有類(lèi)似條目避免重復(fù)建設(shè)。1.2 待辦列表是一條流動(dòng)的需求河不是靜態(tài)的文檔堆很多沒(méi)接觸過(guò)敏捷的同學(xué)會(huì)把“產(chǎn)品待辦列表”誤解成“一個(gè)記錄需求的Excel表”確實(shí)形式上可能就是個(gè)表但本質(zhì)上它是一個(gè)動(dòng)態(tài)隊(duì)列有來(lái)源、有流向、有出口。我習(xí)慣把它比喻成一條河流。上游是需求收集什么都往里面倒但下游有篩選網(wǎng)優(yōu)先級(jí)排序、有分流迭代計(jì)劃、有沉淀池暫緩或歸檔。河流是流動(dòng)的所以需求不能像文檔一樣不斷往抽屜里塞而是要持續(xù)被評(píng)估、被排序、被消耗。產(chǎn)品待辦列表Product Backlog在敏捷框架里是唯一的需求來(lái)源它里面的條目通常叫“用戶故事”或“PBI”P(pán)roduct Backlog Item它不一定要求每條都寫(xiě)得盡善盡美但一定要保證“堆頂”的條目即將進(jìn)入迭代的條目足夠清晰。這也引出了核心思想漸進(jìn)明細(xì)。需求不需要在一開(kāi)始就死摳細(xì)節(jié)而是隨著臨近開(kāi)發(fā)逐漸細(xì)化。這能節(jié)省大量前期文檔工作也不會(huì)扼殺需求在探索期該有的彈性。為什么這個(gè)思路能有效我認(rèn)為有三個(gè)原因第一可視化讓一切問(wèn)題無(wú)處藏身需求不再藏在某人的電腦里第二優(yōu)先級(jí)排序是強(qiáng)制性的逼迫團(tuán)隊(duì)不斷做取舍第三它自帶節(jié)奏感每個(gè)迭代都有從待辦到完成的過(guò)程需求管理被植入到了團(tuán)隊(duì)的工作節(jié)拍里而不是事后補(bǔ)一篇報(bào)告。2. 用待辦列表承載需求先搭好這四根柱子想真正落地待辦列表不是建一張表就完事你需要先把四個(gè)基礎(chǔ)打牢條目格式、字段設(shè)計(jì)、工具選型、粒度控制。這四個(gè)柱子缺一根待辦列表就容易變成另一個(gè)沒(méi)人看的文檔。2.1 需求條目的標(biāo)準(zhǔn)格式讓返工率降下來(lái)需求條目別隨便寫(xiě)格式最好統(tǒng)一。我最常用的是標(biāo)準(zhǔn)用戶故事格式“作為某類(lèi)用戶我希望做某件事以便獲得某種價(jià)值。”這個(gè)格式看起來(lái)簡(jiǎn)單但作用不小。舉個(gè)例子以前團(tuán)隊(duì)收到的需求是“登錄頁(yè)增加驗(yàn)證碼功能”。這句話信息量嚴(yán)重不足誰(shuí)要用驗(yàn)證碼解決什么場(chǎng)景為什么現(xiàn)在要做改成用戶故事后是“作為注冊(cè)用戶我希望在登錄時(shí)通過(guò)驗(yàn)證碼驗(yàn)證身份以便在密碼泄露時(shí)保護(hù)我的賬戶安全”。這樣一來(lái)開(kāi)發(fā)就知道為什么要做且能在實(shí)現(xiàn)方案上給出更好的建議比如是短信驗(yàn)證碼還是圖形驗(yàn)證碼要不要加防重邏輯。并不是所有需求都能套用用戶故事格式比如缺陷、技術(shù)債、合規(guī)風(fēng)險(xiǎn)。但是這些條目也可以借用“描述價(jià)值”的框架例如“作為運(yùn)維我希望升級(jí)基礎(chǔ)組件版本以便消除已知安全隱患”。這個(gè)思路是讓每條都回答“對(duì)誰(shuí)有價(jià)值”防止一堆失效需求壓垮團(tuán)隊(duì)。另外我強(qiáng)烈建議每個(gè)待辦條目都跟著一條“驗(yàn)收標(biāo)準(zhǔn)”。沒(méi)有驗(yàn)收標(biāo)準(zhǔn)的需求就是一張空頭支票。例如用戶故事是“支持第三方登錄”驗(yàn)收標(biāo)準(zhǔn)可以寫(xiě)“在登錄頁(yè)點(diǎn)擊微信圖標(biāo)后跳轉(zhuǎn)授權(quán)頁(yè)授權(quán)成功時(shí)返回首頁(yè)并顯示微信昵稱授權(quán)失敗時(shí)展示錯(cuò)誤提示并返回登錄頁(yè)?！遍_(kāi)發(fā)、測(cè)試、產(chǎn)品對(duì)齊同一份驗(yàn)收標(biāo)準(zhǔn)比幾千字的需求描述管用得多。條目的質(zhì)量可以用經(jīng)典的INVEST原則來(lái)檢視獨(dú)立的Independent可協(xié)商的Negotiable有價(jià)值的Valuable可估算的Estimable足夠小的Small可測(cè)試的Testable。每次往待辦列表里加新條目時(shí)對(duì)照這六個(gè)字母過(guò)一遍。容易卡住的是“Independent”和“Testable”。不獨(dú)立的故事會(huì)讓優(yōu)先級(jí)排序失效因?yàn)槟阋詾樵趯?duì)待辦A其實(shí)還隱含著待辦B不可測(cè)的故事會(huì)導(dǎo)致“我以為完成了但大家無(wú)法驗(yàn)證”的尷尬。2.2 字段設(shè)計(jì)不是越多越好但有幾個(gè)不能少待辦列表的本質(zhì)是數(shù)據(jù)字段設(shè)計(jì)決定了這個(gè)數(shù)據(jù)容器的質(zhì)量。我見(jiàn)過(guò)一些團(tuán)隊(duì)上來(lái)就建二十多個(gè)字段搞狀態(tài)機(jī)、審批流結(jié)果光填表就累死人后來(lái)干脆棄用。我的建議是先用最少必要字段跑起來(lái)后面不夠再加。常見(jiàn)的最小字段集包括ID或編號(hào)方便引用和排錯(cuò)。標(biāo)題用一句話概括需求清晰即可。詳細(xì)描述通常是用戶故事正文和補(bǔ)充說(shuō)明。優(yōu)先級(jí)建議用P0、P1、P2、P3或Must/Should/Could/Won‘t。估算故事點(diǎn)或人日用于迭代規(guī)劃。驗(yàn)收標(biāo)準(zhǔn)明確“怎樣算做完”。狀態(tài)待處理、已排期、進(jìn)行中、已完成、已取消。負(fù)責(zé)人當(dāng)前誰(shuí)在跟進(jìn)便于追責(zé)但注意別把待辦經(jīng)理當(dāng)圖書(shū)館管理員。來(lái)源記錄需求誰(shuí)提的解決“這需求是誰(shuí)說(shuō)的”爭(zhēng)議。日期創(chuàng)建日期、目標(biāo)日期如果有。這十個(gè)字段已經(jīng)能覆蓋大多數(shù)團(tuán)隊(duì)的需求再多的字段屬于錦上添花。不要一開(kāi)始就強(qiáng)制所有人填寫(xiě)“業(yè)務(wù)價(jià)值”“用戶價(jià)值”“風(fēng)險(xiǎn)等級(jí)”等容易空泛的字段因?yàn)槟愫芸鞎?huì)發(fā)現(xiàn)大家會(huì)為了填而填反而失去意義。真正該花精力維護(hù)的是“描述”“驗(yàn)收標(biāo)準(zhǔn)”和“優(yōu)先級(jí)”這三個(gè)字段決定了后面的開(kāi)發(fā)和測(cè)試能不能快速進(jìn)入狀態(tài)。2.3 工具選型從白板到電子表格的輕量起步工具永遠(yuǎn)不是核心但是一個(gè)用不順手的工具會(huì)加速流程破產(chǎn)。根據(jù)團(tuán)隊(duì)體量不同我推薦三種起步方案。最輕量的是物理白板加便利貼。團(tuán)隊(duì)人少、辦公地點(diǎn)在一塊時(shí)一張白板分三列待處理、進(jìn)行中、已完成。每個(gè)需求寫(xiě)在一張便利貼上貼到“待處理”區(qū)。好處是透明、零學(xué)習(xí)成本、順手就能調(diào)整優(yōu)先級(jí)壞處是沒(méi)法遠(yuǎn)程協(xié)作也不方便統(tǒng)計(jì)歷史。第二個(gè)階段是共享電子表格。所有需求按行排列按優(yōu)先級(jí)降序排列每個(gè)人都能在線查看和編輯。這個(gè)方案非常適合小團(tuán)隊(duì)起步成本接近零。我甚至見(jiàn)過(guò)很多幾百人規(guī)模的團(tuán)隊(duì)也在用電子表格跑待辦只要維護(hù)得好效果不輸專(zhuān)業(yè)工具。代價(jià)是沒(méi)有自動(dòng)估算匯總、燃盡圖、工作流管控全靠人工。第三個(gè)階段是真正上敏捷項(xiàng)目管理工具。市面上的成熟工具都支持產(chǎn)品待辦、迭代規(guī)劃、看板、燃盡圖等功能適合分布式團(tuán)隊(duì)和復(fù)雜協(xié)作。工具本身不是越強(qiáng)大越好而是越貼合團(tuán)隊(duì)節(jié)奏越好不要讓工具成為行政壓迫的工具它唯一目的是讓你的需求流更透明、更高效。很多人覺(jué)得從Excel遷移到專(zhuān)業(yè)工具很麻煩其實(shí)沒(méi)必要一步到位。我建議先在電子表格里把格式跑順跑三個(gè)月等團(tuán)隊(duì)確認(rèn)這套邏輯真正有用再遷移到專(zhuān)業(yè)工具。如果連電子表格都維護(hù)不好換什么工具都是死。2.4 粒度控制拆到能“吃”下去為止待辦列表里最大的災(zāi)難是一眼望去全是“跟企微打通”“重構(gòu)首頁(yè)”這種龐然大物。這類(lèi)需求扔給開(kāi)發(fā)根本排不進(jìn)迭代就算勉強(qiáng)排進(jìn)去了也會(huì)因?yàn)闊o(wú)法拆分導(dǎo)致延期或需求蔓延。經(jīng)驗(yàn)法則是一條待辦應(yīng)能在單個(gè)迭代內(nèi)完成且在完成時(shí)能交付獨(dú)立價(jià)值能被一條明確的驗(yàn)收標(biāo)準(zhǔn)驗(yàn)證。如果滿足不了就說(shuō)明太大需要拆。拆分可以按幾個(gè)維度來(lái)按用戶操作流程拆、按數(shù)據(jù)維度拆、按用戶角色拆。比如“實(shí)現(xiàn)登錄”可以拆成“手機(jī)號(hào)驗(yàn)證碼登錄”“微信授權(quán)登錄”“記住登錄狀態(tài)”“忘記密碼重置”這樣每一條都能獨(dú)立驗(yàn)收、獨(dú)立排期不會(huì)因?yàn)椤暗卿洝闭w風(fēng)險(xiǎn)太大而卡住整個(gè)迭代。如果“手機(jī)號(hào)驗(yàn)證碼登錄”還涉及到短信服務(wù)接入、前端倒計(jì)時(shí)、后端驗(yàn)證接口、風(fēng)控策略那還可以繼續(xù)拆成更細(xì)的支持性任務(wù)。關(guān)鍵是待辦列表頂部的每條需求要能在一個(gè)迭代內(nèi)被“吃下去”而不是一句話驚醒所有開(kāi)發(fā)。拆分的時(shí)候有一個(gè)很實(shí)用的技巧跟團(tuán)隊(duì)一起拆。不要產(chǎn)品經(jīng)理自己悶頭拆完再扔給團(tuán)隊(duì)確認(rèn)。開(kāi)發(fā)對(duì)實(shí)現(xiàn)細(xì)節(jié)和技術(shù)風(fēng)險(xiǎn)的理解能幫你把需求拆得更合理。比如你原本打算按頁(yè)面拆分開(kāi)發(fā)過(guò)來(lái)告訴你某個(gè)底層服務(wù)一定要先做否則每個(gè)頁(yè)面都做不出來(lái)。讓團(tuán)隊(duì)一起參與拆解既提高了估算準(zhǔn)確度也提前暴露了依賴關(guān)系。3. 需求從進(jìn)庫(kù)到出庫(kù)的全流程管理搭好基礎(chǔ)之后關(guān)鍵就看日常怎么運(yùn)轉(zhuǎn)了。這里我把需求的完整生命周期分成五個(gè)環(huán)節(jié)收集、排序、估算、排期、變更。每個(gè)環(huán)節(jié)都有對(duì)應(yīng)的實(shí)踐心得。3.1 收集漏斗讓所有想法都進(jìn)得門(mén)來(lái)需求收集環(huán)節(jié)最容易犯的錯(cuò)誤是設(shè)門(mén)檻。老板說(shuō)“你先做個(gè)方案看看”客戶提了一句“如果頁(yè)面能導(dǎo)出就好了”于是產(chǎn)品經(jīng)理記在自己的小本本上然后就沒(méi)有然后了。這樣做的問(wèn)題在于需求沒(méi)有進(jìn)入統(tǒng)一池子后續(xù)無(wú)法追蹤也無(wú)法判斷是不是會(huì)影響當(dāng)前迭代目標(biāo)。我建議團(tuán)隊(duì)開(kāi)通一個(gè)“任意門(mén)”任何人都可以把需求放進(jìn)待辦列表不需要預(yù)先審批。不管是老板的宏偉藍(lán)圖、客服收集的用戶反饋、運(yùn)營(yíng)發(fā)現(xiàn)的轉(zhuǎn)化卡點(diǎn)還是開(kāi)發(fā)在寫(xiě)碼時(shí)遇到的技術(shù)債通通先記成為一條待辦。不一定每條都要按完整的用戶故事格式寫(xiě)但至少要包含“場(chǎng)景”“期望”“為什么”三要素。哪怕只有一句話也沒(méi)關(guān)系后續(xù)梳理會(huì)上可以慢慢完善。收集之后的梳理會(huì)很重要我習(xí)慣每雙周安排一到兩小時(shí)的待辦梳理會(huì)。會(huì)上不是逐條念過(guò)去而是做三件事過(guò)濾明顯無(wú)效的需求歸并重復(fù)需求把有潛力的需求補(bǔ)充完整描述。這個(gè)會(huì)議的產(chǎn)出不是“報(bào)告”而是更新后的待辦列表。一定要讓列表成為會(huì)議的主角而不是PPT。你不要擔(dān)心列表變得太長(zhǎng)太亂收集階段本就允許雜亂“漏斗”的寬口就是為了不遺漏。真正的篩選發(fā)生在后面的優(yōu)先級(jí)排序階段。3.2 優(yōu)先級(jí)排序別用感覺(jué)用規(guī)則優(yōu)先級(jí)排序是需求管理中最容易撕扯的環(huán)節(jié)。業(yè)務(wù)方都覺(jué)得自己手里的需求最重要產(chǎn)品如果只會(huì)說(shuō)“我們?cè)僭u(píng)估評(píng)估”遲早要被口水淹沒(méi)。所以一定要建立一套大家都認(rèn)的排序規(guī)則讓“為什么做這件事”盡量客觀化。最簡(jiǎn)單的規(guī)則是MoSCoW法Must必須做、Should應(yīng)該做、Could可以做的、Won’t這期不做。非黑即白的分類(lèi)能快速暴露團(tuán)隊(duì)的分歧兩個(gè)人對(duì)同一個(gè)需求的歸類(lèi)不一致恰恰說(shuō)明需求描述或價(jià)值還不清晰需要進(jìn)一步對(duì)話。稍微高級(jí)一點(diǎn)的是WSJFWeighted Shortest Job First也就是加權(quán)最短作業(yè)優(yōu)先。它的核心思想是優(yōu)先做“延誤成本高”且“工作量相對(duì)小”的需求。簡(jiǎn)化版公式是WSJF值 用戶業(yè)務(wù)價(jià)值 時(shí)間緊迫性 風(fēng)險(xiǎn)降低機(jī)會(huì) ÷ 工作量大小。舉個(gè)例子兩個(gè)需求估算都是5個(gè)故事點(diǎn)需求A能帶來(lái)50萬(wàn)新增收入且涉及監(jiān)管合規(guī)需求B只是一次體驗(yàn)優(yōu)化那么A的分子遠(yuǎn)高于B所以A先做。如果B工作量只有2而A是13那就要拿捏一下可能B先做更劃算。實(shí)際工作中不必算得很精確給每一項(xiàng)打個(gè)分讓團(tuán)隊(duì)討論排序依據(jù)就已經(jīng)比“因?yàn)橹匾砸觥钡牧Χ葟?qiáng)得多。這里還有個(gè)反直覺(jué)的經(jīng)驗(yàn)高優(yōu)先級(jí)條目需要控制數(shù)量。如果整個(gè)待辦列表里有一半都是P0那等于沒(méi)有優(yōu)先級(jí)。我給團(tuán)隊(duì)定的原則是“進(jìn)入當(dāng)前迭代后P0不超過(guò)三到五條”其他都是P1/P2。這樣既給了方向感也保留了彈性。3.3 估算與拆分讓團(tuán)隊(duì)有參與感估算往往會(huì)激起開(kāi)發(fā)的反感“需求都還沒(méi)說(shuō)清楚憑什么讓我估時(shí)間”所以我們要把估算的目標(biāo)從“承諾日期”扭轉(zhuǎn)為“理解需求、拆解復(fù)雜度”。我最推薦故事點(diǎn)估算因?yàn)樗窍鄬?duì)度量。團(tuán)隊(duì)先選一個(gè)大家都熟悉的基準(zhǔn)故事比如“修改用戶昵稱”是2點(diǎn)然后拿著其他需求跟它比較。它不算人天不承諾具體日期卻能比較出相對(duì)大小。用撲克牌估算也很方便每個(gè)人從0、1、2、3、5、8、13這些數(shù)字里選一張表示自己對(duì)復(fù)雜度的判斷然后同時(shí)翻牌偏差大的進(jìn)行討論。這樣能有效避免“專(zhuān)家一言堂”或“跟風(fēng)估算”。估算和拆分是相互強(qiáng)化的。當(dāng)你對(duì)一個(gè)模塊估算出13點(diǎn)時(shí)所有人都會(huì)覺(jué)得太大那就趕緊拆開(kāi)。拆開(kāi)之后每條小故事可能有3、5、8點(diǎn)整體也就更可控了。我要求產(chǎn)品經(jīng)理不要替團(tuán)隊(duì)做估算而是讓開(kāi)發(fā)團(tuán)隊(duì)自己估因?yàn)楹罄m(xù)為估算買(mǎi)單的是開(kāi)發(fā)。產(chǎn)品經(jīng)理在估算會(huì)上的職責(zé)是解釋需求上下文、回答各種為什么不是給標(biāo)準(zhǔn)答案。3.4 迭代計(jì)劃與進(jìn)度追蹤從待辦到完成待辦列表不是擺著看的它的價(jià)值在于被“消費(fèi)”。每個(gè)迭代開(kāi)始前團(tuán)隊(duì)要在一起做一輪迭代計(jì)劃從待辦列表的頂部按優(yōu)先級(jí)往下選選出一個(gè)迭代能完成的需求集合并承諾一個(gè)迭代目標(biāo)。選擇的標(biāo)準(zhǔn)不是簡(jiǎn)單“能塞多少就塞多少”而是圍繞迭代目標(biāo)挑選最有協(xié)同效應(yīng)的需求。比如這個(gè)迭代目標(biāo)是“提升用戶注冊(cè)成功率”那就優(yōu)先選跟注冊(cè)流程、第三方登錄、驗(yàn)證碼優(yōu)化相關(guān)的故事而不是順手塞一個(gè)“個(gè)人中心皮膚改版”。這樣即使中途有調(diào)整迭代目標(biāo)的輪廓也依然清晰。迭代啟動(dòng)后就把看板用起來(lái)列別設(shè)為“待開(kāi)發(fā)-開(kāi)發(fā)中-待測(cè)試-已完成”。每日站會(huì)時(shí)大多數(shù)人會(huì)對(duì)著看板說(shuō)進(jìn)展而不是對(duì)著文檔虛空匯報(bào)。這看起來(lái)樸素但效果奇好。我自己最關(guān)注的是燃盡圖Burndown Chart它會(huì)根據(jù)已完成工作量畫(huà)出剩余工作線。如果迭代過(guò)半但燃盡圖還有大段尾巴說(shuō)明進(jìn)度風(fēng)險(xiǎn)很高產(chǎn)品經(jīng)理就要趕緊介入是砍范圍還是加人手要趁早做決定。許多團(tuán)隊(duì)只在迭代結(jié)束時(shí)更新待辦列表這是錯(cuò)誤的。完成一個(gè)故事之后應(yīng)該立刻更新?tīng)顟B(tài)讓列表反映當(dāng)下的事實(shí)。否則過(guò)了三天列表就成了“僵尸遺體”沒(méi)人信它自然也不會(huì)維護(hù)它。3.5 變更管理需求變了待辦怎么跟著變需求變更本身不是問(wèn)題的核心問(wèn)題是如何讓你的待辦列表依然有序。很多團(tuán)隊(duì)一變就亂是因?yàn)闆](méi)有建立清晰的“待辦操作規(guī)則”。我定的規(guī)則很簡(jiǎn)單變更分為三種新增、暫停、重排序。新增需求走收集漏斗先落到列表底部或?qū)?yīng)優(yōu)先級(jí)位置等下個(gè)迭代規(guī)劃窗口再評(píng)估不直接塞進(jìn)當(dāng)前迭代。暫停需求將狀態(tài)標(biāo)為“暫停”注明原因和暫停日期但不清除條目因?yàn)橛锌赡芎竺孢€會(huì)撈回來(lái)。重排序則是直接在列表里調(diào)整位置但要在變更欄里記錄一下是誰(shuí)、什么時(shí)候、為什么調(diào)整。最怕的情況是當(dāng)前迭代進(jìn)行到一半老板突然說(shuō)“下周三必須上線某個(gè)新功能”。如果這個(gè)功能真的牽扯到線上風(fēng)險(xiǎn)或客戶合同那就走緊急流程但必須從當(dāng)前迭代里換出相同工作量或更低保級(jí)的需求來(lái)保證團(tuán)隊(duì)產(chǎn)能不過(guò)載。這里有一句我常對(duì)團(tuán)隊(duì)說(shuō)的話不是不能插隊(duì)但插隊(duì)必須有人被擠下飛機(jī)。變更管理不是拒絕變而是讓每次變都付出可見(jiàn)的成本別讓待辦列表成為被改得面目全非的自動(dòng)承諾機(jī)。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄最后說(shuō)說(shuō)實(shí)際運(yùn)行中我最常遇到的問(wèn)題和對(duì)應(yīng)解法每一條都是我或身邊團(tuán)隊(duì)真實(shí)踩過(guò)之后摸索出來(lái)的。4.1 待辦列表越長(zhǎng)越?jīng)]人看怎么辦列表膨脹是很自然的事。你辛辛苦苦收集了500條需求最后所有人打開(kāi)列表都眼花繚亂干脆不看。解決思路不是限制收集而是讓列表有“分層視圖”。我習(xí)慣為待辦列表配置三個(gè)視圖當(dāng)前迭代視圖只顯示本迭代條目近排期視圖未來(lái)一到兩個(gè)迭代可能進(jìn)入的條目數(shù)量控制在30條以內(nèi)年度遠(yuǎn)景池視圖所有遠(yuǎn)期、模糊、未決的想法。也就是說(shuō)物理上所有需求在同一個(gè)列表里但大家在日常協(xié)作中只關(guān)心前兩個(gè)視圖遠(yuǎn)景池每月批量梳理一次即可。如果某條需求在遠(yuǎn)景池里躺了超過(guò)一年又沒(méi)有任何行動(dòng)直接刪除或歸檔別心疼。另一個(gè)很有效的機(jī)制是定期“清淤”。每個(gè)迭代結(jié)束后用10分鐘掃一遍列表把狀態(tài)混亂的條目理一理把明顯過(guò)時(shí)的需求移動(dòng)到“已取消”或備注說(shuō)明。列表和房間一樣不定期打掃就會(huì)變成垃圾堆。4.2 需求在迭代中途被硬插怎么辦這幾乎是所有團(tuán)隊(duì)的痛。處理這個(gè)問(wèn)題的核心不是向上管理而是給“插隊(duì)”設(shè)計(jì)明確的成本表。當(dāng)有人提出“這個(gè)迭代必須加上某某需求”時(shí)我不是直接說(shuō)不而是反問(wèn)“那我們從當(dāng)前迭代里砍掉哪條把這個(gè)讓出去”操作上先讓提出方明確該需求的緊急等級(jí)和業(yè)務(wù)價(jià)值再讓交付團(tuán)隊(duì)快速估算工作量最后就“替代哪條需求”達(dá)成一致。有次客戶硬要加一個(gè)導(dǎo)出功能開(kāi)發(fā)估了一下要8人天那我們就跟客戶商量把原本計(jì)劃里的報(bào)表優(yōu)化砍掉6人天再削減一個(gè)非核心UI調(diào)整2人天寧可這個(gè)迭代交付少一點(diǎn)也要保證團(tuán)隊(duì)不超負(fù)荷。那次聊完之后客戶自己也意識(shí)到“還是要尊重節(jié)奏”往后插隊(duì)就謹(jǐn)慎多了。還有一點(diǎn)很重要迭代中確定范圍內(nèi)的需求如果發(fā)生變化一定要重新定義“完成標(biāo)準(zhǔn)”。而不是一句“簡(jiǎn)單調(diào)一下”最終讓團(tuán)隊(duì)加班買(mǎi)單。4.3 驗(yàn)收標(biāo)準(zhǔn)寫(xiě)得像廢話怎么破很多新手產(chǎn)品在驗(yàn)收標(biāo)準(zhǔn)欄寫(xiě)上“功能正常”“頁(yè)面美觀”這種不可驗(yàn)證的話等于沒(méi)寫(xiě)。解決方法是引入“Given-When-Then”格式。用它來(lái)寫(xiě)登錄功能Given給定用戶已注冊(cè)且處于未登錄狀態(tài)When當(dāng)輸入正確手機(jī)號(hào)和驗(yàn)證碼并點(diǎn)擊登錄按鈕Then那么系統(tǒng)跳轉(zhuǎn)首頁(yè)并展示用戶昵稱與頭像。再如Given 用戶輸入錯(cuò)誤驗(yàn)證碼When 點(diǎn)擊登錄按鈕Then 系統(tǒng)顯示“驗(yàn)證碼錯(cuò)誤”提示且不跳轉(zhuǎn)頁(yè)面。把驗(yàn)證碼錯(cuò)誤、重復(fù)提交、網(wǎng)絡(luò)超時(shí)、賬號(hào)鎖定這些邊界情況都寫(xiě)出來(lái)開(kāi)發(fā)和測(cè)試工作重心就從“理解我猜你想要什么”變成“核對(duì)一條條具體行為”返工率直線下降。寫(xiě)驗(yàn)收標(biāo)準(zhǔn)還有一個(gè)技巧讓測(cè)試人員參與。測(cè)試最懂怎么把需求搞掛他們提的邊界情況往往是你壓根沒(méi)想到的。驗(yàn)收標(biāo)準(zhǔn)在進(jìn)入迭代前最好能拉到開(kāi)發(fā)測(cè)試一起過(guò)一遍這叫“三人成虎”這里就是“三人成標(biāo)準(zhǔn)”。4.4 相關(guān)方覺(jué)得待辦列表是行政負(fù)擔(dān)怎么破技術(shù)團(tuán)隊(duì)覺(jué)得要花時(shí)間維護(hù)列表老板覺(jué)得流程太慢運(yùn)營(yíng)覺(jué)得表格太難用。這些多半是因?yàn)樗麄儧](méi)看到列表給自己帶來(lái)的好處。要讓待辦管理化真正立住關(guān)鍵是把收益展示出來(lái)。比如老板上次提的需求你可以在一個(gè)月后向他展示“這條您提的需求在X月X號(hào)進(jìn)入優(yōu)先級(jí)評(píng)估Y月X號(hào)排進(jìn)迭代當(dāng)前已經(jīng)上線數(shù)據(jù)提升了X%?！崩习蹇吹阶约旱囊庖?jiàn)被透明跟蹤就會(huì)理解排隊(duì)不是敷衍而是負(fù)責(zé)任的流程。開(kāi)發(fā)團(tuán)隊(duì)也會(huì)看到因?yàn)榇k列表清晰自己不用再去群里翻聊天記錄猜需求加班變少了。我還有一招“透明化儀式”每周發(fā)一封極簡(jiǎn)的“待辦周報(bào)”內(nèi)容包括本期新增X條、排入迭代Y條、完成Z條、當(dāng)前積壓TOP5是什么。不用寫(xiě)花哨的正文用數(shù)據(jù)說(shuō)話。幾次下來(lái)你可能會(huì)發(fā)現(xiàn)主動(dòng)來(lái)維護(hù)列表的人反而多了。4.5 三個(gè)低成本排查技巧待辦列表管理得久了很容易出現(xiàn)“看起來(lái)一切正常其實(shí)暗流涌動(dòng)”的情況。我經(jīng)常用下面三個(gè)技巧來(lái)排查健康度。第一看“卡住”的位置。如果待辦列表某一欄長(zhǎng)期不變比如“開(kāi)發(fā)中”的故事一周都沒(méi)動(dòng)過(guò)說(shuō)明有阻塞或技術(shù)問(wèn)題趕緊約人聊聊別等問(wèn)題發(fā)酵。第二做一次“待辦健康度檢查”隨機(jī)抽10條高優(yōu)先級(jí)條目看看有沒(méi)有超過(guò)兩個(gè)月沒(méi)動(dòng)過(guò)的如果有要么說(shuō)明優(yōu)先級(jí)排序是假的要么說(shuō)明團(tuán)隊(duì)根本不認(rèn)可這個(gè)優(yōu)先級(jí)。第三做“反饋閉環(huán)抽檢”從已完成的需求里抽查對(duì)應(yīng)的驗(yàn)收標(biāo)準(zhǔn)是否全部通過(guò)、業(yè)務(wù)指標(biāo)是否達(dá)到預(yù)期。如果很多已完成條目沒(méi)有實(shí)際產(chǎn)出價(jià)值說(shuō)明需求進(jìn)入待辦時(shí)的價(jià)值判斷出了問(wèn)題下一輪排序要提高門(mén)檻。這幾個(gè)排查技巧的成本都很低但往往能讓我們?cè)趩?wèn)題爆發(fā)前就把根子挖出來(lái)。最后再分享一點(diǎn)個(gè)人體會(huì)。把需求管理做成產(chǎn)品待辦列表管理化最難的從來(lái)不是工具或流程而是堅(jiān)持“所有需求都要有入口所有入口都要變成條目所有條目都要有輸出”的心法。我從一開(kāi)始的手忙腳亂到后來(lái)形成固定的節(jié)奏前后大概花了三個(gè)迭代周期。一旦團(tuán)隊(duì)適應(yīng)了這種可流動(dòng)、可排序、可追溯的待辦列表你會(huì)發(fā)現(xiàn)很多之前吵不完的架都變成了數(shù)據(jù)上的對(duì)比和取舍而不是個(gè)人立場(chǎng)的博弈。如果你正在被需求混亂折磨不妨從今天起拿起一張白板或一張電子表格把最近能想到的需求全部倒進(jìn)待辦列表里然后開(kāi)始第一次優(yōu)先級(jí)排序。先跑起來(lái)你很快就會(huì)感受到這套管理方式的威力。