最近看了一本书《群体智慧驱动的需求工程》。

个人觉得这本书虽然学术性比较强，但是可以尝试在实际项目中使用其中的一些方法，特别是多个业务干系人的情况下，这种方法有利于帮助理清用户想要什么。

在需求捕获的时候，我们通常的做法是逐一进行调研访谈。

我们会在对这个用户访谈的时候将设计好的问题都交流完成，再对另外一个用户进行访谈。

每次访谈会涉及到很多的故事，而有比较大风险的是，我们并不确定是否有所遗漏，或者对方说的就是他们真实的业务场景。

不要怀疑，一般来说，用户会把他们认为正确的讲述给我们听，而他们目前是否真的按照“程序”执行？你通过一次访谈很难知道。

更别说，如果发现两个用户在描述同一个场景不一致的情况，还可能会需要额外的时间和精力去研究去设计。

换句话说，我们通常的做法不是针对业务故事、业务场景，而是针对用户，针对人的。

从这个用户这里获取到“足够”的信息，再转换到下一个用户。

而群体智慧驱动的需求工程是从另外一个角度来进行需求获取的。

它是针对一个主题进行故事讲述和需求获取。

这样就有效避免了故事的遗漏和故事的矛盾情况的发生。

具体的实施方法并不复杂，我简单介绍一下。

第一步：群组讲故事

由主持人组织讲故事者和业务建模师一起参加，用来捕捉知识、期望和经历。

讲故事者主要由客户、用户或者是领域专家构成。

这项活动的输出是文本型的故事。

第二步：创建抽象

大家一起来理解上一步得到的故事，并进行标注：这个故事中有哪些参与者，有什么事件被提及，是否有什么外部的资源（比如文档）参与了这个故事……

然后将这些标注出来的元素进行抽取，并且构建叙事网络模型。

最终这个步骤输出的是业务过程元素（也就是你标注出来的元素）和叙事网络模型。

第三步：构建规范化陈述

这个步骤主要由业务建模师，也就是商业分析师主导，通过上一步得到的输出创建需求的规范化描述，比如UML等业务过程模型。

贯穿步骤：对话游戏

贯穿在每个步骤中间的还有一个：对话游戏。

对话游戏主要用于在每个步骤结束前各个角色通过对话的方式对规则、信息等进行澄清、精化。

比如，在第一步中，BA发现用户在讲故事中提到了一种业务场景，但是没有描述清楚该场景会在什么时候发生，于是可以在对话游戏中提出问题。

这个时候，讲故事者将提供更精确的信息以补充并澄清这个故事的相关元素。

甚至说，由于两个不同的讲故事者的角色不同，关注点不同，讲述了两个逻辑相悖的故事，那么这个时候BA也可以提出问题。

从我的角度看来，这本书介绍的这个方法也有局限性。

比较难组织

所有的人要在同一个地方，面对面的对话才能获取比较好的效果。

虽然书上说可以通过Wiki来解决地域差异的问题，但是我始终觉得面对面的沟通是最好的方式。

就算大家可以在同一个地点，你还需要找出大家都有空的半天甚至一整天的时间。

经历过需求讨论的小伙伴都知道，如果同时访谈或者讨论的人多了的话，时长会成倍增加，效果也不大好。

所以，人数、地点、时间是组织上的困难。

记录和整理量很大

你需要记录下来故事讲述者的所有故事。人的语速是很快的，但并不是所有的讲述信息都是有用的。

如果你在记录的同时还要识别哪些是有效，那肯定记不全。但是如果不识别，那肯定来不及记。

为了下一步的抽象做准备，你还需要对记录下来的信息进行整理。记录和整理的工作量非常大。

抽象难度比较大

并不是每个人讲话都是符合标准规范语法的，毕竟每个人说话方式不一样。

有些人讲故事的时候是这样说的：首先XXX会去填一个申请单，然后交给直属领导审批，如果领导同意了接着给人事会签。

但是有的人不这么说，他会说：XXX填张单子给领导，领导批了交人事。

像后面这样的描述是非结构化的，你在抽象的时候会花比较大的力气。

我的一些设想

现在随着语音识别技术和数据分析技术的发展，我在想是不是有这样一种可能：

我们用语音识别软件将讲故事的过程录制并识别，然后运用工具和定义好的一些算法规则来完成元素抽象的工作。

利用机器来完成抽象的工作，这样可能会有一些我们自己没有注意到的信息被挖掘出来。

目前我们可以尝试的

我建议大家可以根据自己项目和产品的实际情况来尝试一下刚才提到一两个步骤。

比如在多干系人的情况下，使用群体讲故事，尝试挖掘所有的业务场景。

比如尝试结构化的需求编写方式，看看会不会对现有的工作有什么改进。

这些都是我们可以去尝试的内容。

或者你有些其他新的想法？