“世间无限丹青手，一片伤心画不成。”——唐·高蟾
上次我们讲到了一些产品文档的模式，以及应用场合和特点，这部分内容实践性挺强的，好多人经常会到处找到一个“好的文档”模板，其实模板根本没那么重要，了解文档目的，能把逻辑表达清楚才是第一要务，只要你能表达清楚，不写文档，拍个短片也可以。所以跟我们之前说到一些工具软件一样，不要本末倒置。
今天我们接着产品文档的话题，产品文档中经常要用到各种图例，我们来介绍几种常用的图例，以及他们的功能特点。
概念模型的目的是要将产品中的业务概念分门别类的整理出来，并在同时确定概念之间的关系。在复杂业务的系统中，这一工具非常重要，它是一切业务流程的基础。
抽取概念模型的过程并不复杂，但需要一些时间，我们可以首先去尽可能详细地描述系统各种场景和逻辑，然后注意描述中的所有名词。比如我们说用户可以创建账号、设置用户名，登录系统，系统管理员为其指定一个角色。
这样简单的一句话中就包含了用户、账号、用户名、系统、系统管理员和角色等名词，我们把这些名词不断地取出来，去分析他们之间的关系。
比如一个用户和账号之间是对应关系，这是就要去确定对应方式，是一个用户只能有一个账号，还是可以有多个账号，或多个用户共用一个账号。基于这个关系，可能就能长出用户识别、同账号登录互踢或子母账号管理的需求。如果再考虑账号和角色之间的关系，可能就是一套完整的权限系统。
而有的名词可能是其他名词的属性，比如上面提到的“用户名”便是账号的属性，属性跟概念之间也会有对应关系，比如是否唯一，是否可变，是否是与其他概念产生关系的“键”等等。技术可能会据此去做系统设计。
越是基础的东西，在这时越需要谨慎设计，比如有多少系统错将用户名作为主键，导致未来有用户需要更换用户名时无比复杂（我职业生涯中至少遇到过两次）。
所以概念模型的梳理最大的作用是来回答系统的根本性问题，从而可以帮助工程师设计数据结构，也帮助业务找到设计出发点。一个产品的架构扩展潜力，很多时候就受限于概念模型的设计。比如订单管理系统在最初设计中，订单和标的之间的关系被设为一一对应，那将来要多产品搭售的时候，整个产品技术团队就会无比痛苦。
概念模型图通常是用 UML 中的类图或传统的 E-R 图的结构来绘制，突出概念和关系，去询问自己每个概念实体和另外一个概念实体之间可能有的关系。
也有人会说，这样的概念模型应该是工程师在做概要设计或数据结构设计时才应该考虑的，产品经理考虑早了点。
我不这么认为，我认为这是一个产品经理和工程师需要共同关注的地带，甚至产品经理的职责更重，因为它背后更多的是业务上的前瞻、取舍和判断。工程师在设计中会讲 DDD、OOD，进而去理解和重现业务架构模型，那产品经理就更应该把业务背后的逻辑关系抽丝剥茧整理清楚。
我们在招产品经理时会要求产品经理具备“抽象和建模的能力”，其实指的就是抽象概念模型的能力。有些公司甚至会在复杂系统中设立“业务架构师”岗位，专门做这件事情，有点像传统软件行业里的“系统分析师”。
概念模型有一点偏技术，又不是一个酷炫的东西，很难拿出来做展示，而且它的作用不那么立竿见影，所以没有得到应有的重视。但它在业务逻辑复杂的产品设计中确实非常重要，希望你动手去尝试一下，挖掘它的价值，为自己所用。
所有的业务系统都有流程，我们的文档中一定会或多或少涉及“流程图”，最基础的流程图是面向过程的描述性流程图，有些图形规范，比如开始结束是圆角矩形，数据操作是矩形，判断是菱形等等，还有些其他的一些形状代表的意思。但我很少见过真的完全按照标准格式画的，基本就用到矩形和菱形，有时为了加以区分会有颜色上的差异。
但如果流程比较复杂，涉及的角色或子系统、模块多起来的时候，传统的流程图就会开始捉襟见肘，应接不暇；所以除非描述单一功能模块内部的流程外，我一般很少会用传统流程图。而是用泳道图和时序图。
泳道图很好理解，就是在传统的流程图上加入角色，因为每个角色之间是平行的，从图上看起来每个角色就像是一个泳道。通过这些泳道去标识每个动作是由哪个角色（或子系统）做出的。这种图形一般用于比较宏观的流程描述中，比如划分各业务角色之间大的流程步骤，或描述子系统之间的边界和职能。
当进一步细致到具体的用例或方法时，则可以用时序图，时序图也是 UML 标准里面的一种图示，也是面向对象设计的一种工具，本来是工程师用，后来被产品经理借来描述业务流程。
时序图整体看起来像很多根竹签，每根竹签代表用户、业务对象、子系统甚至“时间”，凡是可以向其他竹签发出请求的都可以表示为一根竹签，而有些过程是需要定时执行的，在时序图上，我们就可以将其表示为“时间”。每根竹签向自己或其他竹签发起请求，然后响应请求的竹签则根据这个请求开始一个过程，这个过程可以是同步，也可以是异步，可以是判断过程，也可以是循环。
总之时序图可以表达的逻辑非常丰富，能将复杂逻辑梳理得很有条理，而且读图成本很低，既能一目了然，也有引导按图索骥。我有一段时间非常迷恋时序图，连项目管理中的不同角色的流程安排都用时序图表达，强烈建议你深入学习一下，把它用到你的流程分析中。
系统中所有的概念实体都应该有状态，用户有状态，订单有状态，账单也有状态。在数据结构设计时，经常会在业务对象表里加一个“状态”字段。产品经理有时不会将状态显式地单独表达出来，而是让工程师自己通过读业务逻辑去区分和判断业务对象的状态。
这样的沟通断层会产生一些风险，有时描述同一个状态用了不同的用词，导致工程师记录成了两个状态，比如前一条业务逻辑写的是“完成对账后系统进入休眠状态”，后一条写成了“完成角色更新后系统挂起”，这可能来自于产品经理的不严谨，结果系统里就出来一条没有必要的脏状态。
更吓人的是有时产品经理描述不清，导致本来应该是不同的状态，被开发理解为同一个，未来需要再做拆分时，难上加难。比如用户欠费挂起和用户到期挂起应该分开不同的状态，但产品经理在文档里都写着“挂起”，导致未来给用户开通服务的时候不知道该怎么直接从数据表里区分，还要去关联行为日志的表。
建议产品经理对于比较核心的业务对象，把状态画成状态图，每个节点是一个状态，每两个状态之间是一个行为，描述的是出发状态转变的可能。这么做还有一个好处是，可以帮助你从状态的角度出发，去穷尽所有状态之间可能的变化，保证不会遗漏用例。
上篇文章我们提到用例文档，这里我们来说说用例图。
用例图是 UML 的标准图示，看起来特别简单，一个火柴人和一些椭圆。每个椭圆是一个用例描述，然后把椭圆和人连起来。用例图复杂起来很复杂，还有扩展点，互相之间的关联包含关系等等。但开始使用它很容易，只用火柴人和椭圆就够了。
那这么简单，甚至有点蠢的图，能干吗呢？首先是可以让读者一眼看到一个产品或一个项目需要实现的用户价值，以及它可能的规模是什么；另外则是可以利用用例来组织产品文档的结构，很容易理解，也容易作为标准来管理进度。
用例图的一个老大难问题是区分用例的粒度，这是个没有唯一答案的问题，同一个人的用力粒度划分标准可能都不同。比如 CRUD （创建、读取、更新、删除）算一个用例，还是四个用例。比如“账户管理”算是一个用例，还是“账户创建”“角色分配”“账户删除”“账户查询”四个用例。这简直是个哲学问题，这么多年我也没能找到一个金标准。
我最喜欢的标准是来自一场 UML 培训，说的是“以卖点作为粒度”，也就是设想你的系统是按功能收费的，你从兜里一个接一个地往外掏用例，每掏一个用户就要付一份钱，你要保证每个用例用户都是愿意买单的，同时，又要保证用例尽量丰富，以求收到足够多的钱。
假设你现在做“极客时间”，你从兜里掏出一个“修改密码”，用户不会认为它是个卖点。但你假设你现在做的是一个复杂的金融保险系统，很可能“修改密码”就会成为一个独立的卖点，所以用例粒度划分一定是因系统而异的。
我们今天从概念模型开始，说到流程图、状态图和用例图，从表面的图讲到图背后的工具和方法，这些东西最主要的作用是可以辅助我们找到思维框架，用完整而有条理的逻辑去把一个业务描述出来。他们就像是工具箱，只有熟悉了这些工具的效用，同时又足够熟悉环境，才知道什么场合拿出哪一样工具是恰当的。
这也是产品经理的基本功，即便用不上，也不要让自己的工具箱里只有单调的几样工具，因为掌握的工具会影响你解决问题的思路，正像那句古话说的，手里拿着锤子，看起来全世界都是钉子。而这些已经被大量的前人应用和雕琢过的工具，自然带着他们的智慧，研究这些工具本身，也是一种对于经验的学习。
今天的分享就到这里，如果你有关于这些图例的具体问题，欢迎留言讨论，我们下次再见。
评论