对于B端产品经理而言，UML的思维是帮助B端产品进行业务调研的利器。本文结合自己的实践经验，与大家分享如何应用UML思维做B端产品，希望对你有所启发。

B端产品们做业务调研工作时，是不是经常遇到这些情况：

1）公司业务复杂，极容易错漏某个重要的业务节点，等你把原型都出好了，业务过来说他们还有XXX情况需要加入系统。

2）公司部门利益不一致，每个部门都觉得应该优先实现他们的需求。

前段时间我阅读了大象希形老师的书籍《Thinking in UML》。大象希形老师是在IBM有10年丰富经验的架构师，这本书集合了他工作中的经验心得。

阅读完这本书后，我发现UML的思维是帮助B端产品进行业务调研的利器，每一位B端产品都应该具备这种思维。

在运用这种思维之前，我也经常陷入杂乱的业务规则、冲突的业务需求中，不知道如何处理。

但是运用了UML思维后，我在处理公司级别的大项目，且截止时间仅有一个月的情况下，我保质保量地梳理出了项目需求的所有脉络，推进项目顺利完成交付。

通过这篇文章，我把这次实践后的经验分享出来，希望能帮助到大家。

（友情提示：本篇文章干货满满，读完一遍后可以先收藏，实际运用的时候再翻出来回顾。）

一、UML思维是什么

想要理解UML思维是什么，首先需要了解UML是什么。

UML（Unified Modeling Language）中文名称是统一建模语言，又称标准建模语言。是一种为面向对象系统的产品进行说明、可视化和编制文档的一种标准语言。

那UML思维是什么呢？

UML思维我认为可以简单地理解为“面对对象的方法”。

在软件领域，有两种常见的术语：面对过程的方法、面对对象的方法。

什么叫面对过程，什么叫面对对象呢？

面对过程方法认为我们的世界是由一个个相互关联的小系统组成的，就像DNA一样，整个人体都是由这样的小系统用严密的逻辑组合而成。并且面对过程的方法假设这个过程是稳定的，不会改变的。

在使用“面对过程方法”做设计时，我们需要找到过程的起点，顺藤摸瓜将这个过程中牵扯的因素逐一分析出来，理清这个过程中的因果关系，最后到达过程的终点。

而面对对象的方法认为我们的世界是由各不相干的独立个体组成的。过程不是这个世界的本源，过程是由一些“对象”通过特定的规则组织起来的。

如果把世界比喻成汽车，那么对象就是汽车上每个不同的零件。

不同的零件组合成了汽车，不同零件之间的组合也会达到不同的效果。如果规则允许的情况下，我们还可以将零件随意更换。比如材质可以从钢铁换成铝合金的，来源可以从工厂A换成工厂B的。

面对对象的方法不考虑对象之间的因果关联，只是在需要的时候把他们拼合在一起，这种方法能更好地应对我们现在面对的复杂业务。

二、如何把UML思维运用到业务调研中

可能看到这里，你会觉得：“UML思维也太抽象了！我要怎么用UML思维做需求分析呢？”

其实只需要记住：先将业务当成是一辆汽车（整体），然后拆汽车里的零件（部分），最后将零件拼合起来（连接）。

一般我们常见的业务调研方法是这样的：先明确调研目标，再选取调研对象，然后明确自己的调研方法，执行调研计划，最后得出结论。

可是这样的调研方法太宽泛了，调研对象怎么选取才是正确的？是所有相关人员都要调研吗？执行调研计划该怎么做才能得到用户最准确的需求？我该怎么提问？

而运用了UML思维，业务调研流程能够更被细化，对我们的具体工作更有指导意义：先是明确调研目标，再梳理业务中所有的人事物（整体），然后确定业务主角、访谈业务主角（部分），最后得出结论（连接）。

针对我细化的每一个步骤，下面我会仔细讲一下怎么落地，和这么做的好处。

为了大家更好地理解，我会辅以我自己参与过的项目案例举例说明，大家可以结合案例去更好地理解。

步骤1：梳理业务中所有的人、事、物

1.1 为什么这么做

为什么第一个步骤是先梳理业务的整体呢？

因为这么做有两个好处：第一个，了解业务的整体能让我们更快速地把握业务背后的逻辑。第二个，了解整体业务能避免我们在需求调研的过程中遗漏了业务细节。

如果我们在开头不是梳理整体，而是梳理某个业务节点，那我们很快就会被繁杂的业务扰乱自己真正的目标。

之前我在为公司的会员体系搭建管理系统时，就因为一开始太着眼于具体的会员升级规则，会员购买折扣之类的需求，反而被弯弯绕绕的业务规则弄得不知道如何下手，影响了工作的开展。

并且因为我的切入点是某个会员规则，由这个会员规则再带出了其他业务事件，这样切入和梳理，非常容易遗漏了业务中某个人或某些业务事件。

