一文带你成为业务分析师

2024年度脱口秀冠军付航说他做过BA，这是典型的反差幽默。因为正常认知中的BA（Business Analyst，业务分析师） 是一个听起来很高大尚的职业，和保安（BA）相去甚远。

理论上说，软件研发开端于需求，需求来自于业务，所以BA应该是一个不可或缺的岗位。可实际情况是，在我的从业生涯，只有早期的阿里短暂的设立过BA岗位，便裁撤了。其它公司压根连这个岗位都没有，这样看来，BA并非是不可或缺，更像是可有可无。

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

然而，这么重要的能力，长期却没有引起我们足够的重视。说实话，虽然之前我业务分析技术零零星星的已经在用了。但真正成体系化，还是这几天我相对比较系统的整理之后。在阅读相关资料和书籍之后，我发现，原来我之前写的User Story，画的用例图，画的原型草图，整理的核心领域词汇表等等都属于业务分析的技术范畴，而我却完全不自知。

我想不自知的可能不止我一个，所以这篇系统的整理文章，应该可以帮助你迅速提升业务分析能力。 本文将从如何理解业务，如何进行需求分析，如何进行业务建模，三个大的方面，系统的介绍业务分析技术。 内容比较多，我先把文章导图放在前面。

如何理解业务

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

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

组织结构

做事先做人，同样，熟悉业务先熟悉人。特别是我们空降到一个新团队，这一点尤其重要。再说，业务都是人在做，一个企业的组织结构，能直观的呈现出他的业务是如何开展的。比如一个典型的互联网公司会包括产品部，运营部，销售部，技术部，人力资源部，财务部，法务部等。熟悉它的组织结构，以及每个部门的职责分工，会对理解业务有很大的帮助。更多该部分内容可以参看《程序员的底层思维》17章内容。

用户访谈

首先，要注意“用户”和“客户”的区别，以幼儿玩具为例，用户是幼儿，客户是父母，客户是真正买单的，而用户是使用者。如果想要玩具卖的好，在上面标识出“无毒”是明智的，虽然你的用户根本不关心这个。

其次，访谈时要知道干系人的职务是什么，处在业务流中的哪个节点，都有哪些业务活动，做好笔记，特别是业务活动，活动的输入输出（数据），业务规则，做好记录，以备后续分析使用。有时候直接用户可能直接触达，那么访问“用户代理”也是个不错的选项。比如幼儿玩具的用户代理是父母，销售员的用户代理可以是销售主管。

最后，别忘了，给被访谈对象带上一杯咖啡。我之前在阿里工作时，就通过这种咖啡访谈的方式，采访了零售通业务的多位运营岗位负责人，并做了大量笔记，通过整理笔记，画流程图，从而迅速理解新业务。

实操观察

如果说访谈是耳闻的话，那么耳闻不如一见。实地探访用户，观察他们是如何进行业务操作的，观察用户实际使用软件的情况，是非常不错的方法。每次看到有人使用我的软件，我都会获得很多提高用户体验或生产力的想法。

我曾经为交通银行做过一个票据审查软件，因为我对系统刚刚做了重大重构，所以有段时间，我就驻扎在客户现场，以便审查员在工作中发现问题，我可以及时修复。我记得有一次有一位审查员在和我描述一个问题的时候，他要在一堆单据列表中找到那个有问题的单据，因为表格行之间是无差别显示的，这个简单的“搜索”工作，很是费劲。实际上，只要把有问题的单据用不同颜色高亮显示，挑选就会快很多。像这样的用户问题，客户并不重视，也没有需求提到研发部门。当你观察到，优化后，往往会有非常好的效果。

业务实操

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

阅读文档和书

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

另外，阅读领域相关的书籍也很重要。比如要从事供应链相关软件研发，那么看看供应链、物流相关的书是不错的选择。

正式会议

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

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

问卷调查

说实话，这个我没有实践过。鉴于《用户故事与敏捷方法》和《七步掌握业务分析》这两本书都有推荐这个方法，所以放在这里供大家参考。注意一点，调查问卷，尽量用封闭的问题和选择题。这样效果会更好，开放的问题没有那么多人愿意写。

