后台产品设计系列:产品设计方式(二)

产品举例:如果我们要做一个芒果TV后台管理系统,简单的方式和复杂的方式分别怎么来做呢?

一、简单系统设计方式——需求驱动设计

针对简单的后台产品,我们通常采用需求驱动设计(Request-driven design,以下简称RDD)。

1、概念

所谓需求驱动设计,是指我们在设计后台时,根据上级、运营、市场、客服、前端产品等需求方所提的具体需求,直接进行产品架构、功能设计。这种设计方式简单快捷,与我们做前端产品思路、方式相同,对于很多做前端产品的同学而言,这种方式是最容易理解和掌握。

2、设计流程

后台产品设计系列:产品设计方式(二)

3、流程拆解

(1)明确目标

任何一个产品的萌芽,往往是因为一句话,一个问题,或领导的一个idea,而这些起因,就是我们的产品目标,这些目标有时很模糊,但对于系统产品,这个目标都是很明确的,明确的业务场景下,XX用户产生的明确需求。例如我们要做芒果TV,分别有APP、web、PC、TV四个端,就需要有一个统一的管理后台,对前端进行支撑,运营人员能够对内容进行维护。

(2)需求分析

明确了方向,接下来就需要做需求调研。

第一步:穷举用户角色

进行需求调研时,需要先找用户角色,再找需求。

清晰地列出使用此系统的用户角色,以用户角色为划分维度进行调研。因为后台产品不同于前端,不同的用户角色需求差异很大,甚至风马牛不相及,而每种角色对应的用户都是这个系统的目标用户,并不存在所谓的核心用户和潜在用户一说,这些用户都是重要的,都需要满足他们的需求。例如,使用芒果TV后台管理系统角色包括运营、产品经理、公司管理者、审核员。

第二步:需求调研

调研方式——深度访谈

与前端产品不同,后台产品的用户在现实生活中离我们很近,很容易就能接触到,这个时候就不要用调查问卷这种大覆盖面的方式了,一是用户基数没有那么大,二是后台需求基本不需要做定量分析,无需通过这种方式去挖掘需求。所以直接与用户交流、访谈是最快速有效的方式;

调研对象——关键人

我们的访谈对象,需要尽可能满足资深、直接使用、有话语权三个条件,因为这种关键人所提出的需求会更加全面、具体且有深度,能够清楚的解释为什么要有这个功能,如果没有会出现什么后果,还能巴拉巴拉一堆历史故事,这种用户就是完美的访谈对象。这些被伤害过的人,知道心痛的滋味;

第三步:建立需求池

根据访谈内容,建立需求池。例如,在对运营、产品经理、公司管理者、审核员访谈后,建立了以下表格

后台产品设计系列:产品设计方式(二)

(3)结构设计

将调研后的需求进行初步筛选过滤后,需要根据确定、高优先级的需求,归纳这一期后台所需实现的功能模块。

做功能模块划分,需要秉持一个重要原则:一个角色,一个模块,完成一件事。也就是一个具体的角色,能够在一个功能模块中完成他想完成的任务。原因主要是以下两点:

降低用户记忆成本,提升操作体验。你绝对不想为了做一件事,要在多个模块跳转、多个页面点击吧,这个看起来对前端产品再正常不过的要求,后台经常没有达到;

便于权限区分。做系统产品,权限划分永远是重点关心的,将一个角色要进行的操作单独作为一个模块或模块下的子栏目,方便做权限设置;

同样,划分模块后进行栏目划分,然后按照操作流程,从上至下排列,就能得到以下产品结构图:

后台产品设计系列:产品设计方式(二)

至此,简单系统的产品需求设计阶段就告一段落了,后续步骤,且看下回分解。但既然说这种方式只适用于Easy模式,那一定是有原因的。

4、不足

这种设计方式,用开发的行话说,是一种面向过程的设计方式。这种方式有一个专有名词——贫血模型。

贫血模型有以下几大致命缺点:

创建的对象不准确,直接影响产品和开发对业务的正确把握和扩展;

业务逻辑分散,业务难以复用;

业务间耦合度高,迭代及维护成本极高;

名词定义不一致,开发与业务出现沟通问题。

二、复杂系统设计方式——领域驱动设计

为了解决上述问题,同时应对复杂的系统产品,就需采用领域驱动设计(Domain-driven design,以下简称DDD)模式。

1、概念

领域驱动设计,是指在一个具体的领域中,一种面向对象的设计方式。例如,我们要做一个更大的芒果TV后台管理系统,以满足更多角色的更多需求,那么这个系统就属于一个具体的领域——视频娱乐领域。在这个领域中,包含影片、演员、订单等对象,这些对象就是我们要面向的设计目标,而非直接根据需求做设计。

2、流程

后台产品设计系列:产品设计方式(二)

3、流程拆解

在这种方式的流程中,增加了“建立领域模型”和“系统划分”两个环节,其他环节与RDD相同,就不再赘述,现针对新增的两个环节做说明。

(1)建立领域模型

此处的领域模型,是一种简化后的E-R图。E-R图是后台开发在数据库设计中通常会用到的一种模型,用来表示实际业务中各个实体及其关联关系,核心三要素是实体、联系、属性。如下图中,长方形体现的就是实体,也就是实际业务中的各个概念;椭圆形体现的是实体包含的属性,类似概念下的各个字段,菱形体现的是实体间的关系。

