原标题：UML建模方法论（上）：建模初期的准备
建模语言很重要，建模思想更重要。
接下来大家将会看到的是一个系列的文章，分为上中下三篇。本文是第一篇，我将以我在实际工作中遇到的情景作为案例和大家分享我的“建模方法论”。这个方法论是我通过看书和自己的思考，再加上工作中的实际经验总结而来。
建模方法论的概况 1. 整个建模方法论的结构
2. 为什么需要掌握建模技术
1）帮你从业务出发推导出具体要做的功能
在我们从0-1 打造一个软件的时候，我们面临着这样的问题，这个软件应该有哪些模块？每个模块有哪些功能？
如果是一个面向C端的产品，有可能你自己就是一个目标用户，你可以将自己代入情景，寻找痛点，找到要做的功能。
可是，如果是一个面向B端的产品，因为B端软件的业务属性非常重，如果你对业务不是那么熟悉，那么在一开始你可能对于上面提到的两个问题会感到没有头绪。即使你对业务非常熟悉，也不一定就能保证你做出的软件符合业务的要求。
因为，在熟悉业务和做出符合业务要求的软件之间，还有一个鸿沟，你需要掌握建模技术帮你跨越这条鸿沟。
2）进入大厂的必备技能
腾讯对于产品经理的要求分为通用能力、专业知识、专业技能、组织影响力这几个大的模块，在最重要的专业技能模块中包含了对产品规划能力的要求，具体又划分为5个等级，其中第3等级的标准中就包含了对建模能力的要求。
名词说明
为了大家看文章的过程更加的顺畅，这里对一些基础的名词做一些说明。
1. 业务
百度定义：“业务”更白话一些来说，就是各行业中需要处理的事务。
我的定义：公司为了实现某个目标而需要开展的工作，或者所需要处理的事务。
2. 建模
百度定义：建模就是建立模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。
我的定义：建模是一个过程，目的是为了把复杂的事物用图形或者文字的方式描述出来，便于自己思考和他人的理解，最后输出的可能是一些图形或文字的说明；在软件领域里主要使用UML来进行建模。
3. UML
UML全称是Unified Modeling Language，统一建模语言。
很多人认为学会了UML就学会了建模，这种想法真是大错特错。UML仅仅是我们用来建模的工具，是否真的会建模取决于你的建模思维，不同的人使用UML建立的模型可谓天差地别。就好比你学会了Java编程语言，并不能表明你是个优秀的程序员，你是否是个优秀的程序员取决于你的编程思维。
阅读本篇文章需要读者具备一定的UML基础知识，这样可以更好地帮助你看懂本文中的一些术语。不懂UML的小伙伴也不用沮丧，可以先把文章看完，回头再去充充电，UML学起来很快的。
建模第一步：了解业务概况
所谓业务概况，就是先大致了解下公司有哪些业务，这些业务是如何配合从而支撑起公司的运转。我们只需要把最主要的业务环节梳理出来即可，每个业务环节具体不需要非常细致。
我所在的教育培训行业的业务概况：
目的：了解业务概况的目的，是让我们对于客户公司的业务有一个大致的认知，为我们接下来开展工作奠定基础。
如何了解业务概况
- 我们可以通过一些行业分析报告，或者在网上找到这样的资料；
- 如果是给自己的公司做管理软件，我们也可以通过简单的调研了解业务概况。
简单说，业务目标就是客户或者公司对于软件系统的期望。客户希望用系统来做什么，即建设系统的目的是什么、准备用它来做什么。
举例：
- 为市场人员提供线索管理系统；
- 帮助销售部管理好客户，提高销售部的工作效率；
- 采集营销和管理数据，进行商业分析，提供决策支持。
为我们大致划分了系统将涉及到的业务范围，为后续的调研决定了方向。
3. 如何获取业务目标
在实际工作中，业务目标一般是公司高层领导或者项目发起人提出来的。比如公司的CEO可能希望为公司开发一款软件，用于提高公司办公效率，节约公司运营成本，也有可能是IT部门根据公司的业务状况整理得到的。
注意：客户提出的业务目标需要评估后，才能知道软件是否能够支持到这些业务目标。
建模第三步：涉众分析 1. 什么是涉众
涉众是与要建设的业务系统相关的一切人和事。
首先，要明确的一点是，涉众不等于用户，通常意义上的用户是指系统的使用者，而这仅是涉众中的一部分。
如何理解与业务系统相关的一切人和事呢？
凡是与这个项目有利益关系的人和事都是涉众，他们都可能对系统建设造成影响。
目的：为后续进行业务建模分析业务主角做准备。
2. 如何发现涉众
大家可以从以下大类去寻找涉众：
1）业主
① 业主和业务方的区别：
业主是系统建设的出资方、投资者。虽然大多数情况下业主指的就是系统的需求提出者和使用者，即业务方，但并不是绝对的。
比如，可以假设系统建设是由一家国际风险投资机构投资的，它本身井不管理和运营这个系统，它只是从资本上拥有这个系统并从运营收入中获得回报。
即使业主与业务主是重合的， 但是业主从概念上讲井不等于业务方，他们关心的内容是不一样的。了解业主的期望是必需的和重要的，业主的钱是这个项目存在的原因。若系统建设不符合业主的期望，撤回投资，那么再好的愿望也是空的。
② 业主关心的点：
一般来说，业主关心的是建设成本、建设周期以及建成后的效益。
虽然这些看上去与系统需求没什么大的关系，但是建设成本、建设周期将直接影响到你可以采用的技术，可以选用的软件架构，可以承受的系统范围。
一个不能达到业主成本和周期要求的项目是一个失败的项目，同样，一个达到了业主成本和周期要求，但却没有赚到钱的项目仍然是一个失败的项目。
2）业务提出者
① 业务提出者简介：
业务提出者是业务范围、业务模式和业务规则的制定者，一般是指业务方的高层人物，比如CEO、高级经理等。他们制定业务规则，圈定业务范围，规划业务目标。他们的期望十分十分重要。实际上，系统建设正是业务提出者经营目标和管理意志的体现。
虽然他们的期望一般都比较原则化和粗略化，但是却不能违反和误解，否则系统将有彻底失败的危险。换句话说，业务提出者的期望是系统建设的最高纲领。
② 业务提出者关心的点：
业务提出者一般最关心系统建设能够带来的社会影响、效率提升、管理改进、成本节约等宏观效果。换句话说，他们只关心统计意义而不关心具体细节。
但是，如果建设完成的系统不能给出他们满意的统计结果，这必定是一个失败的项目．在系统建设过程的沟通中，他们的意志一般是极少妥协的，系统分析员不必太费心去试图说服他们接受一个与他们意志相左的方案。
实际上，由于他们的期望是非常原则化和粗略化的，因此留给了系统建设者很大的调整空间和规避风险的余地。
3）业务管理者
① 业务管理者简介：
业务管理者是指实际管理和监督业务执行的人员， 一般是指中层干部，他们将业务提出者的意志付诸实施，并监督底层员工工作的作用。他们的期望也很重要，一般也是系统的主要用户之一。
② 业务管理者的关心点：
业务管理者关心系统将如何实现他们的管理职能，如何能方便地得知业务执行情况，如何下达指令、如何得到反馈、如何评估结果等。
业务管理者的期望相对比较细节，是需求调研过程中最重要的信息来源。系统建设的好坏与业务管理者的关系最多，也是系统分析员最需要下功夫的。
业务流程、业务规则、业务模式等绝大部分来自业务管理者。系统分析员必须要把业务管理者的思路想法弄清楚，业务建模的结果也必须与业务管理者达成一致。
业务管理者应当成为需求评审小组的成员，如果可能，他们甚至应当成为需求分析小组的成员与系统分析员一同工作。
③ 对于业务管理者的期望可以提出建议：
在系统建设过程中，业务管理者的期望可以有所妥协，一个经验丰富的系统分析员可以给他们灌输合理的管理方式，提供可替代的管理方法，以规避导致高技术风险或高成本。
4）业务执行者
① 业务执行者是哪些人：
业务执行者是指底层的业务操作人员，是与将来的计算机直接交互最多的人员。
他们最关心的内容是系统会给他们带来什么样的方便，会怎样的改变他们的工作模式。
② 业务执行者的需求的特点：
业务执行者的需求最为细节，系统的可用性、友好性、运行效率等与他们关系最多。
系统界面风格、操作方式、数据展现方式、录入方式、业务细节都需要从他们这里了解。他们将成为系统是否成功的试金石。系统的界面风格、操作方式、表单细节等是系统分析员向他们调研时需要多下功夫的地方。
③ 管理业务执行者的期望：
这类人员的期望灵活性最大，也最容易说服和妥协。同时，他们的期望又往往是最不统一的，各种各样的古怪要求都有。
但是，不管他们的期望有多古怪，都必须服从业务管理者的期望。系统分析员需要做的事情是从他们的各种期望中找出普遍意义，解决大部分人的问题，对于特殊的问题尽量予以说服，必要时可以依靠说服业务管理者，来影响和消除那些不合理的期望。
5）第三方
第三方是指与这项业务有关系的，但并非业务方的其他人或事。比如购物网站系统，如果交易双方是通过网上银行完成支付交易的，则网上银行就成为了购物网站系统的一个涉众；如果货物是通过邮政系统交付的，那么邮政系统就成为购物网站系统的一个涉众。
一般来说，第三方的期望对系统来说不会产生什么决定性影响，但大多会起到限制作用，成为系统的一个约束。通常，在最终系统中，这些期望将体现为标准、协议和接口。
另一种典型的第三方是项目监理，项目监理的期望也会对系统建设起到约束作用。
6）承建方
承建方，也就是你的老板。实际上老板的期望也是不容忽视的。
通常老板关心的是通过这个项目是否能赚到钱、是否能积累核心竞争力、是否能树立品牌、是否能开拓市场等。老板的期望将很大的影响—个项目的运作模式、技术选择、架构建立和范围确定。
比如，如果老板试图通过这个项目打开和培育一个新兴市场，树立起公司品牌，并不惜成本，那么系统分析员就要尽可能的深入挖掘潜在业务，建立扩展能力很强，但成本较高的业务架构；选择那些比较新、具有一定领先优势但风险较高的技术。
反之，如果老板只想通过这个项目赚更多的钱，关心的是投入产出比，那么系统分析员就需要引导业务方压缩业务范围，选择风险小的成熟技术。甚至可能放弃成本较高的架构化开发模式，仅仅考虑系统的可维护性是否能够接受，而较少考虑系统扩展能力。
一个业主满意但老板不满意的项目，恐怕也不是一个成功的项目吧？
7）相关的法律法规
相关的法律法规是一个很重要的，但也最容易被忽视的涉众。
这里的法律法规，既指国家和地方法律法规，也指行业规范和标准。例如，服务行业建立客户档案，就必须保障客户的隐私权，系统设计时就不能够将涉及隐私的信息向非授权用户开放。
极端情况下，业务方有时提出来的一些需求违反了法律法规，系统分析员如果知晓则应当指出来，说服无果的情况下则应当与老板商量在合同里留下免责条款。
另外，有时必须得遵守一些行业规范。现在许多行业都有本行业的信息系统建设标准，如信息安全标准系统建设时就必须考虑信息安全的问题。
3. 制作涉众汇总表格
在分析完涉众后，我们可以简单整理成表格，为我们后续的调研打下基础，知道哪块业务去找哪些人。
至此前三个步骤告一段落，后面的两个步骤是整个建模过程的核心，将会在接下来的一周内分享给大家。
作者：一点优秀，教育行业产品经理，微信号：gentleman52520，欢迎交流
本文由 @一点优秀 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议游戏网
责任编辑：