极客时间已完结课程限时免费阅读

23 | 产品经理的图文基本功（下）：产品图例

23 | 产品经理的图文基本功（下）：产品图例-极客时间

23 | 产品经理的图文基本功（下）：产品图例

2018-01-11 邱岳 来自北京
《邱岳的产品手记》
课程介绍

讲述：邱岳

时长13:51大小4.76M

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

1. 概念模型图

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

2. 流程图 / 泳道图 / 时序图

所有的业务系统都有流程，我们的文档中一定会或多或少涉及“流程图”，最基础的流程图是面向过程的描述性流程图，有些图形规范，比如开始结束是圆角矩形，数据操作是矩形，判断是菱形等等，还有些其他的一些形状代表的意思。但我很少见过真的完全按照标准格式画的，基本就用到矩形和菱形，有时为了加以区分会有颜色上的差异。
但如果流程比较复杂，涉及的角色或子系统、模块多起来的时候，传统的流程图就会开始捉襟见肘，应接不暇；所以除非描述单一功能模块内部的流程外，我一般很少会用传统流程图。而是用泳道图和时序图。
泳道图很好理解，就是在传统的流程图上加入角色，因为每个角色之间是平行的，从图上看起来每个角色就像是一个泳道。通过这些泳道去标识每个动作是由哪个角色（或子系统）做出的。这种图形一般用于比较宏观的流程描述中，比如划分各业务角色之间大的流程步骤，或描述子系统之间的边界和职能。
当进一步细致到具体的用例或方法时，则可以用时序图，时序图也是 UML 标准里面的一种图示，也是面向对象设计的一种工具，本来是工程师用，后来被产品经理借来描述业务流程。
时序图整体看起来像很多根竹签，每根竹签代表用户、业务对象、子系统甚至“时间”，凡是可以向其他竹签发出请求的都可以表示为一根竹签，而有些过程是需要定时执行的，在时序图上，我们就可以将其表示为“时间”。每根竹签向自己或其他竹签发起请求，然后响应请求的竹签则根据这个请求开始一个过程，这个过程可以是同步，也可以是异步，可以是判断过程，也可以是循环。
总之时序图可以表达的逻辑非常丰富，能将复杂逻辑梳理得很有条理，而且读图成本很低，既能一目了然，也有引导按图索骥。我有一段时间非常迷恋时序图，连项目管理中的不同角色的流程安排都用时序图表达，强烈建议你深入学习一下，把它用到你的流程分析中。

3. 状态图

系统中所有的概念实体都应该有状态，用户有状态，订单有状态，账单也有状态。在数据结构设计时，经常会在业务对象表里加一个“状态”字段。产品经理有时不会将状态显式地单独表达出来，而是让工程师自己通过读业务逻辑去区分和判断业务对象的状态。
这样的沟通断层会产生一些风险，有时描述同一个状态用了不同的用词，导致工程师记录成了两个状态，比如前一条业务逻辑写的是“完成对账后系统进入休眠状态”，后一条写成了“完成角色更新后系统挂起”，这可能来自于产品经理的不严谨，结果系统里就出来一条没有必要的脏状态。
更吓人的是有时产品经理描述不清，导致本来应该是不同的状态，被开发理解为同一个，未来需要再做拆分时，难上加难。比如用户欠费挂起和用户到期挂起应该分开不同的状态，但产品经理在文档里都写着“挂起”，导致未来给用户开通服务的时候不知道该怎么直接从数据表里区分，还要去关联行为日志的表。
建议产品经理对于比较核心的业务对象，把状态画成状态图，每个节点是一个状态，每两个状态之间是一个行为，描述的是出发状态转变的可能。这么做还有一个好处是，可以帮助你从状态的角度出发，去穷尽所有状态之间可能的变化，保证不会遗漏用例。


4. 用例图

