B端产品业务需求分析之涉众概述

一般在开始新的项目之前，产品经理或者项目负责人还有一个重要角色：系统分析员。主要对整个项目要建设的系统进行整体和部分的理解和规划，也就是经常提到的需求分析。

需求分析有多种方式方法，下面主要介绍下 UML建模分析方法。本章先为大家介绍业务涉众，下一阶段才会进入到正式的业务建模。

一、了解问题领域

首先我们要知道软件是一种工具，是用来辅助人们解决某一问题的。软件的价值就在于它能够符合问题领域的需求，并达到人们解决问题的期望，软件项目总是从了解问题领域开始的。

二、了解业务概况

在每一个信息化项目启动前，作为产品/项目经理，你首先需要考察和评估客户的业务模式，主要包括项目背景调查、业务前景分析、业务可行性分析、技术可行性分析等。

通过这些步骤，你将初步了解项目的产生原因、运行环境、系统规模、软硬件环境以及客户期望，这些内容将成为软件目标的最初输入也是十分重要的输入。

三、整理业务目标

业务目标又称为业务前景，是对要建设的系统的展望。一般客户立项准备开发一个软件系统，就会对这个系统有明确的展望，即建设系统的目的是什么、准备用它来做什么。

一般情况下我们会根据对业务概况的了解来整理业务目标。有些项目，客户会在招标文件中提出具体的业务目标。但在实际项目中，也会有一部分客户对于自己的业务系统理解不是特别的清晰，他们会通过一些场景化的描述来阐述对于目标系统的需求。

总之，业务目标非常重要，因为我们还需要通过业务目标来辅助定义系统边界。在了解业务目标之后，可以开始推导需求和建立业务模型。在初步了解业务概况后，接下来就需要进行涉众分析。

四、做好涉众分析

在了解业务概况和业务目标以后，系统分析员最先要做的事情是去发现与这个目标相关的人和物。英文把这种人和物称为 Stakeholder（利益相关者）。有的资料翻译为干系人或者涉众。本文采用涉众称呼，然后我们可以开始业务建模的第一步：发现和定义涉众。

1. 什么是涉众？

涉众是与要建设的业务系统相关的一切人和事。涉众不等于用户，通常意义上的用户是指系统使用者，而这仅是涉众中的一部分，如何理解与业务系统相关的一切人和事情呢？

凡是与这个项目有利益关系的人和事都是涉众，他们都可能对系统建设造成影响。不过我们在实际项目中，有些影响特别小的涉众可以忽略不考虑。

当面对一个陌生的问题领域时，在项目初期不一定能够很清楚谁是系统的真正使用者，随着需求的深入才会逐步明确。因为最终的系统使用者肯定会从涉众当中产生，所以涉众分析就十分重要。

2. 业主

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

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

一般来说，业主关心的是建设成本，建设周期以及建成后的效益。虽然这些看上去与系统需求没有什么大的关系，但是，建设成本、建设周期将直接影响到你可以采用的技术，可以选用的软件架构，可以承受的系统范围。

一个不能达到业主成本和周期要求的项目是一个失败的项目，同样，一个达到了业主成本和周期要求，但却没有赚到钱的项目仍然是一个失败的项目。

举个笔者参与的案例：一个公益机构委托开发1套信息化平台，主要使用者有公益机构本身工作人员，也有普通公众和政府相关机构人员，这里的业主也是需求提出者和使用者——公益机构。

3. 业务提出者

业务提出者是业务范围、业务模式和业务规则的制定者，一般是指业务方的高层人物，比如CEO、高级经理等。

他们制定业务规则，圈定业务范围，规划业务目标。他们的期望十分十分的重要，实际上，系统艰涩正是业务提出者经营目标和管理意志的体现。

虽然他们的期望一般都比较原则化和粗略化，但是却不能违反和误解，否则系统将有彻底失败的危险。换句话说，业务提出者的期望是系统建设的最高纲领。

业务提出者一般最关心系统建设能够带来的社会影响、效率提升、管理改进、成本节约等宏观效果。即他们只关心统计意义而不关心具体细节，但是，如果建设完成的系统不能给出他们满意的统计结果，这必定是一个失败的项目。