需求分析技术

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

统一语言（Ubiquitous Language）

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

我认为，任何项目，都应该有一份核心领域词汇表，方便团队在这些核心概念的表达和命名上达成共识。 典型的词汇表如下所示，至少应该包含中文名、英文名和含义描述，然后团队所有人要遵循词汇表进行沟通，书写。更多关于统一语言的内容可以参看《程序员的底层思维》2.2.3小节。

中文名	英文名	缩写	代码中的表达	含义
单品	Children Standard Product Unit	CSPU	CSPU	SKU的产品信息聚合
商品	Item	无	Item	由商家发布，可在App购买
标品	Standard Product	无	Product	有69码的是标准产品

用户故事（User Story）

相较于传统的Use Case描述，User Story更加轻量简洁。大部分的系统，都可以通过这种方式来表达，虽然会遗漏比较多的细节，但是作为理解问题的开始，至少不会那么令人讨厌。

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的要义一致。你可以根据自己的习惯，挑选自己喜欢的呈现方式。

用户故事地图（User Story Mapping）

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

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

• Task：任务，一个任务就是用户执行的一个动作，比如“睁开眼睛”、“关闹钟”、“赖一 会床”等。

• SubTask：子任务，子任务是任务的细化，比如淋浴这个任务，可以进一步拆解为调节水温、洗头、洗身体等子任务。

• Activity：活动，活动是比任务更大粒度的概括，主要是为了让主线更清楚。

• Backbone：故事的主线，一般是按照从左往右的时间顺序来的。

• Role：角色，也就是活动和任务的发起方，可能是人，也可能是外部系统。

用户故事地图特别适合用头脑风暴和集体共创的方式来梳理业务全貌。记得，我在给招商银行做咨询的时候，对于一个全新的领域系统，我就是通过用户故事地图的方式，和团队共创，用半天的时间，我就能做到从对系统一无所知，到相当了解了。关于用户故事地图，更多详细内容可以参看 《用户故事地图》一书。

界面原型

我之前在阿里工作的时候，有一个UED（User Experience Design）部门，负责在项目初始阶段，根据产品经理的需求描述，画出界面原型。然后研发团队会在需求评审的时候，产品经理会对着原型阐述业务逻辑。这的确是一个很不错的方式，业界称这种方式为PDD（Prototype Driven Development）。

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

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

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

业务建模技术

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

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

1. 角色： 任何业务活动都有一个主体发起，这个发起方就是角色

2. 过程： 商品浏览、商品加购，下订单，支付都是不同的业务过程

3. 数据： 软件最重要的职责是处理信息流，因此过程中沉淀的数据至关重要，比如商品加购会产生购物车数据，下订单会产生订单数据等

4. 业务规则： 业务的复杂度往往体现在业务规则的多少，双11活动满1000减100就是业务规则

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

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

用例	角色	过程	数据	业务规则
客户注册	客户	注册	客户名 称客户地址 客户手机号 登录名密码	1. 登录名不能重复2. 邮件地址必须有效 3. 手机号必须是11位 4. 密码不能低于8位
客户下订单	客户	下订单	订单编 号订单日期、 商品编号 商品名称 商品数量	商品库存必须大于购买数量
客户支付订单	客户	支付订单	支付编 号订单编号 金额 支付时间	订单金额大于50免运费
配送员送货上门	配送员	送货	物流单 号订单编号 配送时间

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

角色建模

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

1. 通过头脑风暴，列出初始的用户角色候选

2. 对候选角色进行分类

3. 整合角色，删除无用角色，提炼角色

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

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

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

这样经过头脑风暴，以及整合、提炼，我们会得到一个相对有价值的角色模型。更多内容可以参看《用户故事与敏捷方法》，书中的第三章是专门讲解角色建模的。

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

• 大明用户：对自己需求十分清晰，追求效率，但没有忠诚度

• 笨笨用户：有大概的需求，但需求并不明确

• 小闲用户：没有消费需求，就是希望打发时间

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

过程建模

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

能够描述业务过程的方式有很多，比如UML的活动图，泳道图，数据流图等。还有专门的业务过程建模表示法（BPMN，Business Process Modeling Notation），在BPMN中会提供更加丰富的活动和事件图示。这些都是常用的手段。

