起点学院课程

产品经理方法论:如何进行需求定义?(二)

0 评论 4053 浏览 24 收藏 23 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

需求范围定义的工作重点在于明确项目的目标和范围,通过三步走的方法,界定了需求范围以后,就可以以业务事件列表和报表列表为线索,进行进一步的需求分析需求分析和需求业务建模提供架构基础。

一、需求范围定义

我们在做项目的时候,进行需求工程分析项目,为了能给需求分析与需求建模提供有效的支持,避免出现“上梁不正下梁歪”的情况,我们在立项阶段的需求范围定义就显得尤为重要。而需求范围的定义应该放在项目的启动立项阶段,对整个项目的宏观业务需求,起到指引的作用。

一句话说就是:明确项目的目标和范围。

那么需求范围定义的应该怎么做?结合笔者的经验,三步可以概括:

  1. 划分主题域,进而画出构件图,即摸清楚结构性框架;
  2. 绘制上下文关系图,找到主题域承担的责任,即找到每个板块的业务范围;
  3. 标识业务事件和报表,输出需求大纲。

划分主题域顾名思义就是划分板块,但是划分的方法,维度,参考的标识应该是什么呢?我们可以通过两个方法来识别:

  • 以“事”为线索划分主题域,通过业务事件找到业务流信息;
  • 对于复杂的联机处理业务系统,单单以一条线划分主题域还不够,结合职责划分主题域会有更好的效果。

二、案例:商旅平台系统

(1)确定主题域

通过典型的业务职责,将系统分为:销售、生产、售后三部分。

  • 销售职责区块:由于产品特性,商旅针对的B端用户是组织和企业。所以这里的客户是企业。销售这个业务职责就是对客户企业的管理,服务跟踪,运营数据数据分析等,这里把这个主题域命名为客户管理子系统,也是通常说的CRM
  • 生产职责区块:这个职责区块就是为企业用户提供全面的商旅业务(包括机票,酒店,用车等),也就是商旅业务就是他的核心生产业务。因此可以把这个业务区块主题域称为“商旅业务系统”,但是由于业务相当复杂,以及服务业的特性,光是一级主题域还不够,商旅业务子系统下,平台内部还应该划分更细的业务职责以及协同职责,这里才是整个平台高效运转的核心,也是我们划分主题域的核心工作,所以这个案例的重点是把业务系统下的二级主题域划分清楚。
  • 售后职责区块:这个区块,为企业提供售后的支持的主题域,主要是财务上的,和C端的旅游不同,商旅很多是企业和平台月结的,而平台和供应商一般也是周期结算。所以售后这个区块一是平台和企业的按照周期结算对账,二是平台和供应商的结算。这个主题域叫做结算系统。

下面我们来进一步二级主题域的划分。

在业务子系统内部,由于业务的特殊性和复杂性。我们进一步进行职责划分:生产、支持、服务三个职责区块。

  • 生产职责区块:商旅平台在本质上属于电商平台,只不过商品不是实物产品,他只是一个平台代理商,所以它的核心业务应该是属于电商:查询、下单、支付、发货这个完整的业务流程。这个主题域我们把它叫成:生产系统。业务要走的通,除了业务,还应有资金。支付方式如果支持多种:月结、现结、预存,那么还应该有支付系统,或者第三方提供支付服务,提供支付接口,或者提供记账的虚拟支付系统。
  • 支持职责区块:由于业务的复杂特性(以机票为例:各种政策投放,优惠,里程兑换,行程单报销,短信通知),质量风控,投诉质检等。需要大量的运营人员以及系统对业务的支持。这里把所有的业务支持的东西都放在一起,叫业务支持主题域。生产上即业务支持子系统
  • 服务职责区块:由于服务行业7*24服务业的特性,在这个职责区块上,为了给客服中心提供有效的协同支持,还应该有工单子系统,呼叫子系统。

第二步:绘制构件图

完成了主题域划分以后,可以用一个构件图,标识出各主域题之间的关系,即找到各主题域之间的接口,把整个系统联系起来,搭建出整个业务框架。

在前面我们已经标识出了一级主题域有:“客户关系管理系统”、“商旅业务系统”、“结算系统”,现在我们先来梳理一下一级主题域之间的关系。

客户关系管理子系统和商旅业务系统:以商旅机票服务为例,只有企业账户已经开通,企业下的用户才能在业务系统下单,所以在用户下单时候,需客户关系管理系统提供相应的用户数据,企业信息给业务系统。而为了分析企业的商旅出行的数据等,业务系统还应该把订单数据回传给客户关系管理系统,以为生成各类运营报表提供基础。所以这两个主题域之间的接口应该是:CRM提供查询客户资料的接口供业务系统查询,业务系统提供同步订单数据的接口给CRM。

