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