华为大咖说丨一文带你成为业务分析师

全文约6299字，阅读约需9分钟

BA（Business Analyst，业务分析师）是一个听起来很高大上的职业。理论上，软件研发起源于需求，需求来自于业务，因此BA应该是一个不可或缺的岗位。然而实际情况是，很多公司压根没有这个岗位，一些大厂早期有，可后面也撤销了该岗位。这样看来，BA并非是不可或缺，更像是可有可无。

之所以这样，是因为相较于岗位，“业务分析”更是一种能力。就像软件研发团队，没有架构师一样可以研发软件一样，架构师也是一个“可有可无”的岗位。实际上，业务分析师这个岗位可以没有，但业务分析能力必须要有。而且是所有的软件从业人员都应该有，包括解决方案架构师、业务分析师、架构师、产品经理、软件工程师、测试工程师等等。因为，没有人可以在不理解业务的情况下，设计产品，架构系统，研发系统，测试系统。

然而，这么重要的能力，长期却没有引起我们足够的重视。这次系统地整理这篇文章，希望帮助你迅速提升业务分析能力。 本文将从如何理解业务，如何进行需求分析，如何进行业务建模，三个大的方面，系统地介绍业务分析技术。

PART.1 如何理解业务？

我最近刚通关《黑神话悟空》，我发现理解业务的过程和打游戏的过程类似。一开始觉得二郎神遥不可及，然而道阻且长，行之将至。一个新的业务领域就像一个没有被探索过的新游戏，有很多未知的领域，但随着我们不断推图，业务全貌开始慢慢变得清晰，终有一天，所有的未知领域都会被“点亮”。根据我的经验，很少有高深到不能被理解的业务，二郎神再厉害，也有被打败的一天。只是，你是一把就打过，还是像我一样打了三天才打过，是效率上的区别。

接下来介绍的6个理解业务的方法，就像游戏中的各种道具和加点，可以帮助我们提升效率，减少“跑图”时间。

1.1 组织脉络：理解业务的结构支撑

业务是由人组成的团队来执行，而组织结构则是这些团队协作的骨架。要理解一项业务如何运转，需要先弄清楚他的“组织地图”。特别是我们空降到一个新团队，这一点尤其重要。

一个企业的组织结构，能直观的呈现出他的业务是如何开展的。比如一个典型的互联网公司会包括产品部，运营部，销售部，技术部，人力资源部，财务部，法务部等。熟悉部门的组织结构，以及每个部门的职责分工，能帮助你迅速定位关键角色，理解决策路径，为后续深入理解具体业务活动打下基础。

1.2 用户访谈：倾听业务的需求源头

用户访谈是直接接触业务需求源头的重要方式，前提要明确“用户”和“客户”的区别。以幼儿玩具为例，用户是幼儿，客户是父母，客户是真正买单的，而用户是使用者。如果想要玩具卖的好，在上面标识出“无毒”是明智的，虽然你的用户根本不关心这个。

因此，访谈时要知道干系人在业务流程中的职务，处在业务流中的节点以及业务活动，做好笔记。特别是业务活动，活动的输入输出（数据），业务规则，做好记录，以备后续分析使用。

如果直接用户很难触达，也可以访谈“用户代理”。比如幼儿玩具的用户代理是父母，销售员的用户代理可以是销售主管。访谈时，可以营造一个放松的氛围，比如给被访谈对象带上一杯咖啡，可以挖掘更多有价值的信息。

1.3 实操观察：让业务“活”起来

如果说访谈是耳闻的话，那么耳闻不如一见。访谈获取的是信息，而实地探访用户，可以直观地看到他们如何进行业务操作，了解他们实际使用软件的情况。经过实操观察，能发现许多在访谈中容易被忽略的细节和痛点，获得提高用户体验或生产力的想法。

比如我曾通过观察某银行票据审查员的工作，发现他们在一堆无差别的单据列表中寻找特定单据时非常费劲。这个观察直接促成了一个简单的优化——高亮显示问题单据，极大地提升了效率。像这种问题，客户并不重视，也没有需求提到研发部门，需要实际观察才能发现。观察能让你将抽象的业务概念与具体的操作画面联系起来，让业务“活”起来。

1.4 体验业务：在实践中获得真知

