产品经理必须懂的—常用图表以及使用场景

2 评论 4010 浏览 28 收藏 13 分钟

编辑导语:初级产品经理在接到需求时,当我们无法把比较抽象的概念用文字表达出来时,可以转化为图表描述出来。借此,作者讲解了产品经理常用的几大图表类型以及图表的使用场景,分享给你。

背景:

初级产品经理在接到需求时,不能够将抽象的概念,用文字表达出来,而是需要用一些计算机的行话(大家都理解的术语或者图表),将抽象的概念,通过图形、图表描述出来。下面,将会讲解产品经理常用的图表类型,以及图表的使用场景。

一、ER 图

ER(Entity Relationship)图是一种描述实体对象(Entity) 之间关联关系(relationship)的经典图表,由科学家Peter chen 于1976年发明,最早被用于关系型数据库。

ER 图是产品经理在工作中,经常会打交道的一种图表,ER 图的呈现方式有很多种,比较常用的是使用UML 中的类图(class diagram)所规定的符号标记规范来进行描述和呈现。

下面的所有例子,都是通过Process On 这个工具来进行操作的。

一个ER 图中,每一个大方框代表一个对象,方框中的第一行描述的是对象的名称,第二行描述的是对象中的数据字段,大方框和大方框之间的连线,表示实体之间的关系,如果新手产品经理,不了解什么是“关系”,可以看看之前这篇文档 http://www.woshipm.com/pmd/5176906.html

多对一关系ER 图示例:

产品经理必须懂的 -常用图表以及使用场景

两个ER图使用实线链接,实线标注N :1,表示着多对1 对关系,即 多个学生对应着一个教室。

如下图所示,则为一对一关系ER图,表示着一个公民,必定对应着一张身份证,一张身份证,也对应着一个公民。

产品经理必须懂的 -常用图表以及使用场景

一对一关系ER 图

1. 使用场景

我们在产品设计初期,我们就要想好这些实体类型之间的关系,如果你现在做的产品,经常出现逻辑混乱,功能重复的问题,以后分解需求以后,可以先从分析ER 图开始。除此之外,产品经理在输出PRD文档时,如果使用文字,以及图表,不能够很好的体现需求中的实体关系,这时候,我们就可以考虑使用ER 图来进行表示。

通常产品经理,只要掌握一对一关系,一对多关系,多对多关系,那么就可以解决我们在工作中遇到的绝大多数实体问题了。

2. 流程图

国际标准组织ISO(International Standard Organization)在1970年定义了流程图的基本符号规则,方便不同背景的读者阅读理解,建议尽量采用简单的绘图规则,例如,只使用开始,结束,执行,判断这四种符号来绘制流程图。

(1)流程图的符号要求

流程图看起来很容易画,但是想要画好、画标准一张流程图,还是需要一些练习的,下面这张图介绍了画流程图的一些特定符号,我们一定要记清楚每个符号的含义,在画流程图的时候可不要弄错了。

下面是几个重要且最常用的符号,需要牢记!

产品经理必须懂的 -常用图表以及使用场景
(2)流程图的三大结构

流程图由三大结构构成,这三大结构分别为顺序结构、选择结构和循环结构,这三个结构构成了流程执行的全过程。

① 顺序结构

在顺序结构中,各个步骤是按先后顺序执行的,这是一种最简单的基本结构。如图,A、B、C是三个连续的步骤,它们是按顺序执行的,即完成上一个框中指定的操作才能再执行下一个动作。

产品经理必须懂的 -常用图表以及使用场景

② 选择结构

选择结构又称分支结构,选择结构用于判断给定的条件,根据判断的结果判断某些条件,根据判断的结果来控制程序的流程,判断的流程可以有

产品经理必须懂的 -常用图表以及使用场景

③ 循环结构

循环结构又称为重复结构,就是流程在一定的条件下,反复执行某一操作的流程结构。循环结构下又可以分为当型结构(when)和直到型结构(while)。

当型结构:该结构可以理解为,判断所给条件p是否成立,当P成立,则执行A(步骤);再判断条件p是否成立;当P成立,则又执行A,若此反复,当条件p不成立时,则跳出循环。

产品经理必须懂的 -常用图表以及使用场景

