访谈与书摘：精通需求过程

Suzanne 和 James Robertson 发布了《精通需求过程》第三版。该版本包括的主要内容专注于在如今的项目环境中需求的挑战，包括敏捷和外包的关系。他们介绍了许多基本的真理，这些真理是他们方法的基础。

InfoQ有幸采访了该书的作者，就这本新书进行了讨论。

可以在此处下载该书的摘要内容。

InfoQ：这是你这本书的第三版，为什么要更新？它比第二版有哪些改变足以使其成为一本纯粹的新书？

非常多。敏捷开发方法越来越主流，人们想知道在敏捷环境中应该怎么做需求。然而，这本书不仅仅是关于敏捷的，它涵盖了发现需求和交流需求时业务分析师的所有任务。除了第二版的内容，我们还增加了：

• 针对不同环境（包括外包）的指导策略
• 适用于迭代发布去发现和实现需求的策略
• “在一般标准之上” 思考以发现真正的问题
• 如何从需求转化为正确的解决方案
• 使视点更为清晰的 Brown Cow 模型
• 把故事卡作为需求来使用
• 使用 Volere 知识模型为需求的记录和交流提供帮助
• 关于需求、系统开发（以及其他更多的）的基本真理
• 你要先预备一张基本原理列表，为什么它们如此重要？

与许多业务分析师交谈时，关于业务分析和系统开发方面，我们总会听到一些混杂、矛盾的信息。似乎很多人搞不清楚他们的方法论和最佳实践。我们要指出一些必须用心遵循的基本原则。例如，“需求分析并不来源于需求本身”，这项任务是去研究工作开展的业务，作为需求的来源。如果你不懂这项工作，你就无法明确适当的产品规格。

我们确信，还有一些其他真理也非常有助于业务分析师的持续研究。

InfoQ： “需求”现如今并没有过时，像精益创业和敏捷之类的方法对现在需求定义工作有怎样的影响呢？

你如何开发软件对它并没有太多的影响。如果它无法满足业务需要，无论从哪个方面来看，它都是一款低劣的软件。（我并不确定谁先这么说的，但这是事实。）现如今许多流行的方法专注于解决方案，很少考虑实际应该要解决的问题。的确，按他们这种做法可以很快完成软件，但是，如果他们构建软件时忽略实际的问题，那么即使软件做成了也没什么用处。像我们上面所说，需求并不是创作一篇厚重的规格说明书（大多数当今的内部开发团队并不这么做），而是真正地理解问题。

我们还必须考虑大量远在彼岸的开发人员，如果你打算在印度或俄罗斯开发软件，那么最好有一份非常完备的规格说明书，否则就会浪费大量的金钱。再次强调，你需要解决正确的问题。

在这本书中，我们涵盖了各种不同类型开发的策略。显然，你着手于需求的活动差异，取决于你现在的开发方式。

InfoQ：您介绍了 Volere 需求过程，您能简单地介绍一下这个过程吗？它的独特之处在哪里？

我们不喜欢把它当作一个死板的过程，而是把它当作一个去发现并交流业务实际需要的框架。该过程由活动组成，这些活动必须由某人通过某种方式、按某种次序、做到某种程度。接下来我们为读者提出建议，告诉他们可以如何完成这些活动，我们清楚，组织机构和历史的差异使我们有必要采用不同的方式来处理这些任务。最重要的是，过程中的每一部分都要获得正确的结果。

Volere 过程之所以独特，是因为它并不是在某些人关于如何做事的想法之上建立的，而是观察在需求发现和实现方面较为成功的领域，基于这些观察结果建立的。我们谈到，你需要达到有形的成果，而不是把精力集中在一些程式化的工作上，比如每天早晨 9：30 都要开一次站立会议。

InfoQ：您认为产品实现“最佳价值”的概念非常重要，为什么？

如果它没有为业务提供价值，那么构建它就是浪费资源。最优价值意味着你在构建产品时没有投入过多的精力，也就是说，相比产品的价值回报，你没有对它做过度的开发。如果你采用这个理念，首先就要清楚产品能带来多少业务价值，它必须解决哪些重大的业务问题。只有了解了价值，你才可以确保在开发上的投入未超过它的价值回报。

所有软件都“时髦的”把这个概念叫作“客户价值”。可是这完全不对，除非它是为业务提供的一个即可以带来好处、又可以度量的服务。如果叫它最优价值，那么你就可以做到这两点。

InfoQ：在这本书里的动物（马、大象、兔子和“棕牛”）简直可以组成一所小型动物园了，你能解释一下它们的隐喻吗？

前三个动物是类比法。我们要求读者考虑他（或她）的项目。它是不是小型的、快速的、短期的项目？如果是的话，那么它就是一个兔子项目，你只需要做一些必须要做的，而忽略那些并不必须要做的。例如，我们建议兔子项目必须要挖掘所有的需求，但没必要去写全面的规格说明书。兔子项目可以缩略规格说明书。

另一种情况，假设你正外包或正在做一个军事的、医疗的或者一些政府的项目，那么你就是一头大象。大象比较慢也比较大，需要正规的文档（试着让一架新飞机在没有完整说明书的情况下通过联邦航空局的验收）。

马恰好在这两者之间。通过为这种项目风格赋予名称和形象，业务分析师能够更好地讨论项目差异及相应行为的差异，哪些事要花时间做，而哪些事其实并不需要去做。

棕牛模型是一个思考工具，着眼于问题域不同的视图或抽象。模型的第一象限叫做 How-Now，我们借用了英语的发音练习（绕口令），“现在棕牛怎样？（How now brown cow?）”，看起来有点蠢，但很容易记。

