本文首發(fā)于「BY林子」籽御，轉(zhuǎn)載請參考版權(quán)聲明绘沉。
「質(zhì)量三人行」播客在3月發(fā)布的一期《那些在需求評審和迭代計劃會議中容易忽視的質(zhì)量問題》赃绊，其中有個關(guān)于需求梳理會的問題：
問：周期為兩周的迭代，團隊的需求梳理會要花1-2天時間守问，這是合適的嗎匀归？
答：不合適，這個梳理會太重了耗帕！
有朋友聽完播客給我們留言說他們現(xiàn)在就是這么做的穆端，覺得2天是可以接受的。
因此仿便，本文就這個話題跟大家聊聊体啰。
01 什么是需求梳理會？
需求梳理會也稱為Product Backlog Grooming Meeting嗽仪，通常指的是團隊定期進行的一系列活動荒勇，以確保產(chǎn)品需求列表（Product Backlog）中的所有需求都足夠明確、可操作钦幔、可測量枕屉，并為團隊的開發(fā)工作提供足夠的指導(dǎo)。
在Grooming過程中鲤氢，團隊成員將一起審查搀擂、討論和精煉產(chǎn)品需求列表中的用戶故事（User Story），以確保它們已經(jīng)足夠詳細卷玉、具體哨颂，并與其他用戶故事之間形成邏輯關(guān)系。
02 每次需求梳理會的理想時長是多少相种？
我想先問下大家：
如果一個團隊在一起討論需求威恼，你覺得多長時間是你能坐得住并能高效參與討論的？
就我個人而言寝并，一個小時內(nèi)我能高效參與箫措，再長到兩個小時我還能接受，兩個小時以上我的腦子可能就不轉(zhuǎn)了衬潦，也沒有耐心參與討論了斤蔓。
其實，2周一個迭代的敏捷開發(fā)模式镀岛，每次需求梳理會在1-2個小時比較合適弦牡，最多也不要超過半天。整個團隊坐在一起開太長時間的會漂羊，那真的是非常痛苦也非常低效驾锰。
03 每個迭代的需求梳理會需要開兩天是合適的嗎？
不要對任何別的團隊實踐妄下結(jié)論走越，需要具體情況具體分析椭豫。如果迭代周期為兩周，有的團隊每個迭代要開兩天的需求梳理會旨指，而團隊自己覺得是合適和必要的捻悯。我首先愿意相信那應(yīng)該是基于團隊現(xiàn)狀所采取的最佳實踐。
那么淤毛，是不是自己團隊覺得每個迭代用兩天來梳理需求今缚，就可以保持現(xiàn)狀呢？答案當(dāng)然是否定的低淡。
畢竟姓言，每個迭代要花20%的時間痛苦而低效地討論需求，真的是很不健康的狀態(tài)蔗蹋。如果你的團隊正好是這樣的何荚，我建議團隊花點時間來分析一下，找出需要這么長時間的原因猪杭。
04 導(dǎo)致需求梳理會時間很長的因素有哪些餐塘？
通常，根據(jù)我的經(jīng)驗皂吮，需求梳理會的時間長短可能會受以下幾個因素的影響：
1. 業(yè)務(wù)需求或系統(tǒng)架構(gòu)相關(guān)
業(yè)務(wù)需求和系統(tǒng)架構(gòu)可能是一個非常關(guān)鍵的影響因素戒傻，常見的相關(guān)問題有：
- 對于新產(chǎn)品税手、非常復(fù)雜的產(chǎn)品需求或者復(fù)雜的系統(tǒng)架構(gòu)，都可能需要更多時間去討論和澄清需纳；
- 需求拆分不合理芦倒，團隊間依賴較強，也可能會有影響不翩；
- 前期沒有對需求進行必要的分析兵扬，直接拉上團隊所有人來梳理，這也不太可能做到高效口蝠。
2. 團隊現(xiàn)狀相關(guān)
團隊本身的情況也是影響會議時長的重要因素器钟，通常可能有如下兩種情況：
- 團隊成員間的溝通和協(xié)作情況妙蔗，如果溝通不暢或協(xié)作意識不強傲霸，需求梳理會上的討論就很難順利進行。團隊規(guī)模太大灭必，組織架構(gòu)過于復(fù)雜狞谱，或者團隊在形成初期，都有可能會出現(xiàn)溝通協(xié)作不順利的情況禁漓。
- 團隊成員的技術(shù)水平和經(jīng)驗：團隊成員的技術(shù)水平和經(jīng)驗差異較大時跟衅，確保每個人對需求的理解達成共識可能需要更多時間。
3. 會議相關(guān)
會議是否高效播歼，跟會議召開情況也是密切相關(guān)伶跷。比如：
- 缺乏清晰的目標(biāo)和計劃：需求梳理會和任何會議一樣，如果沒有明確的目標(biāo)和計劃秘狞，很可能會討論過于發(fā)散叭莫，導(dǎo)致低效、耗時長烁试。
- 會前準備不充分：除了前面提到的需要會前對需求進行初步的分析雇初，會前還需要相應(yīng)的角色對系統(tǒng)架構(gòu)、系統(tǒng)相關(guān)代碼實現(xiàn)情況减响、系統(tǒng)其他相似功能被用戶使用的情況等進行調(diào)研靖诗。如果沒有做足會前準備，這些調(diào)研可能需要在需求梳理會上來進行支示，肯定會影響需求梳理的效率刊橘。
04 需求梳理會時間過長怎么優(yōu)化？
基于前面對影響因素的分析颂鸿，我們不難逐個找出優(yōu)化方案促绵。這里我基于個人項目經(jīng)驗，總結(jié)如下建議：
1. 控制每次會議上需要梳理的需求量
過于復(fù)雜的需求要先進行拆分，并且按價值和開發(fā)依賴關(guān)系排列優(yōu)先級败晴，將小塊需求分批次進行梳理浓冒，不要在一次需求梳理會上討論復(fù)雜的大塊需求。每個迭代的需求梳理會不一定是一次性活動位衩，可以/應(yīng)該持續(xù)地進行裆蒸。
2. 縱向切分需求熔萧，減少依賴
不要將需求橫向切分（有的是將需求橫向切分給不同的團隊）糖驴，這樣不同需求模塊之間的依賴過強，沒法獨立交付佛致，自然梳理過程也就更加復(fù)雜贮缕，因為需要增加很多依賴的處理“秤埽縱向切分的需求相對更容易獨立開發(fā)和交付感昼，分析起來也會更加順暢。
3. 提前做足功課罐脊，減少團隊大規(guī)模討論的時長
在召開全組的需求梳理會之前定嗓，業(yè)務(wù)分析師需要整理盡可能多的業(yè)務(wù)需求相關(guān)信息，技術(shù)人員同步對系統(tǒng)架構(gòu)和系統(tǒng)代碼實現(xiàn)情況進行調(diào)研萍桌，思考技術(shù)方案宵溅；還需要測試人員對系統(tǒng)其它相關(guān)功能的使用情況、現(xiàn)有缺陷數(shù)據(jù)進行了解上炎。
我之前項目經(jīng)歷是在進行這些分析和調(diào)研之后恃逻，業(yè)務(wù)分析師、技術(shù)負責(zé)人和測試負責(zé)人會一起對業(yè)務(wù)實現(xiàn)方案進行討論和梳理藕施，然后才是全組人員參與的需求梳理會寇损，那個時候需求基本定型了，主要是跟團隊進行更新以及討論前期可能遺漏/遺留的問題裳食，時間不會太長矛市。
4. 控制團隊規(guī)模
開發(fā)團隊的規(guī)模不要太大，如果業(yè)務(wù)需求實在無法再次拆分給更小的團隊诲祸，也可以按照需求模塊來分批次進行需求梳理會浊吏，參考結(jié)合前面第1、3兩點來處理烦绳。
5. 增強團隊的溝通和協(xié)作
對于團隊溝通和協(xié)作方面存在的問題卿捎，得從團隊管理和建設(shè)的角度去尋求解決方案，之前有相關(guān)文章討論過類似的場景径密，比如：
- 《敏捷測試的指導(dǎo)性原則》中提到的“能夠整體對質(zhì)量負責(zé)的團隊有哪些特征”
- 如何警惕團隊的“蘑菇種植”
- 我眼中的優(yōu)秀PM是如何管理團隊的
6. 掌握會議原則午阵，提高召開效率
如果是會議本身效率不高的問題，可能需要參考《高效會議的13條軍規(guī)》來調(diào)整和優(yōu)化。
05 寫在最后
本文是由需求梳理會的時長問題引發(fā)的討論底桂，分析下來我們發(fā)現(xiàn)這不一定某一方面的問題植袍，需要系統(tǒng)性地從全局來看，找出關(guān)鍵的根因籽懦，才有可能從本質(zhì)上解決問題于个。
任何實踐都不能生搬硬套，適合自己的才更有價值暮顺。別人家的優(yōu)秀實踐可以參考厅篓，但要結(jié)合自身情況進行調(diào)整和定制化。此外捶码，需要定期回顧總結(jié)并持續(xù)改進羽氮，以確保該實踐始終符合自身現(xiàn)狀。
06 推薦閱讀
- 《敏捷測試的指導(dǎo)性原則》
- 《警惕團隊的“蘑菇種植”》
- 《我眼中的優(yōu)秀PM》
- 《高效會議的13條軍規(guī)》
- 《怎樣梳理需求全景》
- 《測試左移：需求相關(guān)的質(zhì)量保障》
本文首發(fā)于「BY林子」惫恼，轉(zhuǎn)載請參考版權(quán)聲明档押。
