共读.jpg

第八章 开始解决方案

在到达产品的Future-Now视图之前，花了一些精力来发现产品打算做什么。

图片发自简书App

目前已经收集了大部分功能需求和重要的非功能需求，而且收集到的是本质的与技术无关的需求。

图片发自简书App

1 确定产品的范围

业务分析师的任务是确定为工作未来应该是什么，以及产品怎样能为工作提供最大的帮助。
只有先理解工作，然后将工作的一部分自动化，我们才能无缝地将自动化的产品放到工作中去，得到正确的产品范围，对于得到正确的需求是很关键的。

2 考虑用户

如果你打算销售你的解决方案，或如果你需要人们自愿开始使用它，那么你就有理由希望产品能吸引潜在客户。
研究用户的一种方式是采用族群研究，即研究人们的习俗和文化。族群研究的目的是描述目标对象的本性，如何进行如何行为和思考。
第二种方式是假想用户。烈建议你观察真正的用户，或采用假想用户。尽量不要使用用户代理，他们常常说出他们想象的需求，但因为他们不是真正的用户，这种需求有时候很不靠谱。

3 设计用户体验

设计的目的是得到一种使用体验，令人满意且令人激动，同时符合用户的文化和期望。
这样的设计更专注于用户对产品的感觉，而不是为产品增加功能。
体验设计不应该让业余的人员来做，它结合了许多学科。
如果希望做对，就应该交给有经验的专业人士。
业务分析师不是有经验的体验设计师，但他理解本质业务的功能需求和非功能需求。
业务分析师已经确定了一些顾问，比如易用性、心理、图形设计和文化专家，可以在项目遇到问题时请教他们。
业务分析师在这里的任务是提出建议为业务辩护，而不是自己尝试设计用户体验。

4 创新

不要冲向首先想到的解决方案，而要花一点时间和利益相关者一起寻找更好的解决方案，更能经得起时间考验，更有吸引力的方案，创新的方案。
有一些创新的触发器，我们在项目团队中使用这些概念来促成创新，找到更新更好的解决方案。

• 方便：主要思考你的用户想做什么，尽可能让这事儿又方又容易又方便
• 联系：假定你的客户和现代大多数人一样，认为联系很有价值，那么尽量为他们提供联系。“我的产品能做些什么，更好地建立与客户或用户的联系呢？”
• 信息：想想你的业务客户：他想要信息想要很多信息，而且希望没有延迟
• 感觉：如果你的客户或用户在使用时感觉不好，就不太可能会使用它

最后你必须让用户或客户感觉你在响应他们的需求。
也就是说你的解决方案必须足够创新，让客户觉得你已经理解了他的请求，正在进行所能提供最适合的解决方案，你的响应是你所能发出的最强烈的信息。

5 相邻系统和外部技术

相邻系统，正如其名他们是某种系统，与你的工作相邻，他们在上下文范围图中用方块符号表示。
看图你会发现，相邻系统从你的工作接收数据或服务，反过来也为你的工作提供数据。
你要构建的产品的范围在某种程度上是由相邻系统期望决定的，你需要理解他们以及他们在工作中可能扮演的角色。
为了方便考虑，你可以将这些系统分为三类：主动的，自治的和合作的。

• 主动的相邻系统
  主动的相邻系统是人，他们与工作交互或参与工作。
  仔细弄清相邻系统的想法，产品将实现周围世界的更多需求。
  换言之，我们得到了更好的更有用的产品。

• 自治的相邻系统
  自治的相邻系统是某种外部实体，诸如一个公司，一个政府部门，一个顾客。
  他们不直接与工作交互。
  自治的相邻系统，通过单向的数据流工作进行通信，如信件，电子邮件或在线表格，没有来回的交互。
  让相邻系统参与进来，有更多机会可以得到更好的产品。
  你只需要足够属性自治的相邻系统识别期望和机会，扩展产品的范围，就能让相邻系统更密切地参与到工作中来。

• 合作的相邻系统
  合作的相邻系统是自动化的系统。
  在业务用例执行的过程中，他们与工作合作。
  通常的方式是简单的请求-响应对话。

6 成本收益和风险

