需求梳理会这么开隔壁组都馋哭了

作者：王洪亮/大锤老师​ 

社区知名技术大牛，资深软件开发及敏捷咨询师，精益创业导师。他整理了一套独到的需求分析工具箱。该套工具箱的工具以可视化为主要特点，帮助企业在需求分析的过程中以图和表为主的形式来展现需求，提高需求分析全面性的同时，缩短需求分析所需要花费的时间。并且为开发人员和测试人员在需求理解的过程中节省时间，减少反复确认，从而对整体开发效率起到了提升的作用。

★ 文章导读 ★

01	需求梳理会是什么？
02	需求梳理会不是什么？
03	需求梳理会的目标
04	需求梳理会的准备
05	需求梳理会的参与者
06	需求梳理会的过程
07	需求梳理会的工具、方法

一、需求梳理会是什么？

需求梳理会(Product Backlog Refinement，正式名称是：产品待办事项梳理会)是PO向各位Developers (Scrum Guide 2020)讲解清楚需求，以便于在稍后的迭代计划会(Sprint Planning)上能够顺利的开展相关的工作，推进Sprint的顺利进行。

需求梳理会并不是Scrum中的标准事件，但是在实际项目运行过程中，都难免需要对需求进行梳理，和开发测试确认以便达成共同的理解，为Sprint的开展奠定基础。

二、需求梳理会不是什么？

需求梳理会是讲解会，不是讨论会。如果需求梳理会上要花费大量时间进行相关需求的讨论，那么这个需求梳理会其实是没有准备好的。

需求梳理会不要做估算(Estimate)、但是要排序(Prioritize)。

需求梳理会并不是做任务分解(Task Breakdown)，是做待办事项细化(Backlog Refinement)。

过去的问题

1、开会中间大部分人都走神犯困

我在全国各地都听到同样的声音，一开始我认为是企业没有招聘到合适的员工，后来我知道了这事儿跟大脑的工作方式有关系。因为采用的是纯文本为主的需求描述方式，所有的与会听众只能脑补，当脑补到一定程度的时候就会开始陷入脑能量不够的状态，因此就开始走神犯困。

“你跺你也麻”

而在开发过程中开发和测试反复来找PO/BA确认需求的情况，会造成严重打断，进而造成进一步效率下降。据各种访谈了解到，这种情况普遍存在。

2、开会时间过长

开会时间过长其中原因之一是，陷入无休止的讨论，这其实是没有准备好的表现。具体的现象可能是：

• a. 没有确保完整性       
  • i. 有场景的疏漏  比如，需求中遗漏了一个角色的参与过程。
  • ii. 有条件的疏漏 比如，一共有3×4=12种组合，但是只根据经验描述了其中5种场景。    
  •  iii. 有因素的疏漏 比如，没有考虑到具体的一个字段在场景中的变化
• b. 没有确保正确性     
  • i. 比如，公式描述错误，括号括错了。     
  • ii. 比如，业务逻辑正好搞错了。 
• c. 没有确保精确性     
  • i. 用词模糊   比如：“最近”“一个月之内”     
  • ii. 术语没有解释 比如：对于“本地仓”一次没有任何解释，假设大家都理解这个词的真正含义。
• 开会时间过长的另外一个原因是会议的节奏没有经过设计，就是想到哪讲哪儿。为了避免这个情况的发生，可以设计一下会议的结构。
  

3、很多人觉得当前主题和自己没有关系

一个需求梳理会可能要讲到需求的各个部分，由于任务分配的关系，每个部分就会有不同的人关注。所以，开会的时候会有“当前主题和我无关”的现象发生。

4、会上都没有提问，一开始写代码就有提问

需求梳理会上，讲解需求的一方（通常是PO）提出：还有别的问题吗？通常得到的答案都是“没有”。等开发一开始写第一行代码的时候就有可能来问问题。PO就会觉得很反感。

为什么会上不认真听，要到开发的时候就开始问题。因为讲解的时候都是对着空气讲的，听众就对着空气听，自己脑补，对大脑的消耗非常大。虽然有大量的文字说明需求，但是那基本上是不会有人愿意去聆听和阅读的。很快就会陷入到听不进去的境地。经验来看，这个极限大约在20分钟。
采用对照UI原型讲解的方式，也是大量的口头描述，需要让听众自己脑补。这并不是解决问题的方法。当然，UI原型是非常有用的，只是，仅有UI原型，或者增补一些文字说明是不够的。

三、需求梳理会的目标

需求梳理会要有明确的目标，下面是一些常见的需求梳理会的目标参考：

1. 对需求达成共识
2. 对需求进行排序
3. 对需求细节进行确认
4. 对需求进行不同视角的反馈，便于之后的修改
   

四、需求梳理会的准备

1. 经过排序的Product Backlog Item （一般以User Story形式呈现）以及对应的各种参考资料，在这里，一般都是可视化需求分析的各种成果。对每个PBI进行解释说明。
2. 邀请参会人员，准时参会。
3. 要求参会人员，提前阅读各种资料。

五、需求梳理会的参与者

需求梳理会除了负责讲解的PO之外，还需要明确听众必须参加的是：

1. 开发
2. 测试

可选参加的是：

1. 运维
2. 数据库管理员

取决于是否有相关的事项参与。

除了理解清楚需求的内容之外，听众们还要从不同的视角给出反馈，以便完善需求。

六、需求梳理会的过程

针对上述过去发生过的问题，设计一个更具备效率的需求梳理会的结构

下面是一个建议的需求梳理会的结构：

1. 从目的开始——why
2. 重要参与者——who
3. 他们如何完成工作，即使没有这个系统的情况——how
4. 因此需要什么功能来完成任务——what

这样的方式可以帮助听众把握整体需求脉络。

以一个会员系统为例：按照生命周期来讲，就会让会议的结构非常清晰。

如果按照功能来讲解，就会让需求变得扑朔迷离。

详细展开

先讲述本次迭代的商业价值    明确了商业价值之后，能够让所有的参会者都明确自己在讨论什么主题，而不是只能听到各种碎片信息。这是容易造成会上走神的原因。

然后是术语说明，缺少术语的说明，大家将会云里雾里    比如说：会员系统的会员资质特权接着分段分层讲解需求    略。按生命周期讲解整体需求    在讲的时候如果有一定的脉络就容易吸引听众的思维，并且能够更好的调动听众的参与。上例中按照生命周期讲解是一种比较有效的方式。按层讲解各个阶段的需求    在讲到生命周期的每个环节的地方可以按照分层的方法往下展开。    比如说，延续会员资质，可能有多种途径        – 满足一定的消费前提        – 支付一定的续会员费用

    另外可以准备一张功能映射表，结合上述的结构来讲解，则可以在中间的过程中标记已经讲完的部分，让所有参会者对于会议进度有个明确的认知。最后是非功能性需求    性能、安全、用户体验、兼容性等非功能性需求都是需要考虑的点。

七、需求梳理会的工具、方法

上面的是会议的结构，而关于需求本身的书写方式，为了不让听众陷入迷雾中，非常奏效的一种方式是：可视化需求表达。这套方法已经在若干企业得到了实施和验证。需求的书写方式改变了之后，需求梳理会上的效果得到了大幅度提升，开发和测试在之后反复过来确认需求细节的情况得到了很大幅度的减少。如果你想了解如何书写可视化需求,扫描下方二维码，跟着大锤老师学BA。