第二章：Business Analysis Key Concepts

在正式介绍Business Analysis的六大知识领域之前，先就一些后面会用到的关键概念进行了介绍。

特别是这里面有些困惑大家已久的概念，对这些概念进行声明，便于达成共识后进行后续知识的学习。

Business Analysis Core Concept Model

BACCM主要是对BA工作过程中的六个核心概念及其之间关系的描述。

这个模型可以用作：

在业务分析过程中，对专业业务和领域进行描述。

对于业务分析过程中遇到的信息进行评估。

可以作为BA开展工作的思考框架。

变革Change

Change is the act of transformation in response to a need.

It works to improve the performance of an enterprise.

从这个概念我们不难看出，Change是一个高层级的动作，它会对整个enterprise产生改善绩效的影响。

也可以说，这个Change是需要与战略、目标一致的。

需要Need

Need is a problem or opportunity to be addressed.

我们可以把Need理解为纯业务的，与技术、解决方案无关的。

甚至我更提倡直接将其理解为待解决的问题。

我们在做解决方案的时候，一般都是从问题出发的。

之前我写过“需求分析第一步：定义真正的问题”。

（可以点击链接直接跳转查看相应的文章）

我们的日常工作中最经常接触到的是Need，对于Change一般是中高级领导会去思考的问题。

但是我们在分析Need的时候不能偏离Change。

也是一种不忘初心。

当然也不排除分析Need后，导致了Change的发生。

解决方案Solution

Solution is specific way of satisfying one or more needs in a context.

解决方案是用来解决问题，满足相应环境下的需求的。

这点就不多说了，没有什么歧义。

干系人Stakeholder

Stakeholder is a group or individual with a relationship to the changes, the needs, or the solution.

基本上受到Change、Need、Solution影响的，或者影响它们的个人或团队都可以视为干系人。

考过PMP的同学都知道，基本上你想得到的人都属于干系人。

这里也不做过多说明了。

价值Value

Value is the worth, importance, or usefulness of something to a stakeholder within a context.

价值不是显然是需要进行评估的，而且是对stakeholder有价值的。

在这里，因为stakeholder的覆盖面非常广，所以价值也会覆盖得非常广。

比如，不仅仅是对客户有价值，对运维人员有价值、对实施团队有价值……

另外，有一点需要特别注意。

在BABOK Guide3.0中，对于价值声明了一点：

价值可以是带来改进、收益等正面的，也可以是一些负面的。

就好像我们在PMBOK中可以看到对风险管理的说明。

其认为风险与机遇都是需要管理的，都属于风险管理的范畴。

在这里，Value也是一样的，有正面的，很负面的。

这个概念对于后面去理解一些其他的信息很重要。

上下文Context

Context is the circumstances that influence, are influenced by, and provide understanding of the change.

这个概念在BABOK Guide 3.0里面被作为关键概念提出，我深感其专业。

现在很多的教程、文章在说需求分析的时候，从来不提业务环境。

你看到中东富人们没有羽绒服，于是去卖羽绒服。

这就是无视环境。

还有在分析一些非功能需求时，也从来不考虑环境。

另外，我一直觉得，任何的需求都是基于业务场景的。

不管你这个需求的性质是什么。

如果没有合理的业务场景，并且假设太多，那么你凭什么说你的设计和解决方案是有价值的呢？

总结一下，当你在进行分析的时候，从这六个问题分别去寻找答案：

What are the kinds of changes we are doing？

What are the needs we are trying to satisfy?

What are the solutions we are creating or changing?

Who are the stakeholders involved?

What do stakeholders consider to be of value?

What are the contexts that we and the solution are in?

Key Terms

本节主要介绍了再BA工作过程中会涉及到的一些关键信息。

这些信息大部分会反复出现在六大知识领域的任务中。

Business Analysis

关于这个概念，在第一章已经进行了说明。

此处不再说明。

Business Analysis Information

这里需要注意的是分析的对象。

这个分析的对象是information，而不是requirement和need。

也就是说，作为BA需要分析的对象是信息，并且这个信息可能是任何的种类、级别、粒度。

Design

Design is a usable representation of a solution.

由此可以看出来，Design是针对Solution的。

Design聚焦在如何才能让Solution实现其价值。

Enterprise

Enterprise is a system of one or more organizations and the solutions they use to pursue a shared set of common goals.

说实话我以前从未注意过Enterprise到底是什么意思。

从这里的定义看来，Enterprise是一个比企业、组织更大的范围。

我自作主张的将其理解为“圈子”，也就是为实现目标的一个大圈子。

这个圈子里有所有的干系组织，以及相关的解决方案。

这个圈子是虚拟的，没有一个非常清晰的边界，并且它的边界是由业务定义的。

Organization

Organization is an auto group of people under the management of a single individual or board, that works towards common goals and objectives.

Organization显然是我们常规意义上理解的组织、企业、单位。

Plan

Plan is a proposal for doing or achieving something.

所有的工作在进行的时候，肯定都需要进行策划。

以PMBOK为例，其中的过程组中就有不少在做规划，也就是Plan的工作。

Business Analysis也是如此。

需要有一定的策划和规划去进行整体工作的指导。

Requirement

Requirement is a usable representation of a need.

这里我们可以看出这个定义和Design非常相似，只是Requirement是聚焦在Need上的。

而在实际的工作过程中，我们很难去界定你在进行requirement的分析，还是在做design。

并且因为各个公司对于BA的职责界定不同，大部分的（国内的）BA不可避免的会涉及到一些Design的工作。

也许有的大公司界定的比较清晰，会有专门输出Requirement的BA，和专门做Design的SA。

