「質量三人行」播客在3月發布的一期《那些在需求評審和迭代計劃會議中容易忽視的質量問題》，其中有個關于需求梳理會的問題：
問：周期為兩周的迭代，團隊的需求梳理會要花1-2天時間，這是合適的嗎？
答：不合適，這個梳理會太重了！
有朋友聽完播客給我們留言說他們現在就是這么做的，覺得2天是可以接受的。
因此，本文就這個話題跟大家聊聊。
01 什么是需求梳理會？
需求梳理會也稱為Product Backlog Grooming Meeting，通常指的是團隊定期進行的一系列活動，以確保產品需求列表（Product Backlog）中的所有需求都足夠明確、可操作、可測量，并為團隊的開發工作提供足夠的指導。
在Grooming過程中，團隊成員將一起審查、討論和精煉產品需求列表中的用戶故事（User Story），以確保它們已經足夠詳細、具體，并與其他用戶故事之間形成邏輯關系。
02 每次需求梳理會的理想時長是多少？
我想先問下大家：
如果一個團隊在一起討論需求，你覺得多長時間是你能坐得住并能高效參與討論的？
就我個人而言，一個小時內我能高效參與，再長到兩個小時我還能接受，兩個小時以上我的腦子可能就不轉了，也沒有耐心參與討論了。
其實，2周一個迭代的敏捷開發模式，每次需求梳理會在1-2個小時比較合適，最多也不要超過半天。整個團隊坐在一起開太長時間的會，那真的是非常痛苦也非常低效。
03 每個迭代的需求梳理會需要開兩天是合適的嗎？
不要對任何別的團隊實踐妄下結論，需要具體情況具體分析。如果迭代周期為兩周，有的團隊每個迭代要開兩天的需求梳理會，而團隊自己覺得是合適和必要的。我首先愿意相信那應該是基于團隊現狀所采取的最佳實踐。
那么，是不是自己團隊覺得每個迭代用兩天來梳理需求，就可以保持現狀呢？答案當然是否定的。
畢竟，每個迭代要花20%的時間痛苦而低效地討論需求，真的是很不健康的狀態。如果你的團隊正好是這樣的，我建議團隊花點時間來分析一下，找出需要這么長時間的原因。
04 導致需求梳理會時間很長的因素有哪些？
通常，根據我的經驗，需求梳理會的時間長短可能會受以下幾個因素的影響：
1. 業務需求或系統架構相關
業務需求和系統架構可能是一個非常關鍵的影響因素，常見的相關問題有：
- 對于新產品、非常復雜的產品需求或者復雜的系統架構，都可能需要更多時間去討論和澄清；
- 需求拆分不合理，團隊間依賴較強，也可能會有影響；
- 前期沒有對需求進行必要的分析，直接拉上團隊所有人來梳理，這也不太可能做到高效。
2. 團隊現狀相關
團隊本身的情況也是影響會議時長的重要因素，通常可能有如下兩種情況：
- 團隊成員間的溝通和協作情況，如果溝通不暢或協作意識不強，需求梳理會上的討論就很難順利進行。團隊規模太大，組織架構過于復雜，或者團隊在形成初期，都有可能會出現溝通協作不順利的情況。
- 團隊成員的技術水平和經驗：團隊成員的技術水平和經驗差異較大時，確保每個人對需求的理解達成共識可能需要更多時間。
3. 會議相關
會議是否高效，跟會議召開情況也是密切相關。比如：
- 缺乏清晰的目標和計劃：需求梳理會和任何會議一樣，如果沒有明確的目標和計劃，很可能會討論過于發散，導致低效、耗時長。
- 會前準備不充分：除了前面提到的需要會前對需求進行初步的分析，會前還需要相應的角色對系統架構、系統相關代碼實現情況、系統其他相似功能被用戶使用的情況等進行調研。如果沒有做足會前準備，這些調研可能需要在需求梳理會上來進行，肯定會影響需求梳理的效率。
04 需求梳理會時間過長怎么優化？
基于前面對影響因素的分析，我們不難逐個找出優化方案。這里我基于個人項目經驗，總結如下建議：
1. 控制每次會議上需要梳理的需求量
過于復雜的需求要先進行拆分，并且按價值和開發依賴關系排列優先級，將小塊需求分批次進行梳理，不要在一次需求梳理會上討論復雜的大塊需求。每個迭代的需求梳理會不一定是一次性活動，可以/應該持續地進行。
2. 縱向切分需求，減少依賴
不要將需求橫向切分（有的是將需求橫向切分給不同的團隊），這樣不同需求模塊之間的依賴過強，沒法獨立交付，自然梳理過程也就更加復雜，因為需要增加很多依賴的處理。縱向切分的需求相對更容易獨立開發和交付，分析起來也會更加順暢。
3. 提前做足功課，減少團隊大規模討論的時長
在召開全組的需求梳理會之前，業務分析師需要整理盡可能多的業務需求相關信息，技術人員同步對系統架構和系統代碼實現情況進行調研，思考技術方案；還需要測試人員對系統其它相關功能的使用情況、現有缺陷數據進行了解。
我之前項目經歷是在進行這些分析和調研之后，業務分析師、技術負責人和測試負責人會一起對業務實現方案進行討論和梳理，然后才是全組人員參與的需求梳理會，那個時候需求基本定型了，主要是跟團隊進行更新以及討論前期可能遺漏/遺留的問題，時間不會太長。
4. 控制團隊規模
開發團隊的規模不要太大，如果業務需求實在無法再次拆分給更小的團隊，也可以按照需求模塊來分批次進行需求梳理會，參考結合前面第1、3兩點來處理。
5. 增強團隊的溝通和協作
對于團隊溝通和協作方面存在的問題，得從團隊管理和建設的角度去尋求解決方案，之前有相關文章討論過類似的場景，比如：
- 《敏捷測試的指導性原則》中提到的“能夠整體對質量負責的團隊有哪些特征”
- 如何警惕團隊的“蘑菇種植”
- 我眼中的優秀PM是如何管理團隊的
6. 掌握會議原則，提高召開效率
如果是會議本身效率不高的問題，可能需要參考《高效會議的13條軍規》來調整和優化。
05 寫在最后
本文是由需求梳理會的時長問題引發的討論，分析下來我們發現這不一定某一方面的問題，需要系統性地從全局來看，找出關鍵的根因，才有可能從本質上解決問題。
任何實踐都不能生搬硬套，適合自己的才更有價值。別人家的優秀實踐可以參考，但要結合自身情況進行調整和定制化。此外，需要定期回顧總結并持續改進，以確保該實踐始終符合自身現狀。
06 推薦閱讀
- 《敏捷測試的指導性原則》
- 《警惕團隊的“蘑菇種植”》
- 《我眼中的優秀PM》
- 《高效會議的13條軍規》
- 《怎樣梳理需求全景》
- 《測試左移：需求相關的質量保障》