选择解决方案，不只是在过程模型上画几道线，并希望得到最好的结果。
你有责任得到最有价值的产品，即对拥有者有价值。
这意味着解决方案的成本必须与它给拥有者带来的收益相称。
类似的，风险必须与收益和成本相符。
这里的风险包括潜在的问题，变成真正问题的可能性，以及问题成真所带来的负面影响。

7 产品用例场景

在合适的会议上，将产品用例场景展示给利益相关者，不要只给他们发电子邮件，你需要得到他们的反馈。
文档，不是用来记录产品做什么，而是为什么产品做他所做的事。
利用这种技术来克服许多需求规格说明书中固有的问题：他们很难阅读，甚至不可阅读。

图片发自简书App

开始，先确定业务事件，选择其中一个。
然后通过网罗发现对该事件的响应，如业务用例。作为展示你的理解的一种方式，写下这个事件的业务用例场景。
如果利益相关者对这个场景满意，就决定该业务用例的哪些部分可以实现为产品，得到的结果将成为产品用例。
建议通过，产品用例场景来描述它。

怎样使用产品用例场景呢？
首先它以适合业务利益相关者的方式解释了预期的产品要做什么。
在展示该产品时，你可能发现，需要对它做一些改动，但到了你和利益相关者完成讨论时，他应该准确反映要构建的产品。

本章小结

没有公式化的方法能得到最佳解决方案。
你需要考虑很多因素，最佳设计就是这些因素的最佳折中。
你将被拉向许多方向，一个方向是功能性。
一般来说自动化的功能越多收益越大，很自然，开发成本拉向完全相反的方向。
另一个方向是差异化。
差异化，意味着你的解决方案与其他解决方案有明显的区别。
一般来说，你的产品差异化越大，它带来的收益越大。
你的解决方案应该是创新的，创新不是意味着闪亮的界面特征，而是用户在采用你的解决方案，是以创新和有益的方式工作，或者你的解决方案包括了一些创新或有益的工作。
在一些情况下，创新会带来额外的成本，但在大多数情况下，它带来的收益超过了所有国外的时间成本。
另一个要考虑的因素是影响产品设计的限制条件。
非功能需求也会影响解决方案。

图片发自简书App

所有这些因素都有设计技术可行性支持，在这一切之上，也许代表了最重要的影响，是公司和项目的目标。

小婧的总结：

这个章节其实和下一个章节一样是承上启下的部分，首先对之前的工作进行一个总结，然后告知大家在开始准备解决方案的时候需要考虑到的因素。
一个最佳的解决方案必定是多个方面权衡的结果，在此过程中虽然业务分析师是主导，但是也需要挖掘各个角色的参与。
但是总体来说，还是不涉及到技术实现的细节，依旧需要用业务的眼光去观察和思考。

第九章 今日业务分析策略

今天的业务分析师有一项额外的任务：决定最佳的策略来发现和沟通需求，不论组织机构决定采用哪种方式实现自动化。

1 几种策略

图片发自简书App

• 外部轮廓

图片发自简书App

拥有外部轮廓的项目是：你将发现的需求发送给外部的解决方案提供商。
外部轮廓适用的情形包括从外部供应商那里购买已完成的解决方案，或将解决方案的开发外包，或将需求发给几个供应商竞标，如果你需要采购或集成一些组件，可能涉及到多个供应商。

• 迭代轮廓

  
  
  图片发自简书App
  
  

  你有机会以迭代的方式发现需求，并交付部分解决方案，直到产品完成。
  这种轮廓的动机是希望尽快交付给客户一些结果，并响应业务的变化，采用这种轮廓时，开发解决方案的开发者和你密切合作，通常他们和你属于同一个组织机构。

• 项目轮廓（顺序轮廓）

  
  
  图片发自简书App
  
  

  记忆顺序型项目，对具体的活动和交付社有更多的限制，在极端的情况下，他们有严格的阶段，必须得到文档才能进入下一个阶段。
  需求必须完全确定，才能提交给设计者和开发者，让他们开发解决方案。
  采用这种轮廓的项目在经过阶段检查点后就很难改变。