除此之外还有小众的用来从宏观视角看业务流和关键KPI的六西格玛工作流图SIPOC，S-I-P-O-C是五个字母的缩写，分别是Suppliers（供应者）-Inputs（输入）-Process（流程步骤）-Outputs（输出）-Customers（交付顾客），也就是在流程步骤、输入、输出之外又增加了Suppliers和Customers这两项内容，来明确流程交付给谁，以及由谁来进行输入的提供。

鉴于以上过程建模使用很广泛，相关的介绍和资料也很多，这里就不再赘述了。需要进一步学习的，寻找相关资料自行学习就好。除此之外，还有一个非常有用的建模方法：结构化分解图。比如对招聘网站，我们可以如下的结构化分解：

熟悉我底层思维课程的应该知道，我认为最重要的两个思维能力，分别是抽象思维和结构化思维，而结构化分解图就是结构化思维非常好的应用。如下图所示，分解图可以在无须表现任何顺序和关系的情况下展示核心业务流程，把复杂系统分解成可以管理的小块。被称为“分解”的原因在于，每个过程都可以被分解成为多个详细描述它的子过程。这对我们看清业务全貌非常有帮助，用它和业务人员沟通，也非常的清晰明了。

数据建模

如果你是技术人员，数据建模应该是你工作中最重要的工作之一了。通常我们会用ERD（Entity Relationship Diagram，实体关系图）来建立逻辑数据模型。

我仍然记得，当年在学校学习《数据库》的时候，课程教导我们在画ERD的时候，要如何处理复杂的实体和实体之间的关系，如何避免数据冗余，让关系满足3NF的要求。但实际上，业务分析阶段的“数据建模”和设计阶段的面向数据库存储的“数据建模”还不大一样。因为在业务分析阶段。我们不用太关心数据是如何存储的，更多的是抓住主要实体概念，以及建立他们之间的关系。

所以，我个人更倾向于叫这个阶段为领域建模，或者叫概念建模。我一般会用UML类图作为表示法，进行概念建模。因为类与类之间的关系（关联，组合，继承，依赖）能很好的反映实体之间的关系。鉴于UML类图和ERD也是成熟的技术，如果要学习UML，推荐阅读《UML和模式应用》，这里就不多做赘述了。如果要进一步学习领域建模，推荐阅读《程序员的底层思维》的第12章模型思维，该章是专门讲解数据模型和领域模型的，以及他们之间差异的。

其它建模技术

以上内容涵盖了主要的业务建模技术。除此之外，还有很多其它的建模技术，提供了不同角度对业务的描述，比如状态机就非常适合状态建模。大家可以把它们也加到自己的工具箱中，以备不时之需。这里主要介绍两种：

• 事件建模：识别并分析事件是另外一个很有价值的需求角度。事件是指在业务过程中触发，系统必须响应的事情。对事件的响应也是业务过程。在DDD中，事件风暴 是业务分析和建模的重要手段，有兴趣的可以去研究一下。事件的命名一般使用英语的过去完成时，比如下单事件，应该叫orderPlacedEvent。

• 状态建模：所有的业务活动，反映在实体数据上，就是数据的变化。其中和业务过程联系最紧密的是状态变化，状态是实体行为模式的一个阶段。支付订单，会导致订单的状态从“新建”变为“已支付”；发送货物，会进一步改变订单状态到“已发货”，客户收到货物，订单会被标记为“已收货”。不同的业务过程，是通过在“订单实体”上打上自己的烙印来流转的。通常，我们会用UML的状态机图描绘业务状态的流转。如果你熟悉COLA开源项目的话，我也建议你使用cola-statemachine解决复杂的状态流转问题。

这么多技术要如何选择？

业务员分析技术提供了一种结构化的思考方法，帮助“业务分析师”——再强调一遍，这不仅是岗位，更是能力，是优秀的软件从业人员都必须具备的能力——从不同侧面、不同角色理解业务问题、业务机会和需求。分析时，我们要特别留意角色、过程、数据和业务规则等核心要素。

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

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

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