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

B端产品业务需求分析之涉众概述 / 一般在开始新的项目之前，产品经理或者项目负责人还有一个重要角色：系统分析员。主要对整个项目要建设的系统进行整体和部分的理解和规划，也就是经常提到的需求分析。 需求分析有多种方式方法，下面主要介绍下 UML建模分析方法。本章先为大家介绍业务涉众，下一阶段才会进入到正式的业务建模。 一、了解问题领域 首先我们要知道软件是一种工具，是用来辅助人们解决某一问题的。软件的价值就在于它能够符合问题领域的需求，并达到人们解决问题的期望，软件项目总是从了解问题领域开始的。 二、了解业务概况 在每一个信息化项目启动前，作为产品/项目经理，你首先需要考察和评估客户的业务模式，主要包括项目背景调查、业务前景分析、业务可行性分析、技术可行性分析等。 通过这些步骤，你将初步了解项目的产生原因、运行环境、系统规模、软硬件环境以及客户期望，这些内容将成为软件目标的最初输入也是十分重要的输入。 三、整理业务目标 业务目标又称为业务前景，是对要建设的系统的展望。一般客户立项准备开发一个软件系统，就会对这个系统有明确的展望，即建设系统的目的是什么、准备用它来做什么。 一般情况下我们会根据对业务概况的了解来整理业务目标。有些项目，客户会在招标文件中提出具体的业务目标。但在实际项目中，也会有一部分客户对于自己的业务系统理解不是特别的清晰，他们会通过一些场景化的描述来阐述对于目标系统的需求。 总之，业务目标非常重要，因为我们还需要通过业务目标来辅助定义系统边界。在了解业务目标之后，可以开始推导需求和建立业务模型。在初步了解业务概况后，接下来就需要进行涉众分析。 四、做好涉众分析 在了解业务概况和业务目标以后，系统分析员最先要做的事情是去发现与这个目标相关的人和物。英文把这种人和物称为 Stakeholder（利益相关者）。有的资料翻译为干系人或者涉众。本文采用涉众称呼，然后我们可以开始业务建模的第一步：发现和定义涉众。 1. 什么是涉众？ 涉众是与要建设的业务系统相关的一切人和事。涉众不等于用户，通常意义上的用户是指系统使用者，而这仅是涉众中的一部分，如何理解与业务系统相关的一切人和事情呢？ 凡是与这个项目有利益关系的人和事都是涉众，他们都可能对系统建设造成影响。不过我们在实际项目中，有些影响特别小的涉众可以忽略不考虑。 当面对一个陌生的问题领域时，在项目初期不一定能够很清楚谁是系统的真正使用者，随着需求的深入才会逐步明确。因为最终的系统使用者肯定会从涉众当中产生，所以涉众分析就十分重要。 2. 业主 业主是系统建设的出资方、投资者，大多数情况下业主也是系统的需求提出者和使用者，即业务方，但并不是绝对的。比如可以假设系统建设是由第三方机构投资，但它本身并不管理和运营这个系统，它只是从资本上拥有这个系统并从运营收入中获得回报。 即使业主与业务方是重合的，但是业主从概念上讲并不等于业务方，他们关心的内容是不一样的。了解业主的期望是必须的和重要的，业主的钱是这个项目存在的原因。如果系统建设不符合业主的期望，撤回投资，那么再好的愿望也是空的。 一般来说，业主关心的是建设成本，建设周期以及建成后的效益。虽然这些看上去与系统需求没有什么大的关系，但是，建设成本、建设周期将直接影响到你可以采用的技术，可以选用的软件架构，可以承受的系统范围。 一个不能达到业主成本和周期要求的项目是一个失败的项目，同样，一个达到了业主成本和周期要求，但却没有赚到钱的项目仍然是一个失败的项目。 举个笔者参与的案例：一个公益机构委托开发1套信息化平台，主要使用者有公益机构本身工作人员，也有普通公众和政府相关机构人员，这里的业主也是需求提出者和使用者——公益机构。 3. 业务提出者 业务提出者是业务范围、业务模式和业务规则的制定者，一般是指业务方的高层人物，比如CEO、高级经理等。 他们制定业务规则，圈定业务范围，规划业务目标。他们的期望十分十分的重要，实际上，系统艰涩正是业务提出者经营目标和管理意志的体现。 虽然他们的期望一般都比较原则化和粗略化，但是却不能违反和误解，否则系统将有彻底失败的危险。换句话说，业务提出者的期望是系统建设的最高纲领。 业务提出者一般最关心系统建设能够带来的社会影响、效率提升、管理改进、成本节约等宏观效果。即他们只关心统计意义而不关心具体细节，但是，如果建设完成的系统不能给出他们满意的统计结果，这必定是一个失败的项目。 在系统建设过程的沟通中，他们的意志一般是极少妥协的，系统分析员不必太费心去试图说服他们接受一个与他们意志相左的方案。实际上，由于他们的期望是非常原则化和粗略化的，因此留给了系统建设者很大的调整空间和规避风险的余地。 4. 业务管理者 业务管理者是指实际管理和监督业务执行的人员，一般是指中层干部，他们起到将业务提出者的意志付诸实施