邱岳的产品手记
邱岳
无码科技产品经理,公众号二爷鉴书作者
立即订阅
9928 人已学习
课程目录
已完结 48 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 | 产品经理的世界没有对错
免费
01 | 验证码是个好设计吗?
02 | 产品经理工具指南
03 | 产品案例分析·Trigraphy的设计哲学
04 | 如何当好AI时代的产品经理?(学习篇)
05 | 如何当好AI时代的产品经理?(实践篇)
06 | 产品案例分析 · The Guardian的文本之美
07 | 关于需求变更(上):需求背后的需求
08 | 关于需求变更(下) : 化变更于无形
09 | 产品案例分析:Hopper的“人工智能”
10 | 产品被抄袭了,怎么办?
11 | 如何借鉴灵感?
12 | 产品案例分析:LabRdr的设计实验
13 | 无用却必要:产品规划(上)
14 | 留白与节奏:产品规划(下)
15 | 产品案例分析:Mimo与Learn Python的导学之趣
16 | 在内部产品中找到产品经理的价值
17 | 产品经理如何获得非权力性的影响力?
18 | 产品案例分析:WWF Together的情怀设计
19 | 产品经理如何与开发打交道(上):打破思维的边界
20 | 产品经理如何与开发打交道(下):合作与共赢
21 | 产品案例分析:Fabulous的精致养成
22 | 产品经理的图文基本功(上):产品文档
23 | 产品经理的图文基本功(下):产品图例
24 | 产品案例分析:PathSource的混乱与直观
25 | 产品世界的暗黑模式:操纵的诱惑
26 | 写好产品文档的诀窍
27 | 产品案例分析:Quartz&Hooked的对话式交互
28 | 产品分析的套路(上):谁是利益相关者?
29 | 产品分析的套路(中):解决什么问题?
30 | 产品案例分析:Primer的扑克牌交互
31 | 产品分析的套路(下):如何出解决方案?
32 | 从受众规模、需求频率和强度出发:排定需求优先级的方法(上)
33 | 产品案例分析:Arts & Culture 的架构之美
34 | 价值曲线分析:排定需求优先级的方法(下)
35 | 答疑时间:关于产品经理的12个问题
36 | 产品案例分析:解读知识星球
37 | 如何做好需求评审(上):需求评审不只是一次会议
38 | 如何做好需求评审(下):在评审中控住全场
39 | 产品案例分析:SeatGeek的订票设计
40 | 新年给产品经理的几碗鸡汤
41 | 产品经理的项目管理心得
42 | 产品案例分析:Unread的阅读体验
43 | “玩”的力量:从游戏设计中学习产品设计(上)
44 | “玩”的启示:从游戏设计中学习产品设计(下)
45 | 产品案例分析:Chartistic的“复杂”图表
尾声:你的快乐是哪一种
【第二季回归】二爷归来,再次扬帆起航
邱岳的产品手记
登录|注册

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

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

1. 概念模型图

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

精选留言(17)

  • GeekAmI
    所以,二爷有什么和此篇文章相关的书籍推荐?
    2018-01-12
    10
  • 晓小
    文档和画图是产品经理的基本功,这些内容对每一位产品经理都非常实用。
    流程图、泳道图和时序图在实际工作中用到,但遇到比较复杂的流程时,经常感觉画不好。
    光看文字描述和简单的案例感觉还没能真正吸收精髓,很希望二爷针对这三种流程图,能够分享一些更复杂的案例出来学习。
    2018-01-13
    9
  • 发条
    有点缺案例,不明所以可
    2018-07-29
    3
  • 刘祯
    今天学习完才发现很多知识一定要主动去了解并且实践,概念图、时序图、用例图这些平常真的运用得太少,而一旦出问题却是后患无穷。

    我理解的产品图例或是文档本质上是为了大家能够统一产品认识,明确需求和产品表现,再去分工合作。关于工具,二爷的理念很赞,不管黑猫白猫,抓到老鼠就是好猫。我们要做的就是不断扩充自己的兵器库,然后信手拈来。

    给自己定个目标,下次得聊聊这些不懂的概念。
    2018-01-11
    3
  • 李晓凌
    用例分析既是非常好的需求分析方法,又能起到需求/功能文档撰写大纲的作用,能做到让文档表达更清晰,有逻辑有层次。仅要讲清楚用例估计三个这样的篇幅都讲不完吧,这里最多只是个线头
    2018-08-06
    1
  • 对于这类,如概念模型图的话,二爷有没有什么拓展阅读呢?若有的话贴一下,谢谢

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

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

    作者回复: 从传统软件行业的角度来推,产品经理确实有点像项目经理和需求分析师,你分析的两方面工作都对,其实我刚入行的时候第一个头衔也是需求分析师。

    不过因为互联网行业和传统软件行业有不少本质差异,所以我更建议尽可能从互联网行业本身去理解这个岗位,而不是借由横向的类比。

    2018-01-11
    1
  • 龙猫
    我们准备做新的项目了,是从0开始,我觉得倒是可以试试这些文档或工具。感受一下它们的作用和好玩之处。既可以对产品使用工具,也可以对团队/工作节奏使用工具。
    2019-05-07
  • 李沛欣
    怎么做项目,从产品经理的视角来看,也有很多可资借鉴的东西。
    2019-02-09
  • 北冥Master
    有时间让你写这些文档?事后补的没有太大意义吧
    2018-11-30
  • javaadu
    这些东西我们这边是开发做的
    2018-08-24
  • Zach
    二爷可否细说一下为什么不能把用户名作为主键?谢谢!

    作者回复: 因为会变

    2018-08-03
  • Dylan
    梳理逻辑,这些图必不可少。其中老师文中讲的状态图,我觉得对我来说是非常受用的,把初始两种状态先列出来,而后去考虑他们中间可能发生的事情,这样避免有忽略的行为以及异常情况。
    2018-07-02
  • 追风筝的小蜜蜂
    ddd领域驱动设计无技术基础可以读吗,
    2018-05-04
  • 123456
    时序图经常用到,感觉对梳理流程特别有用,尤其是多系统之间协作,用例、状态图倒用的少,主要还是没理解透他们的用法与背后的思想,今天看到二爷的文章受益匪浅,感谢🙏
    2018-01-26
  • 张星彩
    用户名作为主键应该就是唯一属性时,应该不允许用户更改吧;其次如果加一个用户ID,作为唯一属性,这样就可以更改用户名了吧。想请教下两个问题,有看到知乎可以改用户名,但是180天内只能修改一次,是出于什么考虑的?还有就是什么样的数据需要有唯一属性?

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

    2018-01-19
  • 时间之树
    理念需要工具来实现,工具反过来也会影响理念的形成。前辈们总结出来的方法和验证过的工具,作为产品经理,可以不用,但不能不会。
    2018-01-12
收起评论
17
返回
顶部