共读《掌握需求过程》P2问题及业务分析（第三章~第七章）
共读.jpg
第三章 确定业务问题的范围
如果想知道什么是最理想的价值，必须先确定拥有者实际在做什么？他和谁一起做？为谁做，或为什么他想这么做？换言之：范围，利益，相关者和目标是什么？
1项目启动
项目启动，确定了工作领域的边界，产品将成为其中的一部分；同时也确定了产品要实现的目标；也确定了利益相关者，即对产品的成功有兴趣的人；项目启动的其他提交产物，确定了产品的可行性；并为后续需求发现活动输入信息。
- 项目的目标：一段简短的定量的陈述，说明产品要做的事以及带来的业务好处。
- 工作的范围：指产品安装将影响的业务领域。
- 利益相关者：在项目中拥有利益的人。这个群体包括所有对结果会产生影响的人，或拥有发现产品需求所需知识的人。
- 限制条件：对产品的范围或风格的约束条件，包括事先决定必须采取的方案，对现有业务过程进行改变的限制条件，以及项目可用的时间和经费。
- 名称：项目中使用的特别术语。
- 相关事实和假定，：是否有一些特殊的事实需要让大家知道？是否做了一些假定而这些假定会影响到项目的结果？
- 估算的费用：项目启动提供了一些提交产物，为预估过程提供的输入，让我们在项目的早期就能进行相当不错的估算。
- 风险：可能是一段简短的风险分析，揭示项目面临的主要风险。
-继续或终止的决定该项目是否可行：考虑生产该产品的成本值得吗？是否拥有足够的信息继续需求活动，或者需要多花一些时间了解更多的信息。
2.设定范围
你不太可能需要研究拥有者的全部业务，你几乎可以肯定只需要研究部分业务，就是安装了待开发的产品后才将改变的业务。
共读《掌握需求过程》P2问题及业务分析（第三章~第七章）
我们称这部分业务为“工作”。
产品开发生命周期的第一项任务，就是定义工作的准确范围，你需要知道工作包含哪些业务，哪些业务可以安全地排除在外。
可以通过上下文范围图，来解决这个分析的问题过程。
上下文范围图展示了要研究的工作以及决定，你不研究哪些活动。
不研究的活动称为相邻系统。
上下文范围图的目的是展示工作的处理职责，以及相邻系统的职责。
3.范围、利益相关者、目标
共读《掌握需求过程》P2问题及业务分析（第三章~第七章）
范围：受产品影响的业务领域部分。
所以范围指出了一些利益相关者，他们对项目的成功有兴趣会有影响，利益相关者反过来又决定了目标，及产品使用后，期望获得的业务上的改进。
利益相关者的类型非常多，下图是利益相关者图，又称为洋葱图。确定了利益相关者的常见类型，可能有项目中的一个或多个角色来承担。
共读《掌握需求过程》P2问题及业务分析（第三章~第七章）
目标：想要达到什么目的。需要知道项目的目标，你可以将项目的目标看成是最高层次的需求，所有陆续收集的详细需求，必须为实现该目标作出积极的贡献。
对于目标的描述，主要包括：
- 目标：关于产品要做什么的描述
- 好处：产品能提供怎样的业务好处
- 度量：如何对好处进行度量？
- 合理性：考虑到对限制条件的理解，产品是否有可能实现业务好处
- 可行性：考虑到启动会议上得到的信息产品能达到的度量标准
- 可达成性：组织机构是否具备或者能够获取构建该产品的技能，在构建好之后是否能够操作它。
有些产品的目标说明不止一个。
4.需求限制条件
限制条件可能限制了项目可能花的时间或金钱，从而影响产品范围的决定。
5.命名惯例与定义
每一个项目都有一些特有的名称，需要对这些命名惯例和术语进行记录。
这个词汇表将作为整个项目的参考。
6.估算项目的成本
工作领域完成的功能越多，就需要越多的工作量来研究它并设计解决方案。
- 要测量工作领域的规模或功能，最简单计算方法就是计算上下文模型中相邻系统的数目以及输入输出数据流的数目。
- 要精确的费用可以通过影
响工作的业务事件来确定数目来。 - 更精确的费用，可以通过影响工作的业务事件的数目来确定，再精确一点的方法是功能点技术。
7.风险
项目启动过程中，包括一个简单的风险评估，这种评估可能发生在业务分析的范围之外。
应该由有能力的风险评估人员完成。
8.继续还是终止
在项目启动阶段得到的提交产物，为评估项目的可行性提供了基础，当仔细研究一下提交产物所说明的东西后，就可以决定按下项目启动的按钮是否能带来业务的好处。
本章小结
项目启动阶段是一个了解认识的过程，了解希望该产品做什么，要花多少成本类来构建它，了解要研究的工作范围，以便为需求为产品收集需求，了解哪些人将参与项目，并让他们知道对，他们的期望，了解用户，从而了解产品的可用性需求，了解项目的限制条件，即可以花多少钱，有多少时间来完成该产品，了解项目的所使用术语，了解是否能成功。
小婧的小结
第三章涉及了很多项目管理方面的内容，在项目启动会上需要对上述内容进行明确，这里面的很多工作内容已经超出了BA的职责，而是项目经理的职责。
但是因为项目启动的时候，很多文档和文件会成为接下来需求分析工作的必要输入，所以这里作者花了一个章节的内容进行描述。
而这里面所有的内容其实展开来讲都可以作为独立的一章。
BA需要特别注意的是，关于目标的部分：目标是什么，带来的好处以及如何度量这样的好处。
第四章 业务用例
共读《掌握需求过程》P2问题及业务分析（第三章~第七章）
1用例及其范围
用于描述系统及其用户之间的交互。
首先需要将系统划分为一些较方便的大块，这些大块的划分应该从用户的视角出发。
2工作的范围
工作是最终产品拥有者的业务活动，工作存在是为了向外部世界提供服务。当我们讨论上下文范围时，要注意该模型有限的关键的目的。
这个模型只展示信息的流动，并不尝试展示工作的限制条件，尽管这些可以从该模型中推导出来。
相邻系统与所有其他系统表现类似：它们包含了一些过程消费或产生一些数据，常常作为顾客消费工作提供的信息或服务，或者因为他们为你的为你的工作提供了所需的信息。
3业务实践
总有一些数据源自业务事件，调用预先计划的对该事件的响应，这种响应就是业务用例。
可以这样看这些工作的部分有预先计划好的业务用例。
当外部实体，也就是相邻系统发起一个业务事件时，业务用例被激活。
4业务用例
业务用例总是包含一些可识别的过程，一些被存取的数据产生一些输出，发送一些消息。
换言之，业务用例就是一个功能单元，可以把一个业务用例的工作隔离开来。
因为它的处理与其他业务用例基本上没有关系，业务用例之间唯一的重叠就是它们存储的数据。
5业务用例和产品用例
在外围，有要研究的工作范围，这个范围的界定是通过与围绕工作的相邻系统的通信来完成的。
研究业务用例，考虑工作要做哪些事相邻系统的期望和预期的结果。
在理解之后，决定业务用例中多少由产品用例完成。
共读《掌握需求过程》P2问题及业务分析（第三章~第七章）
具体来说，业务用例中有自动化系统，处理的部分就是产品用例。
从业务用例导出产品用例，你找到了更有用的产品，它对拥有者的价值贡献更大，这是项目的要点。
如果产品要让预期用户认可并认为有用，那么它的产品用例必须基于最初的业务事件，必须能追溯到业务用例。
本章小结
业务用例和业务事件，让你能够切分出一部分内聚的工作，用于进一步的建模和研究。
用业务事件来划分工作时，你必须从外部来观察工作，从业务事件推导出业务用例。
这意味着需求是根据工作对业务事件的响应来进行分组的。
这导致工作以一种自然的方式划分，最终得到的产品对外部世界的真实要求响应得更好，从而为它的拥有者提供更佳的最佳的价值。
小婧的小结
这一章描述的业务用例其实与我们BA日常工作中接触到的用例是不同的。
这里的业务用例单纯是从业务的角度来进行分块的业务描述。不涉及任何的系统或者技术实现。
而我们在后期进行系统设计的时候，编写解决方案的时候，会关注的是产品用例，产品用例就是源自业务用例的。
而我们最常用的用例，其实是系统用例，比产品用例更加细致的更加低层级的一种用例。
第五章工作调研
1网罗业务
我们使用“网罗”来描述业务调研活动。
这个术语反映了我们所做的事的事实“捕鱼”：不是空闲地垂下一条线，希望鱼会路过，而是采用一定的方法拖网扫过业务，捕捉每一个可能的需求。
共读《掌握需求过程》P2问题及业务分析（第三章~第七章）
你在网罗知识时，第一个任务就是调研并理解工作现在的完成方式。
你可以剥离当前的技术，得到真正业务的清晰画面，然后与利益相关者一起深入理解工作的本质，从而得到新产品的需求。
共读《掌握需求过程》P2问题及业务分析（第三章~第七章）
2业务分析师
业务分析师，主要：
- 观察和学习该项工作
从拥有者的角度来理解他，当用户一起工作时研究他们的工作，必须问他们正在做什么，为什么要这么做？ - 解释该项工作
虽然用户是这部分的专家，但他们对工作的描述并非总是事实。分析师必须对用户的描述进行过滤，跳过当前的技术，从而揭示工作的实质，而不是它的具体形式 - 用利益相关者能理解的分析模型记录结果
分析师必须确保它与利益相关者对产品的理解是一致的，我们建议使用模型作为共同的语言，与利益相关者沟通你的知识。
3网络需求的几个技巧
-
Born Cow模型。该模型展示了工作的四个视图：
共读《掌握需求过程》P2问题及业务分析（第三章~第七章）
How-Now展示了工作当前的实现，包括物理工件人员和完成工作的处理节点。
What-Now展示了真正的业务策略，即工作的本质。说明当前的业务实质在做什么，避免涉及将来实践中可能不会出现的处理节点和物理工件，不会对业务做出限制。
Future-What展示了拥有者希望的业务，但仍然没有可能用于实现该业务的技术，他纯粹是建议业务领域的将来状态。
Future-How展示业务策略的视图，加上使之成为现实的技术和人员。 -
当前做事的方式（当前如何）
可以利用模型来帮助理解工作，但矛盾的是，如果不理解工作，就无法创建这个模型。
如果模型不能工作，就表明你的问题并没有足够理解，没有得到足够的正确答案。
随着模型的建立已逐渐明白，你不知道什么有多少不知道以及业务人员不知道什么。
理想的模型，包括足够的信息让你理解工作，此外没有更多的信息。
建模时不该限制方面是模型所包含的业务领域，模型应该包含可能与产品有关的所有工作，对新产品有贡献的所有业务部分，以及过去曾碰到过操作问题的那些部分，其他值得包含的领域，以及那些没有很好理解的业务。 -
做学徒
分析师与用户一起坐在用户工作的场所，通过观察、问问题，或者通过在师傅指导下完成一些工作来进行学习，这种技术有时也被称为“旁观工作”。
做学徒可以与建模结合起来。你在观察工作和用户解释时，可以勾勒出每项任务的模型以及它们与其他任务之间的联系。
在建模时将它反馈给用户求得确认你自然会得到这些反馈，对所有不确定的地方提出问题 -
业务用例研讨会业务用例研讨会
对大多数项目都是有用的，也是最常用的需求技巧。
这些研讨会会检查一部分业务，目标是发现理想的工作。
你必须克服地理上的限制，确保召集合适的特定利益相关者组合。
他们对这个业务用例有兴趣，如果要对工作进行根本的改变，这些研讨会会特别有用。
在研讨会上，针对一个具体的业务用例感兴趣的利益相关者描述或重新制定他们目前在做的工作，讨论他们希望完成的工作。
你的任务是记录下这部分工作，让利益相关者理解并一致同意，这是准确的描述。
一般来说，我们建议通过场景来展示业务用例的功能，稍后你将利用这些记录来改进工作，导出支持工作的产品需求。
分析师与利益相关者共同探讨业务，用例并记录以下信息：
-- 业务用例的预期成果
-- 正常场景描述：业务用例完成的工作
-- 一些异常场景：描述哪些事情可能出错以及工作通过哪些活动来纠正他们？
-- 适用于该业务用例的业务规则
-- 草图原型：用于帮助利益相关者将业务用例可视化，这些可抛弃的草图是可选的，并不打算在需求阶段结束后继续保存。
- 利益相关者访谈
如果人们对工作很熟悉，这种方法可能很有效。
但这种知识常常局限于他们常常直接接触的领域，访谈也要求受访者有一些抽象和沟通的能力，所以不能将访谈作为唯一的需求收集方式，应该将它与其他一些技巧配合使用。
建议发出一份简单的议程，列出访谈将涉及的主题以及访谈的时间。
这样至少会让受访者有机会在背后进行一些思考，准备需要的材料或者一些领域专家出席访谈。
在访谈的过程中，利益相关者不应该是完全被动的，而应该让他们尽量参与建模，这样你就可以和利益相关者之间建立起一种反馈。
- 寻找可复用的需求
建议为工作结构建立抽象的模型，既不要特别的对事物给出具体的技术名称或使用，属于组织机构某部分所特有的技术。
这样的模型也不适用于任何具体的用户或使用具体用户确定的术语。
使用泛型，而不是具体实例，
所以是寻找相似处而非不同之处。
- 快而不完美的过程建模
使用大量的即时贴或者索引、卡片针对过程中的每个活动建立过程模型。
虽然我们鼓励物理模型，但是我们不鼓励设计屏幕界面并深入底层是细节中。
因为这些活动在这个阶段中是不合适的。
- 原型和草图
原型和草图他们实际上是一回事，可以是有效的需求提取技术。
基本思路是用草图勾画建立的产品，然后逆向工程从草图导出需求。
在下列情况中，这是特别有效的方法：
-- 产品以前不存在很难想象
-- 产品的利益相关者对这种产品或建议的技术没有经验
-- 利益相关者做了一段时间的工作，但卡住了
-- 利益相关者很难说出他们的需求是什么
-- 需求分析师很难理解需求是什么
-- 产品的可行性存在疑问
我们必须强调，这里讨论的原型和草图是可抛弃的原型。
他们的目的不是演化成最终的产品，当然它们也可以变成最终的产品，但那是对于需求收集任务来说是偶然的。
-
思维导图
思维导图是绘图和文字的结合，是用图案的存储信息的方式来展示信息。
所以导图把用线把表示信息的词和图联系起来，从而模拟大脑的存储机制。
导图对于组织思想是非常有用的。
关于思维导图的一个技巧是：使用能够找到最大的只会最大的最最大的纸或白板。- 谋杀卷宗
我们常常对业务分析任务才用同样的方式：我们收集所有文档和其他的证据放入一个活页夹。
有的时候是几个活页夹。
像侦探一样，我们的目的是创建并集中存放，以备将来应用。
就像侦探常常通过回头查看谋杀卷宗来破案一样，分析师也可以从项目卷宗中发现有用的好东西。 -
录像和照相
录像可以用于研究业务，可以结合用户访谈和现场观察，用户一起使用录像的使用可以更加结构化。
显然，在对别人进行录像之前，必须征得他们的同意。 -
博客和论坛
互联网是一个慷慨的需求来源，可任意查找感兴趣的领域。
你可能会发现许多关于其他人在这个领域完成的工作的信息。
如果走运的话，你会直接发你会直接，你会发现直接可以转化为产品需求的信息。 -
文档考古
文档考古学是通过检查组织使用的文档和文件，来确定根本的需求文档。
考古学是对当前工作使用或产生的文档进行反向工程，从而得到新的需求。
但是要注意，仅仅因为文档是来源于当前计算机系统或手工系统的产物，并不代表它就是正确的也不表示他就是客户所需要的。
也许该文档并没有什么用处，或者需要大幅修改才能成功的复用。 -
家庭治疗
不应该期待每个利益相关者彼此同意，应该帮助他们成为一个整体，接受其他人的不同意见也不一定是错的，总是需要选择和折中。
我们使用家庭治疗中的思想，帮助我们聆听利益相关者并提供反馈，以避免错误的解读。
共读《掌握需求过程》P2问题及业务分析（第三章~第七章）
我们需要选择在给定的情况下，应该使用几个技巧。
这取决于几个因素：最重要的就是你对这种技巧的得心应手的程度。
还有一些其他的因素，包括地理位置一流，系统抽象以及知识。
本章小结
我们这里讨论的“网罗”关注的是发现和理解业务，开始由分析师的研究，主要集中于当前的工作。
这种研究应该尽快完成，只要利益相关者一致同意实际工作上工作是什么，就不必进一步研究了。
其中最重要的工具就是“思考”和“倾听”。
网罗技巧是沟通的工具，它会有助于你和一利益相关者进行对话并提供反馈。
小婧的小结
经常有人会问如何做业务调研，如果进行需求调研。
其实这里介绍了很多技巧，但是这些技巧并不是在每个产品或者项目上都会使用到的。
建议大家对经常使用的几种熟练掌握。特别是Born Cow模型、访谈、做学徒。
对于原型，我的观点和作者的观点非常一致：原型和草图是可抛弃，目的不是演化成最终的产品，当然它们也可以变成最终的产品，但那是对于需求收集任务来说是偶然的。
第六章 场景
1场景
场景准确来说就是情节梗概或一系列假设的步骤。
建议在编写场景时，将业务用例的功能分解成一系列步骤。
每个步骤都是某种有意义的，可识别的活动构成业务用例的一部分。
目标是保持场景足够简单易于理解，3到10个步骤，通常能够实现这个目标。
邀请利益相关者参与修订场景，直到它代表了工作中应该做什么的一致意见。
2业务的本质
业务的本质不是对问题更好的解决方案，业务的本质是真正的问题。
如果你消除了工作描述中通常充斥的所有技术伪装，就会发现真正的业务问题。
有几种图可以用于描述业务场景，包括活动图，跨职能流程图。
3场景的划分
正常场景就是一个非常美满的情况。
异常是对正常情况的偏离，它是人们不希望发现的，不可不希望发生的，但又不可避免的。
只有有了正常情况，你才能有条理地研究它的步骤，寻找出一场决定如何处理它们。
异常场景的目标是展示工作如何安全地处理异常。
换言之，必须进行哪些步骤才能正确回到正常的情况。
假设场景让你探索一些可能性对业务规则提出疑问。
假设场景的目的是激发创造性，引导利益相关者得到更创新的产品。
在收集需求时尝试产生一些假设场景，来研究不可预见的事情。
这样做的意图是将不可预见转变为可以预见在，构造产品之前对可能发生的事情了解的更多产品就会更健壮更耐用。
小婧的小结
有一本书叫做《实例化需求》，不知道大家是否有看过。其实很多的需求书籍都有在倡导使用场景来进行需求的描述。这种使用场景进行需求描述的方式有时也被称为“用例需求”。而在进行SOA设计时，需求的用例化使得SOA的实现变得更加可行。
而至少现在在我接触到的BA来看，使用用例进行需求的描述的方法在实际项目和产品中使用的非常少。
原因可能是在于BA对于编写用例的技巧掌握的不是很娴熟，更重要的原因在于BA没有深入的去梳理和理解所有的业务场景和分支。
第七章理解真正的问题
1.Born Cow模型在横线上思考
花时间在横线之上是为了发现真正的问题，避免在许多组织机构中发生的情况。
需要从所有的解决方案中分离出问题的本质。
无论技术如何实现，本质总是存在的。
寻找业务本质的重要一步就是查看端到端的过程，忽略当前工作所在部门的划分。
在我们深入未来之前，值得强调一点：你必须理解工作范围内的当前工作本质，要开始思考，非常偶尔地问你的产品拥有着一个简单的问题“未来你希望开展什么业务”。
共读《掌握需求过程》P2问题及业务分析（第三章~第七章）
转向未来不只是愿望，这需要业务分析师的创新以及业务利益相关者愿意贡献并接受新的思想。
你要做的是得到现在的业务本质，将他变成未来的业务本质。
要让你的项目有价值，你就必须导致业务上的某种进步：你和利益相关者必须创新并找到重要的变化，而不只是安于立行的增量式改进。
你不只是在构建一个另一个计算机系统，而是要改进工作。
2.如何创新
有三样东西是人们想要的，他们愿意为之付出支配金钱：快乐、面子和方便。
你的业务能够提供方便性，这不是很难的工作。
但要提供这一特征，你必须从建设的解决方案上后退一步，从用户的视角来审视它，考虑用户的本质目标，然后尝试让用户用较少的步骤来实现该目标，比你计划的更少。
3.系统思考
和创新一样转向未来，意味着系统思考工作，整个问题端到端的系统。
视野太狭隘，只看见一的产品会妨碍系统思考。
产品的基本功能和它选择的用户交互的方式肯定是重要的，但产品在更大的组织机构范围内所做的事更重要。
后退一步，看产品如何影响其他的工作。
4.价值
我们做需求的前提是，如果你创造一个软件，一个消费产品或一种服务，那么它必须对拥有者有价值。
价值表示你准备付钱的某个东西：你根据它的价值决定是否要购买如果你觉得费用值得，那就在上面花钱，如果你觉得要求的价格不值，那么那对你就没有好价值，你就不买它。
价值可以认为有三个因素构成：回报处罚和成本。
5.假想用户
如果真正的用户不能出席或者人数太多，无法逐个进行访谈，假想用户用户就有用了。
假想用户是一个虚拟的角色代替真人用户。
建议在无法接触到真正的用户和客户时，采用假想用户。
与代理人相比，假想用户几乎总是能更好地代表用户。
6.挑战限制条件
这是每一个业务分析师都应该做的事。
这里的限制条件是强加在问题或可选，解决方案上的限制，它可能是一条业务规则，说某个过程必须以某种方式进行，也可能是一条指令，说明解决方案必须采取的方式，或者是关于其他任何方面的。
限制条件的问题在于每个人都假定现实条件是真实的不变的。
挑战限制条件常常导致一些令人吃惊的创新。
7.创新研讨会
创新研讨会是产生想法的一种方式。
如果有大量的利益相关者参与创新过程，可以使用这种方法。
如果希望利益相关者理解新的更好的工作方式带来的好处，而不只是重新构建同样的老系统，也可以采用创新研讨会。
采用创新研讨会，有以下建议：
- 设定创新的范围
- 利用业务时间划分范围，让参与者能够专注到端到端的业务过程
- 为研讨会制定计划
- 进入研讨会上发生的一切
- 在研讨会后将结果反馈给参与者
- 孵化
8.头脑风暴
头脑风暴是一种创新的方法。
头脑风暴很有用，针对问题的范围，或范围可以是什么，它会产生许多想法。
这种策略并不是要推动不受约束的范围蔓延，相反头脑风暴产生的想法会导致更好的产品，而没有增加费用。
头脑风暴有一些简单的规则：
- 头脑风暴的参加者应该尽可能具有各种学科背景，经验各不相同
- 暂时不要做判断评估或者批评，最重要的是不要争论
- 产生大量的想法，想到尽可能多的想法数量终将产生质量
- 这得到尽可能多的不寻常的独特的疯狂的出格的想法我在新的想法基础上得到新的想法，就在一个想法上产生了一个想法
- 记下每个想法不要删减
- 如果感觉受到阻碍，可以从字典中随机手的时候去一个词让参与者想出相关的一些涉及该产品的词
- 让会议变得有趣
小婧的小结：
在《Business Analysis》一书中，花了很多的篇幅去描述如何定义真正的问题，并且给出了解决步骤。这个部分我在之前的文里也写过很详细的解读。
我更愿意将本章理解为一种“创新的号召”。创新其实并不难，有很多方法可以激发你的灵感，最终实现创新。
小婧是一名行走在产品路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！
