撰写「质量三人行」播客在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条军规》
- 《怎样梳理需求全景》
- 《测试左移：需求相关的质量保障》