后台产品设计系列:产品设计方式(二)

当在需求设计阶段时,并不需要像做数据库设计那么复杂的模型,我们需要创建的领域模型,就是要根据实际业务,展现全部的实体及其关联关系,无需属性,避免在规划阶段陷入过深的细节。

第一步:与领域专家一起,梳理实体

领域专家,是指对这个领域非常熟悉的人,可以是业务人员、老板、产品经理等任何角色。这个专家对领域内的各种业务场景和各种业务规则非常清楚,有能力表达出系统该做成什么样子,有哪些核心业务关注点。

在本文的例子中,我们梳理的实体包括用户、影片、栏目、推荐位、演员、导演、订单、运营活动等,在这些实体概念里,就是一个个的具体对象,例如演员里有刘亦菲、刘德华。每个实体要求能用文字精确的、没有歧义的描述其涵义以及包含的主要信息,同时每个实体定义要完全独立,概念上不能有交叉或模糊的界线。

第二步:梳理关联关系

确定了实体,就需要建立实体的联系,标识实体间的对应关系。

实体联系:

直接关联:实体间直接关联,在系统中需手动建立联系的实体;

间接关联:根据实体图,能够通过间接关系找到唯一对应实体。通过间接关联关系,往往可以通过多条路径找到同一具体实体,如果出现不同路径找到不同目标,那就需要重新检查关联关系是否正确;

对应关系:

1对1(1:1):1对1关系是指对于实体A与实体B,A中对象至多与B中一个对象有关系;反之,在实体B中的每个对象至多与实体A中一个对象有关系;

1对多(1:N):1对多关系是指实体A与实体B中至少有N(N>0)个对象有关系;并且实体B中每一个对象至多与实体A中一个对象有关系;

多对多(M:N):多对多关系是指实体A中的每一个对象与实体B中至少有M(M>0)个对象有关系,并且实体B中的每一个对象与实体A中的至少N(N>0)个对象有关系。

关联建立原则:

关联尽量少。实体间的复杂的关联容易形成实体关系网,这样对于我们理解和维护单个实体很不利,同时也很难划分实体与实体之间的边界;

化繁为简。在建立关联时,需要挖掘关联关系的限制条件,如果存在,那么最好把这个限制条件加到这个关联上,往往这样的限制条件能将关联化繁为简,即可以将多对多简化为1对多,或将1对多简化为1对1;

第三步:走查场景,修改领域模型

关联关系、对应关系是否正确?

分析关联,通过对业务的更深入分析,明确关联的方向或者去掉一些不需要的关联;

这些实体及关联关系能否全部覆盖这些业务场景?

后台产品设计系列:产品设计方式(二)

(2)系统划分

为了解决在方法一中遇到的问题,需要采用微服务的思想,根据实体间的联系强弱,以实体为对象,划分到不同系统中。

后台产品设计系列:产品设计方式(二)

将每个系统独立开(解耦),系统与系统间通过接口调用数据,公共模块单独作为一个系统(如此处用户管理系统),每个系统都有各自的三层结构(详见上篇)。

三、两种设计方式总结

介绍完两种不同的需求设计方式,再来看这两种方式的联系。

1、如何选取

后台产品设计系列:产品设计方式(二)

这个图表示随着系统复杂程度增加,两种设计方式开发时间的变化趋势。可以看出,但产品复杂度低时,RDD的模式会很快捷,这个就非常适合初创型、小型的系统设计,当产品复杂到一定程度时,RDD的开发时间会指数上升,而DDD的模式则始终比较平稳,所以DDD会适合复杂的系统设计。

2、两种方式中的实体

上篇说到,后台三层结构中,业务层也叫领域层,其实和领域模型中的领域是一样的。RDD在数据库设计时依然需要有E-R图和实体,但产品经理做需求设计时可以不用考虑(当然有资源这样做更好),因为对于简单的后台产品而言,无需在初期理解的那么复杂,同时对很多从前端做到后台的产品而言,不用学习领域模型相关的内容。

那么在DDD中,对于一个已经对业务非常熟悉的产品经理,可以直接跳过实体,进行系统的微服务设计。但需要注意一个实体在多个系统都存在的情况,这个时候就会导致同一实体的数据,存储在多个系统中,无论是数据管理还是调用,都会存在问题。所以老司机们还是要划分清实体,只是不用那么细致。

3、两者关系

写到这里,大家其实就会发现,这两种方式其实是一种包含关系。对于复杂系统而言,需要先采用DDD模式进行前期需求设计及系统划分,当微服务化后,每个子系统也就变成了简单系统,也就可以采用RDD的模式了。

原创文章,作者:研究院精选,如若转载,请注明出处:https://www.pmtemple.com/academy/8380/

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
研究院精选的头像研究院精选认证编辑
上一篇 2018年7月23日 上午12:00
下一篇 2018年9月9日 上午10:47

相关推荐

发表回复

登录后才能评论
微信公众号
微信公众号
edgesensor_high 小程序
小程序
分享本页
返回顶部