5个方法，帮助产品经理做好业务分析

Lobster. 2023-07-23 19:47:46

在产品经理教学市场中，充斥着大量的课程、书籍，向我们灌输用户需求分析，用户研究等等概念，但少有人提及“业务”，即使提及了，也讲述得非常笼统，在进行“业务分析”关键词的搜索时，甚至很难看到有人对“业务”进行了定义。

相比于国外，B端的业务分析体系已经较为成熟，形成了健壮的知识共同体，有认证机构、配套的教学体系等等。而C端业务，由于面向群体的混沌性、随机性，国内国外都未呈现出系统性的知识体系。

在本文中，笔者尝试通过对“业务”进行定义，并对业务进行建模，得到描述业务的主要维度，并定义“业务需求”是什么。接着我会聊聊为什么重视业务以及业务建模很重要。

最后讲讲关于阐述业务的可视化方式，也就是业务分析完后需要输出的内容是什么。但具体的了解业务的方式由于篇幅有限就暂且不展开了。

一、什么是业务？

我们在研究一样东西的时候，首先需要对这件事情做一个定义。业务这个词对于产品经理来说并不陌生，但让你回答一下“业务”是什么的时候，这个事情似乎又没那么容易。

写这篇文章前，我就因为这个问题卡住了不少时间，司空见惯的东西却是最难以解释的。

后来我从他的英文单词中，明白了它的定义 — Business。

*Business* is the activity of making one’s living or making money by producing or buying and selling products (such as goods and services).业务(商业)是通过生产和买卖产品(如商品和服务)来谋生和赚钱的活动。业务一词最早来源于日本的翻译。

那我们可以明白，业务的本质其实就是商业，那我们在研究业务过程，本质上是在理解商业过程，及这个过程中供需关系与其中信息流、物流、资金流的传递。

从我过去所读过的一些经济学、进化论社科类书籍中，我明白了一个道理，人类的社会的经济发展来自于个体自下而上的信息、物质互换，在这过程中，比较优势凸显出来，个体的分工也越就更加明确。

在这个分布式的信息、物质传递过程中，一个复杂适应系统演化出来（复杂适应系统是我最近比较感兴趣的内容，不知不觉就会扯到它，以后找机会写写），在「理性乐观派」中，将这个系统称之为“集体大脑”，他是个体分工合作的集合。

业务，就是分工合作的小集合。社会中不同的业务共同构成我们的集体大脑。

「理性乐观派」中有一段话：经济进步的一项衡量标准：超过一半的人口脱离了自给自足，去探索以集体大脑为基础的生活所充满的无穷可能性。

啥意思呢？集体大脑是人类分工合作的结果，是社会中所有岗位的集合，我们工作就是参与了集体大脑的构建，从而有了更安全、更干净、更便捷的生存空间。但我们工作之余，也有精神需求，有学习、阅读、追求个性等等需求，他们则是集体大脑为基础的更多可能。

所以，我个人将产品分为两类，一种是为了构造集体大脑的，及业务型的产品，需要研究业务本身，研究促成社会发展的分工合作；另一种是有足够生活基础后，是对美好生活的探索，需要研究个体需求，这类产品俗称C端产品。

二、业务有哪些元素？

业务是分工合作，通俗的说，就是一群人在一起合作，以完成业务，达到各方的期许。通过业务，供需双方各取所需，各方消耗边际成本，获得边际收益，B端产品则是服务于这一过程的信息系统或服务。

那么完整地描述一个业务，需要有哪几个维度？这关乎到每一个产品经理在面对一个或陌生或熟悉的业务时，是否能准确分辨研究对象。

通过用户？场景？需求？似乎这种方式太过于简单粗暴，不太严谨。通过流程图？还是不够全面，业务中涉及到的信息没法很好的体现。

最后我在这本书中找到答案 –「七步掌握业务分析」

10年出版的书，评价仅有五十来人，页数也不算很多，但内容牛批。