观察不如实操，亲身体验则是理解业务最深层次的方式。我曾经为了了解零售通的供应链业务是如何进行的，就实地到仓库干了半天的拣货工作，然后再跟车送货。整个一圈跑下来，让我对供应链的感知从一堆抽象的概念，变成了具象画面。原来供应链里面很多难以理解的业务问题，一下子清晰明了起来。正如王阳明所说：“你未看此花时，此花与汝同归于寂，你来看此花时，此花颜色一时明白起来。”

1.5 阅读文档和书：填补知识空白

很少有系统或者业务是从零开始构建，更多时间我们都是在遗留系统上做业务叠加、改进、重构、重写。对于这种情况，之前的需求文档，设计文档就是我们获取业务知识非常好的途径。如果你是技术出身，阅读代码，特别是系统的API和数据库的数据模型，也是快速理解业务不错的方式。

另外，阅读领域相关的书籍也很重要，能帮助你建立起对该业务领域的系统性认知，填补知识空白。比如要从事供应链相关软件研发，那么看看供应链、物流相关的书是不错的选择。

1.6 组织会议：高效达成共识

如果一个需求要从几个不同的干系人那里了解信息，可以考虑召开一个正式的需求收集会议，这样效率会更高。会议目的是把不同业务领域的人召集到一起，专注某个特定的流程或者话题，一起建立理解共识，或者产出解决方案。

如果你是空降到某个新业务领域的领导，也可以采用“共创会议”团建的方式组织会议，这样不仅可以高效理解业务，也可以更好地融入团队。

PART.2 如何进行需求分析？

理解业务是需求分析的起点，接下来我们需要用更加结构化的方式，对我们的访谈、问卷、笔记、实操经验等进行整理。从而获得对业务更加深刻的认知，以便在此基础上，整理出软件需求，为后续的软件研发，软件项目管理铺好路，指好方向。

以下四种方法，是需求分析常见的工具。

2.1 统一语言：消除沟通壁垒

在《七步掌握业务分析》一书中，作者把“词汇表”放在业务分析技术的首位。这和我一直强调的统一语言的概念不谋而合。实际上，这个统一语言（词汇表）的工作，应该在我们进入业务的第一天就立即开展。我们要特别留意客户、用户、领域专家口中提到的重要业务术语。如果有歧义，要及时澄清，这对我们后续的沟通、文档、设计、编码将大有裨益。

一个团队只有具有统一的语言，并划分了清晰的边界，才能更好地沟通协作；文档和代码中的核心概念只有保持一致，才会具备更好的可读性和可理解性。因此，任何项目都应该有一份核心领域词汇表，方便团队在这些核心概念的表达和命名上达成共识。典型的词汇表如下所示，至少应该包含中文名、英文名和含义描述，然后团队所有人要遵循词汇表进行沟通，书写。

2.2 用户故事：捕捉轻量需求

相较于传统的Use Case描述，用户故事提供了一种更加轻量、简洁的思维方式。作为理解问题的开始，大部分的系统，都可以通过这种方式来表达。

User Story一般的写法是——As a （who）, I want （what） so that （why）。这样写的好处是，我们可以用简短的话语，把一个事件里面的主要要素（who）（what）（why）都表述出来，即便如此，我们还可以更简便一些，有时候（why）如果是显而易见，或者没那么重要的话，也可以不写。

值得一提的是，User Story不仅是捕捉需求的方式，也是项目管理的方式，很多敏捷项目，会用故事卡片的方式，来分解任务。这就对我们的故事分解提出了要求，故事太大会变成epic（史诗），那么一个迭代（或者sprint）就做不完。与此同时，故事也不能太细，否则会极大的增加沟通和测试成本。

好故事的特点是要有闭包性（Closed Story），衡量闭包性，可以从用户的角度看，做完这件事，这个事是否是就done了。比如用户可以管理招聘广告，就没有一个明确done的标准。而用户可以编辑广告过期时间，就是一个很好的Closed Story。

按照《用户故事与敏捷方法》中的标准，优秀的故事还应该具备INVEST特征：

• 独立的（Independent）
• 可讨论的（Negotiable）
• 对用户或客户有价值的（Valuable to Purchasers or Users）
• 可估计的（Estimatable）
• 小的（Small）
• 可测试的（Testable）

这里有一个小技巧，如果觉得故事太大，可以沿着CRUD的方向进行拆分， 比如管理招聘广告，就可以拆分成发布招聘广告，编辑招聘广告，删除招聘广告，浏览招聘广告4个更小，更INVEST的故事。