客观关系管理系统和结算系统:企业当月使用多少票量,应该月结金额多少钱,企业是否按时还款,这块数据应该由结算系统同步给给客户关系管理系统。所以这两个主题域之间的接口应该是:结算系统提供数据给CRM生成报表。

供应商主题域:在确定最终的主题域之前,我们还需要结合最终的目标来考察这些主题域。从目标范围的角度来说,商旅平台,只是作为一个代理商,他没有真正的产品。刚才我们分析的都是对内的关系,还应分析对外的关系,即平台是通过整合其他渠道或者代预定的方式来提供服务的。所以考虑他的产品从哪里来,就会自然想到其供应商,这里统一叫成:供应商主题域。当然从机票的业务来讲,可能有:黑屏,航司官网,其他OTA等等。从其他平台有交易,有业务就有资金。所以还应该有对供应商的支付体系。

第一级主题域的构件图画好了,标识出服务接口:

如下:

下面来确定第二级主题域的构件图:

首先确定二级主题域之间的关系:生产系统、供应商业务系统、供应商支付系统、业务支持系统、工单系统、外呼系统。

生产系统和供应商系统:以机票为例,来找这两个主题域之间的关系。我们以“事”为线索,从业务事件,找到业务流程,最终推演业务活动。机票下单首先航班信息这些不是凭空变出来的,都是从供应商那里获取到的,包括航班信息,舱位信息,运价,座位的查询,部分退票改签政策等应该由供应商提供。如果用户下单,那么平台还应该去供应商那里自动创单,所以还应该对接供应商业务系统的下单接口,供应商提供的支付接口。

生产系统和业务支持系统:

  • 由于业务的特殊性,对于大客户企业,航空公司会有三方或者两方协议政策提供优惠,每种舱位折扣的优惠力度,又由于每个时间段折扣不同,航线不同折扣不同,高管白名单等。这些都应该维护在业务系统中给生产系统出票提供支持。
  • 退票改签的政策也各个航空公司有差异,每年都在变,甚至每个季度都在变,这些应由运营人员根据航空公司,企业大客户政策,航班舱位多个角度实时更新并给生产提供支持。
  • 作为平台来讲,会有一套自己独有的出票逻辑体系,供应商出票优先级,政策投放规则以实 现盈利,所以业务支持系统维护出票配置,供应规则等给生产系统,当然这部分也可以放在生产系统本身当中,这里不详细介绍。

生产系统和工单系统:电商订单无时无刻不在产生,对于7*24小时的人工服务,客服人员随时在处理订单的问题,也需要其他业务组,或者部门来处理的,甚至是需要技术人员处理(如退款失败,需要人工退款),要实现高效的输出,团队协作必不可少。而其他业务人员想要快速实现高效协作,工单系统中的订单信息必不可少,应该由生产系统通过服务接口提供给工单系统

生产系统和外呼系统:对于人工出票,客户致电后为了能实现智能接听,快速识别出客户个人信息,已预订的订单信息,应该由生产系统提供信息给外呼系统。

通过各个二级主题域之间的分析,找到了二级主题域之间的服务接口,绘制成构建图后如下:

通过我们对系统整体进行主题域划分之后,并且标识出各主题域之间的关系,即服务接口以后,系统整体的架构就一个雏形了(案例只是标识了部分业务接口,具体还有很多其他业务接口,技术上的功能接口未标出)。下面一步就是进一步对各主题域内部进行细节梳理。

(2)绘制上下文关系图

什么是上下文关系图?

当把系统的范围缩小到一个主题域时候,涉及的内容就大大减少了。这个时候我们针对每个主题域来分析,分析其所要承担的业务责任。

我们以二级主题域,业务最复杂的生产系统为例来绘制上下午关系图,通过三个步骤来抽丝剥茧,分析出细节脉络。

a. 将整个系统看成一个盒子

b. 找到系统中所有的customer(客户)和worker(工作人员)

c. 分析customer和worker主动发起的事件

首先把这个生产系统看成一个黑盒子,用矩形表示;接着思考这些主题域需要哪些外部的customer,内部的worker?

很显然,这里的customer最重要的商旅用户。他发起出差肯定会提交出差申请,不管是事前出差申请,还是订票中提出差申请。那么会有他的领导来审核,对于生产系统来说也是属于customer。

申请通过以后就会进行在生产系统订票,生产系统这个时候需要到外部供应商那里去购票,这个时候,企业的业务协同就开始了,所以供应商,结算系统,业务支持系统对于生产系统来说都是属于外部的worker。结算系统负责资金流,业务系统提供业务支持,供应商系统负责提供票务。

用户除了订票还会有什么独立的行为呢?可能会因为天气原因,个人原因临时改变行程,发生改签或者退票。这是一个独立的,不是必然发生的事情。首先应该由customer提出申请,然后由平台客服运营人员进行审核后提交给航空公司或者供应商处

如果退改签的审核通过,则会进行相应的收取手续费或者退款,因此将这两个信息添加到上下文关系图中,这时候就会得到。

