邱岳的产品手记
邱岳
无码科技产品经理,公众号二爷鉴书作者
33999 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
邱岳的产品手记
15
15
1.0x
00:00/00:00
登录|注册

23 | 产品经理的图文基本功(下):产品图例

逻辑表达
UML标准
用例粒度划分
作用
UML标准
作用
风险
概念实体状态
重要性
时序图
适用场景
描述
重要性
UML类图和E-R图
概念梳理过程
目的
产品经理的基本功
工具箱
辅助思维框架
用例图
状态图
流程图/泳道图/时序图
概念模型图
应用场合和特点
模式
总结
图例
产品文档
产品经理的丹青手:图文基本功(下)

该思维导图由 AI 生成,仅供参考

“世间无限丹青手,一片伤心画不成。”——唐·高蟾
上次我们讲到了一些产品文档的模式,以及应用场合和特点,这部分内容实践性挺强的,好多人经常会到处找到一个“好的文档”模板,其实模板根本没那么重要,了解文档目的,能把逻辑表达清楚才是第一要务,只要你能表达清楚,不写文档,拍个短片也可以。所以跟我们之前说到一些工具软件一样,不要本末倒置。
今天我们接着产品文档的话题,产品文档中经常要用到各种图例,我们来介绍几种常用的图例,以及他们的功能特点。

1. 概念模型图