这本书中，将业务分为四个部分：人、信息、流程、规则。从一个信息系统的角度来看，也就是外部实体、数据、过程及业务规则。

以打车这个分工场景为例：参与的人员有司机和乘客，司机需要的信息是是否有乘客是否需要打车，他在哪里，他要去哪里，乘客需要的信息是哪里有车可以打，哪辆车可以提供服务等等。整个流程便是，乘客发布乘车需求这一信息，司机接受后，前往乘客所在地，获知乘客目的地，提供价格，乘客获取价格，选择坐与不坐，最后到目的地，乘客花费了金钱，满足了迅速到达目的地的需求，司机花费了时间成本、燃油费等，获得了酬劳。这一过程，还需要一定的规则，比如行车价格规则、安全规范等等，假若规则不明确，供需双方就可能无法达成平衡，以至于业务无法开展。

用一张图来表示这其中涉及到的人员和信息及规则，可以是这样：

加上流程描述，那就是这样，在书中，被称为核心需求组件。

第一张图，在书中称之为高阶数据流图，而我更倾向于业务全景图，因为他描述的是一个业务大致全貌，有助于我们在一开始确认研究的范围。

在这四个维度的基础上，我又加上了两个维度：业务目的、业务风险。因为业务的完成总是有所目的的，打车的目的是车主赚到钱，乘客安全快速地到达目的地，是业务参与人“想要”的驱动力。

而一个业务参与人也同样是有“不想要”的驱动力，那就是业务风险，完不成业务可能会发生的后果。比方说，打车这个业务下，乘客的风险轻则有黑车坑钱、司机送错目的地、绕道，经济和时间的损失风险，重则有人身危险的风险。

对于业务目的，则尽可能地减少成本，提升效率；对于业务风险，则需进行监管、管控，避免发生。

举几个例子：

产品开发业务，在这个业务当中有多个角色，简单地来看的话，主要是产品经理和程序员，程序员需要产品需求、BUG、数据需求等等，产品经理需要产品成果、开发，流程上可能会有企业的立项流程、产品开发流程等等。大家都基于公司的规章制度来行事，最终是想通过这个业务，这个分工合作来达到企业、员工、客户各方的利益，完不成业务的风险则是错失客户、市值下跌、员工可能被炒鱿鱼…

PM与RD之间，存在信息不对称、不及时的话，就会耽误开发周期，间接影响业务的完成质量，而这些在排除人员个人问题之外，主要就是由流程不明确、规则不明确、角色分工不明确导致的。

案件发生后，警察要抓贼，也就是情报侦查业务，这个业务中，贼与警察是两个主要角色，贼与警察存在着信息的不对称。贼知道是自己犯的事，而警察不知道，业务的目的就是弥合这种信息的不对称，使贼被抓住，维护被害人的权益，维持社会的稳定。那么啊sir就会通过各种手段来弥合这种信息差，通过监控、人脸识别等方式，而啊sir的信息则需要故意不让贼知道，啊sir需要基于一些规则办事，比方说调用监控的权限规则、依据法律办案。倘若破坏了规则，则可能造成一系列的公关问题，信息泄露问题等等。

三、什么是业务需求？

前文我们定义了业务是什么，也就是理清我们的研究对象，但是至于他们想解决什么问题还没有解决。

业务需求的含义指的是他们在分工合作中遇到了一些问题，所以主导这个业务的、能够从这个业务中获利的人希望能够解决掉他们。或者是这个人看到了业务能够提升的空间，也就是业务机会，希望能够抓住这个机会来实现业务的提升。

业务需求来源于业务，那么就是四要素中出现了某些问题，导致成本损耗、营收达不到目标要求、风险失控。不同的业务需求，决定了我们接下来要解决的用户需求是不同的，

四、为什么要理解业务，定义业务需求？

为什么我认为在做产品之前，应当先理解业务，再考虑方案？可能有些人会说因为没考虑清楚业务，做出来的产品肯定是不符合需求的。但个人认为还有一个更重要的原因，这个原因困惑了我许久时间。

