做好涉众分析

在了解了业务概况和业务目标以后，系统分析员最先要做的事情不是去了解业务的细节，而是去发现与这个目标相关的人和物。英文把这种人和物称为 Stakeholder。有的资料翻译为干系人，作者则更喜欢涉众这种翻译方法。这就谈到了业务建模的第一步：发现和定义涉众。

什么是涉众

涉众是与要建设的业务系统相关的一切人和事。首先要明确的一点是，涉众不等于用户，通常意义上的用户是指系统的使用者，而这仅是涉众中的一部分。如何理解与业务系统相关的一切人和事呢？凡是与这个项目有利益关系的人和事都是涉众，他们都可能对系统建设造成影响。

例如修建一条公路，它预期的使用者是广大的司机；监管方是交通管理局；出资方是国家财政；发展商是某某公司；建筑商是某某工程公司等。显然他们都与此项目有利益关系，都是涉众。这些都好理解。但是在某些情况下，看似与公路完全无关的一些人和事却会成为重要涉众。例如当公路修建需要搬迁居民时，被搬迁的居民就成为重要的涉众；当公路规划遇到历史建筑时，文物管理局就成为重要的涉众。

虽然软件项目开发与修建公路相比涉及的人和事要少得多，但是也不能忽略系统使用者之外的其他涉众。另外，当面对一个陌生的问题领域时，往往在项目初期还不能够清楚的获悉究竟谁是系统的使用者，通常得随着需求的深入逐步明确。但是最终的系统使用者将从涉众当中产生，因此涉众分析显得尤为重要。

发现和定义涉众

对于软件项目来说，作者可以给大家分享的经验是通过以下大类去寻找软件项目的涉众，对大部分管理类软件来说，以下的涉众大类可以帮助你定义和发现项目中的涉众。

业主

业主是系统建设的出资方、投资者。虽然大多数情况下业主指的就是系统的需求提出者和使用者，即业务方，但并不是绝对的。比如可以假设系统建设是由一家国际风险投资机构投资的，它本身并不管理和运营这个系统，它只是从资本上拥有这个系统并从运营收入中获得回报。

即使业主与业务主是重合的，但是业主从概念上讲并不等于业务方，他们关心的内容是不一样的。了解业主的期望是必需的和重要的，业主的钱是这个项目存在的原因。若系统建设不符合业主的期望，撤回投资，那么再好的愿望也是空的。

一般来说，业主关心的是建设成本，建设周期以及建成后的效益。虽然这些看上去与系统需求没什么大的关系，但是，建设成本、建设周期将直接影响到你可以采用的技术，可以选用的软件架构，可以承受的系统范围。一个不能达到业主成本和周期要求的项目是一个失败的项目，同样，一个达到了业主成本和周期要求，但却没有赚到钱的项目仍然是一个失败的项目。

业务提出者

业务提出者是业务范围、业务模式和业务规则的制定者，一般是指业务方的高层人物，比如CEO、高级经理等。他们制定业务规则，圈定业务范围，规划业务目标。他们的期望十分十分的重要，实际上，系统建设正是业务提出者经营目标和管理意志的体现。虽然他们的期望一般都比较原则化和粗略化，但是却不能违反和误解，否则系统将有彻底失败的危险。换句话说，业务提出者的期望是系统建设的最高纲领。

业务提出者一般最关心系统建设能够带来的社会影响、效率提升、管理改进、成本节约等宏观效果。换句话说，他们只关心统计意义而不关心具体细节，但是，如果建设完成的系统不能给出他们满意的统计结果，这必定是一个失败的项目。在系统建设过程的沟通中，他们的意志一般是极少妥协的，系统分析员不必太费心去试图说服他们接受一个与他们意志相左的方案。实际上，由于他们的期望是非常原则化和粗略化的，因此留给了系统建设者很大的调整空间和规避风险的余地。

业务管理者

业务管理者是指实际管理和监督业务执行的人员，一般是指中层干部，他们起到将业务提出者的意志付诸实施，并监督底层员工工作的作用。他们的期望也很重要，一般也是系统的主要用户之一。

业务管理者关心系统将如何实现他们的管理职能，如何能方便地得知业务执行情况，如何下达指令、如何得到反馈、如何评估结果等。业务管理者的期望相对比较细节，是需求调研过程中最重要的信息来源。系统建设的好坏与业务管理者的关系最多，也是系统分析员最需要下功夫的。业务流程、业务规则、业务模式等绝大部分来自业务管理者。系统分析员必须要把业务管理者的思路想法弄清楚，业务建模的结果也必须与业务管理者达成一致。业务管理者应当成为需求评审小组的成员，如果可能，他们甚至应当成为需求分析小组的成员与系统分析员一同工作。