上篇文章我们提到用例文档，这里我们来说说用例图。
用例图是 UML 的标准图示，看起来特别简单，一个火柴人和一些椭圆。每个椭圆是一个用例描述，然后把椭圆和人连起来。用例图复杂起来很复杂，还有扩展点，互相之间的关联包含关系等等。但开始使用它很容易，只用火柴人和椭圆就够了。
那这么简单，甚至有点蠢的图，能干吗呢？首先是可以让读者一眼看到一个产品或一个项目需要实现的用户价值，以及它可能的规模是什么；另外则是可以利用用例来组织产品文档的结构，很容易理解，也容易作为标准来管理进度。
用例图的一个老大难问题是区分用例的粒度，这是个没有唯一答案的问题，同一个人的用力粒度划分标准可能都不同。比如 CRUD （创建、读取、更新、删除）算一个用例，还是四个用例。比如“账户管理”算是一个用例，还是“账户创建”“角色分配”“账户删除”“账户查询”四个用例。这简直是个哲学问题，这么多年我也没能找到一个金标准。
我最喜欢的标准是来自一场 UML 培训，说的是“以卖点作为粒度”，也就是设想你的系统是按功能收费的，你从兜里一个接一个地往外掏用例，每掏一个用户就要付一份钱，你要保证每个用例用户都是愿意买单的，同时，又要保证用例尽量丰富，以求收到足够多的钱。
假设你现在做“极客时间”，你从兜里掏出一个“修改密码”，用户不会认为它是个卖点。但你假设你现在做的是一个复杂的金融保险系统，很可能“修改密码”就会成为一个独立的卖点，所以用例粒度划分一定是因系统而异的。

总结

我们今天从概念模型开始，说到流程图、状态图和用例图，从表面的图讲到图背后的工具和方法，这些东西最主要的作用是可以辅助我们找到思维框架，用完整而有条理的逻辑去把一个业务描述出来。他们就像是工具箱，只有熟悉了这些工具的效用，同时又足够熟悉环境，才知道什么场合拿出哪一样工具是恰当的。
这也是产品经理的基本功，即便用不上，也不要让自己的工具箱里只有单调的几样工具，因为掌握的工具会影响你解决问题的思路，正像那句古话说的，手里拿着锤子，看起来全世界都是钉子。而这些已经被大量的前人应用和雕琢过的工具，自然带着他们的智慧，研究这些工具本身，也是一种对于经验的学习。
今天的分享就到这里，如果你有关于这些图例的具体问题，欢迎留言讨论，我们下次再见。
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 14

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
22 | 产品经理的图文基本功（上）：产品文档
下一篇
24 | 产品案例分析：PathSource的混乱与直观
unpreview
 写留言

精选留言(18)

  • 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
  • 文
    2018-02-06
    对于这类，如概念模型图的话，二爷有没有什么拓展阅读呢？若有的话贴一下，谢谢

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

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

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

    1
  • 种菜的渔民
    2020-07-27
    系统的了解UML视图，可能还是没学到精髓，感觉适用性并不是很强
  • 旺旺
    2019-05-07
    我们准备做新的项目了，是从0开始，我觉得倒是可以试试这些文档或工具。感受一下它们的作用和好玩之处。既可以对产品使用工具，也可以对团队/工作节奏使用工具。
  • 李沛欣
    2019-02-09
    怎么做项目，从产品经理的视角来看，也有很多可资借鉴的东西。
  • 北冥Master
    2018-11-30
    有时间让你写这些文档？事后补的没有太大意义吧
  • javaadu
    2018-08-24
    这些东西我们这边是开发做的
  • Zach
    2018-08-03
    二爷可否细说一下为什么不能把用户名作为主键？谢谢！

    作者回复: 因为会变

  • 追风筝的小蜜蜂
    2018-05-04
    ddd领域驱动设计无技术基础可以读吗，
  • 流星🌠火箭🚀蛋�...
    2018-01-26
    时序图经常用到，感觉对梳理流程特别有用，尤其是多系统之间协作，用例、状态图倒用的少，主要还是没理解透他们的用法与背后的思想，今天看到二爷的文章受益匪浅，感谢🙏
  • 张星彩
    2018-01-19
    用户名作为主键应该就是唯一属性时，应该不允许用户更改吧;其次如果加一个用户ID，作为唯一属性，这样就可以更改用户名了吧。想请教下两个问题，有看到知乎可以改用户名，但是180天内只能修改一次，是出于什么考虑的？还有就是什么样的数据需要有唯一属性？

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

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