直接切入具体需求的处理方式就好像在走一个迷宫，不停走进死胡同再出来，磕磕碰碰，最终才能找到了正确的道路。可是如果我们能一开始就能从整体俯视整个迷宫，那我们就能更快地找到正确的道路。

所以通过一开始就把业务整体给梳理清楚，能够避免我们遗漏了业务中某个人或某些业务事件，也能更方便我们了解业务的全局。

1.2 怎么落地

为了更好地梳理业务中的人、事、物，我们需要依靠一个工具——业务用例图。

用例图是UML中十分基础和常用的图，主要元素有业务主角和业务用例两个。我通常用小人的图案表示业务主角，椭圆来表示业务用例。

用例图通常使用在我们业务调研的过程中。通过梳理业务所有的相关角色，和这些角色在业务中会进行的活动得出用例图。

以我做的充值卡业务为例，通过对组织架构和岗位职责的阅读，可以大概了解到他的角色组成和业务用例是这样的：

他们用业务用例图来表示是这样的：

通过业务用例图，我们能更清楚地看到业务中人、事、物之间的关系，也能注意到某些事件可能存在跨多个部门的情况。遇到这种情况时，需要我们在需求设计时需要额外注意。

步骤2：确定关键角色

2.1 为什么这么做

通过上一个步骤我们已经把业务中所有的人事物都整理出来了，但这并不代表着我们要对所有的人都进行调研。

如果碰巧我们负责的系统牵涉部门较多，涉及人员也较多的情况下，往往时间和精力都不允许我们对每位用户都进行访谈。

最好的方法是我们找到业务流程中的关键角色，仅对关键角色进行访谈。

提前整理出关键角色，也能够让我们对自己的系统目标有更清晰的认知，避免被一些杂乱的需求和业务流程扰乱了思路。

2.2 怎么落地

如何确定关键角色？

在确定关键角色之前，首先需要我们确定系统边界。

系统边界可以简单理解为：系统提供哪些功能？使用角色是哪些人？

如果你的系统没有明确的目标，那你就永远无法定义使用你的系统最关键的人群有哪些。

就好比我们写一篇文章，如果我们写的文章没有一个明确的目标，那么我们永远也无法知道谁会愿意点开文章查看，谁会愿意将文章全部看完。

这里还是继续以充值卡的业务为例子：

刚才我们已经主要梳理出了我们业务中包含的所有人、事、物，这时候我们定位充值卡系统主要提供——充值卡配置、充值卡购买/退款、充值卡售卖、订单管理、用户消耗记录、充值卡业绩看板的功能：

那么我们可以从业务用例图中筛选出，主要使用这些功能模块的人群有——销售、销售组长、财务、用户。

通过系统的边界，我们就能确定充值卡业务的关键角色是销售、销售组长、财务、用户。

薪酬专员虽然在我们业务流中也有被梳理出来，但是这次系统实现的功能和薪酬专员不会直接相关，所以薪酬专员不算是业务主角。访谈时主要针对确定下来的角色进行访谈就好了。

步骤3：调研关键角色

3.1 为什么这么做

怎样的调研才能让我们更准确地获取到用户需求？

答案就是我们要以用户视角去调研关键角色。

如果不以用户视角出发会怎么样呢？下面听我讲个小故事：

想象一下，我们生活在自行车刚被发明出来的时代。

今天我们刚领了工资，走入一家超市，想给自己买一辆自行车，这时候导购人员非常热情的招呼了你，并向你这么描述这辆自行车：“这辆自行车是个交通工具，它由刹车系统和传动系统组成…”

相信我们听到这句话一定会一脸懵，不知道自行车是做什么的，对我们有什么用处。

但如果导购人员换了种方式和你介绍：“自行车可以通过踩动脚踏来让自行车快速前进，让你更快到达目的地。当我们手捏着刹车，就可以使自行车停下来。”

这种介绍方式，是不是瞬间清晰了很多？

同样的例子换成我们将要搭建的系统。系统还没有被搭建起来，谁也不知道系统会长什么样子。如果我们在业务调研的期间就先入为主的以计算机的视角去描述系统，可能最后得到的结果和业务想要的结果会出现偏差。

3.2 怎么落地

那么我们怎样去以用户视角做调研呢？其实非常简单，在访谈的过程中，我们可以重点询问调研对象这四个问题：

1. 您对系统有什么期望？
2. 您打算在系统中做什么事情?
3. 您做这件事情的目的是什么？
4. 你就希望这件事情做完后有什么样的结果？

这4个问题本质上的思路就是询问对方希望系统能帮助解决什么问题，理由是什么，和他希望最终能达成什么目的。

理由和目的能帮助我们判断使用者操作某个动作是否是一定要在系统实现的，这个动作最终是不是能带来价值的。