做产品经常会被要求要有框架性思维，我也一直试图再学习练习在面对一个陌生事物，不管是生活中的还是工作上的，都能够带入这套思维去思考，后来发现，不管我怎么做，我最后都还是会回到起点，没有办法在一时间构想整个框架。后来，我发现这个框架太庞大了，从最初的需求到后期的运营，啪一下全构想出来是不可能的，因为工作记忆只能容纳7个数字，人类的大脑特性决定了这件事情是不可能。

但是为什么有些人能够一次性记忆数百个数字，那是因为他将一连串的数字拆分成3-4个数字的组合，并且通过已有知识将这些无逻辑的数字构想成逻辑，组合起来就能记忆上百个数字。比如说记忆100252037989，就可以拆分为1002（是我的出生日期倒过来，Justkidding），5203（我爱你撒），7989，学习更多的数字抽象化方式有助于记忆。

那产品思维的方式也是这样的，需要将多个复杂步骤拆分成几个模块，并且通过已有的知识将这些模块拆解、构成自己的逻辑，就可以有效记忆和理解。同样，学习和练习更多的需求理解方法论，也有助于理解。

那么首先要思考的就是业务的四要素和业务目的、业务风险，通过对业务的了解。

五、业务分析的输出内容

由于篇幅问题，本文就直接讲解业务梳理后输出的内容，也可以说是业务要素的呈现方式。

业务梳理的主要思路是去理清业务中的要素，以及业务方在业务过程中的问题和所关注的核心点、需求。

我们定义了业务是什么，那我们如何梳理业务，让业务信息尽可能全面和清晰呢？

这里介绍几种方法，帮助我们能够梳理清楚并清晰展示业务的过程逻辑。

他们分别是：

业务范围图
核心需求需求组件
业务流程图与用例
业务规则表：决策表、业务术语表、角色与权限矩阵、业务规则表
数据模型：实体关系图

这几个方法的层级关系是这样的：业务范围图描述最粗粒度的业务，只描述关键信息与所涉及的人员。而核心需求组件进一步，描述业务的人（外部主体）、信息（数据）、流程、规则，但也是粗粒度的整体描述。再通过流程图、用例图展开描述所涉及到的人与流程之间的关系，业务规则表展开描述规则，数据模型则描述人与信息之间的关系。

1. 业务范围图

在前文中也介绍过，业务范围图描述业务中所涉及的所有角色，以及每个角色在业务过程中所供给和需要的重点信息。业务范围图，有助于在项目初期理清业务范围、业务干系人，和其中比较重要的信息，无需技术背景，也可以让各方干系人理解沟通。

外部的方块表示外部实体，角色、机构、依赖的系统等。箭头表示信息进出的方向，中心的圆圈表示研究的领域，及业务。

2. 核心需求组件

核心需求组件提炼业务的核心要素。依次来描述：

信息（数据）：可以指的是一个实体，比如说一个订单，也可以是实体的属性，订单价格。对于数据的分析待会会再提及。这里的只需要将这些数据进行罗列，个人建议罗列实体，属性在实体，理清业务中的信息对象。

外部主体（角色）：指的是与业务领域内有交互的人、组织或系统。体现的是业务过程中，哪些角色进行了分工合作，有时候分工对象还有硬件设备或外部软件，它们也是其中的外部主体。

流程：流程是所有产品经理最熟悉的东西了，指的是业务所完成的活动工作。流程就会涉及外部主体与信息的传递。这里只需要概述有哪几个业务流程。比方说项目管理业务，包括立项流程，月总结流程，结项流程。

规则：业务规则是分工合作过程中的条件，是业务演化的结果，它使得业务在一些情况下，能够有决策依据，使业务保持一致，顺利开展。现在很流行的策略型产品经理，我认为本质上就是在写业务规则，即推理规则、计算规则。

3. 业务流程与用例