至于UML的用例图，你可以认为它是User Story的图形化版本，因为用例图里面最重要的元素是角色（who）和活动（what），这和User Story的要义一致。你可以根据自己的习惯，挑选自己喜欢的呈现方式。

2.3 用户故事地图：构建全局视角

如果既要见树木也要见森林，要想看到整个业务的全貌， 我们需要另外一个方法来辅助我们——用户故事地图。所谓的用户故事地图（User Story Mapping），就是用讲故事的方式，按照时间线，展现业务的全景图。 我们以《用户故事地图》一书中“我的早晨”为例，使用用户地图描述的话，就是如下的形式：

从中我们可以看到，典型的用户故事地图中涉及以下概念：

• Task：任务，一个任务就是用户执行的一个动作，比如“睁开眼睛”、“关闹钟”、“赖一 会床”等。
• SubTask：子任务，子任务是任务的细化，比如淋浴这个任务，可以进一步拆解为调节水温、洗头、洗身体等子任务。
• Activity：活动，活动是比任务更大粒度的概括，主要是为了让主线更清楚。
• Backbone：故事的主线，一般是按照从左往右的时间顺序来的。
• Role：角色，也就是活动和任务的发起方，可能是人，也可能是外部系统。 

用户故事地图特别适合用头脑风暴和集体共创的方式来梳理业务全貌。比如我在给某银行做咨询的时候，对于一个全新的领域系统，我就是通过用户故事地图的方式，和团队共创，用半天的时间，我就能做到从对系统一无所知，到相当了解了。

2.4 界面原型：将抽象需求具体化

在项目初始阶段，根据产品经理的需求描述，画出界面原型，然后研发团队在需求评审的时候，产品经理会对着原型阐述业务逻辑。这种方式在业界称为PDD（Prototype Driven Development）。

我个人挺喜欢这种方式，因为系统最后是以“界面”的形式呈现给用户，界面原型是对需求最直接、最直观的表达。面对界面原型，我们可以更好的理解系统行为，可以更好的评审需求的合理性。相比较抽象的文字，界面原型要具象直观的多，即使是手绘的粗糙原型，都能极大的提升我们对业务流程的理解。

在我参与某项目配置系统设计的时候，大家对“配置分组”的设计产生了不同意见，我本着奥卡姆剃刀原则，认为没有必要加这个ConfigSet的概念，这个新加的实体会给系统增加额外的复杂度，然而其好处并不明显。于是我通过工具，简单画了有无ConfigSet概念的界面原型对比。可以看到，差别并不大，分歧自然也就化解了。

所以，项目早期绘制原型图，是非常好的一种理解需求，挖掘需求的方式。

PART.3 如何进行业务建模？

回想一下我们做过的软件产品，比如电商产品，一个典型的业务场景可能会是这样：用户小明选购了一个手机，原价1100元，因为双11活动，减免了100元，只需支付1000元，三天后，小明收到了购买的手机。

这段类似于User Story的描述，反映了业务活动4个重要组成要素：

1. 角色：任何业务活动都有一个主体发起，这个发起方就是角色；
2. 过程：商品浏览、商品加购，下订单，支付都是不同的业务过程；
3. 数据：软件最重要的职责是处理信息流，因此过程中沉淀的数据至关重要，比如商品加购会产生购物车数据，下订单会产生订单数据等；
4. 业务规则：业务的复杂度往往体现在业务规则的多少，双11活动满1000减100就是业务规则。

在《七步掌握业务分析》一书中， 将角色、过程，数据、业务规则称为业务建模的四大要素。

我非常赞同作者的观点。如果一个遗留项目什么文档都没有，但能提供一张包含四要素的表格（如下表所示），也将是善莫大焉了。

接下来，我们仔细看下如何分别对角色、业务过程，数据这些核心要素进行建模。

3.1 角色建模：识别关键角色

角色建模，就是要找出系统中那些有价值的角色。我们可以通过以下步骤来识别、选择有用的用具角色集合。

1. 通过头脑风暴，列出初始的用户角色候选
2. 对候选角色进行分类
3. 整合角色，删除无用角色，提炼角色