在系统建设过程中，业务管理者的期望可以有所妥协，一个经验丰富的系统分析员可以给他们灌输合理的管理方式，提供可替代的管理方法，以规避导致高技术风险或高成本风险的不合理要求。

业务执行者

业务执行者是指底层的业务操作人员，是与将来的计算机直接交互最多的人员。他们最关心的内容是系统会给他们带来什么样的方便，会怎样的改变他们的工作模式。

业务执行者的需求最为细节，系统的可用性、友好性、运行效率等与他们关系最多。系统界面风格、操作方式、数据展现方式、录入方式、业务细节都需要从他们这里了解。他们将成为系统是否成功的试金石。系统的界面风格、操作方式、表单细节等是系统分析员向他们调研时需要多下功夫的地方。

这类人员的期望灵活性最大，也最容易说服和妥协。同时，他们的期望又往往是最不统一的，各种各样的古怪要求都有。但是，不管他们的期望有多古怪，都必须服从业务管理者的期望。系统分析员需要做的事情是从他们的各种期望中找出普遍意义，解决大部分人的问题，对于特殊的问题尽量予以说服，必要时可以依靠说服业务管理者来影响和消除那些不合理的期望。

第三方

第三方是指与这项业务有关系的，但并非业务方的其他人或事。比如购物网站系统，如果交易双方是通过网上银行完成支付交易的，则网上银行就成为了购物网站系统的一个涉众；如果货物是通过邮政系统交付的，那么邮政系统就成为购物网站系统的一个涉众。

一般来说，第三方的期望对系统来说不会产生什么决定性影响，但大多会起到限制作用，成为系统的一个约束。通常，在最终系统中，这些期望将体现为标准、协议和接口。

另一种典型的第三方是项目监理，项目监理的期望也会对系统建设起到约束作用。

承建方

承建方，也就是你的老板。实际上老板的期望也是不容忽视的。通常老板关心的是通过这个项目是否能赚到钱、是否能积累核心竞争力、是否能树立品牌、是否能开拓市场等。老板的期望将很大的影响一个项目的运作模式、技术选择、架构建立和范围确定。

比如，如果老板试图通过这个项目打开和培育一个新兴市场，树立起公司品牌，并不惜成本，那么系统分析员就要尽可能的深入挖掘潜在业务，建立扩展能力很强，但成本较高的业务架构；选择那些比较新、具有一定领先优势但风险较高的技术。反之，如果老板只想通过这个项目赚更多的钱，关心的是投入产出比，那么系统分析员就需要引导业务方压缩业务范围，选择风险小的成熟技术。甚至可能放弃成本较高的架构化开发模式，仅仅考虑系统的可维护性是否能够接受，而较少考虑系统扩展能力。

一个业主满意但老板不满意的项目，恐怕也不是一个成功的项目吧？

相关的法律法规

相关的法律法规是一个很重要的，但也最容易被忽视的涉众。这里的法律法规，既指国家和地方法律法规，也指行业规范和标准。例如，服务行业建立客户档案，就必须保障客户的隐私权，系统设计时就不能够将涉及隐私的信息向非授权用户开放。

极端情况下有时业务方提出来的一些需求违反了法律法规，系统分析员如果知晓则应当指出来，说服无果的情况下则应当与老板商量在合同里留下免责条款。

另外，有时必须得遵守一些行业规范。现在许多行业都有本行业的信息系统建设标准，如信息安全标准，则系统建设时就必须考虑信息安全的问题。

用户

用户是一个抽象的概念，指预期的系统使用者。用户一般是上述涉众的代表。

用户与涉众不同的是，每一个用户将来都可能是系统中的一个角色，是实实在在参与系统的，需要编程实现。而上述的其他涉众，则有可能只是在需求阶段用来分析系统，最终并不与系统发生交互。在建模过程中，概念模型的建立和系统模型的建立都只从用户开始分析，而不再理会其他的涉众。

当通过以上的大类发现和定义了涉众之后，就可以着手进行涉众分析报告的编写了。

涉众分析报告

通过以上的大类帮助，系统分析员对项目范围内的涉众进行调查和访谈，形成涉众分析报告。对于系统建设影响很小的涉众可以忽略。为了展示如何编写涉众分析报告，作者以供电企业案例的一部分作为例子，读者可以通过这些例子学习到如何编写涉众分析报告。

一份完整的涉众分析报告包括涉众概要、涉众简档、用户概要、用户简档和消费者统计五个部分，下面分别进行说明。

为何没有人跟贴，太差劲了！