业务流程是大家熟知的方法，不管是C端B端都会绘制业务流程，后期运营也通常是通过它来找问题。

业务流程图展示的是一个业务分工合作、信息互传的过程，描述的是没有我们的设计方案之前是如何完成业务的，流程通常用动词进行描述，表述角色的任务、动作。关于业务流程图的资料已经较多，就不做展开。

描述角色动作（任务）与信息传递的方式还有用例图。用例图即可以是描述系统功能、产品需求的方式，也是我们做业务分析时，可以使用到的工具。

用例图有四个元素：参与者、用例、边界、箭头（关系）。参与者表示与软件（项目）接口的人、组织、系统；边界在软件需求中指的是系统的操作边界，而对于我们进行业务分析而言，它就意味着业务的边界范围；用例是角色在业务范围内的动作；箭头在复杂的用例图中有多种画法，我们可以尽量保持简洁以便沟通。

参与者 ➡️ 用例：参与者使用用例
用例 ➡️ 参与者：用例使用完后，信息传递给参与者
用例 ➡️ 用例：父用例包含子用例

用例的使用，可以让我们清晰看到在业务范围内，不同角色有哪些职责、任务，也可以理解为不同角色的用户需求，但用例图隐藏了用例过程中的一些细节，有时候还需要更详尽的用例说明来辅助表达。

除了流程图和用例之外，也可以用用户-场景-需求的方式去梳理用户需求。

4. 业务规则

在「软件需求：第3版」中，业务规则分为这么几类：事实、约束、触发条件、推理规则、计算规则。它们都有相应的需求表述的方式。值得一说的是权限也是业务规则的一种说明。

比如：项目管理业务中，公司规定了PM每个月必须上报项目进度。这是一条业务规则，但后期，设计一款项目管理工具时，它就成为一个需求，每个月未上报，会进行邮件通知或者绩效考核扣分之类的后置条件。

业务规则的类型较多，表达方式也比较多，如权限设计有RBAC模型，策略算法可能用的决策树、决策表等等。本文介绍一种简单、通用的方法来记录这些规则，来自于「软件需求：第3版」，业务规则表。每条业务规则用一句话去描述，

来源：软件需求第三版

5. 数据模型

数据模型处理的是人和信息之间的关系。

我们在业务的过程中，我们经常会虚构出一些词汇，来定义某一类东西，以便于业务各方能够快速沟通，同步信息。就像金钱是我们生活中虚构出来的概念，以便于在市场中，能够进行快捷有效的交易，又比方说“订单”，它的作用在于让购买者和出售者用同一载体沟通购买的结果。又比如说“课程”，它是为了让教师和学生方便沟通的统一介质，他们都是某种人为定义的非物理性质（也可能被制定成某种物理材料）的概念。

数据模型的梳理是为了让我们知道业务过程中，有多少种人为抽象出来的概念，以便于信息的传递和沟通。在业务调研过程中，就需要发现和记录这些虚构出来的概念。那如何记录与分析呢，就需要用到我们的实体关系图。

同样，实体关系图也是来自于信息系统设计，它既是一种设计数据层、设计数据库的方法，也可以是我们分析业务数据对象的方法。

我们用实体关系图来对业务信息进行抽象和分析，将大大方便我们后期对产品的设计。由于本次不讲产品设计，所以就暂且不展开。

实体关系图非常的简洁，包含三个元素：实体、属性、关系。实体指的是我们抽象出来的概念，比如之前说的「课程」，又比如说「学生」，学生其实也是一种概念，他们都描述一类事物。

但是描述一类事物还不够，我们还需要区分这类事物的不同个体。比如说上课这个业务，我知道你是学生没有用，我还得知道你这个学生叫什么，是哪一班的，是男是女才行。

所以每种实体还会有属性，比如说「课程」有上课时间、课程类型等属性；「学生」会有姓名，性别，学号，年级班级等等。如果是在产品设计阶段，这些信息就会被存储在一张「课程」、「学生」数据表当中，大概像下图那样。