头脑风暴的过程，我们可以尽量多邀请相关stakeholders（比如客户、产品经理、BA，研发等），让大家聚集在一起。同时准备好足够多的便签贴，每个人在便签贴上写下角色名称，然后贴在白板上。

比如我们要对一个招聘网站进行建模，可能会得到如下的角色候选集：

之后我们可以对这些角色进行整合调整，比如“大学毕业生”和“初次找工作者”有较大的重合，我们就可以丢弃“大学毕业生”，保留一个就好。再比如，区分“工作发布者”和“简历阅读者”的价值并不大，用“招聘者”这个角色代替他们可能会更好。

经过头脑风暴，以及整合、提炼后，我们会得到一个相对有价值的角色模型。

在梁宁的《产品思维课》里面，她通常会把互联网用户，按照用户画像，进行以下分类：

• 大明用户：对自己需求十分清晰，追求效率，但没有忠诚度
• 笨笨用户：有大概的需求，但需求并不明确
• 小闲用户：没有消费需求，就是希望打发时间

通过对用户的分类分层，进一步思考产品的定位和价值，以及如何对不同的人群采取不同的运营方式。因此，角色建模不仅可以服务于业务需求分析，也可以服务于业务价值分析。

3.2 过程建模：描绘业务活动的流转

过程建模是业务完成的活动或工作。对信息系统而言，过程和数据是最重要的要素。这二者离开谁都无法单独存在。每个真正的过程都使用数据，产生数据。每个重要数据都至少被一个业务过程所使用。这和我们通常说“程序 = 算法 + 数据结构”是一个道理。

能够描述业务过程的方式有很多：

l  标准图示法：如UML活动图、泳道图、数据流图、业务过程建模表示法（BPMN，Business Process Modeling Notation），它们提供了标准化的符号来描述流程、决策点和参与者职责。

l  宏观视角法：如六西格玛工作流图SIPOC，S-I-P-O-C是五个字母的缩写，分别是Suppliers（供应商）-Inputs（输入）-Process（流程步骤）-Outputs（输出）-Customers（客户）。他们从宏观视角看业务流和关键KPI，来明确流程交付给谁，以及由谁来进行输入的提供。

l  结构化分解图：这是一种强大的结构化思维应用。它无需关注顺序，仅通过树状分解展示核心业务流程，把复杂系统分解成可以管理的小块。被称为“分解”的原因在于，每个过程都可以被分解成为多个详细描述它的子过程。这种方式能清晰呈现业务全貌，便于与业务人员沟通，是理解复杂系统的利器。

比如对招聘网站，我们可以如下的结构化分解：

3.3 数据建模：构建业务信息

在软件工程中，数据建模是运用正式的数据建模技术，建立信息系统的数据模型的过程。通常我们会用ERD（Entity Relationship Diagram，实体关系图）来建立逻辑数据模型。

在业务分析阶段，我们更多关注的是抓住主要实体概念，以及建立他们之间的关系，而不是数据的存储方式。我个人更倾向于叫这个阶段为领域建模，或者叫概念建模。我一般会用UML类图作为表示法，进行概念建模。因为类与类之间的关系（关联，组合，继承，依赖）能很好的反映实体之间的关系。

PART.4 这么多技术要如何选择？

业务员分析技术提供了一种结构化的思考方法，从不同侧面、不同角色理解业务问题、业务机会和需求。分析时，我们要特别留意角色、过程、数据和业务规则等核心要素。

有些分析技术关注某个特定要素，例如数据建模主要关注数据，状态建模主要关注状态，UML活动图主要关注过程。另一些分析技术会同时关注多个要素，比如用户故事、UML用例图会同时关注角色和业务过程。还有些技术会提供业务全貌视图，比如结构化分解图和用户故事地图。

这么多技术要如何选择呢？

没有固定答案，我认为只要有助于你理解和澄清业务，方便沟通协作的方法都是好方法，你可以选择自己的偏好，采用即可。就我个人而言，我的偏好是，统一语言词汇表、用户故事、概念模型（ERD或者类图）、流程图 。有时也会使用事件风暴、结构化分解图、用户故事地图帮我看清业务全貌。不管选择哪种技术。关键是在你的工具箱中要用足够多的工具可用，文中提及的都是我萃取的非常好的业务分析工具，你可以“先固化，再优化，再泛化”，这样在遇到不同问题时，你自然就知道用哪个技术更好、更高效了。