你的项目很有可能是三种混合的形式，或者包含其他一些活动。
要发现最适合你的项目的策略，最佳的方式是从一个一般的轮廓模型开始，这个轮廓模型很像你目前的工作方式。
然后你进行改变，完成以下目标：

• 通常通过经常交付中间制品或能工作的软件来确保利益相关者参与
• 对业务变化的响应更快
• 让利益相关者更容易提供反馈，避免得到的交付产物，只是复制了原有的知识，基本上不提供新知识

2 提升需求技能

• 不再只是记录员
  今天的业务分析师不只是考虑软件解决方案，而是更关注解决业务问题。
  今天的设计师必须更加积极主动，问题不是你想要什么，而是你要做什么。
  业务分析师现在不仅必须研究利益相关者的需求，而且必须研究产生这些需求的人。

• 限制写下需求数量
  你可以通过迭代或排列优先级限制要写的需求数量。
  如果你已确定了所有的业务事件，建议你对它们进行优先级排列。
  这里所说的优先级意味着你要寻找一些业务事件，改进它们的实现，会给拥有产品的组织机构带来最大价值。
  这些业务是事件如果实现，将导致业务过程成本的最大缩减，。
  会让客户卖出更多的产品，或提供一项服务，带来更大更有利润的客户群。
  如果你发现了这些高价值的事件就按惯例开始开发业务用例场景，随后是需求，从而实现它们。
  然后回到业务事件列表，重复这个过程。
  每次回来选择比上一轮优先级低的一些业务实践。

• 复用需求

• 创新与业务分析师。
  一些微小的增量式改进需要靠业务分析师来领导创新冲锋。
  不是要成为产品项目中的唯一创新者，但他必须是建议创新的人，协调创新会议，让利益相关者有机会提出创新建议

• 寻找业务规则
  作为业务分析师，要揭示以前位置的规则或领导创新，创建新的规则。
  有一种开发方法学叫“业务规则方法”，他用自然语言记录业务规则，然后翻译成业务过程，有时候会翻译成软件。

-分析师作为思想代理
作为代理业务分析的任务，业务分析师的任务是理解每个孤岛的关注点，并在孤岛之间进行解释和沟通

• 系统思考与业务分析师
  业务分析师研究一个系统时，一定不能只看到组件，而是要看到他们写作的方式。
  业务分析师关注研究业务领域，采用系统的观点意味着不仅要看到工作中逐渐的相互连接，而且要看到工作，如何适应更大的系统。
  组织机构本身实际上也要研究组织结构如何适应更大的世界

• 业务分析师与可视化
  在任何产品开发过程中，可视化都是必要的部分。
  可视化通常与数据有关，通过让数据可视化，用图形的方式展示数据，数据的含义就会得到更丰富更有力的体现。
  要有效的可视化，建议画草图。
  画草图的目的是传递信息，让产品可视化。

小婧的小结：

本章总结了不同项目的转阶段标志，具体的可以根据自己的产品项目特点来选择仔细研究。
这是本章最有价值的可落地实操的部分。
我觉得大部分的项目应该是属于迭代轮廓和项目轮廓的综合。
这里面的翻译总是觉得怪怪的，我觉得其实主要是“轮廓”这个词翻译的不好，应该就是开发的模式，是迭代的还是纯瀑布的。
这样比较容易理解。

第十章 功能需求

功能需求指明了产品必须做的事情，即产品为了满足它存在的根本需求和根本理由，而必须执行的一些动作。
需要功能需求，是因为当业务分析是理解了产品必须的功能后，他要用功能需求告诉开发者要构建什么。
如果利益相关者对产品用例场景达成一致，业务分析师写下一组功能需求，确定该场景表明的功能，接下来开发者利用这些需求来构建产品。

图片发自简书App

1 细节程度或力度

需求是由一个单句写成，只有一个动词。
注意产品“应该”的形式，他使用了主动句，并关注于沟通产品打算做的事情。
也为开发者和其他利益相关者提供了一致的形式，这些人需要清楚地理解产品打算做什么。

2 描述和理由

