BABOK:业务分析知识体系指南（节选学习-03）

/*续上篇《BABOK:业务分析知识体系指南（节选学习-02）》*/

/*本篇标题：《BABOK:业务分析知识体系指南（节选学习-03）》*/

1.5 Tasks

1.5 任务

每个知识领域都描述了业务分析师为达成该知识领域的效用而需要执行的任务。在BABOK指南中的每个任务是以下列形式进行表述的：

1.5.1 用途

每个任务都有一个用途。用途是用一段简短的描述来说明业务分析师执行该任务的理由，以及通过执行该任务，能产生什么价值。

1.5.2 描述

任务其实是业务分析所有工作中必须被执行的一个工作要素。在大多数业务分析行动中，每个任务都必须至少被执行一次，但是对于每个任务可以被执行的次数，并没有设置上限。任务可以以任何尺度执行。每个任务的执行期间都可能从数月到几分钟不等。例如，一个业务专案(Business Case)可以是一篇长达数百页的文件，以提出一个数百亿美元的投资，或者是一个简单的语句，说明针对一个特定的个人，做出一项改变所带来的益处。

任务具备下列属性：

>一项任务的完成，产生一个对于发起组织有价值的输出结果──这就是说，如果一项任务被执行，那么它应当产生出某种可证明的，有积极意义的产出结果，该产出结果是有用的、具体的、可见的，以及可衡量的。

>一项任务的完成──原则上说，可以通过另一个人或另一组人利用该任务的输出结果去执行它的后继任务。

>一项任务也是与其关联的知识领域所意图达成目标的必要组成部分。

BABOK指南并没有规定任务执行的过程和顺序。有些任务的顺序是不可避免的，例如当特定任务产生的输出结果是另一些任务的必需输入。然而BABOK指南仅仅规定了输入必须存在，谨记这一点是非常重要的。输入可能是不完整的或者取决于变化和调整，这也可能导致任务需要被多次重复执行。迭代或敏捷的（项目）生命周期也可能要求所有的知识领域中的众多任务被并行执行，即使是清晰定义的（项目）阶段，每个阶段仍然需要执行来源于多个知识领域的任务。只要任务必需的输入已经具备，任务就可能以任何顺序被执行。任务的描述在更大程度上解释了为何该任务要被执行，该任务是什么，以及该任务应当完成的最终结果。

1.5.3 输入

输入代表一项任务开始之前所必需的信息和先决条件。输入可以是：

>业务分析范围以外直接产生（例如，应用软件系统的建设）；

>由某项业务分析任务产生。

这里没有假定一旦一项输入或者输出产生，就意味着相关的可交付物已经完成或者已经处于最终状态。输入需要足够多到什么程度呢？仅仅需要充分到能够让后续工作开展的程度。在整个业务分析行动的生命周期中，任何数量的输入都是有可能存在的。

图 1-2：任务输入/输出图示:

1.5.3.1 需求

需求是输入或输出的一个特例，对于业务分析行动来说，需求的重要性是不言而喻的了，它们是唯一不由单一任务产生的输入或输出。需求能够被以多种方式和多种状态进行分类。当被做出输入或输出列在任务中时，下列格式将被用来指出需求分类、需求状态，以及需求系列：

需求分类[陈述或状态]。如果没有列出分类或者状态，任何或者所有需求都可以被用来作为输入或输出。例如，需求分类[状态]表示需求可以有任何分类，反之，业务需求就意味着这个需求可能是处于任何可能的状态中（例如：已验证，已完成优先级排序、已陈述，或者已进行需求合并）。

状态也可以被合并描述，例如，需求[已验证并且已完成优先级排序]可以被解读为这个需求已经已经完成优先级排序并且也已经被验证。需求 [已验证或者已完成优先级排序] 可以被解读为这个需求已经完成优先级排序，或者已经被验证，或都有。

通常来说，状态被写在前面，紧跟着分类（例如，已陈述需求，已验证业务需求，等等）。当然，如果没有指明状态或者分类，这就意味着提到的需求不仅限于任何特定的状态和分类。

1.5.4 要素

这部分的形式和结构对于每个任务来说都是独一无二的。要素部分描述为了执行任务而必须理解的关键概念。

1.5.5 技术

每个任务包含一系列的相关技术。有些技术是特别针对某个单独任务的绩效的，有些任务（参见第九章：技术）是和众多任务的绩效相关的。如果一个特定的任务可以使用多种不同类型的技术，在第九章找到的任务列在“通用技术”小节。如果没有小节，那么所有的技术都可以在第九章找到。欲了解更多信息，请参见技术（1.6）章节。

1.5.6 干系人

每个任务都列出一个常见干系人列表，这些干系人可能参与该任务的执行，或者会受到该任务的影响。常见干系人代表这样一类人，业务分析师很可能与他们以某种特定的方式进行交互工作。BABOK指南并没有强制要求在任何给定的特定行动中，必须要具备这些干系人的角色。此外，任何干系人都可以是需求、假定或约束的来源。

该列表并不意图去给出所有可能的干系人分类的详尽无遗的信息，因为编制这样一个列表是一件不可能的事情。有些附加的例子，用于说明符合常见干系人的角色的人员，参见图1-3。在大多数情况下，每个分类下可能会有多个干系人角色。类似地，每个人员都可能承担超过一种角色。