直到型结构:先执行流程A,再判断所给条件P是否成立,若p不成立,则再执行A,如此反复,直到P成立,该循环过程结束。

产品经理必须懂的 -常用图表以及使用场景

流程图是产品经理必须掌握的一种图表,当产品经理拿到一个涉及跨模块,跨部门,跨角色协作的需求时,使用流程图来描述业务的过程,以及用户的操作过程,比做高保真的原型要简单清晰。如下图所示,就可以很清晰的描述每个角色,在流程中,应该要做什么事。

产品经理必须懂的 -常用图表以及使用场景

3. 状态机图(State Machine Diagram)

在面对业务流程时,初级的产品会使用文字去描述状态之间的流转,如我一个订单的开始状态,到订单的确定状态,再到订单的结束状态,这种描述是非常难明白的,我们需要通过状态机图,给你的小伙伴们介绍各种状态。状态机图也叫有限状态机图(Finite State Machine Diagram),是一种描述所有状态以及状态之间流转规则的图形。

源状态 (Source State):受转换影响的状态;如果对象处于源状态,则当对象接收到转换的触发事件并且满足保护条件(如果有)时,可以触发传出转换。

目标状态 (Target State):过渡完成后处于活动状态。

在软件设计领域,“状态”在业务系统中,无处不在:订单要有状态,账号要有状态,门店要有状态,可以说任何对象都有状态。状态机要注意以下几点:

  1. 状态值是有限的集合,状态的所有枚举值,必须涵盖所有实际可能的情况
  2. 状态值之间要互斥,不能出现二义性
  3. 为了更准确的描写状态,状态还能有子状态,如订单的“已取消”,可以对应为的子状态为“客户取消”,“商家取消”,“系统取消”
  4. 状态应该是能持续一定时长的,而不是很快就会结束的瞬时态,如订单的状态可以是“待发货”,“待评价”,但不能是“发货中” – 可以是等待xxx 发货,“评价中” — 可以是等待xxxx 评价。

二、使用场景

当产品经理接收到的需求中,一个实例,可以承载多种操作,以及存在多个状态时,那么这个prd 文档,就必须包括状态机图,否则这个prd 文档是很难描述清楚实体之间的状态关系的。

下图的状态机图,则是描述了一个订单的复核,待执行,中间态,以及完结态时的状态流转。使用状态机图比用文字,要简单明了。

产品经理必须懂的 -常用图表以及使用场景

三、用例图

是用户与系统交互的最简单表示形式,展现了用户和与他之间相关的用例之间的关系,通过用例图,人们可以获取系统不同种类的用户和用例,简单说就是某个角色或者用户在不同场景下,可以做什么,实际工作中,我们会用到简单的用例图,复杂的用例图,比较少接触到。

尽管用例本身会涉及大量细节和各种可能性,用例图却能提纲挈领地让人了解系统概况。它为“系统做什么”提供了简化了的图形表示,因此被誉为“搭建系统的蓝图”。

由于其简单纯粹的本质,用例图是项目参与者间交流的好工具。用例图的画法是对现实世界的一种刻画,可以让项目参与者明白系统要做成什么样。

产品经理必须懂的 -常用图表以及使用场景

1. 用例(Use Case)——用例就是外部可见的系统功能,对系统提供的服务进行描述。用椭圆表示

产品经理必须懂的 -常用图表以及使用场景

2. 子系统(Subsystem)——用来展示系统的一部分功能,这部分功能联系紧密。

产品经理必须懂的 -常用图表以及使用场景

用例图涉及的关系,如关联,泛化,包含,拓展等,在这里就不一一展开,有需要的小伙伴,可以去百度对应的资料。

使用场景:

产品经理使用用例图的场景一般是有两种。

第一种是描述用户的行为,通常,我们会使用用例图,描述这个用户在模块上可以做的操作。

第二种是搭配ER 图,描述实体的操作时,我们也会用用例图,去描述实体可以支持的操作。

产品经理必须懂的 -常用图表以及使用场景

用户操作用例图

产品经理必须懂的 -常用图表以及使用场景

学生实体用例图

 

本文由 @danny要做好产品 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自pexels,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
1人打赏
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 非常好

    回复
    1. 谢谢老铁,一起加油

      回复