分析完了customer主动发起的事件后,我们来继续分析worker主动发起的事件。从生产系统customer以外的都是worker,包括供应商,协作系统,财务系统等。

下面我们来分析几个例子:

  • 航空变动:天气原因,原航班有延误,取消等通知需要通知给用户,通过业务支持系统中的短信模块来发送短信通知用户(如果出票有短信服务也会通知);
  • 企业余额不足:企业在商旅系统上余额不足,不足以支付后,将会通知给用户;
  • 航旅个人报告:个人的商旅航分析报告,主动推送给用户。

其他例子不详细说明。

我们再加上这些后,上下文关系图变得更加丰富和清晰:

到现在我们就通过以生产系统为例,从customer和worker的业务事件分析起。绘制出了生产系统的上下文关系图

(3)标识业务事件和报表,输出需求大纲

对于联机业务处理的系统而言,业务事件(业务流程)是核心线索,对于管理信息系统而言,report(包括各种查询,分析,统计)是核心线索,而在此案例中,商旅平台属于复杂的联机处理事务系统。

首先我们来对业务事件做个解析

业务事件是梳理业务系统需求的一个很重要的线索,因为一个企业或组织存在的核心价值在于接受外部用户的请求,通过响应请求让用户满意的同时也创造了相应的价值。

业务事件是业务流程的触发点,标识出业务事件能够帮助我们识别出业务流程;而业务流程是为了响应业务事件而触发的一系列业务活动,它通常是由不同部门、不同岗位协作完成的。因此业务流程的信息是掌握在中层管理人员手里的,它属于脉络信息。

结合我们的案例商旅系统,在我们分析上下文关系图的时候就是按照业务事件分析的,标注出业务事件后如下:

举一个业务事件例子:由用户提出出差申请(业务事件),于是产生审批流程(业务流程),需要相关人员进行审批(业务步骤),提出出差申请是业务事件,即触发整个流程的行为,也是直接作用于系统的行为。通过这个事件,我们可以找到一系列的活动和相关部门。

解析出报表:

在此基础上我们来分析潜在的报表。需求定义阶段主要是识别出报表的类型以及为什么要这些报表,他们的使用场景。这里由于和企业需要结算对账,就需要进行业务账和资金账的核对。

根据分类可以分析出以下报表:

当然,报表不一定完全,还要根据管理层的意图,需求,进行访谈,增加报表类型等。

输出需求大纲,产出需求范围规格文档。

下面就是我们的最后一步,把刚才的分析汇总成需求大纲,输出需求规格的边界,从主题域开始,一个一个小节列出来,阐述业务事件(包括整个流程),列表需求。搭建出了整体的系统框架。为具体的后期业务建模需求说明提供了参考。

下面是我输出的需求大纲作为参考

Word版的文档需求大纲:

XXX商旅平台系统需求规格说明书:

1.文档概述

(略)

2.任务概述

2.1业务需求

  • 为大型企业提供一站式商旅解决方案,包括审批,预订,出行,报销全流程服务
  • (其余略)

2.2用户人群分析

(略)

3.业务模型分析

本系统由客户关系管理系统,商旅业务系统,结算系统,将从业务的销售,生产,售后等范围进行提供支持,其范围如下:

主题域划分示意图

3.1客户关系管理系统

本主题域主要对客户关系管理提供支持,主要对企业信息管理,用户信息管理,消费统计等分析,其范围如下:……

(略)

3.2商旅业务系统

本主题域主要为企业提供整体的商旅业务。在此主题域下又划分为:生产系统,供应商业务系统,供应商支付系统,业务支持系统,工单系统,外呼系统主题域。其关系如下:

3.2.1生产系统

生产系统是整个业务生产的核心系统,是连接各个二级主题域的中枢,下面是生产系统的上下文关系图,标识出了生产系统范围。

3.2.1.1业务事件

  • 提交出差申请
  • 撤销出差申请
  • 预订出票
  • 申请改签
  • 申请退票

3.2.1.2服务接口

  • 获取企业信息
  • 获取用户信息
  • 获取订单信息
  • 下单接口
  • 支付接口
  • 退票接口
  • 退款接口
  • 改签支付接口

3.2.1.3报表

  • 出票周期统计报表
  • 改签周期统计报表
  • 退票周期统计报表
  • 航旅分析统计报表

3.2.2结算系统

(略)

4.具体需求

4.1生产系统

4.2结算系统

4.3呼叫系统

4.4工单系统

三、总结

需求范围定义的工作重点在于明确项目的目标和范围,通过三步走的方法,界定了需求范围以后,就可以以业务事件列表和报表列表为线索,进行进一步的需求分析需求分析和需求业务建模提供架构基础。

以上便是笔者的工作总结以及方法论复盘,欢迎指正和交流。

 

本文由 @谢君翊 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 目前还没评论,等你发挥!