概念模型的目的是要将产品中的业务概念分门别类的整理出来,并在同时确定概念之间的关系。在复杂业务的系统中,这一工具非常重要,它是一切业务流程的基础。
抽取概念模型的过程并不复杂,但需要一些时间,我们可以首先去尽可能详细地描述系统各种场景和逻辑,然后注意描述中的所有名词。比如我们说用户可以创建账号、设置用户名,登录系统,系统管理员为其指定一个角色。
这样简单的一句话中就包含了用户、账号、用户名、系统、系统管理员和角色等名词,我们把这些名词不断地取出来,去分析他们之间的关系。
比如一个用户和账号之间是对应关系,这是就要去确定对应方式,是一个用户只能有一个账号,还是可以有多个账号,或多个用户共用一个账号。基于这个关系,可能就能长出用户识别、同账号登录互踢或子母账号管理的需求。如果再考虑账号和角色之间的关系,可能就是一套完整的权限系统。
而有的名词可能是其他名词的属性,比如上面提到的“用户名”便是账号的属性,属性跟概念之间也会有对应关系,比如是否唯一,是否可变,是否是与其他概念产生关系的“键”等等。技术可能会据此去做系统设计。
越是基础的东西,在这时越需要谨慎设计,比如有多少系统错将用户名作为主键,导致未来有用户需要更换用户名时无比复杂(我职业生涯中至少遇到过两次)。
所以概念模型的梳理最大的作用是来回答系统的根本性问题,从而可以帮助工程师设计数据结构,也帮助业务找到设计出发点。一个产品的架构扩展潜力,很多时候就受限于概念模型的设计。比如订单管理系统在最初设计中,订单和标的之间的关系被设为一一对应,那将来要多产品搭售的时候,整个产品技术团队就会无比痛苦。
概念模型图通常是用 UML 中的类图或传统的 E-R 图的结构来绘制,突出概念和关系,去询问自己每个概念实体和另外一个概念实体之间可能有的关系。
也有人会说,这样的概念模型应该是工程师在做概要设计或数据结构设计时才应该考虑的,产品经理考虑早了点。
我不这么认为,我认为这是一个产品经理和工程师需要共同关注的地带,甚至产品经理的职责更重,因为它背后更多的是业务上的前瞻、取舍和判断。工程师在设计中会讲 DDD、OOD,进而去理解和重现业务架构模型,那产品经理就更应该把业务背后的逻辑关系抽丝剥茧整理清楚。
我们在招产品经理时会要求产品经理具备“抽象和建模的能力”,其实指的就是抽象概念模型的能力。有些公司甚至会在复杂系统中设立“业务架构师”岗位,专门做这件事情,有点像传统软件行业里的“系统分析师”。
概念模型有一点偏技术,又不是一个酷炫的东西,很难拿出来做展示,而且它的作用不那么立竿见影,所以没有得到应有的重视。但它在业务逻辑复杂的产品设计中确实非常重要,希望你动手去尝试一下,挖掘它的价值,为自己所用。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了产品经理在产品文档中常用的图例及其功能特点。首先,概念模型图用于整理业务概念和确定它们之间的关系,对于复杂业务系统至关重要。其次,流程图/泳道图/时序图用于描述业务系统的流程和角色之间的关系,以及业务流程的逻辑。最后,状态图用于表达系统中各个概念实体的状态及状态之间的转变。文章强调了概念模型的重要性,并建议产品经理在产品设计中关注概念模型的设计,以帮助工程师设计数据结构和业务找到设计出发点。同时,建议产品经理将核心业务对象的状态画成状态图,以避免描述不清导致系统出现不必要的脏状态。总的来说,本文通过介绍不同类型的图例及其应用,为产品经理提供了在产品文档中运用图例的指导和建议。另外,文章还提到了用例图的重要性,用例图可以让读者一眼看到一个产品或项目需要实现的用户价值和可能的规模,以及利用用例来组织产品文档的结构。同时,文章也探讨了用例粒度的问题,强调了根据系统特点来划分用例粒度的重要性。最后,文章指出这些图例和工具可以辅助产品经理找到思维框架,用完整而有条理的逻辑去描述业务,是产品经理的基本功之一。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《邱岳的产品手记》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(18)

  • 最新
  • 精选
  • 对于这类,如概念模型图的话,二爷有没有什么拓展阅读呢?若有的话贴一下,谢谢

    作者回复: DDD 领域驱动设计

    2018-02-06
    1
  • 从事过一些传统软件工程设计、开发和管理的工作,但对互联网行业了解有限,听了这几日的课后,对相通的一些知识点颇有些感触,但信马由缰还望请指正。听闻互联网产品经理的角色是来源于P&G等外企的设定,猜想在充分的市场竞争中,市场研究特别是对用户的研究变得越来越重要,所以产品经理的一个定位应是类似于传统软件项目立项的职责,回到要做什么和为什么做的问题;另一方面,产品经理作为承上启下的角色,还承担了传统软件工程中业务梳理和需求分析设计的职责,这样也使得工程师的角色定位更清晰,可以更多的关注于技术设计、实现与优化。如果相互配合得好的话,是有利于在激烈市场竞争情况下团队分工合作的。

    作者回复: 从传统软件行业的角度来推,产品经理确实有点像项目经理和需求分析师,你分析的两方面工作都对,其实我刚入行的时候第一个头衔也是需求分析师。 不过因为互联网行业和传统软件行业有不少本质差异,所以我更建议尽可能从互联网行业本身去理解这个岗位,而不是借由横向的类比。

    2018-01-11
    1
  • Zach
    二爷可否细说一下为什么不能把用户名作为主键?谢谢!

    作者回复: 因为会变

    2018-08-03
  • 张星彩
    用户名作为主键应该就是唯一属性时,应该不允许用户更改吧;其次如果加一个用户ID,作为唯一属性,这样就可以更改用户名了吧。想请教下两个问题,有看到知乎可以改用户名,但是180天内只能修改一次,是出于什么考虑的?还有就是什么样的数据需要有唯一属性?

    作者回复: 用户名千万不能做主键啊!有业务含义的字段最好都不要做键;改名限制应该是出于社区稳定的业务考虑。

    2018-01-19
    2
  • GeekAmI
    所以,二爷有什么和此篇文章相关的书籍推荐?
    2018-01-12
    17
  • 晓小
    文档和画图是产品经理的基本功,这些内容对每一位产品经理都非常实用。 流程图、泳道图和时序图在实际工作中用到,但遇到比较复杂的流程时,经常感觉画不好。 光看文字描述和简单的案例感觉还没能真正吸收精髓,很希望二爷针对这三种流程图,能够分享一些更复杂的案例出来学习。
    2018-01-13
    12
  • 发条
    有点缺案例,不明所以可
    2018-07-29
    6
  • 听天由己
    今天学习完才发现很多知识一定要主动去了解并且实践,概念图、时序图、用例图这些平常真的运用得太少,而一旦出问题却是后患无穷。 我理解的产品图例或是文档本质上是为了大家能够统一产品认识,明确需求和产品表现,再去分工合作。关于工具,二爷的理念很赞,不管黑猫白猫,抓到老鼠就是好猫。我们要做的就是不断扩充自己的兵器库,然后信手拈来。 给自己定个目标,下次得聊聊这些不懂的概念。
    2018-01-11
    6
  • 李晓凌
    用例分析既是非常好的需求分析方法,又能起到需求/功能文档撰写大纲的作用,能做到让文档表达更清晰,有逻辑有层次。仅要讲清楚用例估计三个这样的篇幅都讲不完吧,这里最多只是个线头
    2018-08-06
    4
  • Dylan
    梳理逻辑,这些图必不可少。其中老师文中讲的状态图,我觉得对我来说是非常受用的,把初始两种状态先列出来,而后去考虑他们中间可能发生的事情,这样避免有忽略的行为以及异常情况。
    2018-07-02
    1
收起评论
显示
设置
留言
18
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部