但是至少BA需要参与到Design中，以确保Solution可以实现Requirement，这也是BA评估的一个职责。

另外，现在越来越多的团队采用Agile的模式。

造成Requirement和Design的界限更加的模糊。

因为两者之间没有很清晰的交接，而是不断的迭代优化，相辅相承。

Risk

在BABOK Guide3.0中，对Risk的概念及应对措施的描述，与PMBOK一致。

Requirements Classification Schema

众所周知，需求时分层分级的。

而这个层级在BABOK Guide3.0中是怎么描述的呢？

我们按照需求从High Level往下，分为：

Business Requirements——对应Change

Stakeholder Requirements——对应Need

Solution Requirements——分为功能和非功能需求

所以，你是否在日常的工作中直接就落到了最后一级了呢？

你是否遇到过Stakeholder和你提需求的时候，根本就直接就提了Solution Requirement了呢？

另外，在这三类需求之外的另外的一个维度上，还有一个需求：Transition Requirement

一般来说，我们写产品的SRS都会有一个章节专门写“升级影响”。

也就是说，新的版本部署上去后是否会有一些影响。

比如对原有历史数据的影响，是否需要更新、迁移。

这类需求其实就是Transition Requirement。

它有一个特点就是：当实施后就失效了。

我做系统升级只会做一次数据迁移，不会反反复复的做。

所以这个需求只会发生在升级的时候。

但是千万要注意这个需求不能省。

作为用户我曾经经历过因为软件供应商系统升级导致数据丢失的痛苦。

这个影响会很大，后果会很严重。

Stakeholders

在BA的工作中会遇到形形色色的Stakeholder，甚至比项目经理遇到的种类更多。

因为BA的工作不仅仅是在项目进行中，而是在项目开始前的收集、项目中的参与以及项目后的跟踪、评估。

BA

工作中也许你是团队唯一的BA，但是你需要考虑到未来这个需求是否会被复用，是否会扩展到别的部分。

更何况现在大部分情况下，你并不是团队中唯一从事BA相关工作的人。

另外，作为BA你基本上也会有很大的几率兼任以下的角色。

Customer

Customer uses or may use products or produced by the enterprise and may have contractual or moral.

我想把Customer和接下来的End User放在一起进行说明。

End User

End user is who directly interact with the solution.

对比一下不难看出，两者之间的差别。

有的时候Customer就是End User，但是也有不是的时候。

比如，你作为ATM的供应商，你的Customer是银行，而End User是储户。

我们以前最常遇到的问题是，你去业务访谈的对象并不是一线的用户，而是一些管理人员。

他们可能曾经是一线用户，但是因为离开一线很长时间了，对于现状其实了解是很有限的。

对他们提供信息有效性的错误评价，将导致需求的偏差以及解决方案实施的失败。

另外，在后面的章节中，对于Customer和End User的界定，会分别被界定为External和Internal。

对，你没看错，是Customer在外，End User在内。

我仔细思考了下，这个内外应该是对于Solution而言的。

End User直接包括在Solution中。

Domain Subject Matter Expert

业务领域专家们很重要，你的需求、解决方案的评估都要听取他们的意见。

而小婧也一直都在说，BA一条路就是走“专才”。

深钻业务，把自己培养成为领域专家，那么你在做决策和分析的时候更有底气。

而在面对下面这类角色时，BA就是领域专家。

Implement Subject Matter Expert

实施团队主要的职责是实现解决方案。

他们以BA的Requirement为输入，进行Solution的设计，最终提交BA进行Value的评估。

这个实施团队会包括很多的角色，比如：架构设计师、开发工程师等。

Tester

很奇怪，BABOK Guide3.0把Tester作为了一个单独的部分，而没有合并在Implement SME中。

我细想了一下，这有可能是和职责相关的。

在一个职能比较完备的企业中，实施开发与质量保证一般是平级的两个部门。

而他们关注的内容也有不同。

实施开发关注设计和实现，而质量保证关注质量和结果达成。

Operational Support

这个Stakeholder是一个会被忽略的角色。

我们在讲非功能需求的时候会有个“可维护性”。

在我们的需求分析过程中，需要考虑对于运营、售后的相关角色的诉求。

比如是否需要加入一些监控的报表，一些报告，一些检查点来方便他们开展工作。

在进行需求评审的时候，是否需要邀请他们参加，毕竟他们承担着一线的压力。

Sponsor

这个不用说了，相当的重要，给钱的老大。

基本上相关的所有需要审批、签字确认的，都需要他参与。

Supplier

有的时候会有些供应商之类的干系人。

比如你使用了第三方控件，或者开源的什么代码。

比如你需要其他系统提供数据接口，或者其他系统需要你提供接口。

Regulator

把这个放到最后讲，我想说，这个是最最最最容易被忽略的干系人。

这个月我去上海出差，晚上去外滩转了圈。

返回的路上想着骑一辆mobike回酒店。

结果走了很远才在路边找到一辆。

我在刷二维码的时候，过来了一个警察叔叔。

“这里不能停车。”他以为我把车子停这里了。

“不是我停的，我准备骑走。”我赶忙解释。

“快骑走，要不我就拖走了。”

在骑回去的路上，我真的看到有警察叔叔拖着一辆单车。

真的是拖着。

我想，当初应该是没有做Regulator的相关分析吧。

相关的道路、城市管理法规，在进行产品设计的时候需要进行考虑。

特别是一些金融类的、涉密类的产品，在进行分析的时候，一定要考虑一些规章制度的要求。

而在我们企业内部，也存在一些Regulator。

比如我们的QA部门、PMO等等。

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