1.5.6.1 业务分析员

根据定义，业务分析员是一个贯穿所有业务分析活动的干系人。BABOK指南是基于业务分析员对业务分析活动的执行负有责任和课责的假定而撰写的。大多数情况下，业务分析员也应当对其他干系人角色的任务绩效负责。众多附加在业务分析员之外的常见角色可以是：问题域主题专家、实施主题专家、项目经理、测试工程师。对于如何履行这些附加角色的指导不在BABOK指南范围，这些附加角色不在业务分析师的职责。

1.5.6.2 客户

客户是在给定组织或组织单元边界以外的干系人，客户是组织提供的产品或者服务的使用者。组织对客户负有合同或者道德上的责任。

1.5.6.3问题域主题专家(SME)

问题域主题专家是对业务需要或解决方案具备精深知识的个人。这个角色通常由最终用户或者解决方案的间接用户来承担，间接用户包括：经理、过程所有者，法务人员（或者监察方的代理人），顾问，以及其他专家。

1.5.6.4最终用户

最终用户是和解决方案直接进行交互活动的干系人。该术语通常频繁被使用在软件开发语境中，最终用户是那些实际使用开发出来的应用软件的人，但在一个关于解决方案的更宽泛的语境中，最终用户包括业务过程（流程）中的所有参与者。

1.5.6.5实施主题专家(SME)

实施主题专家是负责设计和实施潜在解决方案的人。实施主题专家将会提供解决方案组件的设计和构建工作，这些工作是在业务分析工作范围之外的尽管为所有的行动定义一个合适的实施主题专家角色的列表是不太可能的，一些常见的通用角色包括：

开发人员/软件工程师

开发人员负责构建应用软件系统。开发人员或者软件工程师的专业技术领域包括使用特定的语言或者应用组件的能力。良好的软件开发实践会极大地减少应用系统建设的成本，提高开发过程的可预见性，以及增强对应用系统支持的功能实施变更的能力。

组织变革管理管理专业人士

组织变革管理专业人士是负责促进新的解决方案的接受和采纳，以及克服对变化的抵制。进行专业性的变革管理的领域技能包括行业和背景文化的知识。好的变革管理能够帮助组织内部对变革的拥护。

系统架构师

系统架构师是负责将应用软件系统分解成组件，以及定义它们之间的交互活动。系统架构的领域技能包括理解特定供应商提供的方法论和解决方案。好的系统架构能够促进解决方案的快速开发以及在其他解决方案中对组件的重用。

培训师

培训师负责确保解决方案的最终用户理解它将如何工作，并能够利用它有效地进行工作。培训的领域技能包括基于课堂的或者在线的教育培训。有效的培训能够促进对解决方案的接受和采纳。

可用性专业（设计）人士

可用性专业（设计）人士是负责技术方案的外部交互设计，以及将这些方案制作得越简单适用越好。该领域的技能包括用户接口设计师，信息架构师。良好的可用性设计能够提高生产率，客户满意度，以及降低解决方案的维护和培训成本。

1.5.6.6项目经理

项目经理负责管理交付一个为了满足某项业务需要的解决方案所必需完成的工作，以及确保项目目标的达成，与此同时在项目的多种约束条件之间做出平衡，包括范围、预算、进度、资源、质量、风险、以及其它。

1.5.6.7测试工程师

测试工程师负责决定如何去验证解决方案是否符合业务分析师定义的方案需求，与此同时开展验证过程。测试工程师寻求确保解决方案符合适用的质量标准，确保导致失败的相关缺陷的风险能够被理解并且最小化。

1.5.6.8监察方

监察方负责定义标准和标准的贯彻执行。标准可能是开发解决方案的团队必须遵从的，也可能是解决方案本身必须达到的，也可能这两项同时都要满足。监察方可能是强制性的法律，企业的治理标准，审计标准，或者由组织的竞争力中心定义的标准。

1.5.6.9发起人

发起人负责启动定义业务需要的工作，以及为了满足该需要进行方案开发的工作。他们授权工作的执行，控制行动的预算。

1.5.6.10供应商

供应商是在给定组织或组织单元边界以外的干系人，供应商为组织提供产品或服务，供应商对组织负有合同或者道德上的责任。

1.5.7 输出

一项输出是任务描述中的工作的必要成果。输出作为成功完成的任务的创建、转换，或状态改变的结果。虽然一项特定的输出由某个任务所创建和保持，一项任务是却可以多个不同的输出。

一项输出可以有一个交付物或是一个更大些的交付物的一部分。输出的形式独立于进行中的行动任务的类型，独立于组织采纳的标准，独立于业务分析师的最佳判断─关于什么是合适的途径来呈送干系人的信息需求。

和输入一样，一个特定的任务可以在其最终状态并不产生输出的情况下被完成。输入，或者输出，仅仅需要完善到足够后续工作开展的程度即可。相似地，也许有一个或者多个输出的实例，作为一个给定的行动任务所创建的输出的一部分。最后，输出的创建并不一定要求使用该输出作为输入的后继任务必须立即开始。