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

从零开始学运营,10年经验运营总监亲授,2天线下集训+1年在线学习,做个有竞争力的运营人。了解详情

上篇《后台产品设计系列:认识后台》,笔者对后台(系统)产品做了简单的介绍,让大家有一个初步认识。本篇文章,将以视频产品后台为例,介绍简单系统和复杂系统的不同需求设计方式。

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

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

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

1、概念

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

2、设计流程

3、流程拆解

(1)明确目标

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

(2)需求分析

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

第一步:穷举用户角色

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

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

第二步:需求调研

调研方式——深度访谈

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

调研对象——关键人

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

第三步:建立需求池

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

(3)结构设计

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

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

  1. 降低用户记忆成本,提升操作体验。你绝对不想为了做一件事,要在多个模块跳转、多个页面点击吧,这个看起来对前端产品再正常不过的要求,后台经常没有达到;
  2. 便于权限区分。做系统产品,权限划分永远是重点关心的,将一个角色要进行的操作单独作为一个模块或模块下的子栏目,方便做权限设置;

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

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

4、不足

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

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

  1. 创建的对象不准确,直接影响产品和开发对业务的正确把握和扩展;
  2. 业务逻辑分散,业务难以复用;
  3. 业务间耦合度高,迭代及维护成本极高;
  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. 关联尽量少。实体间的复杂的关联容易形成实体关系网,这样对于我们理解和维护单个实体很不利,同时也很难划分实体与实体之间的边界;
  2. 化繁为简。在建立关联时,需要挖掘关联关系的限制条件,如果存在,那么最好把这个限制条件加到这个关联上,往往这样的限制条件能将关联化繁为简,即可以将多对多简化为1对多,或将1对多简化为1对1;

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

  1. 关联关系、对应关系是否正确?
  2. 分析关联,通过对业务的更深入分析,明确关联的方向或者去掉一些不需要的关联;
  3. 这些实体及关联关系能否全部覆盖这些业务场景?

(2)系统划分

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

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

三、两种设计方式总结

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

1、如何选取

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

2、两种方式中的实体

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

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

3、两者关系

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

相关阅读

后台产品设计系列:认识后台(一)

 

本文由 @Z. Fly 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
6人打赏
评论
欢迎留言讨论~!
  1. 我先给你打赏个红包了来,感谢你的分享! :!:

    回复
    1. 谢谢 :|

      回复
  2. DDD领域模型中的关联关系对最终系统的划分的核心依据是什么?是1:M和1:N的关联关系的划分在一个系统里?1:1关联关系划分在一个系统?是这样划分的吗?

    回复
    1. 系统的划分是将实体划分到不同系统中,这个划分依据是根据需求和实体来定的,跟关联关系无关。这种划分需要站在需求和用户的角度,按功能的远近、逻辑上的先后顺序、实体概念联系强度这些来划分

      回复
  3. 是我太笨了吗?有点糊涂。

    回复
    1. 额,你是指那一块?

      回复
  4. 偏项目一些

    回复
    1. 无论是做To B的产品还是做公司系统,其实都要掌握

      回复
  5. 按角色划分和按领域划分的道理我都明白,可是实体和属性那里不太懂,为什么要梳理实体并建立关联关系?

    回复
    1. “Java语言是一种面向对象的开发语言”,这句话不知道你有没有听说,这个可以跟你们后台小哥聊聊。理解面向对象,就好理解实体了。这个其实就是用开发的思想来做系统,很多没有后台开发背景的产品经理做后台、To B产品之所以很困难,第一个难点其实就是这里

      回复
    2. 第二种方法中,最关键的是第二步,即【根据实体间的联系强弱,以实体为对象,划分到不同系统中】。那么梳理【实体之间的联系】确实是有用的,可以确定两个实体之间是强相关还是弱相关,根据相关度划分领域。

      那么列举【属性】又有什么用呢?只要梳理实体联系就好了吧~~~ :smile:

      回复
    3. 对于产品经理梳理需求来说,不需要列举属性的,这个文中已经提到了。这里梳理实体间的联系对后面做详细需求设计和原型设计有很大作用,后面文章会讲 :oops:

      回复