下面以充值卡业务来举例，因为文章篇幅原因，这里我只展示销售组长的访谈记录前半部分，但是每个人的访谈记录的思路都是一样的。

我们在做访谈的时候不一定要照搬上面的4个问题，记住最底层我们需要了解到的信息是对方希望系统能帮助解决什么问题，理由是什么，和他希望最终能达成什么目的。

访谈对象：销售组长

问：关于充值卡业务，您对系统的期望是什么？(希望系统能帮助解决什么问题)

答：我希望系统能展示清楚充值卡的消耗明细，用户知道自己花了多少，剩余多少。我们内部也要知道。然后我希望能清楚地展示每位销售他售卖的充值卡金额，和他售卖的这些充值卡消耗情况。

问：我了解了。那充值卡的相关功能搭建起来后，您首先得能看到用户的消耗明细，然后和您组内销售售卖的充值卡消耗明细。还有其他的吗？(希望系统能帮助解决什么问题)

答：还有营收计算。我们现在每个部门的充值卡业绩分开来了，这个要统计清楚。

问：好的。下面我想针对这些点展开细聊。我想先请问一下，咱们知道用户充值卡消耗明细的目的是什么吗？我们负责销售的同时，还要负责后续的消耗吗？（理由是什么）

答：不负责的，一个是充值卡还有钱的用户，消费可能更大。我们想先挖掘这些用户。还有用户也会找我们对消费明细，我们也要答上来。

问：明白了。充值卡的消耗明细主要还是希望帮助您达成挖掘用户的目的对吗？对数这个工作虽然有，但应该不是主要工作内容。（达成什么目的）

答：没错的。我希望针对充值卡剩余金额，能分类展示。剩余较多且快到期的，我们可以优先挖掘。剩余较少的，可以慢点再挖掘。

问：您刚才提到需要知道销售售卖的充值卡消耗情况。咱们工作中还是得对自己售卖的充值卡是否消耗了负责对吗？（理由是什么）

答：算是。这个不影响我们的绩效也没有KPI，只是财务会催促我们。

问：那这个功能的主要目的您是希望给您一个展示，提早知道消耗情况？（达成什么目的）

答：是的。（通过这里我们可以判断，其实销售组长只是想知道消耗情况，好配合财务部门的工作，这个需求的价值是不如第一个需求的价值大的。）

…

…

（这里的访谈内容和上面的内容比较相似，限于文章篇幅略过）

…

…

问：非常感谢您今天抽出时间来参与访谈。

答：不客气的，您有问题再问我。

通过访谈，我们又能进一步整理出每一位角色对系统的需求。这些需求我们也可以通过用例图来表示：

1）用户：用户可以购买充值卡、在购买的时候可以选择充值卡付款、同时可以查看自己的消耗金额、剩余金额。（经过访谈，了解到销售不希望用户对充值卡可以退款这个事情感知太强，所以相比一开始的业务用例，我们的系统用例则删除掉了用户可以退款的用例。）

2）销售：销售可以自行生成充值卡订单，可以查看自己的售卖记录，同时可以帮助用户发起充值卡退款。

3）财务：经过访谈，了解到财务要进行退款审核、查看和导出订单、同时需要收到异常消耗的警报。

4）销售组长：经过访谈，了解到销售组长要查看用户消耗记录，充值卡销售情况和要在营销活动期间能根据本组的情况进行一定程度的充值卡套餐配置。

相比于一开始的业务用例，这里的用例图会更具体，细化到系统要实现的功能模块。

步骤4：输出结论

将整体、部分都梳理清楚后，我们需要输出结论，也就是把每个部分连接起来了。

这时候我们需要产出的就是业务流程图。如果业务体量相对不是特别大，那么到这个步骤我们系统的一些基本模块也可以产出来了。

通过最后产出的业务流程图，这时候我们设计的框架就已经出来了，前期准备的工作到这里也基本告一段落，下面可以开始梳理具体的需求内容了。

写在最后

相信你通过阅读我的文章，能够大致了解利用UML思维去做需求调研的主要流程和要点。

我们再一起回顾下，利用UML的思维去做业务调研主要为以下四个步骤：

1. 梳理业务中所有的人事物。利用业务用例图整理起来，并且要和业务方过一下是否还有遗漏。
2. 确定业务主角。从梳理出来的人事物中，利用系统边界的概念，筛选出业务主角。
3. 访谈业务主角。从用户的角度出发，询问用户对系统的期望。
4. 输出调研结论。输出业务流程图、系统的包含的大体模块。颗粒度可以粗一些。

以上就是我利用UML的思维细化了自己业务调研的经验分享，希望对大家同样能有启发。

因为我也是位读者，对书中概念的理解可能存在偏颇的地方，欢迎大家找我一起讨论。