需求不止包含描述，你需要在需求中添加理由，说明需求为什么存在。
在某些情况下，这可能很明显。
但在许多情况下，这是需求的关键部分。
加入理由后，你不仅让开发者有机会构建最好的解决方案，而且也告诉测试人员，需要在测试这项需求上投入多少工作量。
很清楚理由表明这项需求值得关注，对描述给出理由，需求本身就变得更有用了。
也向未来的维护者说明了需求一开始为什么会存在。
理由也有助于克服不小心写下解决方案，而不是真正的需求。
很容易通过描述一种实现来隐藏重要的功能，也容易选择最明显的实现，忽略可能更好地实现。
不论需求最终如何实现写下描述和理由，显然会导致发现真正的需求。

3 数据你的秘密武器

只要你开始收集常用的术语，就应该在数据字典中定义术语的含义。
你列出这些数据流的属性，从而定义他们，这些属性又让你能建立业务数据模型。
这个数据模型作为某些功能需求的定义，并为团队提供了共同的语言。

4 异常和可选方式

异常是不期望，但不可避免地对正常情况的偏离。
是由处理的错误或不正确的活动引起的，对于这些需求必须明确的说明，只有当异常发生时，他们才会成为现实。
为了做到这一点，可以标明一些需求与特定的异常有关，或者于每一项需求都包含这个异常条件。

5 有条件的需求

如果需求只有在特定的处理环境下才会发生，就会出现这种情况。

6 避免二义性

不论你的需求来源是书面的文档还是访谈的口头描述，都应该注意大量潜在的二义性和由此带来的误解，比如一词多义。

7 技术需求

技术需求是纯粹因为所选择的技术而需要的功能。
技术需求不是因为业务上的理由而存在，而是为了让选择的实现方式能工作，将技术需求放在一份单独的规格说明书中记录下来。

小婧的总结：

本章对于描述功能需求方面进行了一些讲解。
值得关注的是第二个部分，关于“理由”的说明。
我非常赞同与研发团队沟通的时候“顺便”介绍一下我们为什么要做这样的需求。
有的时候研发团队在设计的时候会根据你这个“顺便”提供更好的可扩展的设计和解决方案。
但是在这个过程中要警惕“需求镀金”。

第十一章 非功能需求

非功能需求描述的产品必须具备的品质。
换言之，将事情做到什么程度。
这些需求让产品有吸引力，易用、使用快速、可靠和安全。
需要这些属性不是因为他们是产品的功能活动，而是因为客户希望这些活动以特定的方式执行并达到特定的品质。

非功能需求并不改变产品的基本功能，也就是说不管增加多少属性，功能需求都会保持不变。
更复杂的事，非功能需求可能为产品增加功能。
功能需求导致产品去完成工作，非功能需求为工作赋予特征：功能需求是动词，非功能需求是形容词。

图片发自简书App

非功能需求类型：

• 观感：产品的外观精神实质
• 易用性和人性化：产品的用心程度，以及更好的用户体验所需的特征 可用性考虑
• 执行：功能的实现必须多快，多可靠，能完成多少处理量，可用性，多精确
• 操作：产品的操作环境，以及对该操作环境必须考虑的问题
• 可维护性和支持：预期的改变以及完成改变允许的时间，也包括对产品的支持的规定
• 安全：产品的安全性、私密性、可恢复性和可审计性
• 文化和政策：由产品的操作所涉及的人的文化和习惯所带来的特殊需求
• 法律：哪些法律和标准适用于该产品

为了遵从不要写解决方案的指导原则，请检查你的需求，如果它包含任何技术因素或任何方法，就重写它，避免提及任何技术或方法。
可能需要反复做几次，直到达到要求的技术无关性，但对最终产品设计的影响来说，这是值得的。

小婧的小结：

其实非功能需求很多都是和业务场景以及功能需求相关的。
我们在考虑非功能需求的时候可以从这些角度出发。
比如这个场景下会有哪些非功能的要求。
然后站在模块或者产品的角度去思考诸如安全性、可维护性等方面的非功能性需求。
而且我个人觉得非功能性需求之间可能也存在权衡和取舍的问题，比如要考虑数据安全性，可能就会损失一些易用性。这个具体要看产品的要求以及客户的关注点。

小婧是一名行走在产品路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！