在系统建设过程的沟通中，他们的意志一般是极少妥协的，系统分析员不必太费心去试图说服他们接受一个与他们意志相左的方案。实际上，由于他们的期望是非常原则化和粗略化的，因此留给了系统建设者很大的调整空间和规避风险的余地。

4. 业务管理者

业务管理者是指实际管理和监督业务执行的人员，一般是指中层干部，他们起到将业务提出者的意志付诸实施，并监督底层员工工作的作用。

业务管理者关心系统将如何实现他们的管理职能，如何能方便地得知业务执行情况，如何下达指令、如何得到反馈、如何评估结果等。业务管理者的期望相对比较细节，是需求调研过程中最重要的信息来源。系统建设的好坏与业务管理者的关系最多，也是系统分析员最需要下功夫的。

业务流程、业务规则、业务模式等绝大部分也必须与业务管理者达成一致，业务管理者应当成为需求评审小组的成员，如果可能，他们甚至应当成为需求分析小组的成员与系统分析员一同工作。

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

5. 业务执行者

业务执行者是指底层的业务操作人员，是与将来的软件系统直接交互最多的人员，系统的可用性、友好性、运行效率等与他们关系最多。

业务执行者的需求最为细节，系统的界面风格、操作方式、表单细节等是系统分析员向他们调研时需要多下功夫的地方，他们将成为系统是否成功的试金石。

这类人员的期望灵活性最大，也最容易说服和妥协。同时，他们的期望又往往是最不统一的，各种各样的古怪要求都有。但是，不管他们的期望有多古怪，都必须服从业务管理者的期望。

系统分析员需要从他们的各种期望中找出普遍意义，解决大部分人的问题，对于特殊的问题尽量予以说服，必要时可以依靠说服业务管理者来影响和消除那些不合理的期望。

6. 第三方

第三方是指与这项业务有关系的，但并非业务方的其他人或事。

比如共享单车系统，用户和平台的交易是通过微信、支付宝、银行卡等第三方支付系统完成支付交易，因此第三方支付系统就成为了共享单车系统的一个涉众；如果单车是通过自行车厂商提供，那自行车厂商就成为共享单车系统的一个涉众。

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

7. 承建方

也就是你的老板：

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

假设老板试图通过这个项目打开和培育一个新兴市场，树立公司品牌，并且不惜成本，那么系统分析员就要尽可能的深入挖掘潜在业务，建立扩展能力很强，但成本较高的业务架构：选择那些比较新、具有一定领先优势但风险较高的技术。

反之，如果老板只想通过当前项目赚更多的钱，更关心投入产出比，那么系统分析员就需要引导业务方压缩业务范围，选择风险较小的成熟技术。

8. 相关的法律法规

相关的法律法规是一个很重要的，但也最容易被忽视的涉众。

既指国家和地方法律法规，也包括行业规范和标准。例如：公益平台建立客户档案，就必须保障客户的隐私权，系统设计时就不能够将涉及隐私的信息向非授权用户开发。

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

有时还必须遵守一些行业规范，许多行业都有本行业的信息化系统建设标准，最常见的有信息安全标准，在系统建设的时候必须考虑到信息安全的问题。

9. 用户

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

用户与涉众不同的是，每一个用户将来都可能是系统中的一个角色，是实实在在参与系统的，需要编程实现。而上述的其他涉众，则有可能只是在需求阶段用来分析系统，最终并不与系统发生交互。

在建模过程中，概念模型的建立和系统模型的建立都只从用户开始分析，而不再理会其他的涉众。当通过以上的大类发现和定义了涉众之后，就可以着手进行涉众分析报告的编写。

五、总结

通过以上大类的辅助，系统分析员对项目范围内的涉众进行调查和访谈，形成涉众分析报告。涉众分析报告完成后，就会正式开始需求建模分析，下一期继续为大家分享。

参考资料：《大象Thingk.in.UML》，作者：谭云杰

作者：明远；5年互联网工作经验，主要涉及智慧养老、智慧社区、智能安防等方面。

本文作者 @明远 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！