InfoQ：您谈到了发现实际的问题，了解业务的“本质”，为什么这很重要呢？

太多的项目热衷于一开始就去解决一些想法或用户提出的要求。虽然有一线可能，恰好就需要做这些，但历史和统计数据告诉我们，通常都不是这样的。有太多软件（和消费性产品）为了解决错误的问题而被创造出来。为什么? 因为开发团队把精力集中在他们的解决方案上，并没有拿出足够的重视去研究他们的解决方案所要处理的业务。

问题的本质是一个抽象概念：如果我们不需要考虑任何技术会是什么样的？换句话说，实际问题在没有被已提出的解决方案扭曲之前是什么样的？或者我们还可以换其他的说法：从本质上描述要被解决的潜在问题。如果你没有发现本质，那么你就正在解决错误的问题。

InfoQ：你有一章以“适用于如今业务分析师的策略”的形式提供了一些建议，这些策略是什么？为什么需要它们？

一个是适用于外部开发的策略，换句话说，假设你正在做外包。策略会教你哪些活动重要，你需要完成哪些交付，如何评价何时可以满足你具体要求的详细程度。

还有一个适用于迭代开发策略。如果你正在使用敏捷方法，那么它就是迭代的，你需要确保你把时间花在了最重要的、最有价值的事上。这个策略再次说明你需要使用你的方法高效地开展工作。

很明显，所有的组织不可能采用同样的工作方式，所以我们才制定策略。我们提供可选的需求工作方法以适应你自己组织的特质。

InfoQ：你对“符合标准”和根本原因作了重点讨论，它们是什么？为什么重要？

它们之所以重要的原因，是因为没有它们就很可能没有正确的需求。根本原因是需求的原因或理由。“为什么你想要这个？”实际上要比“你想要什么？”更加重要。如果业务分析师和开发人员清楚为什么需要做某些事，他们就能做出最佳的解决方案。

符合标准是指可测量的需求。当你具有根本原因时，你就可以推导出符合标准。举个例子，假设你有一个需求是这么说的，“我希望这个产品易于使用。”这并没有错，但也没有用。现在询问一下根本原因：“为什么你希望这样？”“我希望我的客户自动切换使用新系统。”继续按照上面的方式，你就可以逐渐推导出符合标准“在 6 个月内，70% 的客户采用新系统，并放弃上一个系统。”符合标准实际上就是可接受的标准，设计人员（或开发人员）为了达成这个目标，就要把新系统做得足够吸引人。注意，此处的“易于使用”是一个建议的解决方案，它无法保证客户切换过来。通过包含符合标准，你正在描述问题的本质。

InfoQ: 如何做“好”需求？

这个问题有一个答案，那就是“好的需求解决相关的、值得做的问题，而且，它能为它的拥有者提供相符的投入产出比。”然而，我们猜这并不是你问这个问题的目的。所以我们应该这么说，好的需求是清晰明确的（这也就是为什么我们要有符合标准）、正要去解决的正确的问题（根本原因就特别强调这一点），为了使所有利益相关者理解并达成共识而编写。当然，它必须是可测试的，另外再插一句，符合标准也是为了这一个目标。

InfoQ：Volere 过程如何支持敏捷（或迭代）开发实践？

它不是一个呆板的过程，而是集中精力发现实际的问题。你必须找到真正的需求，否则项目就会构建错误的（或者充其量也就是次优的）产品，Volere 方法并不需要你在编程之前找出所有的需求，编写完整的规格说明书，但你必须能够证明你正在解决问题的本质。

许多敏捷技术使用故事卡。我们有一章专门介绍如何编写好的故事，如何避免许多故事出现过的问题，那就是处理解决方案而不是潜在问题。

InfoQ：这个过程如何支持创新？如果我们只是简单地收集需求，那么创意从哪里来？

创新非常得重要。如果没有创新，那么交付产品的价值几乎是零（它未交付任何新的价值）。“收集需求”的概念通常会带我们远离创新。没有以我们上面所说的方式进行提问，只是问了“你想要什么？”而没有问“你为什么想要它？”

在需求的意义上，创新并不是去发明一项新技术，而是找到一种新的工作方法。通过找到工作的潜在理由，业务分析师不仅能够引领创新去发现更好的工作方法，还能找出更应该去做的事。这把业务分析师从一个收集和记录需求的速记员转变为一个研究工作并发现有价值创新的创新者。

Volere 过程建议你在棕牛模型的 What-Now 和 Future-What 象限之中考虑创新，以及你可以如何通过改进工作，转而改进业务。改进工作是所有软件项目的目的。

关于本书作者

Suzanne Robertson和James Robertson已帮助数以百计的公司改进他们的需求技术以加强系统的开发。他们的课程和需求、分析、设计研讨会因为他们的创新方法而广受赞誉。他们是大西洋系统协会的负责人，这是一家著名的咨询公司，专门从事人文因素复杂系统的构建。他们也是《需求引导项目管理》(Addison-Wesley, 2005) 的共著者。

本文基于《精通需求过程：取得正确的需求》的第三版，该书由 Suzanne Robertson 和 James Robertson 合著，由 Pearson/Addison-Wesley 出版社于 2012 年 8 月出版，国际标准图书编号：0321815742，版权由Pearson 教育股份有限公司所有。请访问出版商网站了解更多的细节。

查看英文原文： Interview and Book Excerpt: Mastering the Requirements Process

感谢崔康对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。